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.


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.

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

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

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!


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.

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.

Twiitter: @arlenemink

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 21nd. 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

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.


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?
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
Thomas M. Cagley Jr.

Audion version can be found on SPaMCast 43 (

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.