Starting With Kanban

The Kanban Method is a particular approach to Kanban espoused the Lean-Kanban University. It is more Theory of Constraints than Lean in that it does not attend to the structure of the teams. It suggests starting where the team is and moving forward in small increments. While this avoids resistance, it risks stagnation and the immediate improvement that may come from some obvious changes. We have found that the Kanban method is not usually the best way to always start with. If one studies Lean, there are three steps to creating balanced flow:

  1. Teamwork
  2. Workflow
  3. 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:

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