141015 Discovering Scrum at Scrum Roma

Photo © javarman -‐ fotolia File 1

File 1

Discovering Scrum

Why do we do Scrum?

Why do we do Scrum?

Why do we do Scrum?

Inspect

Every Scrum Role, Activity and Artifact helps you Inspect and Adapt

Adapt

Photo courtesy of Iain Farrell@

flickr

Photo courtesy of Iain Farrell@

flickr

Certified Scrum Training and Career Path

@peterstev peter@saat-‐network.ch

@peterstev peter@saat-‐network.ch

•  What makes great projects?

•  How does Scrum work, and why?

•  Scrum and its impact on your organization

… while experiencing Scrum

Photo © leon

ardo

viD -‐ fotolia



•  Think back...

•  When were you involved in a project, which really worked well? Everyone pulled together, worked together, all for one and one for all?

•  In 90 seconds, tell the story of this project to your table mates.

•  Note the person who told the “best” story, the one which should be a role model moving forward.

•  Now switch tables so your are with as many new people as possible.

•  What are the stories we’d most like to emulate?

•  Find the best story (from either the first or second round) and put your hand on that persons shoulder.

•  Keep it there, until we find the top 3 stories.

Would the top 3 storytellers please share their stories to everyone.

Photo © leon

ardo

viD -‐ fotolia

Management

Management •  Clear Vision & Goals •  Clear priorities •  Clear decisions •  Clear responsibilities •  Management Support

for the Teams, People & Project

•  Focus •  Close cooperation

with the customer •  Motivated, Activated

& Empowered Team Members






Technical •  Short feedback loops •  Running systems

early •  Clear Acceptance

Criteria / Tests •  Good tools and

equipment •  Risks handled early •  Early and regular

integration •  Thorough Test Suite •  Automated Test Suite






Technical •  Short feedback loops •  Running systems

early •  Clear Acceptance

Criteria / Tests •  Good tools and

equipment •  Risks handled early •  Early and regular

integration •  Thorough Test Suite •  Automated Test Suite



Photo: (CC) joeshlabotnik@flickr

Photo: Peter Stevens

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

Deadline

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

P0

P0

P0

P0

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

P0

P0

P0

P0

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

P2

P2

P2

P2

P2

P0

P0

P0

P0

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

P2

P2

P2

P2

P2

P3

P3

P3

P3

P0

P0

P0

P0

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

P2

P2

P2

P2

P2

P3

P3

P3

P3

P4

P4

P4

P5

P5 P6

P0

P0

P0

P0

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

P2

P2

P2

P2

P2

P3

P3

P3

P3

P4

P4

P4

P5

P5 P6

P1

P0

P0

P0

P0

t

P1

P1 Requirements

Design

Analysis

Test

Development

P2

P2

P2

P2

P2

P3

P3

P3

P3

P4

P4

P4

P5

P5 P6

P1

P1

P1

P1

P0

P0

P0

P0

t

P1

P1

P1

P1

P1 Requirements

Design

Analysis

Test

Development

P2

P2

P2

P2

P2

P3

P3

P3

P3

P4

P4

P4

P5

P5 P6

P1

P1

Phase-‐Driven is a Dghtly coupled architecture.

•  There is always a lot of Work in Progress –  change is hard

•  Delays impact other projects

•  Delays do not slow down the flow of new requests

•  People are fully allocated –  there is no time to do new things

•  “Resource Allocation” is a continuous process –  Priorities are difficult to set and maintain

P5 R-‐A-‐D-‐D-‐T

Team

P1 R-‐A-‐D-‐D-‐T

PotenD

al

Release

P1 R-‐A-‐D-‐D-‐T

PotenD

al

Release

P1 R-‐A-‐D-‐D-‐T

Actual

Release

P4 R-‐A-‐D-‐D-‐T

Actual

Release

P1 R-‐A-‐D-‐D-‐T

P1 R-‐A-‐D-‐D-‐T

P1 R-‐A-‐D-‐D-‐T

P2 R-‐A-‐D-‐D-‐T

P2 R-‐A-‐D-‐D-‐T

P3 R-‐A-‐D-‐D-‐T

P3 R-‐A-‐D-‐D-‐T

P3 R-‐A-‐D-‐D-‐T

P4 R-‐A-‐D-‐D-‐T

P5 R-‐A-‐D-‐D-‐T

Team 1

Team 2

Scrum is a loosely coupled architecture.

max 30 Days

Done PotenDally Shippable Product

RetrospecDve

Review Planning -‐ What

Daily Scrum

Planning -‐ How

Product Owner: Voice of Customer

Scrum Master: Voice of Common Sense, Unblocks Impediments

“Development” Team: Solves the problem



Photo: Courtesy of Roman Keller

Photo © Big Stock Pho

to

Étude HERMES et agilité- V 1.0 QS

10/14

les véritables risques sont découverts à la fin du projet seulement. Les surcoûts et le temps nécessai-re pour pallier ces risques sont alors directement proportionnels à la durée pendant laquelle ceux-ci n’ont pas été évalués et, par conséquent, .

4.2.3 Répartition des exigences collectées Situation dans HERMES : collecte précoce des exigences envers le système

Les exigences sont collectées au début du projet et ne sont pas suffisamment remises en question par la suite. Typiquement, les exigences envers le système sont collectées pendant l’analyse préliminaire. «Elles sont acceptées tant par le donneur d’ordre que par le mandataire du projet comme base de réalisation et de réception du futur système»9

La période séparant la collecte des exigences du test du produit par le client peut être très grande. Il est possible que les spécifications initiales soient déjà oubliées avant que celui-ci soit de nouveau im-pliqué. En outre, les conditions-cadres peuvent s’être modifiées avant cet instant, ce qui fait que les exigences ne concorderont plus avec la réalité.

.

Solution possible avec Scrum: backlog de produit (Product backlog) Les meilleures connaissances sur le produit à développer ne sont disponibles dans tous les cas qu’à la fin du projet. Il s’agit d’exploiter activement, en tant que plus-value, cette amélioration continue des connaissances. Cela signifie que l’on débute consciemment le projet avec des exigences incomplètes, en les affinant et en identifiant de nouvelles au cours du projet. Cependant, pour piloter efficacement le processus de développement, il est nécessaire de disposer, au début du projet, d’une vision du produit décrivant clairement et de manière compréhensible l’objectif final, tout en laissant consciemment un espace suffisant pour la navigation. Au cours du pro-cessus de développement, cet espace sera complété avec les exigences apportant la meilleure plus-value. La collecte des exigences et la fixation des priorités correspondantes ne s’effectuent donc pas au début seulement (up-front), mais en continu, par l’intégration précoce du client et d’autres experts du domaine. Ainsi, des découvertes importantes peuvent encore être prises en compte même très tard dans le projet. De telles constatations apportent souvent la meilleure plus-value et sont importan-tes pour la réussite du projet.

Figure 5: Backlog de produit: catalogue des exigences avec itérations

Le catalogue complet des exigences peut donc être adapté ou même remplacé, en fonction des be-soins, après chaque itération grâce au feed-back de l’incrément de produit qui en résulte. Cette ma-nière de procéder offre aussi l’avantage que seules les exigences qui seront réellement implémentées seront spécifiées de manière complète. Cette réduction de la charge par une diminution du travail né-cessaire permet de se concentrer sur les détails vraiment importants et crée une efficience accrue.

9 HERMES DS, p. 221

Source: Étude

HER

MES et a

gilite

7

9 9 9 9 10

0%

20%

40%

60%

80%

100%

120%

5

10

15

1 2 3 4 5 6 % of C

ommi(men

t Finishe

d

Forecast/A

ctua

l in SP

Sprint (2 weeks)

Commi(ed and Delivered FuncAonality

SP commifed % Done

Note: Sprint 2 was actually a three week sprint with 13 points commifed and delivered. Data is normalized to a 2 week sprint for readability.

52

45

36

28

19

10

0 5

10

15

0

10

20

30

40

50

60

Start 1 2 3 4 5 6

Velocity

FuncAo

nality Re

maining

"Backlog"

Delivered FuncAonality

FuncDonalty Remaining Velocity Note: Sprint 2 was actually a three week sprint with 13 points commifed and delivered. Data is normalized to a 2 week sprint for readability.

0

20

40

60

80

100

120

Start 1 2 3 4 5 6 7 8 9 10 11 12

Scop

e

EsAmated CompleAon

Full Project Reduced Project Note: Sprint 2 was actually a three week sprint with 13 points commifed and delivered. Data is normalized to a 2 week sprint for readability.

Build the right thing

Build it well

Befer ProducDvity

Figure out what the right thing is!

•  The waterfall is poorly suited for software and systems development

•  Modern alternatives

e.g. Scrum

are available and much better

•  You can be much better than you are!

We have a lot of people…

And many quesDons….

How do we know that the most important quesDons get answered?

Photo © leon

ardo

viD -‐ fotolia

•  1 Question per moderation card

•  One question per card / thick pen

•  The question is a complete sentence, that ends with a ‘?’

•  Recommendation: Starts with a ‘W-Word’ –  Why, What, When, Where, Which ( and How ;-) –  Yes/No Questions get a yes/no answer!

•  Recommendation: Keep the question ‘small’

•  The ‘owner’ of the question accepts the answer

•  You may add expectations as notes to your question

Requirements Management in Scrum

Can you do fixed-price/fixed-scope Projects in

Scrum?

Who is responsible for Requirements

Management in Scrum?

I want to understand the duDes and responsibiliDes

of this person

•  Each table designates a time keeper and a speaker/representative (need not be the same person)

•  Everyone take two minutes to write max three questions

•  Place the card on a wall •  Each person explains their questions (max 1

minute each ) •  Speaker combines duplicates – and team uses

dot voting to select top two questions.

•  Speakers bring #1 & #2 questions to plenum.

•  Put #1 question on the board. (Use #2 if #1 question has been proposed already)

•  Agree on order to handle the questions.

•  Time 3 Minutes.

You are here

•  Commit to doing Scrum!

•  Training for Everyone (including Customer & Management)

•  Definition of Ready

•  Definition of Done

•  Pair Immediately

•  No Multitasking

•  Everything in Sprint Prioritized by Product Owner

•  Physical Task Board

•  Short Sprints

•  Improve Engineering Practices

•  Management does Scrum Too

“Some people invest time in open source to save money.

“Others invest money in proprietary software to save time and reduce risk.”

-- MySQL

“The same applies to training and coaching”

-‐-‐ Peter Stevens Picture courtesy of star5112 @ flickr

Peter Stevens @peterstev peter@saat-‐network.ch

Training CerDfied Scrum Master

Roma 16.10 Milano 25.11

For Training Coaching or TransisDons Contact Elena Bassa [email protected]

Photo : ©

Julián Ro

vagnaD

– Fotolia

•  © 2006-2013 Peter Stevens

•  Redistribution permitted under Attribution-NonCommercial-ShareAlike 2.5 Generic (CC BY-NC-SA 2.5)

•  Some image material © Fotolia or BigStockPhoto and their respective photographers – used under license

Software

141015 Discovering Scrum at Scrum Roma