Limiting Work in Progress and Scrum

WIP and Kanban are things that I hear about more and more every day and it's worth noting that I'm personally a big believer in both. Let me tell you a little story...

Background Story

My first tech job was building and configuring enterprise servers and racks in a lab (or a factory depending on your definition). It was a blast because of all the neat toys that I got to play with but it was not without problems. 

You see, we sucked. Specifically, we sucked at getting things done in a timely manner.

At least by my estimation we sucked, I was only a 22-year-old kid at the time though so it seemed possible that I wasn't seeing the bigger picture, but I thought we sucked at making things with anything even remotely resembling efficiency.
As time went on, I started making notes of some of the things that I thought were strange. We were constantly running out of floor space, so we couldn't start new orders and Techs spent nearly 10% of their time waiting for new orders to be brought in for them to work on. At first I thought these two problems should be mutually exclusive, if we've got so much work in front of us that we literally can't fit in the space anymore, then how can we not have anything in front of us to work on?

The Problem

As it turns out the problem was simple, a rack is put in front of me, I start building it and run into a problem that I can't solve on my own. I then have to make a call to somebody else to fix it and move on to whatever is next because it's no longer my problem. Before you know it, everything on the floor is waiting for some magical fix that I can't provide, there's nothing left for me to actually do and so I sit on my hands and complain that I can't get anything done.
This was all an intellectual problem for me until I was put in charge of a team that was failing, even by our already low standards. My new team generally got smaller orders, which meant we had more opportunity to get blocked on any one of them, which played a big part in our abysmal performance.

The Solution

I went about the business of fixing this in the only way I knew how: by being loud and annoying (that's what 22 year old Sean did). There were five of us on the team, so I declared that we would only bring 5 orders into our area. We can be working on fewer than 5 orders but at no point do we put a 6th order in front of the team and I got loud and annoying when anyone tried to do otherwise.
This pushed the other side of things, when an order became blocked it became important to unblock it so that we could really finish it and move on. Sometimes it was painful. Really painful. Really Really Painful. A second order became blocked and it was unbearable.

What happened was that when an order became blocked I would pull the tech working on it to whatever I had my hands on, shot off an email and if I didn't hear back within 10 minutes I went on a manhunt. I didn't send emails asking for a solution twice, I didn't wait all day, and I didn't make phone calls. If my order was blocked and you were the person that could unblock it, I was at your desk, or at your boss's desk, or your boss's boss's desk and I didn't leave your side until I had a solution. Generally I made my loud and annoying presence known until I got what I wanted (which is what everyone wanted but was simply inconvenient to provide). Needless to say, I caught a little bit of heat for this behavior, but luckily my team had become the single most productive (and profitable) on the floor because of this and it's hard to argue with the scoreboard.
You see what happened over time was that my team spent less and less time getting hung up on random issues and more and more time actually building stuff since we weren't spread over tens of orders. Over time my little forays also became less and less frequent as well since it became obvious that I was going to bug the crap out of anyone that held up my team for more than 10 minutes. What happened is that the business actually learned how to become more efficient at providing for the team.

How it Applies to Scrum and Software Development

This was before I had heard of the magic of limiting Work In Progress or Kanban or really any of these, it just seemed like a logical solution for a random problem I had encountered.

So why does this apply to software development?

While your team doesn't need to worry about floor space they can very easily become inefficient through working on too many things at the same time. You end up with a lot of half-finished code mucking up your working directory, or a developer finished up a work item and doesn’t immediately know what to work on next since the entire backlog has been started by other developers. There’s a host of other problems that the team can run into with the entire backlog already started (I could write a whole another article on that alone).

From a project standpoint, it becomes harder to see what is going on if you’ve got 15 work items all in play at a given moment. That means that you spend a lot of time investigating each one to figure things out, especially since they are all likely to have a status of started (which effectively makes that status useless). If you could get that started work down to 7 or even further then your administrative overhead will be decreased significantly. Likewise, with a proper priority list, you’ll always know which feature will not only be started next, but also a rough idea of what will be finished next (since you have to start something in order to finish it).

We’ll also tie this into the Scrum side of the equation; by limiting your Work In Progress you’re ensuring that you always add the most amount of business value to product iteration as possible. If you implement everything by sprint end, you have at least devoted the maximum amount of work to the most important work in that sprint. The least important work items were probably not even started or at least not started until the end of the sprint. If there’s one trick to making this concept work for software development, it’s pre-ordering the work that the team will do so that they can simply grab the next work item from the top of the list and since we’re all Scrum teams we’ve already done that ordering before we even started the iteration with our priorities.

And of course we’ll get a big benefit from learning to attack any impediments or problems that we have right up front rather than pushing them to the back of the sprint. This really is one of those things that allow a team to grow stronger together by solving these problems and allows the organization to really address the development teams needs. If we get in the habit of coming to the organization every 2 weeks (sprint end) with a laundry list of problems, at least some of those problems will go to the backburner (oh the irony) but if we bring the them these problems one at a time they may be more willing to address those problems sooner.

The takeaway here is that limiting Work In Progress (WIP) isn't really a secret, it's not complicated and it's certainly not even something you need to take a weekend to learn or read a book on. It's just good old-fashioned problem solving applied to a really common problem. While floor space isn't something you have to deal with, integrating 10 features into a product in the last few days of a sprint is.

So how do you actually limit your work in progress? It’s simpler than it sounds, ask your team to think of a limit. It may be 2 work items per developer or 10 work items for the team or 5 work items in most circumstances but 6 if it’s an emergency. The important thing is for the team to decide on a limit of items that can be in progress at any given time. If that limit isn’t right then change it (you don’t really need to wait for the end of the sprint). I also recommend some kind of board or tool to visualize what’s in progress, what’s done and what’s yet to be started. This can be done with sticky notes or index cards on a board or through a software solution of some kind but having a visual aid to see everything in play will be a big part of communicating that you’re nearing your limit.

Summary

Limiting Work In Progress works in the same way that Scrum does. You see Scrum doesn't really solve any problems for you and neither does limiting Work In Progress, it just exposes the problem for what it really is which makes it easier to solve. If it's a business area problem, then it's easy to show and prove to the business making the solution easier. If it's a tendency of the team to juggle the entire sprint backlog, then bring in a WIP limit and measuring over a couple sprints might be enough to prove to them the virtues of this new idea.
If your Scrum team can't solve a problem on it's own, then they come to you (the Scrum Master). It's your job to hunt down whoever can unblock the team as quickly as possible and solve that problem. What will your developers do while you're on your manhunt? Partnering up on a single programming task would work great, maybe having a WIP limit of 8 for a team of 7 or a WIP limit of two for each single developer. Use your sprints to experiment here if it seems like something you want to implement.
Just remember to wear comfortable shoes since you'll be walking a bit more than normal for at least a little while.

About the Author

Sean McHugh is one of the Scrum Masters at Axosoft.com. He works with customers who are brand new to Scrum and also with experienced customers who are beginning to implement a scrum project management software solution for their development teams. He gets a chance to work with teams from around the world, who each have their own unique challenges and solutions. He loves to share his thoughts and experiences with the Scrum community writing on his scrum blog.