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.”
Martin Fowler
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.”
Martin Fowler
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.)
Conclusion?
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.
I’m wondering to what extent I can find an answer to this question that is generally valid for different teams, projects and contexts and instead to what degree the answer can change based on the context, team and project.
And how the context, the characteristic of the team and of the project can influence this?
The reason why a team make the change can also be an interesting source of information to dig into this matter.
Hi Luca!
You’re right, a general answer is moot.
I guess my underlying question was, whether you guys see this pattern, too? (Mature Scrum teams evolving / adopting a flow-based approach; ditching the clocked one.)
Have you ever seen it?
I remember a 3 years experience where teams used ideas an practices from XP, Scrum, Lean (and Kanban as part of Lean) and Complexity.
Some development was inherently time-boxed because external events, and some was more a continuous flow (a la XP and Kanban way).
Practices and ideas from different methodologies were more an opportunities for us to improve our way of working and were investigated one after the other without a distinction between the framework/methodology they came from. There wasn’t a transition here to or from Scrum or Kanban. The adoption of new ideas was for sure a path to team maturity / improvement.
I remember 2 other cases where the idea of a transition from Scrum to Kanban was more explicit. In one case Kanban was a way for management to increase control from a sprint level to a task level. In the other case Kanban was a way for the team to avoid estimations that were seen as cause of friction between management and the team.
In both case the reason for the transition was a way to avoid the real obstacle. Becose of this I suppose both Scrum and Kanban was somehow misused here so I don’t think these two cases give me some info about Scrum and Kanban themselves.
What differences you see between a general answer and a pattern?
What are the assumption required in order for the emergence of patterns to be possible here (with different teams, different organizations, different domains/projects, different knowledge/understanding/experience of Kanban and Scrum) ?
I have 2 comments. First it doesn’t make much sense to talk about “switching from Scrum to Kanban” or vice versa. Scrum is a framework for allowing a team to develop complex products. Kanban is a method that can be applied to an existing value chain to assist with evolutionary improvements.
Usually when people talk about switching from Scrum to Kanban they mean 1 of 2 things. First maybe Scrum has identified problems such as team interdependencies or something, and instead of fixing the problem they say Scrum doesn’t work here. So they remove the iterations and call it Kanban. The other thing they often mean is a team may start developing software with Scrum, and they want further improvement across the wider value stream so they implement a Kanban system to help with this evolutionary improvement effort. But it is no switch, the software is still being developed with Scrum, it is just that Kanban is also existing at a different level. Maybe Kanban will eventually steer the software development process so that it is no longer Scrum, maybe not. But it is hardly a switch.
I cannot see how it makes sense to talk about switching from Kanban to Scrum either. Perhaps the team is developing software with some other framework or process, maybe Waterfall, Evo, XP or FDD or something, and they apply Kanban to that to assist in the evolutionary improvement, and through a series of Kaizen events the software development parts of the process evolve to a stage where the requirements in the Scrum Guide are satisfied. Probably because someone thought that Scrum would be better than whatever was there before and used Kanban to help introduce Scrum. And then they would have to stop using Kanban. I suppose it could happen like that. It wouldn’t really be a switch from Kanban to Scrum however, it would be more of a case of using Kanban as part of an effort to introduce Scrum in the software development part of the process.
Also I think Scrum covers both Shu and Ha teams, but most of the literature focuses on its use in Ha teams i.e. it assumes a self-organising team. Scrum in Shu teams, i.e. teams that have not yet reached a level of maturity where they can solve their own problems, look a bit different because the Scrum Master is providing more direction than an agile coach would usually like to. For example with a Ha team, the Scrum Master would likely just ask questions and the team would discover a good solution themselves. For a Shu team, they don’t yet know what good solutions look like so the Scrum Master would just say, “look, many agile teams have success with this so lets try it and see if it works for us”. If I remember correctly Alistair Cockburn wrote about this in his book The Cooperative Game.
I think Kanban is similar and suffers the same issue. The community also assumes a Ha level understanding not so much of self-organisation but of Kanban-compatible decision making and process improvement, that is why there is a lot of focus on a neutral coaching style. However for Shu level companies, companies that still use Theory X management etc, this will lead to disaster. You need some Kanban thinkers providing strong leadership at the beginning until people learn what sort of decisions are going to work with Kanban and which will not.
Hi Kurt!
Thanks for your thoughtful comment!
What you describe (that teams usually don’t switch, but the overarching structure) is not what I’ve seen / heard about. I really meant an single team evolving from the rigid structure of Scrum towards a flow-based approach. This can happen without an explicit switch, because Scrum can be evolved into this; but the switch is often inspired by Kanban literature.
(Also I’m talking about teams that had some degree of success with Scrum prior to “going flow”, so not those who just try to ease the pain of the sprint timebox.)
I absolutely agree with you on the latter part! You probably know it already but other comment readers might not, so here’s one of my favorite links about the topic of team maturity: http://5whys.com/blog/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html
I agree with Kurt here. What you probably see is a switch to Scrumban or giving up some of the Scrum constraints like sprints for whatever reason (maybe inspired by Kanban literature). But Kanban is more than that, it is a scientific method based on measurements and experiments. And this part is often missing.
@Luca: Thanks for sharing your experiences!