Kanban Question

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 Lean guys in Japan stole the idea from Piggly-Wiggly in the US (a grocery store).

The idea is to use the cards to establish a pull system, to generate flow and to minimize WIP (work in process). 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 case, a team.

Another key idea is to use visual management (seeing the cards on a board) to manage the flow.  If flow stops, 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 strong 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 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 true.  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.)

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

This is maybe the toughest question, with not always an easy answer.  My main 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 advocate and you have made a persuasive case for Scrum.  Maybe even 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 like 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.