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 [email protected] 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



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



Valid. Pending


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



Valid. Pending


1 1

The team would be probably doing some kind of Daily Meeting, so they can share, coordinate and decide



Valid. Pending


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:

CO

MM

ITTE

D

PR

IO

Fire!

ASA

P


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:

CO

MM

ITTE

D

PR

IO

ASA

P


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:

CO

MM

ITTE

D

PR

IO

ASA

P

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:

CO

MM

ITTE

D

PR

IO

ASA

P 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:

CO

MM

ITTE

D

ASA

P


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:

CO

MM

ITTE

D

ASA

P


ASA

P Pr

io

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:

CO

MM

ITTE

D


ASA

P Pr

io

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:

CO

MM

ITTE

D

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 [email protected]


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 [email protected]

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

Business

Transcript of Scrumban Ideacamp - Amsterdam Scrum Gathering 2010