
Mike Lyons explains how WIP limits from lean manufacturing boost software team speed. More work in progress actually slows you down. Start with roughly double the number of people doing the work, then adjust in retrospectives.
Chapters
And so in all of these examples, the way that we're maximizing flow is by understanding our work in progress, our wip. So work in progress limits, WIP limits allow us to find the maximum flow. And this applies to agile development as well. Work in progress limits were introduced from the manufacturing industry and have been brought forward to help us really understand how to get the most work done. A statement I like to make all the time is the more work you put into a system, the less work comes out. And it's counterintuitive and many, many executives will want to just insert more work and put, you know, find the best team and just give them more work and give them more work. And what happens, even the best teams begin to slow down because we have to limit our work in progress. And so a technique that many Scrum teams will use is, is to display their work to make their work visible in what is often referred to as a Kanban board. This Kanban board will allow us to see our work and see all of the pieces that are needed to be done to go from our backlog to done. And then you have WIP limits at the top of each column. These numbers indicate the maximum amount of pieces of work we can have in any column at any given time. We focus on having small batches of work, user stories, and delivering them incrementally. This WIP limit helps us get to that incremental value delivery. So setting work in progress limits and making sure that our developers have time to just focus on one story at a time. And testers are, then when it's ready for test, they're going to, they're going to test it. Remember, they're all on the same team, they're going to test that story, but they're, they're focused on just that. One piece of work will actually increase the throughput through the system. Just like limiting the number of cars on a highway increases the speed through the highway, limiting the number of items in a checkout lane increases the speed of the checkout lane. Limiting the amount of items that any person is working on at any given time increases the throughput. This is, it's a little counterintuitive. Sometimes I meet a lot of executives that this, this is, they see it in their regular life, but then they come to work and they pile more work on teams, expecting them to go faster and do more. It's not the case. Now a word on WIP limits. They will change. You probably won't get them right when you start. And that's okay. A good rule of thumb. Let's say you've got, you know, two developers. Maybe your WIP limit for development is four, maybe start there. Good rule of thumb is to double the amount of people who can do that work. And the reason for that is because if they get blocked on one story, they still can move to the next story. Any more than that and we can end up in a situation where we're working on more than one thing at any given time. We really want people to be able to focus on their work. Developers are working on a single story all the way through. Testers are working on a single story all the way through. And it moves through the system in that fashion by limiting our work in process. And it will change. You'll get better at it. It's okay if it's not right the first time because we'll have a retrospective and we'll talk about changing them. It's amazing to be able to tie these lean manufacturing techniques into software development and value creation on agile teams even today.










