In my filter bubble there is this trend of teams switching to Kanban after they’ve used Scrum for a while. Typically they had been successful with Scrum and switched to Kanban, when they felt they’d taken Scrum as far as possible. After the switch they do even better.
I’ve never heard of a team switching in the opposite direction – from Kanban to Scrum – yet. That might be due to the fact that Kanban (for software development) is a decade younger than Scrum, but I don’t think that’s it.
Lately I’ve been wondering whether Scrum is a Shu-stage of agile development:
“Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory.”
With Scrumban and Kanban signalling a step in evolution for a team; the HaRi-stages:
“Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
Ri: Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.”
Let me elaborate on that:
Hypothesis 1: A flow-based process (as in Kanban) is more “natural” than Scrum’s iterations
One of the main complaints of Scrum teams is the fitting of stories into sprints. That if you want to make sure to finish everything, you’ll have idle time at the end. In immature teams you often want that “idle” time, because there are useful activities to fill this time that the team isn’t used to yet (e.g. testing, documenting, preparing the demo, …). But the complaint resurfaces in mature teams and seems to be the major driver behind the switch to Kanban. Afterwards the (sub-)teams just work on and finish a story in however long it takes, then pull the next.
Also, a step towards less rules (without falling into chaos) strikes me as more “agile-y”.*
Hypothesis 2: Scrum teaches many best practices (that teams keep after the transition)
Scrum prescribes many good practices that will benefit a team regardless of the process it’s following, such as: daily meetings to co-ordinate, splitting tasks, discussing tasks before and after implementation, agreeing on what “Done” means, and many more.
Doing these will usually have teams a) acquire good habits and b) eventually lead to an understanding of the effects of these practices. Many of these get carried over to Kanban, when a team switches.
Hypothesis 3: Scrum is a good choice for agile beginners
Scrum carries a lot baggage: its own vocabulary, many meetings and unfamiliar roles. But being very prescriptive makes it easy on beginners: Out of the million combinations of agile methods a team could adopt, Scrum takes a reasonable set to start from. Rules are reassuring. Decisions one doesn’t have to take, make it easier to concentrate on the behaviours themselves.
[Note: Scrum is not a good choice for teams that have a lot of maintenance and support duty, no matter their agile noob level.]
Hypothesis 4: A team that is successful with Kanban after first using Scrum, might not have been successful if they had started with Kanban right away
If you’ve ever talked to me about agile topics you’ve probably picked up that I’m not a devout Scrummer. I’m not bashing Scrum either, I just don’t think Scrum is all it’s cracked up to be (What is ever? Except for Nutella. Nutella’s awesome!). But Scrum has one great ingredient that makes it harder to “cheat”: Sprints.
In my experience you can more easily keep stuck in your old ways starting Kanban than starting Scrum. Scrum enters with a bang and turns the heat up right away. Hey, other teams all over the world can implement and deploy software in 2-week or even 1-week iterations. So if you can’t, you better find out why not and fix it. Fast.
Compared to that, Kanban is more patient and if done sloppy, things stay exactly the way they were before. Just that the team now has a Kanban board. (Yeah, that can also happen with Scrum, but in Scrum there’s usually more people noticing a “fake” implementation.)
I think the trend of mature Scrum teams tweaking their Scrum towards Kanban or switching altogether will continue. In Germany we have the uncommon situation that Scrum is just now becoming widely popular, at the same time that Kanban is picking up the pace. I’m curious to see what happens, if more dev teams start out agile* with Kanban, instead of Scrum …
What do you think? Have you got experience with Kanban-first dev teams?
* Yeah, I know Kanban is Lean, more than Agile, but I didn’t feel like splitting hairs. I’m in a very “everything’s connected”-mood, lately…
PS: Last year, Stefan Roock wrote an article about ShuHaRi stages within Scrum, that shares some observations with this one.