Introduction
More and more Agile teams have started to adopt Kanban as a way to improve beyond what Scrum enabled them to do, as also to address some of the challenges that Scrum presented them with. As a result, many people have attempted to compare and contrast Scrum and Kanban in a variety of “Scrum vs. Kanban” sessions in conferences, webinars and online posts. As the article bemoans, this has been going on since 2012. As more Agile teams have adopted it, as it has found greater acceptance in the Scaled Agile Framework (SAFe®), these debates have only become more frequent.
We decided to initiate a short campaign from outside to bridge this discussion from our side and as the first step in that, I am honored to publish the article ‘Scrum and Kanban revisited’ by Mike Burrows, originally published on Mike’s blog – Agendashift. The article provides great insights on the Scrum and Kanban methods, especially the debate surrounding the two. Mike has, in his inimitable style, taken on some of the common myths and – as he puts it – propaganda – and addressed them head-on. I am sure you will enjoy it!
Cheers,
Mahesh Singh
Scrum and Kanban revisited
Late last week I was invited by Fasih Sandhu to contribute my reactions to a LinkedIn post on the topic of Scrum and Kanban. My initial reaction was “Oh, here we go, 2012 just called”, but I ended up leaving a comment big enough that I had to edit it down for it to fit. Here then is the director’s cut! I don’t for a moment suppose it will resolve the issues once and for all, but it does at least give an opportunity to explain how someone committed to thoughtful integration approaches it.
“Do you think that combining the #Kanban principles and practices with the #Scrum Framework will enhance the collaboration across your agile teams?”
Space did not permit me to address this question on LinkedIn, but had it not contained the phrase “enhance the collaboration across your agile teams” I would likely have not have engaged at all.
To understand why this phrase was so crucial, here’s the Agendashift True North [1]:
I’m interested in enhancing collaboration not just across agile teams (as per the question), but between teams (of all kinds) and across the organization – the right conversations happening between the right people at the best possible moment, wherever in the organization or outside of it they happen to reside. Do I believe that a combination of Scrum and Kanban can help to deliver this? Yes, I do, and I can point to multiple projects where I’ve witnessed it happen.
In a week or so, I will be attending an event on #Scrum versus #Kanban and I am interested to the reaction of my LinkedIn followers to any of the following statements that will be discussed in that event:
- Scrum is for product teams; Kanban is for service teams
- Scrum is for complex work; Kanban is for simple work
- Our Scrum team has evolved to become a Kanban team
- We do Scrumban
- We do Kanban because we can’t plan out for an entire Sprint
- Scrum is revolutionary; Kanban is evolutionary
Oh dear. “Scrum versus Kanban”. 2012 really is calling. Moving on:
1) Scrum is for product teams; Kanban is for service teams
Quick gut reaction: Ugh. Propaganda (at best based on an error of logic, more bluntly a lie based on a misdirection).
Longer answer, explaining the above but leading to a much less controversial conclusion:
Yes, Scrum is, by design, for product teams. Scrum.org describes it as “a management and control process that cuts through complexity to focus on building products that meet business needs”. No argument there, and in that context it is well understood and well resourced. For some it’s the framework of choice, for others it’s a good starting point or something you have to know.
Is Scrum designed for service teams? Not really. Can Kanban help there? In other words, can service teams benefit from Kanban’s visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc? Many can and many do!
What is also true (and it’s what makes this statement so frustrating) is that visual management, controls on work in progress, collaborative, feedback-driven process improvement, etc, etc are also highly useful to product teams, whether or not they are using Scrum.
So… Kanban is not only for service teams, and Scrum and Kanban are not mutually exclusive. Boring, but true! And can your product teams afford to ignore the service dimension anyway? Probably not, and some would even start there…
2) Scrum is for complex work; Kanban is for simple work
Quick gut reaction: Double ugh. Like question 1, but with a dose of Appeal to authority thrown in.
I could give an extended answer here, but suffice it to say that if you don’t understand that Scrum and Kanban both seek – in their quite different ways, both technically and philosophically – to help their organisations (not just their products) evolve in the presence of internal friction and external competitive pressure, then you don’t understand them, Agile, Lean, or Lean-Agile very well at all.
3) Our Scrum team has evolved to become a Kanban team
Positive, negative, and mixed reactions might be appropriate here – it’s hard to comment on this one without knowing the specifics of the scenario.
Unfortunately a statement like this could mean a whole range of things, ranging from “We stopped doing a bunch of Scrum-related stuff and we don’t really know what we’re doing” to “We’re now using a number of new techniques in a the pursuit of flow, leaving some older practices behind once we established that it was safe and effective to do so”.
Minor technicality: By the design of both, ‘Kanban team’ isn’t as well defined as ‘Scrum team’, but I can see how this arises.
4) We do Scrumban
As documented [2, 3, and elsewhere], my personal experience of Scrumban has been very positive.
To celebrate the Scrum part, the teams I worked with very much appreciated the focus of the sprint in the early days of each project; for organizations unused to achieving anything quickly, the experience can be amazing!
As to the Kanban part, this helped immensely in the pursuit of end-to-end flow (see my answer to question 3 above). This isn’t just better task management, this is integrating a process that starts well before development and finishes long after delivery into production.
I’m glad to be able to say that Scrumban is better resourced now than previously; see for example the book [4] by my friend Ajay Reddy and (from the same stable) some tools [5, 6].
5) We do Kanban because we can’t plan out for an entire Sprint
Quick gut reaction: I find it hard to see this as anything other than a feeble cop-out.
Every team is subject to sources of unpredictability – in fact most teams seem to generate a fair amount of the stuff themselves! And yet there’s so much that remains under your control:
- How often you plan is up to you (clue: choose an appropriate sprint size)
- Whether or not you plan with zero wiggle room is up to you (clue: don’t)
- The confidence you attach to your plans is up to you (clue: understand that this is crucial to the planning process, and that your choices here should be informed by both capability and need)
6) Scrum is revolutionary; Kanban is evolutionary
Quick gut reaction: Some truth there, exaggerated for effect, not on its own a useful value judgement.
Scrum is revolutionary if you’ve done nothing like it before. Over time and as there is more of it about, it will become less and less revolutionary, (a victim of its own success perhaps). And don’t forget that it has evolutionary goals (see question 2 above).
Kanban is often described as the easier of the two to introduce, but try introducing it in an organization allergic to transparency!
Frankly though, discussions about what does or doesn’t constitute evolutionary change quickly get very dry, and in any case I don’t believe that this is a sensible basis for serious decisions about tool integration (and like it or not, every successful Agile adoption is an integration, not just a selection). Nowadays therefore, I prefer to take a more principles-based approach: Start with needs, Agree on outcomes, and so on [7, 8].
References:
[1] A True North for Lean-Agile? (See also chapters 1 and 5 of [2])
[2] Agendashift: clean conversations, coherent collaboration, continuous transformation, Mike Burrows (yours truly) (2017, Leanpub)
[3] Kanban from the Inside (2014, Blue Hole Press)
[4] The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban, Ajay Reddy (2015, Addison-Wesley Professional)
[5] GetScrumban
[6] ScrumDo
[7] Agendashift in 5 principles
[8] (Non-)Prescription, frameworks, and expertise
This article was originally published on Mike Burrows’ blog – Agendashift – and can be found here – https://blog.agendashift.com/2017/08/29/scrum-and-kanban-revisited/
