Kanban Question

April 9, 2012

A colleague asks: “We are an out-sourcing firm and have a client who does not have a Product Backlog. In fact, they often can’t prepare enough items (stories) for even a full Sprint Backlog. (2 week Sprints). He is not used to Scrum or any other Agile approach. I am thinking of using Kanban with him. What do you think?”

For some readers I guess we should define Kanban.

Kanban

Kanban is the Japanese word for signboard or card. The Toyota folks (Lean guys) in Japan “stole” the idea from Piggly-Wiggly in the US (a grocery store). This was a very good and useful borrowing.

The idea is to use the cards to establish a pull system, to generate flow and to minimize WIP (work in process). Kanban is not the only tool or method used to realize these values, but it is one method.

It is very helpful if each card represents a small amount of work, and roughly an equal amount of work. We establish 3-7 ‘slots’ for each of 3-7 process steps. This establishes the capacity of the ‘system’, meaning in our usual case, a kind of team.

Another key idea is to use visual management (seeing the cards on a board) to manage the flow. If flow stops, it should be very visible on the Kanban board, and the issue is supposed to be addressed immediately.

***

This is a hugely over-simplified view of Kanban, especially as practiced by Toyota. Indeed, Toyota does many other things besides using the Kanban cards to enable pull and flow, and to minimize WIP.

When we hear something that sounds like a team is using ‘only Kanban’, we are worried, because that seems to us likely to not be enough. Of course, almost always, they are doing other things as well, but often not calling them anything.

Summary of recommendations

Scrum comes with a basic Kanban approach ‘out of the box’ — with the scrum board (with backlog, in process, and done columns). Once the team gets the basics of scrum down, we strongly recommend enhancing this board to make it a stronger Kanban board.

In almost all real situations that we encounter, we want to maintain the basic strengths of Scrum even while using Kanban on the board. These include release planning, sprint planning meeting, daily scrum, sprint review (demo), and retrospective. Very rarely we do see weird situations where this just won’t work, but again that is very rare.

If the product owner is not ‘good enough’ or the connection to the business side is weak, we recommend addressing those impediments directly. We do not recommend hiding those impediments by doing only Kanban.

Discussion

Some assumptions…

1. The team is a regular size of about 7.

2. The client has a product of a reasonable size.

3. The product is important, although not always as important to the CEO (of the client, in this case) as we team members might like.

4. An MMFS (Minimum Marketable Feature Set) for this product typically takes at least four weeks of work (or more) by the team. (This means to me, more than 1 sprint.)

I find that situations that don’t fit within these assumptions are rare. But they do of course exist. My recommendations above and my comments below are based on these assumptions.

First issue: a weak product owner or a poor connection with the business is very common!

I am sorry, but this is true, this is common at first. And Scrum makes this issue visible, eg, in the demos.

These problems happen because Technology got divorced from ‘the business’. It happened because mutual disrespect has built up over the years. It happens because no one has ever been asked to be a product owner before. And your firm typically does not have a seriously experienced and successful product owner to train or mentor the freshly minted product owners.

Solve this problem! And it starts by making the pain visible. (Further discussion of this issue in a later blog post.)

In your particular case, take some more time to work with the client to develop a product backlog. This may require that you hire an agile coach, to coach them through the initial process. But it is not really hard. It may also mean that you assign one of your own people as the PO. And treat the customer people (a few of them) as key ‘business stakeholders’.

Second issue: which is better to implement first, Scrum or Kanban?

This is maybe the toughest question, with not always an easy answer. My preferred answer is clear: Scrum. Because it sets so many basic disciplines in play.

This often requires a persuasive advocate for Scrum. Scrum can appear hard (change always feels hard), Scrum is typically blamed for revealing real problems, etc. And often the local advocate does not fully appreciate all the reasons that Scrum works.

Now, let’s assume you have a good agile advocate and you have made a persuasive case for Scrum. Maybe you even have gotten them to try it for 4 Sprints. But they aren’t buying it. This can happen in real life. Not saying that it should, but people are not always reasonable.

In that case, it is reasonable to say, ok, let’s try Kanban. And then later, as you identify issues that make some part of Scrum useful, you implement that part.

This is not to say that professional Kanban is easy to implement. But maybe in some cases easier.

Third issue: Retrospective.

Yogi Berra said: in theory there is no difference between theory and practice, but in practice there is.

In theory, we humans in a team should not need a Retrospective meeting, but in practice we do. And we need one about every Sprint length. (I usually prefer 2-week sprints, but I am not too bothered whatever length you want to say.)

So, if you implement only Kanban, then also implement a Retrospective every 2 weeks.

And the key here is to identify the top impediment and take action. Action in the form of identifying a specific plan to fix it. Or in identifying a business case to fix it, that a manager will approve (once you make the presentation of the case).

***

This is already a long blog post. Let me leave it here (although there is much more to say). Tell me your questions, and I will likely write and explain more.