WIP Limit: Same Numbers but Different Outcomes for the Team

By Alex Yakyma. 

We know that WIP (Work In Progress) Limits are useful. They are useful at different levels of abstraction in the organization: portfolio, program or team (see posts by Dean Leffingwell, and Sean McHugh). Limiting WIP is one of the central themes in Lean Product Development as pointed out by Donald Reinertsen in his uber cool book "The Principles of Product Development Flow". We even know that WIP Limit makes a lot of sense at the individual level as there evolved an individual productivity tool called Personal Kanban, which looks quite simple and logical. However, WIP Limits in software development are not as simple as they may seem. Software engineering is a knowledge-intensive, creative, intellectual type of work and this implies a whole bunch of interesting nuances. We are going to explore some of them now at the team level.

So first of all, let's imagine a team consisting of one developer (and one tester, for instance). Assuming that he has a backlog of user stories, how many of them should he start working on at once? One, right? If it is just one, he won't be multitasking and thus will be totally focused on his current context of work. Well, not quite like that... In the time when I was a developer and then afterwards when working in other different capacities and observing the way other developers worked I was quite often seeing interesting pattern: a person takes a new story and starts slightly digging in that new direction while still working on the old one. And here's why it isn't always all that bad but often vice versa: we are not drilling holes in the wall or assembling chairs - we develop software and this is, as we said, uniquely intensive intellectual work. So let me give you an example: I work on the user story that would enable a search system user to not only see the links of the pages where the search phrase was found but also the short abstracts containing the phrase so I could at a glance see the context in which the phrase is used on the corresponding page. And then all of a sudden while still coding this story I take another one: "negative filtering by keywords" thus enabling the user to narrow down search results to those that do not contain the selected keyword. And it's not that I start coding it, no, I just read about it little bit, I talk to the people who dealt with something similar, I go home after work and when sitting in the bus, I give it some little thinking. Next day I seem to find an interesting idea (when brushing my teeth): in order to easily implement this one we need to start working with a binary vector on top of the array of all keywords in current filter criteria. Finally during the lunch same day with Andrew, the guy from another team, I just share my algorithmic problem that I anticipate in the context of this story and he simply gives me absolutely great idea of how to implement a lightweight comparison mechanism. Inspired by this direction of thinking I seem to know what to do with the rest of the open questions. That's all I did, I thought about it a little bit, talked to other people, slept on it... that's how it works - generating good ideas takes time and there has to be knowledge that eventually morphs into the idea in some miraculous way after some while.

So now I finished coding my first story, maybe a bit slowed down by the distraction that I myself introduced, but I already have a plan in my mind of how I will approach the second story and I can start coding. After a bit of coding, when I see some of my ideas working and some still needed modification, which it took a bit of time to do, I'm certainly gradually moving forward with story #2 and it's just about time to pick another one from the backlog and just see what's in it, speculate a bit, discuss it a bit with someone, sleep on it and maybe in a short while (while still working on story #2) my brain will generate some good ideas...

The takeaway is: one story per person at a time may not be optimal and while coding one story I can start thinking and reading and just doing some slight background work on the next one and it will be more efficient! So in cases when real creative work is required, the optimum WIP Limit per person could be 2, not 1. I know, I know, we have to avoid individual WIP Limits when talking about the team. But bare with me, this is just our thinking tool, we'll get there...

Next trick is even better. What if we now have two devs on the team? Should they follow the same pattern? In other words limiting each devs WIP to 2 instead of 1? Looks like "yes" but this already gives us few alternatives: the stories can be different or can be the same. In other words there can be as many as four stories in progress due to such logic or just two! And the latter is really good approach. So see, with individual WIP Limits = 2 we have three possibilities for the team WIP Limit: 2, 3 or 4, depending on the overlap, and as we know, collaboration is king and we would most likely prefer it equal to 2.Let's now play it backwards: what if we set WIP Limit of the team of two devs equal to 2? Again, we have different alternatives: it could mean that they work each on different story or they are actively coding one story and "previewing" the other. And again, the latter might be of our preference. Thus...

Same WIP Limit at the team level may lead to different outcomes depending on the collaboration pattern that the team chooses. 

Figure 1. Efficient collaboration pattern: WIP Limit = 2 and story "previewing". 

It is easy to see how to scale this logic further to a full-size agile team. When we talk about pairing we by the way do not necessarily assume pair programming. It can be just collaborative work (something we know by name of side-by-side programming, for instance).  So the net result of such collaboration pattern is really interesting: much faster and higher quality results but with the same WIP Limit that equals to the number of developers on the team. This mix of pair work and previewing user stories becomes very useful for knowledge sharing and collective code ownership in the team. All that is needed is just to rotate the pairs over time. Because of the "previewing" the probability that someone (on the pair) will have something to learn from his team mate is now considerably higher.       

All of the above is totally applicable to Scrum teams (and was written with those in mind). We know that once the Scrum team has planned and committed to the Sprint scope, there can be different strategies of how to succeed with the Sprint. Some of them are better than the others. Today we covered one aspect related to collaboration and WIP Limits and I hope it was helpful.

2 comments: