Why Minimize Work in Progress is Important in Software Development

Many years ago, The Goal was written by Eliyahu Goldratt as a business novel to illustrate the fallacies in thinking that companies in a manufacturing world tend to have about how to maximize the profit. In this novel, the protagonist learned how to do so for his plant by applying the theory of constraints. As bottlenecks were identified and solved within a sequential manufacturing process, the flow of the whole system was improved when the group stopped optimizing for utilization, and started optimizing for flow. In this process, the team learned to keep the total work in progress to a minimum, so that as a product was started, they worked to get that piece to completion and shipped as quickly as possible. In that world, inventory was a form of work in progress and that was real dollars to be received if it was shipped.

In software development teams, we have our own form of work in progress. Everything that we spend between requirements and Released Code, is our Inventory. It represents time and dollars that have gone into the process that are not being realized in terms of value for our customers. In the below diagram, everything before Released Code is “inventory.”

This is one underlying reason why Scrum and Agile have taken hold in our software development community. Scrum in particular prescribes a batch size (a sprint’s worth of work) that represents the maximum amount of inventory the team should take on. In general, Scrum teams should have “shippable” software and that distinction between shipped and “shippable” is a compromise because our customers may not be able to accept the software at a frequency of “a sprint.”

Before software is shipped, or deployed to production, represents an expense to the company. Consider the following two cases, one is an agile team, and the other is a waterfall project:

Waterfall Team (18 Month Project, 15 team Members)

  • Requirements Team (3 Members Each Making 80K/Year, 5 Months of Work): $100,000
  • Development Team (8 Members Each Making 80K/Year, 9 Months of Work): $480,000
  • QA Team (4 Members Each Making 80K/Year, 4 Months of Work): $106,666

    In whole, the company has $686,666 of inventory. And if this is a general standard operating practice, they are continually (just in IT) maintaining that much inventory on the books (that’s equivalent to having that many products sitting in a warehouse and not being sold).

Scrum Team (18 Month Project, 15 Team Members (there are two teams)). Below is the amount of inventory the company is holding onto, assuming deployments every two weeks. Assuming maximum amount of inventory below (last day of the sprint).

  • 15 Cross Functional Team Members (2 Weeks of WIP): $46,153

Two scrum teams at any given point have six (6%) of the total inventory being maintained. They then ship their software, and the company can realize value from that software much sooner in the process of building that product. Of course there are caveats here in that a software development product must have a minimal viable product, which is assumed to be less than the total scope. Whenever the scrum teams meet that MVP, the company can start transitioning some of these costs into capital expenditures.

This is not true just of Scrum teams, but teams that apply Lean principals and rely on Kanban boards and release continuously also are taking advantage of the significant savings possible in in this world. Rather than measuring a fixed batch size, they are in fact measuring lead time and time to resolution. Either way, the company again is realizing the value much sooner for their efforts.

So we work to get the boxes out of the warehouse and into the customers hands sooner.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

2 thoughts on “Why Minimize Work in Progress is Important in Software Development