Scrum vs Kanban Cheat Sheet - the mistakes!

This is the “Scrum vs Kanban Cheat Sheet”

Issue 1.5 of the “Scrum vs Kanban Cheat Sheet” to be precise.

It’s been downloaded 3,085 times.

And it's been through a bunch of iterations.

I thought I'd got most of the kinks out it.

Then, three days ago, I received a message. A message containing a whole list of corrections.

When I saw who it came from, I sat up and took notice.

It came... from Scrum!

The message contained six points in all. Shall we take a look?

One - Sprint Planning

**‘Sprint Planning is part of each Sprint: "A new Sprint starts immediately after the conclusion of the previous Sprint."’***

I confess I was never clear on this; I’d assumed that the Sprint started after Sprint Planning.

On this one, I stand corrected.

Two - Lead Developer

‘There is no Lead Developer role or title in the Scrum framework.’

True. (Although, there’s no Lead Developer role - or any role at all - in Kanban.)

But I do take the point.

The “Lead Developer” role appears on the Cheat Sheet in a few places. In most - if not all - cases, swapping “Lead Developer” for “Development Team” would make more sense.

Three - "Facilitate", not "run"

‘Neither it nor any other event is "run by the Scrum Master" as he is not a manager/boss though he may facilitate the event.’

Scrum’s right: there’s a world of difference between “is run by” and “may be facilitated by”.

Four - Continuous Delivery

‘Continuous delivery is permitted and often encouraged.’

This is a good catch.

My first Scrum team wouldn’t have dreamed of releasing more than once a week - such was the pain of releasing at this "major broadcaster".

But in more recent times, I’ve been in Scrum teams that were comfortable with multiple releases per sprint. And even with continuous delivery.

Five - More than a Demo

‘There is a Sprint Review which is much more than a Demo.’

I went straight to The Scrum Guide to check it out.

Turns out, the term “Sprint Demo” isn’t in the Scrum Guide. Never was.

And what appears under “Sprint Review” is more that a demo. Much more. Far more!

And finally

Five down. One to go:

‘WIP limits do not "ensure that items move across the board in the shortest possible time." It can affect cycle time due to increased focus and decreased context switching.’

Ah. Now. Here’s where I have to disagree with Scrum.

Focus and context switching are certainly factors.

(We’ve gone into detail about context switching before here on Development That Pays.)

But they’re second order factors.

Let me see if I can show you.

Three cups. WIP limit of three.

Move each in turn.

After three moves, all three have moved... a little.

Let’s run that again, this time with a WIP limit of one.

This time, one cup moves a long way - all the way across the board. Ready for release.

We have a winner. Context Switching was not a major factor.

Bottlenecks

I should mention that Scrum went on to say this about WIP limits:

‘One of the biggest benefits is identifying bottlenecks in the pipeline’

And on that point, Scrum and I are in complete agreement.

New Improved Scrum vs Kanban Cheat Sheet

My thanks to Scrum for making this episode possible, and for helping me to improve the “Scrum vs Kanban Cheat Sheet”

If you’re yet to grab your copy, what are you waiting for?! It’s better than ever!