discovering scrum in lisbon, portugal
TRANSCRIPT
Photo © javarman -‐ fotolia File 1
• Stand Up!
• Talk individually with 3 people :
– Why are you here? – What are you 3 principal goals at work? – What is preventing you from achieving these goals?
• When you’re finished, .
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
• How does Scrum work, and why?
• Scrum and its impact on your organization
• 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.
• Now tell the same story, again!
• When were you involved in a project, which really worked well? Everyone pulled together, worked together, all for one and one for all?
• 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
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
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
• What makes great projects?
• Scrum and its impact on your organization
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
• What makes great projects?
• How does Scrum work, and why?
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 3/4-‐March-‐14 Lisbon For Training Coaching or TransisDons Contact Hugo Lorenço [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