David Anderson has written about a set of core practices for Kanban adoption that go from shallow to deep:
- Visualise the work and work flow
- Limit WIP
- Manage flow
- Make management policies explicit
- (NEW) Implement feedback mechanisms
- Improve collaboratively using models and the scientific method
Based on his experiences, Hakan proposes a new ordering:
- Visualise the work and work flow
- Make management policies explicit
- Manage flow
- Limit WIP
- Implement feedback mechanisms
- Improve collaboratively using models and the scientific method
The difference is the ordering of "make management policies explicit", "manage flow" and "limit WIP".
Hakan's proposal matches my own intuition and experience.
I typically describe the point of visualisation and making things explicit as both falling under an overall umbrella of creating a shared understanding of the current situation. This is beyond just work, work flow, and policies, I will almost always also look at how to visualise the current capabilities within the team.
I would actually simplify this even further though by borrowing from Steven Spear, we need to setup an environment that allows us to...
- See our work, work flow, policies, and capability
- Learn in a disciplined fashion (i.e., science)
- Share our learning
Regarding the changing of the order, does the new "radar chart" approach to measuring maturity level actually indicate (and allow for) parallel execution/monitoring of the practices?
ReplyDeleteI find that as soon as I get involved with a client, we start to implement all of the practices to one degree or another. For example, I almost always make a card wall (visual), which I also view as an explicit description (policy) of how the team works. We'll then try some initial WIP limits, start making some other policies explicit (e.g. queue replenishment), start our CFDs, and many other activities as we start to build out our Kanban Method implementation.