Scrum and Kanban revisited

Update: See the August 30 webinar of Steve Porter and Dan Vacanti entitled Scrum and Kanban: Make your teams better by busting common myths [scrum.org]. It's great to see such a collaboration, and I'm happy to acknowledge that they are the original source for the 6 titles below (not the content – which remains mine). My apologies to Steve and Dan – unintentional mistake, I should have dug a little deeper.

Late last week, I was invited by Fasih Sandhu to share my reactions to a post LindedIn about Scrum and Kanban. My initial reaction was “Oh here we go again, 2012 here we come”, but I ended up leaving a comment long enough that I had to edit it to fit. Here's a director's version! I don't suppose this will solve the issues once and for all, but it does at least give an opportunity to explain how someone who has engaged in thoughtful integration approaches the subject.

Do you think that combining the principles #Kanban Framework practices #Scrum improve collaboration in your agile teams?

Space did not allow me to address this question on LinkedIn, but if there had not been "improve collaboration in your agile teams" in the sentence, I probably wouldn't have committed to it at all.

To understand why this sentence was so crucial, here is Agendashift's True North [1]:

Everyone able to continually work to their best: 
 • Individuals, teams, between teams, across the organization
 • The right conversations, the right people, at the best possible time
 • Anticipated needs, met at just the right time

I'm interested in improving collaboration not just in agile teams (as in the question), but across teams (of any gender) and across the organization – the right conversations happening between the right people at the best possible time, where whether in the organization or outside if necessary. Do I believe a combination of Scrum and Kanban can help produce this? Yes I believe it, and I can point to many projects where I have been able to witness it.

In about a week, I will be participating in an event on #Scrum versus #Kanban and I would be interested in the reaction of my LinkedIn followers to the claims that will be discussed there:

1) Scrum is for “product” teams; Kanban is for service teams
2) Scrum is for complex work; Kanban for simple work
3) Our Scrum team evolved into a Kanban team
4) We do Scrumban
5) We do Kanban because we can't plan a full Sprint
6) Scrum is revolutionary; Kanban is evolutionary

Oh my God. “Scrum versus Kanban”. We go back to 2012. Let's go:

1) Scrum is for “product” teams; Kanban is for service teams

Quick reaction: Ugh. Propaganda (at best based on an error in logic, at worst a lie based on misdirection).

A longer answer, explaining the sentence above, but leading to a far less controversial conclusion:

Yes, Scrum is, by design, for “product” teams. Scrum.org describes it as "a management and control process that reduces complexity to focus on building products that meet business needs". No debate here, and in this context it is well understood and well documented. For some it's the framework of choice, for others a good starting point or something to be familiar with.

Is Scrum designed for service teams? Not really. Can Kanban help in this case? In other words, can service teams benefit from Kanban visual management, control over work in progress, collaborative improvement driven by process feedback, etc, etc? Many can and many benefit!

What is also true (and this is what makes this statement so frustrating) is that visual management, control over work in progress, collaborative improvement driven by process feedback… are also very useful for teams. "product", whether they use Scrum or not.

So… Kanban isn't just for service teams, and Scrum and Kanban aren't 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 for simple work

Quick reaction: Double ugh. Like question 1, but with a dose of Appeal to Authority in it.

I could give an extended answer here, but suffice it to say that if you don't understand what both Scrum and Kanban are looking for - in their own way, both technically and philosophically - to help their organizations (not just their products ) to evolve in the presence of internal friction and external competitive pressure, then you don't understand them well at all, nor Agile, Lean or Lean-Agile for that matter.

3) Our Scrum team evolved into a Kanban team

Positive, negative, or mixed reactions could be appropriate here – it's hard to comment on this one without knowing the specifics of the scenario.

Unfortunately, a statement like this can mean a lot of things, from "We stopped doing a lot of Scrum-related stuff and we don't really know what we're doing" to "We now use some number of new techniques in search of flow, leaving behind old practices once it has been established that it is safe and effective in this sense”.

Minor technicality: By design of the two, a "Kanban team" is not as well defined as a "Scrum team".

4) We do Scrumban

As documented [2, 3, and elsewhere], my Scrumban experience has been very positive.

To celebrate the Scrum part, the teams I've worked with have greatly appreciated the sprint focus in the early days of each project; for organizations not used to producing things quickly, the experience can be amazing!

Regarding the Kanban part, it has greatly helped in the quest for an end-to-end flow (see my answer to question 3 above). It's not just better task management, it's integrating a process that begins long before development and ends long after release to production.

I'm delighted to say that Scrumban is much better documented today than it was before; look for example at my friend Ajay Reddy's book [4] and (from the same stable) some tools [5, 6].

5) We do Kanban because we can't plan a full Sprint

Quick reaction: I find it difficult to see this as anything other than a lame excuse.

Every team is subject to sources of unpredictability – in fact most teams seem to generate a lot of these elements themselves! And yet, there are so many things that remain under your control:

• How often you plan is up to you (hint: choose an appropriate sprint length)
• Whether you plan with or without wiggle room is up to you (hint: take wiggle room)
• Your confidence in your plans is up to you (hint: understand that this is crucial to the planning process, and your choices here should be informed by both ability and need)

6) Scrum is revolutionary; Kanban is evolutionary

Quick reaction: There's some truth in that, exaggerated for effect, but not in itself a useful value judgment.

Scrum is revolutionary if you haven't done anything else before. Over time and as there is more and more about it, it will become less and less groundbreaking, (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 to an organization allergic to transparency!

Frankly, discussions about what does or does not constitute evolutionary change quickly become sterile, and in any case I don't believe it's a sensible basis for serious decisions about tool integration (and whether you like it or not, any successful Agile adoption is an integration, not just a selection). That's why these days I prefer to take a more principles-based approach: Start with the needs, Agree on the results, 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] Get Scrumban
[6] Scrum Do
[7] Agendashift in 5 principles
[8] (Non-)Prescription, frameworks, and expertise