Mastering scrum

Mastering Agile
GEERT.THEYS@ALTAGE-CONSULT.COM

VERSION Beta

http://www.ﬂickr.com/photos/fengschwing/3278956517/
Thursday 16 December 2010

Agenda


Agenda

The ancient ways
Different Agile Styles
Scrum Style
Results
How to test your Scrum


To improve our kungfu we need
to know what went wrong.

Po: I know you're trying to be all mystical and Kung Fu-
ey, but could you tell me where we're going?


Traditional Software Development


Traditional Software Development

Plan everything
Stick to the Plan
Follow the process


Building the wrong thing

We assume:

The customer knows what he wants
The Developers know how to build it
Nothing will change during execution

Most IT projects fail

23% 28%
What is deﬁnition of Succes?

Standish Group used :

on-time, on-budget and with most of the expected
features

49%
This is not succes but a failure in estimation.

Project success is more about whether the software delivers value that's
greater than the cost of the resources put into it - but that's very tricky
Succes Challenged to measure. (Martin Fowler)

fail


What are the different Agile styles?


Scrum & XP
Scrum
Team Daily Scrum

Product Backlog XP Sprint Backlog

Collective Whole team Coding Standard
Burndown
Ownership
Chart

Customer Pair Planning
Refactoring
Tests Programming Game
Sprint
Planning
Continous Sustainable Meeting
Simple
Integration Pace
Design

Product Owner
Metaphor Small Releases

Scrum Master Sprint
Demo

http://blog.crisp.se/henrikkniberg/

Agile Assumes

We assume:

The customer discovers what he wants
The developers discovers how to build it
Things change on the way http://www.ﬂickr.com/photos/b2tse/3960471608/sizes/o/

Let’s focus on SCRUM


Agile Mind
Accepts that predicatbility in business
Tries to be predictable
software is impossible

Fixes Time, Price and scope on projects Time and price are fixed but not the scope

Measures succes of project by their Success of the project is measured by the value
conformance to plan it gives to the customer

Values Methodology and its processes Values people more than the
more than the people process, hence it accepts a process instead

Resist Change in software requirements and Welcomes Change in software requirements
development process and development process

Sees the system specification as the generated Sees the system specification as the
documentation development code


Three Legs

Transparancy
Inspection
Adaption
http://www.ﬂickr.com/photos/chrisafer/2427399932/sizes/l/

Scrum Roles

http://www.ﬂickr.com/photos/clintjcl/305229885/

Product Owner


Product Owner

Must have authority to
manage the product log
The product owner is not a
comittee


The Team


The Team

Self Organised - Cross functional - max 9 members

Scrum Master


Scrum Master

Teaches Scrum by coaching an
leading it

Removes all impediments


Chicken and Pig


Chicken and Pig
Users Product owner
Managers Scrum Master
Others The Team


Scrum Process


Product Backlog
First person
Shooter

Singe Player Multiplayer

Player Cooperative
Missions Tutorial Online
Control Gameplay

Split Screen Death
Storyline AI
Match


Product Backlog


Product Backlog

Owned by the product owner
Never complete
Best-understood requirements
Evolves
Sorted in order of priority

Sprints


Sprint Planning

Deﬁning the sprint length and goal
What are we going to build
How are we going to build it
When will it be “done”

Sprint Backlog

Owned by the team
Team allocates tasks
No additions from outside the team


Taskboard


Sprint Burndown


Daily Standup

http://www.ﬂickr.com/photos/jonnimont/3763340830/

Daily Standup

Answer: What did I do and what am I going to do?
Comitment to the team not the Scrum Master
Take responsibility on your own work!
MAX : 15 and don’t sit down!
http://www.ﬂickr.com/photos/jonnimont/3763340830/

Sprint Review

Everybody is welcome
No mockups - Show working code
Get feedback on your product
Accept or Reject features


Done?

Avoid 90% problem

General concensus needed what is done...
Done should be clear to everyone!


Sprint Retrospective


Sprint Retrospective

Evolution

Good
Bad
Do more
Do Less

Results


Incremental Change

Deliver feature by feature - Highest value
ﬁrst

Quick Results - Quick Fail

Shorter time to market


Flexibility

Respond easily to change

No danger of missing a deadline


Higher Quality

Continous testing

Continous integration

Inspect - Adapt


More fun - happy teams

http://www.ﬂickr.com/photos/mcanevet/289262598/
http://www.ﬂickr.com/photos/32034590@N04/4657598751/

Grading your mastery

http://www.ﬂickr.com/photos/mcanevet/289262598/


Shu-Ha-Ri stages of learning
Shu = Follow the rules
Ha = Change the rules
Ri = Never mind the rules


Scrum.org


ScrumAlliance

Graduate Proffesional Guide

Certified Product Owner Certified Scrum Proffesional Certified Scrum Trainer

Certified Scrum Master

Certified Scrum Developer Certified Scrum Coach


Questions?


slideshare.net/geerttheys
twitter/toadi
be.linkedin.com/in/gtheys
geert.theys@altage-consult.com
geerttheys
geerttheys.com


This presentation was inspired by the works of many people, and I cannot possibly list them all.
Though I did my very best to attribute all authors of texts and images, and to recognize any
copyrights, if you think that anything in this prevention should be changed added or removed,
please contact me at geert.theys@altage-consult.com

http://creativecommons.org/licenses/by-nd/3.0/

Mastering scrum

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (6)

Destaque

Destaque (9)

Semelhante a Mastering scrum

Semelhante a Mastering scrum (20)

Mastering scrum