Why try Kanbnan?

In my last post “Scrum doesn’t work for us; should we try Kanban?” I gave a warning about adopting Kanban because Scrum doesn’t seem to work. Having given advise on when not to use Kanban I feel I need to suggest when choosing Kanban is the right decision.

Of course list that follow is only broad guidance, each and every team needs to make their own decision based on many factors I cannot even guess at here. Nor is this an extensive list, I’m sure Karl Scotland, David Anderson, Benjamin Mitchell and others would add more to the list but its a good start.

Here goes….

Use Kanban for maintenance: teams who fix bugs, especially teams who fix bugs in live system. Such teams work respond rapidly to unpredictable work, bugs are difficult to estimate and can come up at any time.

Use Kanban when predicting future work is difficult: this is a generalisation of the previous case but expanded. It is not just bugs which are unpredictable, sometimes the work which needs to be done is unpredictable.

Note: some teams fall into this position not because the work they do is really difficult to predict but because there is no effort put into predicting the work, usually because nobody is tasked with looking ahead or the person who is asked to do so isn’t allow enough time to do so. The easy way to spot this is the absence of someone with a title like: Product Owner, Business Analyst, Product Manager or similar.

Use Kanban when the team find Scrum style routines stop them achieving flow: for effective teams who focus on rapidly turning new requirements into working software Scrum routines such as planning meetings can get in the way. Nor is there a lot of point to running a product backlog if items are being delivered rapidly or not done.

Use Kanban when the system is too complex to model with Scrum(XP): the plan-it, do-it, deliver-it model which underpins Scrum isn’t too helpful when a process has a lot of wait states or dependencies. The standard Scrum answer is probably to remove these but that isn’t always possible (e.g. you can’t force a customer to respond).

Use Kanban when learning is a higher priority than delivering: to be effective Kanban requires to learn from what the system is telling you and adjust. If you can’t put the learning into effect Kanban will not be effective. However, Scrum’s pre-packaged solutions means that many teams seem to adopt Scrum and forget about learning (e.g. retrospectives are forgotten.) Worse still, because Scrum (claims) to fix so many problems “out of the box” teams may develop a learn dependency.

Use Kanban when you need to introduce the Agile approach more gradually: strict Scrum mandates a big-bang approach, sometimes this isn’t possible. Kanban provides a foot in the door which becomes a lever for opening it more. (This point flows directly from the previous when you consider change to be the result of learning.) However this also comes with a warning: change can quickly stall if people do not act on what they see and learn.

In the past there has been debate about which style (Scrum or Kanban) a team should start with and which is the advanced style. Personally I find it easier to start with Kanban although many people feel the natural order is the opposite: start with Scrum, get good and advance to flow and Kanban. Although it is easier - in my mind - to start with Kanban it is also a lot, lot, easier to get it wrong.

There is a paradox there: Scrum mandates the role of Scrum Master, I don’t usually see the need for a Scrum Master, an occasional Agile Coach is helpful, but a full time Scrum Master No. Kanban doesn’t mandate any such role, but you probably need someone with past experience far far more with Kanban than you do with Scrum.