Silver Stripe Blog

Teams that do Scrum for a long period of time naturally tend to hit into some walls. In the process of inspecting and adapting over a period of time, they eventually end up with something like a Kanban process. In this post, I’ll explain how the evolution worked for us.

Velocity based sprint planning

To start with, we did plain vanilla Scrum. Two week sprints, sprint planning meetings, releases and so on. However, we soon ran into an issue with velocity based capacity planning.

Velocity is a probabilistic distribution, so if your average velocity is 20 points, then that doesn’t mean you will do exactly 20 points every sprint. Some sprints may be less, some more, but on average it is 20 points.

The first problem is that in Scrum, the team commits to the sprint plan. So if the average velocity is 20 points, typically you will commit to 20 points of work. Problem is, you will rarely do exactly 20 points. Most of the time you are less or more. This is quite natural, because velocity is probabilistic. If we were to use the terminology from Demming, you would say it is common cause variation.

Now, assume that you have committed for 20 points, but you are only going to make it to 15 points. What then? In Scrum, you would work harder (extra nights or weekend maybe) in order to make the commitment. Personally, I do not think this is healthy, because the variation is natural, not something extraordinary. But because of the commitment at the plan time, teams have to do this to keep the promise.

Sometimes the opposite happens, and you are doing better than average. Lets say you finish 20 points early. Scrum says you should not take up new features mid-sprint.  So teams usually do other non-value work to fill in the rest of the sprint.

Therefore in Scrum you end up with a situation where you have to work extra when you are behind, but you waste the time when you are ahead. And most of the time you are ahead or behind. Very rarely are do you go exactly as planned.

The problem is that Scrum ignores the reality of variation in velocity and attempts to force teams to a constant velocity. The root cause is the commitment oriented sprint plan.

Kanban gets around this by embracing variation. Since there is no commitment based iteration plan, teams work at the natural rhythm. This means that sometimes you deliver more and sometimes you deliver less, and there is nothing unnatural about that. Kanban differentiates between common cause variation and special cause variation, and each is handled differently.

The first adaptation we did was to get rid of a commitment based sprint plan.

We would plan out, just to give a feel of the sprint and to maintain coherence between selected stories. But if we did less in a sprint, we just moved unfinished stuff to the next sprint and release only what was completely done. And if we finished early, we’d pick up some new stories, even if we knew that it might spill over the release boundary. Suddenly, we no longer needed to fit a story within a sprint. If it spilled over, thats okay, we just continued it next sprint. This led naturally to the next change.

Swapping items mid-sprint

Once we stopped looking at the sprint plan as a commitment, it enabled us to do something else. Now if some high priority item came into the backlog, we didn’t really mind adding it mid-sprint and taking out something else that was not started. This makes sense – if you haven’t started work on a story, then what is the difference if you take it out and put something else in its place? The team suffers no penalty because you are taking out something that is not started anyway, and it enables delivery of higher priority items. This is a complete win situation. Whats the problem?

Limiting Work In Progress

The problem in traditional Scrum is this – sometimes its hard to find something that’s not started. This is because once the sprint plan is done, teams often start work on all items simultaneously. If you then want to do a swap, you have to remove something that is in progress – in that case there is a penalty for doing a swap mid-sprint. To avoid dropping a story that is already started, you could end up with a situation where the story is added without anything being removed. Because sprints are commitment based, this is a bad, bad thing.

The solution?

Limit work in progress. Don’t start a new story until another one is finished.

Implement a pull system to balance demand with capacity.

Implement a stop the line system so that blockers are taken care of.

We now start noticing something – If items can be swapped mid-way, and the sprint plan is no longer commitment oriented, then why exactly are we planning once every sprint? Which leads to the next point.

Decoupling cadence cycles

Once we started picking items mid-sprint we asked – Why spend the time creating a sprint plan if we are going to be changing it? All we need is a well prioritized backlog. The team can then just keep picking stuff of the top of the queue. Want a change in priority? Just reprioritize the queue.

Suddenly, the concept of iterations and planning cycles were no longer coupled. Planning could happen either when something major came up, or on their own cadence, or when the backlog started running low. Implementation could happen on a different cycle altogether, just pulling stuff from the backlog and releasing on their own cadence.

Similarly, teams would find that retrospectives have a lot of value at certain times (at the start of a project, or after some special cause event), but not much value at other times (in a steady state perhaps). Why tie the retrospective cadence to the delivery cadence? It is an artificial coupling. So retrospective cadence is now separate from a delivery cadence.

The whole concept of fixed sprints with coordinated events at the start and end of a sprint were gone. Note that the conecpt of cadence didn’t disappear. It just got decoupled.

Kanban Demystified

There are a lot of myths about Kanban floating around the Internet. That Kanban is a return to waterfall and handoffs. That Kanban does away with cross-functional teams. That Kanban has no cadence.

Nowhere does Kanban say anything about waterfall, handoffs or cross functional teams. Can you do Kanban with a cross functional team? Sure! Can you have everyone in the same room? Why not! Do you need to have handoffs? Nope. Does Kanban get rid of cadence? No, it just decouples it – but no one stops you from having it coupled if that works for you!

Kanban also works better in a traditional setup. What if you do have handoffs, distributed teams and all that? Scrum will fail miserably – ScrumMasters will (rightly) tell you that Scrum is exposing the organizational limitations. But its hard to make all changes in one go. This is why we have a bunch of teams doing “ScrumBut.”

However, you can still use Kanban in these traditional organizations. You will get a part of the value. And if organizations want the whole value, they can make a decision to reduce handoffs, move to colocated teams and so on in a phased manner.

There has been a lot made out of Kanban boards, lack of estimation and so on. Yes, they are all used in Kanban, but they are incidental. A Kanban board is simply an outcome of using a pull system, which in turn derives from limiting work in progress.

I make this differentiation because there is a misconception that “Kanban Process” equals the “Kanban board”. Some think that they use a Kanban board, so they are doing Kanban. This is missing the forest for the trees. The Kanban board is just a rather small part of things – an outcome of more fundamental principles.

Summary

The way I look at it, Kanban is an inevitable progression from Scrum that occurs naturally over a period of time with teams that inspect and adapt. Inspect and adapt is a core part of Scrum, which is ignored by many teams that are too keen to follow the “rules” of Scrum. Ironically, by following all the rules, except the one that matters most, it is exactly these teams that get into a major tangle.

Did you know for instance, that only 39% of teams do retrospectives? That retrospectives do not find a mention in the Nokia test? (The Nokia test is the “almost official” way to test whether you are doing Scrum) There goes inspect and adapt out of the window.

The retrospective is important enough for Alistair Cockburn to list it as one of only three “must have” properties in the Crystal methodology, but it seems to have gone missing from Scrum.

Kanban is simply a set of natural modifications to Scrum. Each modification automatically leads to another over a period of time, until you go from Scrum to Kanban.

We arrived at Kanban through these principles

• Understand and embrace variation
• Limit work in progress

Each of these further led to others, like pulling value, limiting batch sizes and so on.

For us, understanding variation was the key trigger that led to the chain of changes. For others it might be something else, like too much work in progress, or too many small stories. There are many ways you can end up with Kanban.

Above all, inspect and adapt.

Related posts:

1. An Introduction to Kanban with Silver Catalyst
2. Agile Advice on maintenance projects, Yahoo India tries out Kanban
3. Scrum Cheat Sheet
4. Kanban for software maintenance
5. Evolving from ad-hoc to Agile to Kanban