June 22, 2012 | Author: PM Hut | Filed under: Agile Project Management
WIP Limits Are Critical to Agility
By Neil Killick
Over the last couple of months I’ve really started to understand how important WIP (work in progress) limits are to an agile delivery process. Rather than getting too technical and talking about how cycle times can be derived with throughput and WIP (Little’s Law), or delving into some other, less tangible benefits of limiting WIP, I want to explain in plain terms why this practice is critical to enabling business agility.
The concept of limiting WIP is normally associated with Lean and Kanban principles but is often ignored (or misunderstood) as having anything to do with Agile. However, if you think about it, WIP limits are absolutely essential to allowing a business to respond to change quickly and change priorities for what work should be executed next.
Agile team? I think not…
If you think you are working in an Agile team, consider this: If the business owner walked over to your team area with an index card in her hand (or, more realistically, a value proposition in her head which you will hastily write down on an index card!) and asked how quickly it could be delivered into production, what would your answer be? Let’s assume that the team asks a few questions and breaks down the feature into a couple of stories, each roughly the same size as other stories they implement – so probably 6-8 days of work (if you don’t already know your team’s average throughput, start measuring it now!). With those assumptions in mind, do you know the answer to Gillian’s (yes, let’s call her Gillian) question? If you do, would the answer be days, weeks or months?
If your team had no other work in progress, obviously the answer would be 6-8 days. They can get started on it right away, so the predicted delivery time is equal to the time predicted to be expended on the feature. That sounds very reasonable, right? OK, what if the team currently had 3 other cards in progress (so 5 in total)? Continuing with our assumption of 3-4 days turnaround per card, we’re now talking 15-20 days. Still pretty reasonable I suppose. Now consider if your team had 10 other cards in progress (12 in total)? We are now talking about a 6-8 day feature taking 36-48 days to be delivered into production – that’s 7-10 weeks.
The emerging point from this example is that the more cards your team currently has in progress, the longer it will take a new, top priority card to be delivered into production. Therefore I would be so bold as to say that if you allow too much work to be started (thus in progress), your team really isn’t very agile at all. The whole point of agility (indeed, by its very definition) is to allow the business to be able to quickly respond to changes in the market and be flexible with its portfolio of work in order to deliver maximum value at any given time. Your “Agile” team – with its cards and columns on the wall, its burnup and burndown charts and its daily standup meetings – takes up to 10 weeks to push a new feature costing just 6-8 days of effort into production.
Scrum limits WIP
Those of you using the Scrum framework may never have considered the reason why scope is fixed within a timebox, and why the principle of “stop starting, start finishing” is so key. Fixing scope to what the team feel they can achieve (capacity) means that the WIP of the team at any given time is limited to the number of items in the Sprint Backlog, preventing the situation above. i.e. it implicitly applies WIP limits. Any new priority card can be brought into the very next Sprint without having to wait for other queued-up cards to be implemented. This is one of the key reasons why Scrum is an excellent framework for promoting business agility when it comes to product development.
I hope you can see that if you’re not using Scrum (perhaps a pure Kanban approach), it is crucial to limit the WIP of your team. Even if you are using Scrum there are extra benefits to be had from implementing queue limits within the Sprint timebox (Scrum-ban), especially if your Sprints are longer than 2 weeks and you are employing continuous delivery.
It’s often tempting for a team to start new work rather than wait for a blockage to disappear (e.g. wait for the Product Owner to be available to accept a story), or for a manager to think they are doing the right thing by increasing the number of hours the team are spending working on deliverables (i.e. increasing efficiency). However, you must bear in mind that the act of bringing more work into play will increase the average time it takes a card to be delivered into production and put in front of your customers.
Sometimes, from the team’s point of view, it makes more sense to wait a couple of hours for the blockage to disappear rather than succumb to the temptation of filling your every hour with actual work. From the manager’s point of view, recognize the important of “slack” time and how it speeds up your delivery times.
Neil Killick is a highly skilled I.T. professional with 17 years of varied experience in England and Australia. His background is in Java/Web development, but his more recent experience has encompassed being a ScrumMaster, Iteration Manager, Senior Agile BA and Product Owner, as well as a Team Leader, Coach and Mentor in Agile or transitioning environments. You can read more from Neil on his blog.
No comments yet.