Why you need WIP limits

Why is this crazy person telling me to limit my WIP?

As an agile coach I often come across situations where I need to encourage teams to reduce the amount of work they have in progress. Even though it sounds and feels counter intuitive to do less work, the fact is your team will get more DONE by doing fewer things at the same time.

Activity != Progress

In our scrum teams we naturally tend towards keeping everybody busy. Developers working on development tasks, testers working on testing tasks. History has skewed our mental model of what people should do at work so that we feel like we should always be busy, always processing work. 

This is a good model for the mass production of widgets or the processing of mountains of paperwork BUT a bad model for the production of complex, functional, high quality software.

We use user stories to represent units of complex, functional, high quality software and in scrum the game is to finish a number of these units every sprint. This goal is often overlooked in favour of keeping team members busy. As long as everyone is busy we will eventually deliver the user stories. This is possibly true but they will be delivered in an inefficient and unpredictable manner.

You are slowing your team down by not limiting WIP

What do you mean, how can I slow my team down by working harder on more stuff?

Well you are the guy who is so good at building car doors, that you have focused yourself solely on the optimization of your work for the creation of car doors. This results in the creation of many, many car doors BUT doesn’t deliver any completed CARS from the production line and now if you look around, the factory is full of the car doors and the stockpile is slowing your work colleagues down. They are tripping over doors and themselves. You are increasingly spending your time managing piles of doors, stacking them, shipping excess doors to storage, retrieving them when they are needed and we as a team are still not shipping any finished cars.

My previous blog post on this topic described how we favour working on our areas of specialty (dev & test) and how this results in teams starting more work in order to serve our specialisms.

http://his-scrum-masters-voice.blogspot.co.uk/2014/05/moving-beyond-tasks.html

This works well to keep individuals more productive (or at least occupied for more time) but it doesn’t work well for helping a team to deliver its user stories to DONE.

Instead of continuously creating car doors (pulling new user stories in order to perform new development tasks). What if the car door guy builds a limited number of doors? Just enough to keep the team going for a while. Then instead of building more doors, he stops. He is now “idle”. We don’t like “idle” time, we’ve been trained historically to fear “idle” time. However idle time (or slack time) is crucial if we want to ship any finished products.

How can we go faster when people are idle?

This goes against all your instincts. Team members should be busy. Developers should be developing. You need to change your instinct to read “Teams should be delivering finished work”.

Optimize your ways of working for teams finishing user stories, not for individuals finishing tasks

When car door guy creates just enough car doors to keep the team moving then stops creating car doors he doesn’t sit around being idle. He is a good worker, he wants to do good work and he wants his team to be successful.

His first instinct is to tidy his work-area. This means he will be faster and more productive when he next comes to build more car doors. His previous inventory of car doors is no longer cluttering up the production line. His colleagues are free to do their work more productively. We don’t need to transport car doors to/ from the store room. We have saved ourselves a lot of time and hassle purely by ensuring car door guy is doing less car door building. This is not to say we don’t value his work. We need car doors, we can’t build cars without them but once we have sufficient car doors to keep us going we have other work to focus on as a team.

Once the car door production area is spick and span, car door guy looks around for something else to do. He is really good at making car doors, but the team has blocked him from creating more than is needed. What should he do? He wanders over to his colleague further up the production line and asks if he can help in any way. He doesn’t feel like he can help much given that his skillset is only in the making of car doors. The team encourage him to work with a colleague and learn how to attach his car doors to car bodies. Car door guy expands his skillset and we are one step closer to having finished cars

By limiting WIP team members will frequently be blocked from starting new user stories simply to serve their specialisms. This is a really good thing. It will result in a number of new and wonderful behaviours.

• Team focuses more on the completion of finished products/ user stories (not just dev/ test tasks)
• Individuals stretching their boundaries and learning new skills. (developers helping with testing, test automation, learning new programming skills/ languages outside of their main specialism)
• Less waste and unfinished work in the system, means we can ship finished work faster
• More refactoring and automation

Stop starting – start finishing

Once you’ve finished your stories you can play some more. Don’t pull in new stories before you finish your current in-progress stories and don’t pull in new stories if you still haven’t met your sprint commitment. Finish  the things you start before you start more things, it makes sense right?