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 low standards. This 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 their 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 my 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.
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 low standards. This 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 their 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 my 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, 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 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.
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. What's more, they'll develop a tendency to start everything early but not finish until right near the end of a sprint which can really play havoc with tracking your daily progress.
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.
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 whomever 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.
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.
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 whomever 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.
No comments:
Post a Comment