(It’s been a long time since I have posted. I’m back at it now!)
I have seen a common thread all through my career. A problem experienced seemingly everywhere, at all levels, including with myself. This problem causes all sorts of dysfunctions and symtoms, from frustration and poor quality to wasted effort and missed deadlines. It’s a hard problem to solve because most of our cultures, individual to large corporations, are counter to the solution.
The problem is trying to do too much. A solution is limiting work in progress.
Limiting WIP
This is a concept usually connected with Lean and Kanban. The idea is that work in progress (WIP) is a liability, it is “inventory.” As such WIP represents costs expended without yet realizing value. Therefore limiting the amount of WIP makes sense from a cost perspective. And it is more than that.
Problems from unlimited WIP
I have a wife, children, work, hobbies, volunteer projects, church, community events, etc. that I like to participate with. My ability to pay attention and build any one of these areas suffers if I try to do all of them at once. For example, my wife dislikes my habit of checking my phone during our date night evenings. And she is right!
Many companies and even clubs or other groups take on too many things. For example, that $500,000 contract was too good to pass up, but now the $5,000,000 project is late. Other effects include:
- Employee and personal burn out.
- Expectations of constant over-time by executives and developers.
- High levels of interruption and context-switching.
- Low quality by taking short cuts because there is so much other work to do.
- Stale features, half-developed that clutter code and minds.
- All the requirements are top priority and all must be in the release or product.
- More meetings to coordinate sharing of people between more projects.
- And many other bad things.
Scrum and unlimited WIP
Scrum teams also suffer from situations of unlimited work in progress. There are, of course, the issues of interruptions from outside the team and Sprint which are an organizational symptom. Even if such external issues are not present, unlimited WIP in the team can happen:
- Sprint Planning with stories written such that each team member has stories assigned specific to their individual skills.
- Defining stories that take the entire Sprint to complete.
- No one has time to help team mates with difficulties.
- At the end of the Sprint all or most of the stories are started but few are actually done.
Limit WIP
Simply creating limits on WIP, the number of items allowed to be in process at one time, helps to solve these issues. If I choose my personal projects carefully I can more deeply enjoy the things that really matter. Organizations that discipline themselves to limit work in progress create a culture of focus and urgency. Teams that “swarm” on stories and make sure Sprint items get done before taking on more work find higher quality, better team cohesion and increased ability to get work done.
How do you sent limits?
Empower yourself and people who you work with to say no. For example, the VP does not have the right view and information to know if his “little side job” is really as little as imagined nor the knowledge to know how such a diversion will effect the larger projects. The developer should be allowed to decline and have that answer stick.
Teams need to decide how many stories in a Sprint can be started but not done. And they need to stick to it, getting things done before starting something new.
Most important, you will find that setting WIP limits will reveal problems. Stories will not get done and instead of just starting the next story the team will have to figure out and address why current stories in progress are not done. Organizations will see opportunities go by and will have to figure out which are the most important and what is really needed to support more projects instead of just saying yes and delivering late. This is all good!
WIP limits are a powerful tool for uncovering places of improvement and finding the correct focus. Use them, apply them, learn and grow from them. You really can do more by forcing yourself to do less all at once.
That is a new way of viewing WIP for me, which is normally stock on a floor, people in a queue or papers in a try.
Hi Alan,
I would like to republish your post (which examines a very unique topic on Scrum) under the Scrum Category on PM Hut ( http://www.pmhut.com ). Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.
I think your post will be very beneficial to PM Hut readers…
Thank you! I will contact you by email to get this done.