Kanban Trail Markers

When talking about Kanban Systems for Software Development, I always try to emphasis that the Kanban System is more than the tool, and is a System that should be owned by the team, rather than being imposed upon it. By owning it, and being part of creating it, a team are more likely to evolve the system as part of continuous improvement. Recently, I tried a new analogy to make this point, and while its not perfect, I think its good enough to blog about for further feedback.

The Primary Practices of Kanban that I describe, are not Boolean practices that teams either do or don’t use. Rather they are practices that teams should be constantly revisiting, and re-implementing, as they improve and their context changes. To recap, the primary practices I talk about are:

• Map the Value Stream
• Visualise the Value Stream
• Limit Work in Progress
• Establish a Cadence
• Reduce the Kanban Tokens

I currently describing these practices as like trail markers on the team’s journey of process improvement. At any point in time, the team’s Value Stream, Visualisation, WIP Limits, and Cadence identify where the team currently is, and when combined with Kanban Reduction, point the way forward. As when on a hike, only the group knows where it is, and only the group can decide where it should be going. The hiking group must work together, helping each other out and making sure that everyone reaches the destination. If you’ve read Eli Goldratt’s “The Goal” you’ll recognise the comparison to the one he uses.

Where the analogy breaks down is that a team’s trail markers are only ever unique to that team. They cannot be followed by other teams. Instead, they will only show the journey the team has been on in their quest for success.