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.
[…] article take a different approach and shows how a well lubricated and performing Scrum team can benefit […]
Are you starting with canonical Scrum because the organisation is already pushing it or are you doing it because you think it helps develop people more effectively?
Generally because that’s what the organisation wants, thinks it needs, or has been sold.The jury is still out on whether I would choose this approach given a free reign.
What do you mean by ScrumBut?
I am interested in how you stop teams “struggle” against impediements. That doesn’t sound like great coaching to me.
I’m using the common uage of ScrumBut. For example, “We do Scrum, but we have a separate team implement an architectural layer”.
Not sure what you think isn’t great coaching. I try to allow teams to succeed whatever way they think is best and are comfortable with, rather than sticking to something which they dislike or causes too much friction. They key for me is success.