This is the first in a series of blogs on the topic of Lean Economics, emphasizing the economic aspects of product development.
I have a friend who once emphatically stated “Agile will never work at my company because we have more projects than people! Everyone here works on 5 or 6 projects at the same time. It’s important to show some progress on all efforts to keep everyone happy.” Do you have firsthand experience being in this situation? I’ll share my response to him at the end.
The concept of Work In Process (WIP) – also called Work In Progress – comes from the world of Lean manufacturing. In Lean manufacturing, WIP is considered a form of inventory – the materials that are currently being worked. As such, it is actually considered “waste” because it ties up cash. That’s right – WIP is waste! It needs to be reduced.
Effective Use Of WIP
Effective use of WIP is when the team takes on a small amount of work, focuses on it, and works it to completion in a short period of time before pulling any additional work. This approach enables a consistent flow of value from the team (as indicated in the diagram below) and is considered much more desirable than context switching across multiple efforts in parallel.
Warning Signs You May Be Ignoring Lean Economics
Warning signs that you might not be considering the economics of product development include:
- Many things started, but very little finished recently
- Heavy multitasking
- Costly context switching
- Slow, painful deliveries
- Lack of accuracy when predicting delivery scope and dates
- Low product quality and constant rework
All of these add up to a very frustrated team overloaded with work that just seems to never get completed. Reliance on “heroes” is the norm. Overtime is rampant. Customer satisfaction is dropping. Stakeholders are screaming. We scream back: “We need more people!”, or better yet “Please just let me focus on one thing at a time!”
What is a WIP Limit?
The amount of work occurring at any one time is “limited” to what the team can accomplish in a short period of time and established by a constraint called the WIP limit.
A great description of the economics of WIP is described in Donald Reinertsen’s seminal book The Principles of Product Development Flow. At the time of this writing in 2008, less than 1% of all product development teams were managing WIP constraints. With the success of Agile methods and a renewed focus on the economics of product development, this number has improved greatly over the past years.
Most teams use a default WIP limit according to the available capacity of the team and what makes sense for the effort at hand. Development teams can set their WIP limits for the number of user stories (or tasks) in work at any one time. This WIP limit can provide opportunities for pairing and cross-training.
A Program Management team may have a WIP limit for the number of features being researched, the number of features ready for development, and the number of features currently being deployed. As you move into higher levels of planning in the organization, from individual programs to whole portfolios of programs, executives and business owners may have a WIP limit for the number of business cases being developed, the number of initiatives being considered for funding, and number of initiatives in development at one time. This level-by-level WIP approach helps to create an alignment of available capacity to the demand, and also provides a very important visible indicator as to what initiatives are truly being worked on and even more importantly, which ones are not!
Who sets the WIP limit? WIP limits are determined by the teams involved in the work at their respective level (team, program, or portfolio). Thus, team members at each level need a basic understanding of Lean economics and how adjusting the WIP limit can impact the flow of value – both positively and negatively.
What is the Right WIP Limit?
A WIP limit that is too small will result in idle workers and minimal flow of value. A WIP limit that is too large will result in delayed delivery and increased average cycle time (time from work starting until done). A WIP limit that is “just right” will result in optimized value flow and predictable delivery cycles. Often times finding the optimal WIP limit takes a bit of trial and error.
WIP limits can be adjusted from time to time in an experimental attempt to drive even higher levels of value. For example, an Agile team of 7 developers may adjust their “in work” user story WIP limit from a default of 7 down to 3 to ensure that a healthy amount of “swarming” is occurring on the highest priority user stories committed for the iteration. This supports the concept of demoing stories to the Product Owner as early in the iteration as possible and the possibility of continuous deployment. WIP can also be adjusted downward to account for the typical vacations and personnel outages that teams experience.
Visualizing WIP
WIP limits can be applied as work flows through the different stages of development. A common team-level storyboard example follows with WIP limits indicated in the appropriate columns. These WIP limits cannot be exceeded, forcing team members to consider helping others in pursuit of the larger goal of getting a user story to Done over beginning a new one.
Teams at the program and portfolio levels use the same technique with their specific column names and WIP limits.
What’s the Big Deal?
Applying WIP allows us to “stop starting, and start finishing”. Some advantages of WIP and the use of WIP limits include:
- Improved flow of value through your team pipeline
- Productivity gains due to less context switching
- Ability to focus
- Identification of bottlenecks and waste – leading to subsequent remedy
- Improved cycle time
- Promotion of cross-training and less reliance on “heroes”
- Encouraging a focus on quality!
Conclusion
Now, regarding my friend’s comment about working 5 or 6 projects at once – I used the left hand portion of the first figure (“Working on many items in parallel”) to explain that his approach was making some progress on many things, and every time period check would hopefully show an adjustment in the horizontal progress bar. I deemed this approach “moving yardsticks” instead of truly completing work. In the end, all (yes, all) of his project stakeholders will end up disappointed to varying degrees. I then explained the tremendous cost of context switching across multiple efforts (ref: Quality Software Management: Systems Thinking). I also pointed out that his leaders were suffering from an unwillingness to make tough prioritization decisions, and that this often requires a cultural change at the leadership level – stay tuned for future blogs in this series discussing these concerns.
After a few more (lite) beers to let it all sink in, I explained the good news – there actually is a much better way! Organize all of the work into a single team backlog. Prioritize the work such that single features/stories can be worked to completion and context switching is reduced. Apply WIP limits at all levels (team, program, and portfolio) to ensure a healthy flow of value through the team’s work pipeline. And then say goodbye forever to unmet expectations!