Experimenting with Horizontal WIP Limits in KanbanAgile
An explanation of an alternate means of running a Kanban team to limit WIP - particularly aimed at teams with fewer members than Kanban states.
I've been using Kanban in my team for quite some time and have found it to be a very productive way of working for our particular situation. There are various reasons why this works better for us than Scrum did, but that's not really what I wanted to talk about now. What I wanted to do was show our latest experiment with WIP limits.
So we're probably all familiar with the usual way WIP limits are set within Kanban. You define the states (e.g. Ready, In Progress, Review, etc.) for your stories and each state has its own WIP limit that may not be exceeded. This works pretty well and ensures that we're not working on too many things at once. It also makes sure that the team deals with problems early, as it often prevents us from moving on when there's an obstacle in the way. It's a gentle reminder that there's no such thing as "someone else's problem" when working on a team.
Vertical WIP limits
The problem I've found recently is that the vertical WIP limits we usually set in Kanban aren't working as well as I'd like. In our example, we have a team of 6 people but we have about 5 states. We can come up with some reasonably small WIP limits for each state but that would still allow us to have more stories in play at one point in time than we have people to work on them. This to me seems risky. If your WIP limits allow you to have "idle" stories, something is wrong.
This is roughly how our Kanban board has been set up for the past few months (these aren't our states... just there for illustrative purposes):
Horizontal WIP limits
Last week I decided to do something I've been wanting to do for quite a while now... I added a horizontal split to our board and we now operate as two groups within the team, each with their own global WIP limit. Let me explain this in more detail...
Firstly, we're still a single team, but we operate as two groups within that team. The reason I don't see this as two separate teams is because the groups are flexible and will change regularly. Think of it as similar to pair programming - just because you're pairing, doesn't mean you're now in a different team. A lot of the benefit of working in a team is learning from and teaching each other - and that's amplified when you have just the right number of people to teach and learn from. We conveniently have two developers and one QA per group, so we maintain a sufficiently mixed skill set across the groups. These groups are not isolated - so there's nothing preventing one group from asking the other for help... in fact, it's strongly encouraged. We still work in the same area and attend the same daily standups.
Secondly, the global WIP limit is now set horizontally per group . In our context, this makes a lot of sense. We now have three people that can work on at most 2 stories at once. This means that while one story might be in code review (or some other 'waiting' state), they can continue working on the other. But because there's only one other thing to work on, it naturally leads each group to complete one story fully before getting too invested in the next. Having both stories in code review at the same time is most likely to be due to poor time management or planning (of course, it could be something else, but these seem most realistic).
So this is roughly what our board looks like now (I realise the location of the WIP limit can be misleading... it's a lot clearer on our real board):
What are the benefits?
This is the extremely early stage of an experiment, so this is more of a hypothesis than a list of proven benefits. Once we've been running with this for a few weeks / months, I'll report back on our findings.
This is a tricky topic, because at face value it appears that it's playing into the hands of the "Everything is Priority 1" crowd. In fact, that's not what we're doing (or rather, it's not what we're aiming to do). One of the difficulties we have in building a platform rather than an application is that we have multiple customers with related but different requirements. In the spirit of Agile, we aim to deliver working and usable functionality regularly so our customers can benefit from these new features. If we only worked on a single feature at a time, only one customer would benefit until that feature was complete; and we could then move on to satisfying our next customer. Something along the lines of round-robin feature delivery. Not ideal.
So what we're hoping to gain with the team groups is have each group potentially work on a different feature. I say "potentially" because it's not a rule set in stone. That way we can regularly deliver useful functionality to multiple customers at the same time - but it does have the unfortunate effect that we take longer to fully complete features. It's a trade-off though. Our capacity has not changed, we're just attempting to use it differently. We'll see how well this goes in time.
Less context switching
In an environment where priorities change fairly rapidly, we must be able to react quickly and effectively to those changes. Previously, we were reacting quickly but not really that effectively. The reason we weren't effective is because late changes or emergencies would impact the whole team. Everyone would be aware of the defect or story that came in late and would all be distracted from what they were doing because of it. Momentum was lost as a result, and the cost of late changes was higher than it needed to be.
Now that we have two separate groups, we can choose to distract only one group with late changes. This means that Group A can continue working on Feature X while Group B drops what they're doing to react to some emergency that has just cropped up. We still want the whole team to be aware of work in progress, and this will be reported and discussed in the daily standups, but Group A doesn't need to concern themselves with the details - they just need to be aware that it's going on. Of course, if warranted, we could put the whole team on the emergency - but I've found that it's very rare that we need to go to that extreme.
More focus on pair programming
The single most common topic in our retrospectives is pair programming. Without exception, everyone on the team finds it beneficial. This comes back to the teaching and learning thing again, and diversity in pairing with different people on different problems is very helpful. With the new groups we're firmly enabling pairing, to the extent that our WIP limit prevents stories from being completed without some pairing effort (group size = 3; WIP limit = 2). It's not enforced, because that again would be implying that one size fits all and every story is suitable for pairing (which we've also found is not always true). However, it means that no external influence can prevent the team from pairing if they so choose. No one can come to the board and under threat of deadlines or anything else tell us to work on more stories. Our WIP limit will not allow it, and so it both protects the team and the flow. Nice!
Lastly, I think this will help focus the team on completing one story at a time. Flow in Kanban is really important. "Flow" is really just another way of saying "momentum". Breaking the momentum of a productive team is guaranteed to impact their effectiveness. But sometimes the team can unintentionally break their own momentum by trying to do too much at once. This is very often a well-intentioned attempt to get more done, but it backfires because more work in progress does not imply more work done. Hopefully our small group focus will help bring people together to solve a problem completely before getting too invested in the next. This does rely on effective exit criteria for each of the states, but I think that goes without saying.
Right, so that our latest team experiment and what we hope to gain from it. I'll post an update after we've tried it for a few weeks / months to report back on the outcomes. Hopefully it's in line with our expectations!