- Scrum.
Kanban.
Scrumban.
If you've found this video,
chances are you are just searching
for one or perhaps more than one of the above.
If so, I have a great episode for you
and not one, but three
rather lovely cheat sheets.
Hi, my name is Gary Straughan.
Welcome to Development That Pays,
the number one Agile channel on YouTube.
If we're meeting for the first time
and you like what you see here,
please consider subscribing,
and remember to hit the bell
so you don't miss a thing.
Let's get right to it with the easy one, Scrum.
Scrum traces its history back to 1986.
Mr Schwaber and Sutherland
and sometimes Beedle evolved it
over the course of a decade
with the Scrum Guide making its debut in 2010.
The Scrum Guide was a master stroke
helping to propel Scrum to its current position
as dominant Agile framework.
It's free, it's freely available,
meaning that the vast majority of teams
that claim to be doing Scrum
will at the very least be aware
of the Scrum Guide, and should have
a pretty good idea of whether
what they are doing is or is not
Scrum Guide compliant.
Although Scrum has many moving parts
it's not prescriptive.
It tells you roughly what to do
but doesn't tell you how.
It's framework rather than methodology.
Let's just enjoy that clarity for a second.
Scrum is a framework definitely.
Moving on to Kanban.
Now Kanban, at its root, at its heart, at its origin
is neither framework nor methodology,
it's a set of principles.
These principles.
Visualize the work, limit work in progress,
focus on flow, continuous improvement.
Because it is a set of principles,
Kanban has wide application
from factories to shops, to restaurants,
to coffee shops, and many more besides.
Kanban is far older than Scrum
tracing its roots back to the 1940s.
But it wasn't until the noughties
that it made its presence felt
in our Agile world.
In 2004, David J. Anderson published
Kanban Method, followed in 2010 by this book.
Kanban: Successful Evolutionary Change
for Your Technology Business.
Have we found Kanban the framework?
Let's see what the author says.
"I describe Kanban, capital K,
"as the evolutionary change method
"that utilizes a kanban, small k, pull system,
"visualization, and other tools
"in order to catalyze the introduction of Lean ideas
"into technology development and IT operations."
Hmm, method, not framework.
That kind of puts me in a bind.
On the left, Scrum.
Definitely a framework
and, thanks to the Scrum Guide,
a well-defined framework.
Sharp focus.
On the right, Kanban, out of focus.
In the decade or so since this book
was published we might have expected
a Kanban Guide, something to bring Kanban
the framework into sharp focus.
But it hasn't arrived.
So the Kanban framework is perhaps
more concept than concrete
but it's a useful concept all the same.
On this channel I often talk about Scrum
and Kanban, the Agile frameworks.
And although there is no Kanban guide
if your team plans to do Kanban,
then this is the book that I would recommend.
Unless that is you're currently doing Scrum.
David J. Anderson wasn't the only one
back in the noughties
applying those Kanban principles
to Agile development.
In 2008, Corey Ladas threw his hat
into the ring.
His paper Scrum-ban was followed
a year later by this book, Scrumban:
Essays on Kanban Systems
for Lean Software Development.
If you've heard the word Scrumban before
perhaps you assumed, as I did,
that it represents some kind
of hybrid, a halfway house perhaps
between Scrum and Kanban.
Read the book and it's clear that Ladas,
like Anderson, is all about those Kanban principles.
But unlike Anderson, Ladas defines
a very specific starting point, Scrum.
Three things to say about that.
Number one.
I think that was really a smart move
on Ladas's part to take aim at where the activity,
where the noise was in the Agile community
at that time, of course in Scrum.
Number two is that I don't consider
Scrumban to be a framework as such.
I much prefer to describe it as a pathway,
a pathway that starts at Scrum
the framework, and ends, well,
I think we could say at Kanban
the conceptual framework.
And number three,
if you're currently doing Scrum, then Scrumban
has a surprising amount to offer you.
I'll talk about that in just a second
after the small matter of the cheat sheets.
This is the Scrum cheat sheet.
In the description below you'll find a link.
Click the link, enter your email address,
and I'll get a copy of this to you.
If you're watching this in the future
you may also find a Kanban cheat sheet.
I don't have one at the time of recording
but what I do have is a Scrum versus Kanban cheat sheet.
Again, link in the description below.
And last but by no means least,
you will also find a link to this,
the newly updated Scrumban cheat sheet.
Again, follow the link, enter your email address,
and it is all yours.
Okay, back to the action.
Where were we?
Ah yes, benefits of Scrumban to you
if you are currently doing Scrum.
As I said, this book is aimed directly at you.
If you pick up the book and follow it
all the way through to the end
you'll no longer be doing Scrum.
But you don't move away from Scrum
until more than halfway through the book.
The first half and a bit
is all about applying
those Kanban principles to Scrum,
while remaining, I hasten to add,
100% Scrum Guide compliant.
When I figured that out
I went all in on Scrumban.
Not content with a cheat sheet
I created a fully-blown course,
The Scrumban Blueprint with a 2.0 version
of that course due out shortly.
If you're watching this in the future
it may be available now.
Check the links for more details.
If this notion of augmenting Scrum
with Kanban principles makes you feel
a little uncomfortable,
it may interest you to know that in 2018
Scrum.org got in on the act
and published the Kanban Guide for Scrum Teams.
So what do you reckon?
Are you open to the idea of augmenting Scrum
with Kanban principles?
Let me know in the comments below
and keep watching.
These may be of interest.