Jul 162015

If you’ve been following my series of posts about ALM, you know that the Lean concept of flow is one of ALM’s two central pillars. (The other is alignment, an indicator of the likelihood that the software organization is delivering value.) Whenever I talk about anything related to Lean, I’m always a little nervous. People misinterpret Lean frequently, with highly destructive consequences, so putting a Lean frame around ALM is almost asking for trouble.

The most frequent distortion of Lean that I’ve seen in software development is the following syllogism:

  1. Lean tells us that we should reduce waste.
  2. Unused capacity is a form of waste.
  3. Therefore, we should maximize the utilization of our capacity.

To use language that’s more meaningful to software professionals, the terrifying conclusion is, if you’re not working 100% of the time right now, be afraid that you’ll be laid off soon. While that’s a dispiriting conclusion for individuals, likely to lead to lower morale and lower productivity as a result, there are other reasons why this is a wholly counterproductive strategy, likely to result in less value delivered, not more.

Without getting into a detailed discussion of queuing theory (see Donald Reinertsen’s book Managing The Design Factory for a good overview), suffice it to say that software development and delivery presents a queuing problem that requires excess capacity for a solution. We can never completely predict how long it will take for us to be ready to start a new work item. The bigger the work item is (say, an enterprise application implementation instead of just a bug fix), the more complexity it has, and the greater the odds that it will take longer than expected to get all the pieces in place. We lack complete requirements at the beginning — in fact, an ongoing, in-flight learning process is a hallmark of software innovation — so we can’t know for sure how long the work will really take. The unknowns don’t completely disappear after we deliver the software, so we have to expect some “after-market” adjustments.

Taking these realities of software innovation together, you can see how futile it is to try to manage software development the way that you might manage a team of people scanning paper documents, washing cars, or selling hamburgers. If you don’t build slack into the system, we’ll never be able to adjust to these unknowns. We won’t be able to finish the work we started, make mid-course corrections to meet that goal, or start the next project when we’re supposed to. By making everyone maximally busy, we will have made the organization less productive, not more.

If someone to whom you are explaining this principle still does not understand, you might try this approach. In real life, we don’t operate things to maximum capacity. If there were no speed limits, we still would not drive at the maximum speed that our cars would permit. We would dramatically increase the risk of accidents, and we would be inflicting a lot of wear and tear on the machinery. We need excess capacity — in this example, speed — so that we can swerve around potholes, lower the probability that we will miss the off-ramp, and avoid flipping the car if one of the tires blows out. Software organizations are no different than cars, except that the number of unknowns is drastically higher. Imagine instead that you’re driving on some Max Max-like hellscape, with debris all over the road, no clear signposts to help you find your destination, and no help if your car breaks down.

Therefore, when we talk about maximizing flow in ALM, we’re trying to reach the sweet spot at which we are positioned to create value than we used to, without stressing the machinery of software innovation to the point where it cannot reliably deliver results. Fretting over every possible efficiency gain that we haven’t implemented, or scrutinizing people’s work schedules to see if we can keep them busy all day, is not only pointless, but counterproductive. ALM seeks to maximize the reliable flow of value over time, not drive the organization at top speed until it drives into a tree.

[Editor’s Note: Tom Grant brings his expertise in utilizing ALM to maximize the flow of your software value chain to his upcoming webinar “Create Software Innovation with Application Lifecycle Management.” Sign up now.]


Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>