Scrumban Ideacamp - Amsterdam Scrum Gathering 2010

© 2010 Proyectalis Gestión de Proyectos S.L.
An approach to Scrumban
Whitepaper - Ideacamp
Reducing, measuring and controlling uncertainty

Disclaimer: this presentation is
meant for reading rather than
presenting…

Ángel Medinilla
 Telecom Engineer / vocational
programmer
 13+ years in industry, mainly as a
project manager & agile
consultant
 Entrepreneur, Blogger
 Motorbikes, Aikido, gaming,
books, travel, music, gourmet
cooking, wines, comics…
 Certified Scrum Master - PMI
Member - Agile Spain Co-
Founder
angel.medinilla@proyectalis.com
http://twitter.com/angel_m
http://es.linkedin.com/in/angelm
http://slideshare.net/proyectalis
http://www.presionblogosferica.com (spanish)
http://www.proyectalis.com/en/blog (english, upcoming)

This presentation is about combining
Scrum & Kanban

There are two main schools of
thought out there:
Scrumban & Kan-bum

Kan-bum guys do a full Kanban
implementation, but they add some
Scrum Liturgy

Selected.
Dev. Ready
Valid.
Pending
Integration
Done!
3
4
1 1
There is someone very similar to a Product Owner, and
sometimes (maybe on a weekly / monthly basis) he’ll call
for a prioritization, estimation & planning meeting

Selected.
Dev. Ready
Valid.
Pending
Intergration
Done!
3
4
1 1
He will be responsible for writing stories, prioritizing them
and even setting a Quality of Service for each story

Selected.
Dev. Ready
Valid.
Pending
Integration
Done!
3
4
1 1
On those meetings, maybe they’ll do a Demo and give
their stakeholders (uh, I meant chickens) a whole vision of
what they’re building and ask for some feedback

Selected.
Dev. Ready
Valid.
Pending
Integration
Done!
3
4
1 1
The team would be probably doing some kind of Daily
Meeting, so they can share, coordinate and decide

Selected.
Dev. Ready
Valid.
Pending
Integration
Done!
3
4
1 1
In order to fine-tune their Kanban board, they’ll have to
frequently reflect on how to become more effective
(continuous retrospective)

Beautiful! but sometimes it’s nice to
have time boxes, burn-downs, fixed
delivery dates or it’s too difficult for
the team to work with WIP limits....

Or maybe our team is still too used
to Scrum and finds it difficult to do a
complete switch to Kam-bum

Sooo… now let’s take a look at the
Scrumban guys.

Selected. Dev. Valid.Pending Integration Done!
They probably started with the typical Scrum Board, with
columns mapping their value stream, but with no WIP limit
or queues
Burn-down::
Release Plan:

Sometimes they have to do some bug fixing, and
sometimes the client asks for small and / or urgent tasks
Burn-down::
Release Plan:
!!!!

This leads to Context Switching
it’s identified as an impediment by the team, and even
though the Product Owner understands it, client & product
nature makes this emergent tasks unavoidable.

Different approaches as a Separate
Maintenance Team were tried
but it made situation worse: maintenance team motivation
dropped, knowledge was scattered and value stream was
worsened for this kind of work.

So their velocity is not very predictable, and is hard to
know why sometimes they seem to do more or less
Velocity
?
?

They looked at Scrum Literature, but
all they could find was something
about Focus Factor
It was like reading “it’s your fault you can’t focus only on
Product Backlog during Sprints, and we don’t care a bit
about what happens out of your focus factor” 

So they started doing something:
they tracked what was going on out
of their Focus Factor

They created a separate board (or a new lane on the old
board) where they started to track bugs and emergent
tasks
Burn-down::
Release Plan:

They didn’t estimate bugs or emergent tasks in advance,
but they gave them some effort number once they were
done.
Burn-down::
Release Plan:
This was
definitely a 3…
5
1

So at the end of the sprint, they could measure up how
much effort did they put on bugs & unpredictable tasks
V Scrum
V Kanban

(By the way, they called this “Kanban”, even tough it’s
not really Kanban as there’s no WIP limit yet… Just hope
the Kanban Police doesn’t find out )
V Scrum
V Kanban

As soon as they had some numbers, they were able to
commit better on how much effort would they put both in
Scrum & Kanban development
V Scrum V Kanban
80 20
85 20
75 30
70 35
75 25
80 25
? ?
¿Your prediction?
Uuuh… Well, on average
we make something like
75 scrum points per
sprint. Guess we can
commit on that as long as
you keep the kanban
level safe…
That means
somewhere below
25 kanban points

They were also able to understand and explain what
happened during a given Sprint
V Scrum V Kanban
80 20
85 20
75 30
70 35
75 25
80 25
60 50
Yaaargh! You
failed on your
commitment!
No, in fact we did 110
points of aggregated
velocity, which is quite
good. It was YOU who
told us to prioritize 50
Kanban points during
the Sprint and made us
fail the sprint goal
That means we’re
great and you
suck. Maybe we
should discuss this
with the CEO 
!

Soon, they started to differentiate good Kanban (value to
the customer) from bad Kanban (bug fixing). Bad Kanban
does not add to velocity, but affects it.
V Scrum
V Kanban +
V Kanban -

And they started to see the effect that bugs and
emergent tasks had on Scrum Velocity
Velocity
Vavg Scrum
Vavg Kanban +
Vavg Kanban -

So they could take decisions on things like increasing
investment on bug fixing or stop emergent tasks if project
is running late
Velocity
Vavg Scrum
Vavg Kanban +
Vavg Kanban -

They still had a problem: how to know on which task
should they work next? Should they get the next Scrum
task or the next Kanban task?
Burn-down::
Release Plan:
? ? ? ?

So they implemented a simple and visual quality of service
mechanism(QoS)
Burn-down::
Release Plan:
COMMITTEDPRIO
Fire!
ASAP

Fire!
The Fire lane meant “drop whatever you’re doing, there’s
a server on fire and we don’t care if velocity drops – go fix
it now!!!”
Burn-down::
Release Plan:
COMMITTEDPRIOASAP

Fire!
There should be some kind on control mechanism on Fire
QoS, so it doesn’t open the gates of hell to the team
Burn-down::
Release Plan:
COMMITTEDPRIOASAP
Mwaa-hahaha!!!

Fire!
I.E., every Fire request should be audited post-mortem and
there should be a limit on how many of them you can
open on a given sprint (that’s why it’s a small lane).
Burn-down::
Release Plan:
COMMITTEDPRIOASAP
Was this really
a fire???
No it wasn’t…
Time to coach
our P.O.
Uh-oh…

Prio
Fire!
PRIO lane means “as soon as you finish what you are
doing right now, please choose this urgent task”.
Burn-down::
Release Plan:
COMMITTEDASAP

Prio
Fire!
This is not as disruptive as a Fire, but still introduces some
controlled context switching, so it shouldn’t be over-used
by the Product Owner either.
Burn-down::
Release Plan:
COMMITTEDASAP

ASAPPrio
Fire!
The key words in the asAP QoS definition are “As Possible”,
You should do some of those, but only as long as it doesn’t
compromise the Sprint Goal
Burn-down::
Release Plan:
COMMITTED

ASAPPrio
Fire!
Soon the Team started to keep a separate Kanban
Burndown so they could see if they could invest more on
kanban or not.
Sprint Burn-down:
COMMITTED
Kanban burndown:
Uh-oh, hold the
Kanban, guys!!
Mmm…Guess I’d
like some Scrum
done too…

Some teams found it difficult to give a story-point estimate
to kanban tasks, so they used a different scale (hours, bug
size, kanban points or whatever)
V Scrum V Kanban
80 7500
85 7000
75 8000
70 8500
75 7500
80 7000
? ?
¿Your prediction?
Uuuh… Well, on average
we make something like
75 scrum points per
sprint. Guess we can
commit on that as long as
you keep the kanban
level safe…
That means
somewhere below
7500 kanban
points

This worked like charm. You could even normalize average
speeds and add them up, but that’s too much work, and
there’s no real need to do so 
Yaaargh! You
failed on your
commitment!
No, in fact we did a lot more
kanban than usual (you over-
kanbanized us by 50%,
which is quite a lot). It was
YOU who told us to prioritize
Kanban points during the
Sprint and made us fail the
sprint goal
That means we’re
great and you
suck. Maybe we
should discuss this
with the CEO 
!
V Scrum V Kanban
80 7500
85 7000
75 8000
70 8500
75 7500
80 7000
60 11.200

Just some final advice…

1) Sustainable pace is about
working always towards your
average speed
There’s no use in aiming for top speed every single sprint,
except for undermining team’s morale

Min. V
Max. V
This will be done for sure
(boring)
Yougottabekiddin’ me! 
We will probably end up
somewhere over here
(average speed) – a.k.a.
“We can do this!” 
Backlog and average speed

2) No tool is foolproof
if your P.O. is opening 25 PRIO Kanban every single day, I’ll
give you a clue: the problem is not in the post-it notes brand
you’re using… 

Hope it helps!
I would love to hear about how this is helping you or how could we improve it . Please
frop me a line at angel.medinilla@proyectalis.com

http://creativecommons.org/
licenses/by-nc-nd/3.0/
This presentation is based upon
the ideas and work of many
people. And while I’ve tried to
recognize copyrights and give
credit and attribution where
possible, I cannot possibly list
them all, so if you feel like
there’s something that should be
added, changed or removed
from this presentation, please
drop me an e-mail at
angel.medinilla@proyectalis.com
Special thanks to Henrik Kniberg, on
whose article “one day in kanban
land” is this presentation inspired.
You rock!! 

Scrumban Ideacamp - Amsterdam Scrum Gathering 2010

Related slideshows

More Related Content

Scrumban Ideacamp - Amsterdam Scrum Gathering 2010