I’ve noticed a pattern that I’ve found myself using recently when I’ve worked with new teams that makes use of both Scrum and Kanban ideas. I’ve already said that I believe the two are complimentary, and this should help show how.
- I’ll often begin with a “Canonical Scrum” implementation. This gives a relatively simple introduction due to the ubiquitous language, standard training and often client demand. I also find that its a very good way of quickly exposing the real underlying workflow. Stressing a team by introducing a new way of working soon makes the current way of working apparent.
- After a few Sprints,once the team understands both what the desired outcome is and the current context is, I’ll ease back into what many people might call “ScrumBut”. Rather than continuing to highlight and struggle against impediments and constraints which are out of the teams control, I will apply kanban aspects to help the team acknowledge, but deal with their context without feeling dogmatic.
- Finally I’ll help both the team and the organisation improve, by seeing where the issues are, whilst continuing to be able to deliver. Sometimes the current workflow is appropriate for the team and it is smaller batches and queues that are needed. Sometimes the current workflow is a symptom of silos and poor collaboration.
So I find Scrum to be a good way of showing teams what could be possible, and finding out where I can help make improvements. Then I find Kanban a good way of enabling a smoother transition for those improvements in a way which is appropriate for the teams’ contexts.