I’m having the opportunity to coach in an organization that isn’t used
to agile practices. This is very refreshing and they are constantly
challenging me and the ways that I think for granted. Quite often I find
myself stumbling to explain practices that I for so long just have
assumed that everyone was doing.
A couple of days ago I stumbled upon one of those. Here’s
the dialogue that played out (as I remember it at least):
Me: You are doing a lot of things at once here…
Appointed Product Owner: Yes. But there’s a lot of things that we have
promised them to finish by [date]
Me: But why don’t you limit your work in process then? That will get
stuff done faster and ..
PO: Whatever do you mean? We cannot just limit the work. This [pointing
to board] is what we are supposed to have done. We better do it now. As
fast as we can.
There’s two things that I have missed to explain here; the use of WIP
(what is it good for) and why they (the stakeholders) shouldn’t and
probably doesn’t care about your WIP.
First; what is a WIP (work in
process) limit? For me
it’s a team agreement on how much work we take on a given time. It’s not
pushed upon us from the outside and we can change it and break it if we
see the need or use for it.
In Scrum a very
important aspect of the sprint work load is that the team takes on how
much work they think they’ll manage with the next sprint. This is done
to balance the workload for the team and also, since the team takes on
the work, you enforce a sense of commitment to the work you have taken
on. If, during the sprint, new work appear we, as a team, could decide
to take that on and hence stand the risk to not complete the backlog of
work we took on for the sprint. Or we could talk to the product owner
and say that we wont manage the new work as well as the sprint backlog.
Could she please help us prioritize between these?
WIP limits serves the same purpose. We limit the amount of work that we
take on (per stage in our process or totally in our process or what have
you). It’s an working agreement that we have decided (as we do with
sprint backlogs).
If new work should appear that would make us break our WIP-limit we need
to have a discussion. This is really what a WIP-limit is; a trigger for
a discussion.
law](<http://en.wikipedia.org/wiki/Little>'s_law) tells us that the more
work we do, the slower each work item will take. Bringing on new work
will in other words slow down the progress on all work a little bit. Are
we willing to pay that "toll"? Is the "toll" so small that we feel that
we can make this decision on our own?
we're doing. To quote [David J.
Andersson](http://www.agilemanagement.net/) (as I remember it)
> "Kanban allows you to become a Yes-man. You can always say 'Yes'.
> 'Yes - we'll take this on - what should we stop doing?"
Finally - with less work in process the work will flow faster, according
to [Little's law](http://en.wikipedia.org/wiki/Little's_law). That is -
you will do less work at the same time but every work item will go
faster. This in turn gives us feedback on our work and helps us improve.
We get more decision points and can become more nimble and agile in our
business. We can prioritize work that give us more business value or
quick-wins, first for example.
Finally, if you try games like [Pass the
pennies](http://blog.crisp.se/2008/09/08/mattiasskarin/1220882915232),
you'll see that the total time for all work will also go down. Just by
doing less work at the same time. Working the exact same way with your
work items, but taking fewer of them on at the same time.
To recap; WIP limits are triggers for discussions. We put them in there
to make the work flow more even and faster. And to not overload people
with work.
### Limit WIP doesn't mean less work done
After that first point (yes, there's "First" waaay up there...) let's
turn our attention to limiting WIP. Limiting WIP means that we decide a
limit of the number of items that we work on **at the same time.** It's
a team thing and doesn't say; we will do fewer items in total.
Again - we use the tool limiting WIP to help the work that we're
actually are working on to flow faster, and to manage more items in
as I mentioned above. It shows, very clearly, that with less work in
process (at the same time) you not only finish each item faster but also
the total time for all the work you do is lower.
Finally - this is a team internal practice. It's the way that the
factory that we're constituting is operating. We pick a limited number
of items and try to complete them before starting anything new. That's
our aim. We don't always succeed on sticking to it, but we try, since we
When we feel the need of breaking the limit we have a discussion on why
and the benefits versus the cost of taking on more work. All we really
want is to make informed decisions. We can decide to slow the system
down for a while, in favor of expediting another critical item, for
example.
In that regard the stakeholder outside the team is probably not
interested in WIP limits. Just like I don't care how the internals of a
computer works. As long as it works and does it's job I really do not
want to know about the inner workings.
### Conclusion
This was a really long way of saying; WIP limits are not fast rules,
they are triggers for discussions. We use them to improve the flow
through the system.
Limiting WIP does NOT mean that your doing less work in total. Just that
you're doing less work at the same time.
(outside the team) doesn't even care. They want features, as fast as
possible with great quality.
