It’s
been so exciting to hear so much positive feedback and interest in the new
Scrum.org Kanban Guide for Scrum Teams
and the accompanying Professional Scrum with Kanban class. Creating the class
and guide together with Daniel (Vacanti) & Steve (Porter) and then working
on getting it to market in a professional way (how else?) with the Scrum.org
staff has been a great experience and a major focus area for me in the last
couple of months.
As
you might imagine, together with the interest come some questions about some
choices we made in the design of the guide and the class. Several are emerging
as the frequently asked ones. I wanted to tackle a couple of those in this
post.
Where
are some of the core Kanban practices?
The
major one we’re getting comes from people who are experienced Kanban
practitioners who notice that how we describe Kanban in the Kanban guide for scrum teams in professional scrum master training is different than
the definition they’re familiar with. (Including my Kanban Primer for Scrum
Teams blog post for example…) This isn’t an oversight. It’s by design. When we
set out to create the Kanban Guide for Scrum Teams/approach we had a specific
context in mind. That context is teams using Scrum according to the Scrum
guide, ideally professionally.
In
the Kanban Guide for Scrum Teams, we focus on helping in this context. These
teams already have a collaborative inspect and adapt experimentation process
together with a set of explicit feedback loops they’re using. So, we set out to
define the minimal simplest set of Kanban practices that these Scrum teams
would need to add in order to achieve steadier, healthier, more sustainable
flow (I like to say it is like moving from a sprint that looks like a swamp to
one that looks like a river).
After
some discussion we decided that these practices actually complement what a
professional Scrum team is already doing:
· Visualization of the workflow
· Limiting WIP
· Active management of work items in progress
· Inspecting and adapting their definition of
"Workflow"
While
we agree with the importance of “Improve Collaboratively (Using models and the
scientific method” and “Implement feedback loops” we think they are redundant
in a professional Scrum context.
Where
are some advanced Kanban concepts like Classes of Service, Cost of Delay, Flow
Efficiency?
They’re
not part of the guide because we don’t consider them part of the “Minimally
viable set of practices” a Scrum team should focus on when trying to improve
their flow. Having said that, our guide and especially the PSK class provides
people with some pointers towards advanced complementary Kanban/flow
practices/metrics that at least some can use to continue their learning and
improvement journey.
Beyond
that - Some of them might be useful in some Scrum contexts, some less so.
Is
this an application of the Kanban Method or not?
In
my personal view, it is pretty close, as long as you assume professional scrum
is your starting point. (see a blog post I wrote back in 2012 about this
context). You are starting with the way the team uses Scrum and with respecting
their current Scrum process & roles. You are obviously interested in
pursuing an incremental evolutionary change to improve your performance and
satisfaction with your process beyond what you’re currently achieving with Scrum.
There is that argument that limiting your work in process is far from being an
evolutionary change but rather a disruptive revolution. My personal take on it
is that yes, limiting your work in process and moving to a disciplined pull
mode is far from being easy, but it’s still evolutionary compared to changing
team structures, roles, process flows. And in any case, this is an argument
about the Kanban Method outside of a Scrum context as well. A professional
Scrum team should actually have an easier time limiting WIP than most.
Is
this ScrumBan?
Depends
who you ask. Some people’s definition of ScrumBan is “A way to help teams’
transition from Scrum to Kanban”. This isn’t what we’re talking about here.
Another
definition (that I subscribe to) is to see ScrumBan as a way to introduce
Lean/Kanban flow into a Scrum context – while keeping the core Scrum process
intact. This is pretty similar to our take on the process Scrum teams will
typically take to get to an effective combination of Scrum and Kanban.
Finally,
a variant on this definition is to see ScrumBan as simply the Scrum+Kanban
combination itself, without worrying about your starting point and journey.
This, in my view, is indeed what the Kanban Guide for Scrum Teams describes.
Why/When
should you add Kanban to Scrum?
The
last question I want to tackle is one of the first you might want to think
about. Essentially the question is “Why bother? Isn’t Scrum great as is?”
Most
of the teams I’ve worked with since 2010 or so find Scrum+Kanban to be the
ideal mix. I’ve helped Scrum teams achieve an even healthier smoother flow by
adding Kanban to their process. I’ve helped Kanban teams accelerate their pace
of improvement by adding cadence/rhythm and clarity. I’ve helped teams look
beyond their Sprint at the end to end flow all the way from idea to outcomes
using a Kanban system. I’ve helped organizations manage the flow across several
Scrum teams using a Kanban system.
When
a Scrum team wants my opinion on whether adding Kanban would be a good idea I
typically ask them to think about how hard it is for them to Sprint and whether
they feel like they have good flow during the Sprint. (And like I mentioned
above - do they feel like their process is a swamp or a river). It’s as simple
as that. I find most Scrum teams struggle to achieve good sustainable healthy
flow and Kanban tends to help them with that.
When
is Kanban with Scrum a bad idea?
Some
Professional Scrum Trainers asked “When would it be a bad idea to introduce
Kanban to your Scrum? What are some indicators that you should stop using
Kanban as part of your Scrum?” I can’t think of any team where I thought they
should stop using Kanban. If they understand Kanban and do it well, there’s
really little that can go wrong. The problems start when they don’t understand
Kanban or use it as an escape from the challenges of Scrum. Yes, Kanban can
help you make your Scrum more sustainable and healthier, but please don’t add
Kanban if you’re looking for an escape from the difficulties. Kanban done well
adds discipline to your Scrum. Another bad time to introduce Kanban is when the
team isn’t looking to improve. If things are working well or more importantly
if the team perceives things as working well, they won’t have the energy needed
to successfully add Kanban to their process. So make sure you agree on pains/motivations
before you move forward to implementing something like Kanban.
Kanban
- A way back to Scrum!
To
finish with scenarios where introducing Kanban IS a great idea – It pains me
every time I see a team/company using Scrum as a new variant of “project
management command and control” focusing more on tasks, story points, velocity
and burndown than on empiricism leveraging Done Increments of potentially
releasable product.
What
I’ve noticed is that introducing Kanban ideas helps these teams/companies
finally understand what Scrum really is about and shed a lot of the unnecessary
and even harmful baggage and instead refocus on the transparency, inspection,
and adaptation brought to life by the core Scrum events, roles, and artifacts.
Pretty amazing isn’t it?
Interested
to learn more about how Kanban and Scrum make each other better together? Join
a public Professional Scrum with Kanban class or request a private training for
your team.
Resource: https://www.scrum.org/resources/blog/understanding-kanban-guide-scrum-teams
