Starting Kanban

The Kanban Method is the stated method of starting Kanban. In working with hundreds of clients, of all sizes and types, we have found that the Kanban method is not the best way to always start with (see Why You Need a Hybrid System).  If one studies Lean, there are three steps to creating balanced flow:

  • teamwork
  • workflow
  • kanban

We believe starting to use Kanban Software development should include all three of these, not just kanban as in the Kanban Method.  Teamwork means to start teams if possible. While an attractive aspect of Kanban is that it doesn't require teams, that doesn't make teams any less valuable if they can be formed.   Most teams or work groups develop software in the wrong order.  They do analysis, design, code, and then test.  Test-first is very critical.  Test-first at the story level is known as Acceptance Test-Driven Development.  It changes the order of the workflow and is a much more effective way of developing software.  There are few places where ATDD isn't something to start as soon as possible.

It is usually easier to get cross-functional teams and do ATDD than it is to get agreements on WIP limits.  Given these have a more beneficial impact, we definitely recommend doing them if possible.  Thus, the steps to start Kanban that we believe should be followed are:

  • Agree to goals
    • Purpose of pilot and how people on pilot will be used
    • Get agreement to use MBIs if possible
  • Map the value stream
    • Define where you start
    • Define where you finish
  • Can teams be created?
    • True teams
    • Core / extended (full time, rotating, virtual)
    • Virtual
  • Define a set of work item types
    • User stories
    • Bugs
  • Meet with external stakeholders
    • Agree to input cadence
    • Agree to delivery cadence
    • Set WIP limits (if possible)
  • Create board for tracking
  • Does team agree ATDD would be useful?
  • Agree to standup
  • Agree to operational review
  • Educate the team
  • Start doing it