Kanban from the Inside: 16. The Kanban Method

Chapter 16 of my book Kanban from the Inside condenses into a single chapter the following:

  • Some historical context
  • The principles and practices of the Kanban Method
  • “Contextualized Kanban” — Personal Kanban, Portfolio Kanban, and Scrumban
  • So-called “enabling concepts” —values, agendas, the Kanban Lens, etc
  • Implementation guidance —an overview of STATIK, to be covered in part III (chapters 18-23)

This week’s excerpt comes from that “Contextualized Kanban” section.

Kanban-from-the-inside


Scrumban

Scrumban is a name coined by Corey Ladas, for what happens when what you do now is Scrum and you apply Kanban.

I stress again the cautions of Chapter 13: Kanban does not mean recklessly throwing out all of your Agile discipline; rather it’s a transformative process that takes time, thought, care, and collaboration.

This progression is typical:

  • Already practicing a degree of visualization, the team organizes work according to its “done-ness.” This extends beyond “code complete,” “demo-able,” or “potentially shippable” to cover acceptance, deployment, and customer validation states.
  • Increasingly, standup meetings are organized around the board.
  • Already limiting work-in-progress through the sprint mechanism, the team pays more attention to the amount of work started but not yet finished. As a result, they start to see work items getting completed sooner. Immediately or after seeing the board operating well, explicit WIP limits may be introduced.
  • With work items completed sooner and more visibly, greater attention is given to the later stages of the process. Impediments to continuous delivery start being addressed. The nature of the sprint begins to change as releases are planned independently (if they need much planning at all).
  • Having decoupled releases from sprint planning, the system now easily accommodates work of different types and speeds. The team pays attention to the cost of delay of individual items and to the mix of work overall. Mid-sprint changes become much easier to accommodate; classes of service may be offered.
  • The rhythm of sprint planning continues, but the meeting itself gets easier. Estimating the right amount of work for the sprint seems less important; it’s enough to ensure that there is sufficient work of high enough value and quality and that the riskiest items have been identified and broken down where necessary.
  • With the need for customer validation made more visible, new feedback loops begin to emerge.

Different attitudes toward the Scrum practices and roles will of course lead to different outcomes. It’s not unusual for teams to go through changes of the kind described here and for them still to identify themselves with Scrum. That’s completely fine with us—it’s “Kanban with,” not “Kanban versus.”

The team I’m currently [mid 2014] working with as its interim development manager is a long way down this path. The planning rhythm is still there and I’m in no hurry to see it disappear. The highlight of my working fortnight is the “Show and Tell” (the sprint review), a lively meeting in which the project team is outnumbered by customer representatives and outside observers (as a “digital exemplar,” one of a number of pioneering citizen-facing projects delivering services online for UK Government departments, we often receive visitors from other departments and public agencies interested in how we do things). Not only do we review progress and show what we’ve recently built, we often review pertinent videos of outside customers interacting with the live system or with prototypes. These are highly motivating—sometimes even moving—and the shared experience adds to its impact.