SPaMCAST 492- Murali Chemuturi, Software Design

http://www.spamcast.net

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Software Process and Measurement Cast 492 features our recent interview with Murali Chemuturi.  Murali and I discussed his new book tilted Software Design: A Comprehensive Guide to Software Development Projects (Link https://amzn.to/2qMAgKW).  Murali makes a strong case that design can’t be purely emergent.  Design impacts usability, security and data architecture to name just a few areas. Practical advice and strong opinions.

Note Murali and I co-authored Mastering Software Project Management (buy a copy!) https://amzn.to/2F5LWxB).

Murali’s Bio

Murali Chemuturi is an information technology and software development subject matter expert, hands-on programmer, author, consultant and trainer. Since 2001, he is offering consultancy on information technology and training to organizations in India and USA from Chemuturi Consultants. Chemuturi Consultants also offers a number of products to aid project managers and software development professionals such as PMPal, a software project management tool; and EstimatorPal, FPAPal & UCPPal, a set of software estimation tools. Chemuturi Consultants also offers a material requirements planning software product MRPPal to assist small to medium manufacturing organizations to efficiently manage their materials.

Web: www.chemuturi.com

Email: murali@chemuturi.com

Re-Read Saturday News

In week seven of the re-read of L. David Marquet’s Turn the Ship Around! we begin Part 2 of the book and tackle chapters 8 and 9, titled Change, In a Word and Welcome Aboard Sante Fe.

Current Installment:

Week 7: Change, In a Word and Welcome Aboard Sante Fe –https://bit.ly/2r5l1hk

 

SPaMCAST 466 – Ross Smith, Legacy Application Modernization

http://www.spamcast.net

 

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 466 features our interview with Ross Smith.  Ross and I discussed legacy application modernization.  Legacy application modernization delivers quantitative and qualitative value to organizations. Modernization can breath new life into old applications.  We also discussed why organizations sometimes avoid biting the modernization bullet!

Ross Smith is Chief Architect at PITSS America.  He has been on the PITSS team for five years, a time during which the company transformed from an Oracle Forms upgrade vendor into a business process and application transformation provider.  He recently spoke at Oracle Open World about the untapped potential of leaving vital legacy applications out of a digital transformation strategy, and the realities of integrating them into a modern enterprise environment.

Email: rsmith@pitss.com
Web: https://pitss.com/
Linkedin: https://www.linkedin.com/in/ross-smith-5427497

I am participating in the Agile Online Summit
30 Oct – 3 Nov 2017
At the summit, I talk about the power of storytelling with Tom Henricksen!
⇒ Register

Metricas 2017
I will be keynoting on Agile leadership and delivering one my favorites, Function Points and Pokémon Go
29 November 2017
Sao Paulo, Brazil
⇒ Register

Re-Read Saturday News

This week we re-read Chapter 2 of Actionable Agile Metrics for Predictability: An Introduction by Daniel S. Vacanti. Chapter 2 is titled The Basic Metrics of Flow. We go deep on WIP, Cycle TIme and Throughput.  Powerful metrics that every team needs to understand and leverage.  Buy your copy today and read along!

Previous Installments

Introduction and Game Plan

Week 2: Flow, Flow Metrics, and Predictability

Week 3: THe Basics of Flow Metrics

 

SPaMCAST 445 – Capers Jones, Selecting Software Metrics

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 445 features the return of a favorite, Capers Jones.  It is always fun to talk with someone with their own page in Wikepedia.  Capers and I talked about his new book, A Guide to Selecting Software Measures and Metrics. Capers is passionate about software quality and measurement. Capers said, “High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership.” from The Economics of Software Quality.  As usual, Capers was engaging, educational and controversial.  Spending time with Capers is always a learning experience!

Capers biography is long and storied.  Let it be said that Capers is a serial author, public speaker, pundit, guru and deep thinker.  Check out his Wikipedia page or Linkedin.

Capers can be contacted at capers.jones3@gmail.com.

Capers first appeared on SPaMCAST 3 and  last appeared on SPaMCAST 53

Re-Read Saturday News

This week we tackle Chapter 7 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 7 shows how to generate alignment between roles, circles, and the overall organization.  Lots of inspect and adapt talk this week.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 446 will feature our essay on questions.  Questions are a coach and facilitator’s secret power!   Do you have a favorite go-to question you like to ask?  Care to share?

We will also have columns from Gene Hughson and Jon M Quigley (and maybe more)!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

 

SPaMCAST 438 – Size for Testers, Organizations as Systems, Problem Solving

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play MusicListen Now

The Software Process and Measurement Cast 438 features our essay on leveraging sizing in testing. Size can be a useful tool for budgeting and planning both at the portfolio level and the team level.

Gene Hughson brings his Form Follows Function Blog to the cast this week to discuss his recent blog entry titled, Organizations as Systems and Innovation. One of the highlights of the conversation is whether emergence is a primary factor driving change in a complex system.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses why blindly accepting canned solutions does not negate the need for active troubleshooting of for problems in software development.

Re-Read Saturday News

This week, we tackle chapter 1 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Chapter 1 is titled, Evolving Organization.  Holacracy is an approach to address shortcomings that have appeared as organizations evolve. Holacracy is not a silver bullet, but rather provides a stable platform for identifying and addressing problems efficiently.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Alex Yakyma.  Our discussion focused on the industry’s broken mindset that prevents it from being Lean and Agile.  A powerful and possibly controversial interview.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

SPaMCAST 359 – Reviews and Inspections, Independent QA, Improvisation

http://www.spamcast.net

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast features three columns.  The first our essay on Reviews and Inspections.  Reviews and inspections are a critical tool for improving quality and team effectiveness. Whether you are using Agile or classic techniques improving your reviews and inspections will directly increase the value you deliver.

We also have a new entry in the QA Corner with Jeremy Berriault.  Jeremy and I discussed the value of independent QA.

Anchoring the cast is a new installment from the Software Sensei, Kim Pries. Kim contrasts planned activities and improvisation in software development.  Kim builds on the differences in the two approaches to help teams to understand when to do either.

Call to Action!

For the remainder of September let’s try something a little different.  Forget about iTunes reviews and tell a friend or a coworker about the Software Process and Measurement Cast. Let’s use word of mouth will help grow the audience for the podcast.  After all the SPaMCAST provides you with value, why keep it yourself?!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing.  This week we tackle the essay titled “The Documentary Hypothesis”! Check out the new installment at Software Process and Measurement Blog.

Upcoming Events

Software Quality and Test Management
September 13 – 18, 2015
San Diego, California
http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams.  Let me know if you are attending! If you are still deciding on attending let me know because I have a discount code.

Agile Development Conference East
November 8-13, 2015
Orlando, Florida
http://adceast.techwell.com/

I will be speaking on November 12th on the topic of Agile Risk. Let me know if you are going and we will have a SPaMCAST Meetup.

More conferences next week including Agile DC and Agile Philly!

Next SPaMCAST

The next Software Process and Measurement Cast will feature interview with Steve Boronski. Steve and I had a great conversation about Agile and Prince2. The conversation focused on the new Prince2 Agile Project Management Best Practice extension to Prince2 and why the world needs another interpretation of Agile project management.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

SPaMCAST 350 – Arlene Minkiewicz, Technical Debt

http://www.spamcast.net

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 350 features our interview with Arlene Minkiewicz. Arlene and I talked technical debt.  Our discussion included the definition of technical debt, a set of philosophies for technical debt and perhaps a few solutions. Regardless of philosophy or approach, a little technical debt goes a long way!

Arlene F. Minkiewicz is the Chief Scientist at PRICE Systems, LLC with over 30 years of experience at PRICE building cost models.  She leads the cost research activity for TruePlanning, the suite of cost estimating products that PRICE provides.  She is a software measurement expert dedicated to finding creative solutions focused on helping make software development professionals successful.  She is widely published and speaks frequently on software related topics.  She has a BS in Electrical Engineering from Lehigh University and an MS in Computer Science from Drexel University.

Email: Arlene.Minkiewicz@PRICESystems.com
Twiitter: @arlenemink
Website:  www.pricesystems.com

Call to Action!

I have a challenge for the Software Process and Measurement Cast listeners for the next few weeks. I would like you to find one person that you think would like the podcast and introduce them to the cast. This might mean sending them the URL or teaching them how to download podcasts. If you like the podcast and think it is valuable they will be thankful to you for introducing them to the Software Process and Measurement Cast. Thank you in advance!

Re-Read Saturday News

We have just begun the Re-Read Saturday of The Mythical Man-Month (buy it here to support the blog and podcast). We are off to rousing start beginning with the Tar Pit. Get a copy now and start reading!

The Re-Read Saturday and other great articles can be found on the Software Process and Measurement Blog.

Remember: We just completed the Re-Read Saturday of Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement which began on February 21^nd. What did you think?  Did the re-read cause you to read The Goal for a refresher? Visit the Software Process and Measurement Blog and review the whole re-read.

Note: If you don’t have a copy of the book, buy one. If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Upcoming Events

Software Quality and Test Management 

September 13 – 18, 2015

San Diego, California

http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending!

 

More on other great conferences soon!

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on distributed Agile. Distributed Agile is not just Scrum and other Agile techniques over a distance.  As distribution and cultural diversity increase what worked for a co-located team will often fall short.  We will identify solutions next week!

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

What Is a Framework?

While I was attending a recent conference I heard the term framework used at least five times in five different contexts in the span of one morning.  Software development frameworks are a scaffold for developing, maintaining and enhancing software. Values and principles help shape the framework so that specific types of techniques and practices fit into the scaffold.

All major buildings begin with scaffold into which all sorts of things like windows, rooms and the façade are added.  The scaffold will only hold the parts it has been constructed to hold.  Just think of tacking the façade or windows of the MOMA in New York onto the Chrysler Building.  The result of that mess would not be fit for use.  The scaffold of the building was influenced by the values and principles that the architects chose to express in their creative vision.  Software development frameworks have the same architecture; a scaffold shaped by values and principles. For example, Scrum is a framework that is molded by the principles and values set forth in the Agile Manifesto. The CMMI© is also a framework.  Goals which embody values and principles govern each process area in the framework.

There are numerous frameworks to develop, maintain and enhance software. A framework provides a structure for software developers to create or maintain software using a set practices and techniques that fit into the framework. A framework provides a blueprint to guide you you while building software. The techniques and practices you use to fill in the scaffold define how you will build.

 

Manufacturing, Engineering or Craft?

Manufacturing, Engineering or Craft?
By Thomas M. Cagley Jr

Audio Version in SPaMCAST 181

A few weeks ago I sat next to a gentlemen on a flight to Albuquerque. After talking through a couple of glasses of wine we found we were in related fields. As the conversation progressed he confided in me that he did not understand why software projects were never on time, never on budget or never exactly what he wanted — since software development was engineering and he’d been told by his consultants that development was like a factory. I paid for the next round of wine as I tried to persuade my new friend that building, enhancing or maintaining software was not really like assembling a car.

Why has the manufacturing model as a metaphor and therefore the ideas of Fredrick Taylor been so firmly entrenched in IT? In reality, is IT a creative model (science or craftsman) or a manufacturing model (assembly line) more accurate in describing the behavior required to deliver value from development? Which metaphor is more predicative? If we introduce the term software engineering, does the use of the word, engineer complicate how IT personnel are perceived? Does the perception create a set of expected behaviors for software development and maintenance personnel that makes it harder to deliver value than it needs to be?

I have been always hard-pressed to buy the factory / manufacturing mode. I have worked on an assembly line. One of the jobs I had was building tires for Firestone Tire and Rubber Company at their plant in Memphis. That job was one of the reasons I made sure I went to University. Building tires is interesting from an engineering point of view. Tires are built shaped like a barrel with sheets of rubber and other components layered on each other, based on a specific design or recipe. In the end, the recipe metaphor might be the most appropriate as in the end they cooked and molded into the shape we know. Every specific type of tire follows the same set of steps. Any thoughts of creativity in the process are erased by the second tire you “make.” How can the metaphor of manufacturing model be used in software development, maintenance or enhancements where creativity and art are needed to deliver a solution?

One of my hobbies is craft brewing beer. Craft brewing starts with a recipe that specifies the amount of grains and hops to be used, approximate boiling times and a schedule for adding the hops as the process progresses to which is added elbow grease. As all brewers know, going from being a novice to something more, they begin to modify and tailor their recipes to meet their individual tastes. While operating within the basic recipe and laws of both chemistry and biology (brewing is cool), the brewer acts as a craftsman rather than a simple cook or assembly line worker.

I would suggest that a better analogy for software development is a scientific or engineering craftsman which mirrors my experience in craft brewing.

Words and names are important because they frame the questions that will be addressed. An engineering project begins with an idea, just like any other project. From the idea requirements are created and followed by the transformation of those requirements into something of value based on the physical laws and material tolerances. Projects following an engineering pattern include building a bridge or building a computer. The outcome of these types are predictable (assuming no major mistakes). When you build a house you generally pay a fixed price based on a fixed set of requirement. A builder is expected to answer, with high precision, the questions of how much the house will cost, when it will be completed, and when it will be delivered. When dealing with a craft or art, the answers to those questions are generally much fuzzier. While an artist might give you a fixed price for a portrait of your family the true cost, margin, and delivery date are far less predictable if for no other reason than the interplay between human, tools, and suppliers is more chaotic. Computers do not create great art . . .humans do.

So why does this discussion matter? Hasn’t this been debated many times over the years? Why does the model you leverage to describe IT matter? It matters because it sets expectations. If we use the manufacturing model why shouldn’t we expect to provide firm fixed prices? In manufacturing we should know when we can deliver the product. We should understand all the requirements from beginning of a project. In many cases the exception would be that we are delivering a product that we put on the shelf or that we assemble from known parts. This might be true if we were buying a vanilla commercial-off-the shelf product like Microsoft Office or SAP. If using an engineering metaphor, our processes will be based on the physical laws of nature and/or material science to describe how things are to be built. Examples include building a computer or standing up a set of servers. At its base, engineering is deterministic (x + y = z . . . every time). If developing or maintaining software were an art we would have very different expectations on whether we could predict the future (cost, quality, and delivery). A creative process that actually is far more chaotic and less deterministic.

Reality suggests that developing systems, enhancing systems, and maintaining systems are human dominated activities which are less than perfectly deterministic; therefore, they have at least some “craft” involved. I’m not suggesting that software development, enhancements or maintenance are art but rather a combination of science, engineering and craftsmanship.

 

Compound The Interest In Process Improvement

Compound The Interest In Process Improvement
Thomas M. Cagley Jr.

Audion version can be found on SPaMCast 43 (www.spamcast.net)

Sometime near the beginning of process improvement time W. Edward Deming documented his 14 Points for Management. One of those points struck me as I reviewed the course of software development and process improvement. The principle in question was constancy of purpose. Controlled changes are hard for many reasons but not staying the course once you begin a change is tops on my list of mistakes. Change usually begins with great fanfare and acclaim. Over time, events intervene (the famous stuff happens) which diverts attention and resources. Deming suggested that for change to have a positive impact, management needs to have constancy of purpose. Stated another way management must stay the course. This is not stay that once started a change program can never be modified, changed or abandoned. They all must evolve to meet changing needs but generally needs change slowly (unless financial derivatives are involved).

A time comes in every process improvement program or new development methodology deployment when interest wanes and the perceived value begins wane to a degree that something new begins to be planned. The point at which planning for the next big thing starts is a tipping point that marks the half-life of the process change. Every change has a half life. Your job as a leader is to extend the time it takes to get to the tipping point in order to maximize the value derived from any individual change. Keeping your customers interested in your program is a crucial tactic to delay the investable tipping point.

So who is responsible for stoking the fire of interest? Simply put the person or persons that are managing the change program. The role of maintaining interest is a blend of cheerleading, sales and guru-dom. Many process improvement leaders believe these tasks are beneath them therefore assign a staff member or decide that the purity of their vision should be enough to ensure movement toward the bright light of the future. That bright light in reality may well be the light to be an oncoming train. Quoting Colin Powell, “Leadership is solving problems. The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership.” Interest is your problem, your roles is to lead.

One of the reasons interest wanes is that other events overtake the initial burst of energy and rational. Without someone to act as a town crier, memory fades. You must refresh both managers and practitioners’ memory as to why the change is important, what the change is, what is in it for them and what pain the change seeks to solve. A coherent story requires that you have a good handle on why you are doing the project.

You must understand the pain you are trying to solve not just what you are going to deliver (one tends to be a reflection of the other). I suggest that to effectively communicate, begin by crafting a message around how you are solving your client’s pain. Then measure the results you are delivering to prove you are actually delivering on the promise of your solutions. Finally, talk to your clients (management and practitioners) about how you are solving their pain (at the same time validate that the bar has not changed). I also suggest soliciting testimonials from your clients. Testimonials coupled with your message are excellent tool support continued change.

Why is interest important? A lack of focused interest is a risk because the IT landscape can be described as needs chasing resources while the resources get squeezed putting process improvement personnel and process improvement budgets are at risk. Salespersonship and marketing are critical roles when managing a process improvement project. These talents and roles support both the initial process of making a change and also when you are sustaining a change. Recognize that like skin moisturizer, sales and marketing can extend the life of change program only if applied early and often. Further the program you are trying to focus interest on must deliver value. Your mission is not only to be a leader but a cheerleader, salesperson and a communicator.