Agile and Scrum seminar (english)

Agile & Scrum

Barcelona, November 2011

© 2010 Proyectalis Gestión de Proyectos S.L.

ngel M edinilla!
Á @proye
c talis.co
m
edinilla
angel.m l_m
@ange

© 2010 Proyectalis Gestión de Proyectos S.L – htttp://slideshare.net/proyectalis.

Nice to
meet you!


Some
Ground
Rules


**
*

"What" ain't no
country I ever
heard of! They
speak English in
"What"?

Speak English (and help me do so!)

Principles, Rules, Opinions…


Open Mind


Don’t Kill the Messenger!


Take some notes

Mmmmm…
Lunch time…


Exercise: Scrum Ball


Enough for a start…


Project Management


A tale of two states

 Statewide Automated Child
Welfare Information System
(SACWIS)
 Florida: started 1990,
forecasted 8 years, $32M
 2002: $170M spent,
deadline estimates 2005,
cumulative cost $230M

Source: Jim Johnson, Standish Group President, as quoted in “Lean Software Development,” , Mary&Tom Poppendieck

Standish
68% project
Group challenge / fail rate

59¢ value for
every $ of software

64%
functionalities never
used


Developers everywhere are in
terrible pain

Vicious cycle

Late Hurry

Low
productivity Low
quality
Interruptions

Errors


Vicious cycle

Late Hurry

Low
productivity Low
quality
Interruptions

Errors Unhappy
Higher costs customers
Lower profits


Vicious cycle
No training

Pressure
Late Hurry Lack of skills

Low
Demotivation
productivity Low
quality
Interruptions

Errors Unhappy
Higher costs customers
Lower profits


Meanwhile, in Minessota
 Essentially the same system, same functionality,
started in 1999
 Finished at the beginning of 2000, costs $1.1M

Source: Jim Johnson, Standish Group President, as quoted in “Lean Software Development,” , Mary&Tom Poppendieck

Is luck the whole story?


Rule Set


First Rule

Time Scope

?
Resources

Good, Cute, Cheap…Choose any two!


Project Buffers
60% buffer used

80% project done

Buffer

Min T Max T

 Measure buffer consumption velocity
 Work against the average (not accuracy)
 Avoid hidden “padding” or wild sandbagging

Traditional vs. Agile

Fixed Scope Cost Time

Value
oriented

Plan
oriented

Estimate Cost Time Scope


Second rule

Change is the only constant

Uncertainty cone

(Tip: estimate here )

Uncertainty cone


Uncertainty


Estimation is not THIS:
Probability

Estimation Value


Estimation is not even THIS:
Probability

Estimation Value


Estimation is THIS:
Probability

Estimation Value


Accuracy vs. effort
Accuracy

Good enough!

Estimation effort


Accuracy vs. effort
Accuracy
100% accuracy

50-70% accuracy

Good enough!

Estimation effort


Gedanken: the perfect P.O.

…..


Histogram


Histogram
Average


Histogram
Average

95% SLA
80% SLA


Different kind of stories

 T-Shirt size
 XS – 2 days
 S – 4 days
 M – 9 days
 L – 15 days
 XL – 22 days


Third Rule
Requirements

Technology
It is complex (maybe impossible) to give a
perfect up-front design for a software system

Software
is not
THIS:


Software
is THIS:


Agile


Exercise: human circle


Principios:
 Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
 Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
 Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.


Principios:
 Business people and developers must work together daily throughout the
project.
 Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
 The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.


Principios:
 Working software is the primary measure of progress.
 Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
 Continuous attention to technical excellence and good design enhances
agility.


Principios:
 Simplicity--the art of maximizing the amount of work not done--is essential.
 The best architectures, requirements, and designs emerge from self-
organizing teams.
 At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.


Agile101
Estimate

Ouch!
R1.0 ¿R2.0?
Estimate BV

Replan R1.0 ¿R2.0? t

Agile101
- Self-organized, Motivated team
Estimate - Working on a sustainable pace
- Collaborates with customer and
business people daily
- Communicates face to face
- Strives for technical excellence
- Reflects on how to improve,
Ouch! eliminates waste

R1.0 ¿R2.0?
Estimate BV

Replan R1.0 ¿R2.0? t

Values

Principles

Processes Practices

Roles Artifacts

Tools


Challenges:

5thAnnual ”State of
Agile Development”
Survey, 2010


5thAnnual ”State of
Agile Development”
Survey, 2010


Scrum


The name:


Some folks doing Scrum


What Scrum is NOT


Scrum 101


Scrum 101
Stakeholders
Product Owner

Team

Sprint
Backlog
Scrum
Master

Product Backlog

Organizational Anti-Pattern

?

? ? ?


Scrum 101
Stakeholders
Product Owner Team

?

Sprint
Backlog
Scrum
Master

Product Backlog

Scrum structure / same product

?

? ?

? ?


Agile Hyper-specialists?


Skills Matrix


Scrum structure / same product

?

? ? ?

? ?


Organizational anti-pattern

? ?


Scrum structure / several products -
clients

?

? ?

? ?


Communities of practice

?

? ?

? ?


The framework:


Our 10 rules for healthy Scrum
1. Individuals
2. Not a silver bullet
3. Retrospect, retrospect, retrospect
4. Daily Scrum, Daily control
5. Working software is our measure of
progress
6. Self-organizing self-committing
teams: Scrum Master is not a boss,
but a team’s servant
7. Iterative and incremental
development


8) “Done, done”


9) “Orcs at the gates”

?


10) “The Muffins Oven”

?


10) “The Muffins Oven”

+3 !!
!!

?


Options:
 Queue the cake (can affect
value delivery)
 Delay red muffins and use
that space for the cake
(equal clients)
 Put the cake first (priority
client, delays the whole
muffin portfolio)
?
 Have spare capacity for
cakes (Scrumban)
 Drop quality, build technical
debt, ask for overtime (not
Agile)


This ten commandments are bound
by a Supreme Command:

¡Time Boxing!


Agile Planning


Exercise:
burning man project


Burning Man Project
= 12.000 Scrum$ / sprint
? ~20 work units / sprint


Burning Man Project

…..
120 work units (~72.000s$)


Burning Man Project

…..
120 work units (~72.000s$) Buffer size: 12 units(~7.200S$)


Burning Man Project

…..

Estimated Real Left Should be Deviation
20 18 102 100 -2


Burning Man Project

…..

20 18 102 100 -2
22 15 (-5) 92 80 -12


Burning Man Project

…..

20 18 102 100 -2
22 15 (-5) 92 80 -12
25 20 72 60 -12


Burning Man Project

20 18 102 100 -2

22 15 (-5) 92 80 -12

25 20 72 60 -12


Burning Man Project

20 18 102 100 -2

22 15 (-5) 92 80 -12

25 20 72 60 -12

Delay: 0 days
V=24
S$=0


Burning Man Project

20 18 102 100 -2

22 15 (-5) 92 80 -12

25 20 72 60 -12

V=20
Delay=-12 (1/2 sp.)
S$=6.000S$

Delay: 0 days
V=24
S$=0


Burning Man Project

20 18 102 100 -2

22 15 (-5) 92 80 -12

25 20 72 60 -12

V=20 V=15
Delay=-12 (1/2 sp.) Delay=-27 (2 sp.)
S$=6.000S$ S$=24.000S$

Delay: 0 days
V=24
S$=0


Burning Man Project

20 18 102 100 -2

22 15 (-5) 92 80 -12

25 20 72 60 -12

V=20 V=15
Delay=-12 (1/2 sp.) Delay=-27 (2 sp.)
S$=6.000S$ S$=24.000S$

Delay: 0 days
V=10
V=24
OMG!
S$=0


Burning Man Project

20 18 102 100 -2
V=18
22 15 (-5) 92 80 -12
Delay=-18 (1 sp.)
25 20 72 60 -12
S$=12.000S$

V=20 V=15
Delay=-12 (1/2 sp.) Delay=-27 (2 sp.)
S$=6.000S$ S$=24.000S$

Delay: 0 days
V=10
V=24
OMG!
S$=0


Burning Man Project
V=18
Delay=-18 (1 sp.)
S$=12.000S$

V=20 V=15
Delay=-12 (1/2 sp.) Delay=-27 (2 sp.)
S$=6.000S$ S$=24.000S$

Delay: 0 days
V=10
V=24
OMG!
S$=0


Burning Man Project
We can:
V=18 - Drop scope (~18pt.)
Delay=-18 (1 sp.) - Give more time (~1sp.)
S$=12.000S$ - Add more resources
(Brooks law!!)

V=20 V=15
Delay=-12 (1/2 sp.) Delay=-27 (2 sp.)
S$=6.000S$ S$=24.000S$

Delay: 0 days
V=10
V=24
OMG!
S$=0


Burning Man Project

…..

20 18 102 100 -2
22 15 (-5) 92 80 -12
25 20 72 60 -12
22 25 47 40 -7


Burning Man Project

…..

20 18 102 100 -2
22 15 (-5) 92 80 -12
25 20 72 60 -12
22 25 47 40 -7
25 28 19 20 +1


Burning Man Project

…..

20 18 102 100 -2
22 15 (-5) 92 80 -12
25 20 72 60 -12
22 25 47 40 -7
25 28 19 20 +1
19 19 0 0 0


Burning Man Project

…..

20 18 102 100 -2
22 15 (-5) 92 80 -12
25 20 72 60 -12
22 25 47 40 -7
25 28 19 20 +1
19 19 0 0 0

????


Burning Man Project

…..

200 18 102 100 -2
2,2 15 (-5) 92 80 -12
2500 20 72 60 -12
22M. 25 47 40 -7
0,25 28 19 20 +1
2¶/3 19 0 0 0

????


Estimation is WASTE!

How?

“The emphasis is on steering the project - wich is quite
straitghtforward - rather than an exact prediction of
what will be needed and how long will it take - which is
quite difficult”
Ron Jeffries, XP co-founder


Velocity

Min. V Sure we’ll make it

We’ll probably end
somewhere over here
Max. V

Are you freakin’ kidding me?


Bell curve / Gauss curve
Worst case: minimum
scope or maximum
time

Min. V

Estimate

Max. V

Better case: maximum
scope / minimum
time


Capacity
105
100
100
+5 -5 -25 -32 -46 -46 -59 -70 -70

93
90 90

86 86
80
80
¡¡900 points in 9
weeks!!


Capacity
105
100
100
+15 +5 +5 -5 -2 -6 +4 +0 +0 +10

93
90 90

86 86
80
80
¡¡Between 700
¡¡900 points and 900 points
between 9 and in 9 weeks!!
11 weeks!!


Scrum Planning

Backlog=
Bunch of
functionalities,
Prioritized and
Estimated

(Following that sequence,
in fact)


Functionalities
 SMART (Specifical, Measurable, Achievable, Reasonable,
Time Boxed)
 INVEST (Independent, Negotiable, Valuable, Estimatable,
Small, Testable).
 MOSCOW (Must, Should, Could, Wish…)


Iceberg Backlog

Sprint

Product

Version


IEEE-830
“Entree comes with soup
or salad and bread”
(Mike Cohn)


An office virus:


Common Understanding

User stories


Product specs:
 Product must have petrol engine
 Product must have four wheels
 Product must have at least one seat for human
driver
 Product must have metalic framing
 Product must have steering wheel
 Product must be able to move through
countryside
 Product must be cheap


User story:
 “As a frequent gardener, I want to mow lawn fast
and comfortably, so I don’t get tired or hurt ”.
 Acceptance criteria: mown lawn using traditional
method. Then use new system: should be at least
2x faster, virtually no tiring and much more fun.


What did we build / What did
user need?

 Describe solution  Understad user need


Story maps
“Épics”

Time
need

Stories

© 2006-2008 Jeff Patton, www.agileproductdesgin.com

Story map

Time
Neccesary
Release one
Less optional
Release two
necesidad

More optional Release three


MVP / MMFS


MVP / MMFS

?

Walking Skeleton:
1 2 3

1 2 3


Important

The story or the card are not as
important as the conversation they
come from

Important

≠

Engineering is not to be described in the story

Reminder:

Backlog=
Bunch of
functionalities,
Prioritized and
Estimated

(Following that sequence,
in fact)


Prioritize

 Consensus
 Voting
 Buy a feature
 Dot voting
 Story maps
 Iterative rounds (rate 1-5)
 Cost benefit analysis (Uh?)


Estimation
 Dish washing
 Dog walking
 Lawn mowning
 Plants watering
 Beds changing
 Laundry
 Ironing
 Oven cleaning
 Monthly shopping
 Groceries shopping
 Floor cleaning
 Windows cleaning
 Paint bedroom

Planning Poker


Roles, processes and tools


Scrum Framework

Product Backlog Sprint backlog Product owner

Scrum Master
Scrum board Artifacts Roles
Team
Impediment backlog

Retrospectives Processes Demo

Product planning Sprint planning Daily Scrum


The roles:


 Manages vision and roadmap
 Gathers specs, writes user
Product stories
Owner  Manages Product Backlog:
decides on scope and priority
 Defines acceptance criteria for
every user story
 Accountable for financial
success and customer
satisfaction
 Business & stakeholders
interface with Scrum
 “Feathered pig”


 Gives estimates, reports progress
 Committed to deliver working
software at the end of the iteration
Team  Cross-functional, self-managed
 Accountable for quality and velocity
 7±3 people (“feed them two pizzas”)


 “Shepherd dog”, servant
leader, Coach
Scrum  Close to the team
 Maintains process
Master
 Manages impediment
backlog
 Makes the team improve
 Maker team life better
 Moderator - facilitator
 If necessary, acts as an
interface with Product
Owner


The evolution of the Scrum
Master
“The Scrum
guy”
ScrumButt Scrum Agile Nirvana

- Schedule
meetings
- List
impediments


Master
“The Scrum “Scrum
guy” Mom”

- Schedule - “I’ll take care of that”
meetings - Moderator
- List - Diagnoses &
impediments Decides
- Directly removes
impediments
- Team interface
- Evades conflict
(artificial harmony)
- Does not really trust
the team, still bossy


Master
“The Scrum “Scrum True Scrum
guy” Mom” Master

- Schedule - “I’ll take care of that” - Trainer, mentor
meetings - Moderator - Facilitator
- List - Diagnoses & - Motivator
impediments Decides - Team gardener
- Directly removes - Involves everyone
impediments - Progressively delegates
- Team interface - Collaboration
- Evades conflict - Innovation
- Deals with Conflict
- Change agent
- Agile evangelist
- Leader

Master
“The Scrum “Scrum True Scrum Scrum Sensei –
guy” Mom” Master Agile Coach

- Schedule - “I’ll take care of that” - Trainer, mentor - Listen
meetings - Moderator - Facilitator - Master silence
- List - Diagnoses & - Motivator - Ask
impediments Decides - Team gardener - Be a mirror
- Directly removes - Involves everyone
impediments - Progressively delegates
- Team interface - Collaboration
- Evades conflict - Innovation
- Deals with Conflict
- Change agent
- Agile evangelist
- Leader

Master
“The Scrum Scrum Sensei –
guy” Agile Coach
ScrumButt Agile Nirvana

- Schedule - Listen
meetings - Master silence
- List - Ask
impediments - Be a mirror


Master

Decide Sell Consult Participate Advice Inquire Delegate


Master

Estimate
stories
Sprint
Length
Definition
of done
Team
composition
Business
strategy


Master

Estimate
TEAM
stories
Sprint SM
Length
Definition PO
of done
Team Manager
composition
Business
Manager
strategy


Master
Coach (leader?)
C&C
Estimate
TEAM
stories
Sprint SM
Length
Definition PO
of done
Team Manager
composition
Business
Manager
strategy


Procesos


Planificación de producto


Planificación de Sprint


Scrum diario

Demo


Retrospectiva


Retrospectives


Formatos


Muy importante:


Prueba
cosas
nuevas


Pero no es
esto…


Artifacts


Scrum Board
Stories Pending Develop Test Done
Project:

Team: Scrum, Demo:

Burn-down::

Release Plan:

Impediments


“Olores”


Historia Pendiente Desarrollo Test Terminado
Proyecto:

Equipo: Scrum, Demo:

Burn-down::

Release Plan:

Impedimentos:


Burn-down
Trabajo

KO!

OK!

Tiempo


Release Plan


Trabajo

Tiempo


Kanban & Scrumban


Exercise: serial
or parallel


Kanban

Kanban
 Start where you are
 Map your value stream
 Visualize flow
 Limit WIP – adjust
workload to capacity
 Measure and improve lead
time and cycle time
 Make policies explicit
(definition of done, WIP
limits, coding standards,
bloqued tasks…)


Capacity
50l/sg
20/sg

10l/sg

100/sg

30/sg


Capacity
- Old troughput: 10
50l/sg - New troughput: 11 (10% ok)
- Cost: 16
22/sg

11l/sg

¡¡+10%!! 110/sg

33/sg


Capacity
- Old troughput: 10
50 23l/sg - New troughput: 23 (130%)
- Adjust workload to capacity
23/sg
- Cost: 16

- R&D+i
23l/sg - Tech Debt
- Decouple
¡Kaizen! 100l/sg

33l/sg


Capacity
 Bottlenecks: exploit, subordinate, rise
(beware of the “need more resources” song)
 Be sure your bottleneck operates at full
capacity (eliminate waste at the bottleneck)
 Be sure the system works at the pace of the
bottleneck
 Be sure the entrance to the bottleneck has
good quality
 Be sure your bottleneck is not idle / blocked
 Use the “slack” around your bottleneck to
work the bottleneck
 Treat your bottleneck as a national
emergency

The 40 hour week fallacy:

Programming (value adding tasks, focus
100% (40
factor, sprint dedication, project
hours a
advance…)
week)


A more realistic approach:

Programming ( value adding tasks, focus
factor, sprint dedication, project 50%
advance…)

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework,
15%
context switching, other forms of waste…
Reports, e-mail, internal meetings, hiring interviews, 10%
admininistrative stuff, bureaucracy…

Slack 10%
Research, Development, training, innovation 5%

Naked truth:

Programming ( value adding tasks, focus
factor, sprint dedication, project 35%
advance…)

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework, 30%


Slack 10%

Naked truth:

Scrum (measured & known)
35%

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework, 30%


Slack 10%

Naked truth:

Scrum (measured & known)
35%

65%


Burn-down::
Pending Selected. Dev. Valid. Integration Done!

Release Plan:


Scrumban

Burn-down::

Release Plan:


5

1

This was
definitely a 3…

Scrumban


V Scrum


V buffer

Scrumban

V Scrum V buffer
80 20
85 20
75 30
70 35
75 25
80 25
? ?

¿Your prediction?

Scrumban

V Scrum V buffer
80 20 Uuuh… Well, on average
we make something like
85 20
75 scrum points per
75 30 sprint. Guess we can
70 35 commit on that as long as
you keep the buffer level
75 25 safe…
80 25
? ? That means
somewhere below
¿Your prediction? 25 buffer points

Scrumban

V Scrum V buffer
80 20 No, in fact we did 110
85 20 points of aggregated
velocity, which is quite
75 30 good. It was YOU who
70 35 told us to prioritize 50
buffer points during the
75 25
! 80 25
Sprint and made us fail
the sprint goal
60 50

Yaaargh! You
failed on your
commitment!

Scrumban

V Scrum V buffer
80 7500 Uuuh… Well, on average
we make something like
85 7000
75 scrum points per
75 8000 sprint. Guess we can
70 8500 commit on that as long as
you keep the buffer level
75 7500 safe…
80 7000
? ? That means
somewhere below
¿Your prediction? 7500 buffer points

Scrumban


V Scrum


V buffer +

V buffer -

Scrumban

Vavg Kanban + Velocity
Vavg Scrum

Vavg Kanban -

Scrumban

Burn-down::

COMMITTED

Release Plan:

Fire!
PRIO
ASAP

Scrumban

Dev. Done! Sprint Burn-down:
Pending Selected. Valid. Integration

COMMITTED

Fire!
Buffer burndown:
Prio
ASAP

Mmm…Guess I’d Uh-oh, hold the
like some Scrum Kanban, guys!!
done too…

Scrumban

Dev. Done! Sprint Burn-down:
Pending Selected. Valid. Integration

COMMITTED

Fire!
Buffer burn-up:
Prio
ASAP

Mmm…Guess I’d Uh-oh, hold the
like some Scrum Kanban, guys!!
done too…

Scrumban

Add queues and WIP limits!
Design Code Test
Backlog Selected - 3 Done!
On- 3 Rdy On -2 Rdy On - 2 Rdy
SPRINT

FIRE!

PRIO

ASAP


Bonus: drop estimations!


Epilogue…


There’s no road…

Let’s swim!


Training
retrospective

angel.medinilla@proyectalis.com

Thank you!


Read this books!


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

Special thanks to Henrik Kniberg. Mike Cohn,
Lyssa Adkyns and Jeff Patton. I owe you so
much I’ll have to buy you some drinks if you
ever happen to come to Spain ;). BTW, have
you ever considered a holiday here? Drop me
a line! :D


Agile and Scrum seminar (english)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (8)

Similar a Agile and Scrum seminar (english)

Similar a Agile and Scrum seminar (english) (16)

Más de Proyectalis / Improvement21

Más de Proyectalis / Improvement21 (20)

Último

Último (20)

Agile and Scrum seminar (english)