This is a fast introduction to Agile Scrum that I created (from Mike Cohn Creative Common one) to bootstrap agility in a new team at Alcatel-Lucent.

1. One of Agile methods:
“Scrum”
Fabien.Bataille@alcatel-lucent.com – Wireless/LTE
Alcatel-Lucent France
Certified Scrum Master

2. Rugby instead of Relay race
“The… ‘relay race’ approach to product development…
may conflict with the goals of maximum speed and
flexibility. Instead a holistic or ‘rugby’ approach—where
a team tries to go the distance as a unit, passing the ball
back and forth—may better serve today’s competitive
requirements.”
Hirotaka Takeuchi and Ikujiro Nonaka,
“The New New Product Development Game”, Harvard
Business Review, January 1986.

3. Agile origin

4. Scrum = most used Agile
Methodology

5. Sequential vs. overlapping
development
Source: “The New New Product Development Game” by Takeuchi and
Nonaka. Harvard Business Review, January 1986.
Rather than doing all of one
thing at a time...
...Scrum teams do a little of
everything all the time
Requirements Design Code Test
T1
T1+d

6. Iterative & Incremental
(iterate the whole)

7. AgileManifesto
www.agilemanifesto.org
Weareuncovering better waysof developing
softwareby doing it and helping othersdo it.
Through thiswork wehavecometo value:
Individualsand interactionsover processesand tools
Working softwareover comprehensivedocumentation
Customer collaboration over contract negotiation
Responding to changeover following a plan
That is, whilethereisvaluein theitemson
theright, wevaluetheitemson theleft more.

8. Characteristics
• Self-organizing teams
• Product progresses in a series of 2-4 weeks “sprints”
• Requirements are captured as items in a list of “product
backlog”
• No specific engineering practices prescribed nor forbidden
• One of the “agile processes”

9. Agile Scrum rules

10. Putting it all together

11. Sprints
• Scrum projects make progress in a series of “sprints”
• Analogous to Extreme Programming iterations
• Typical duration is 2–4 weeks
• A constant duration leads to a better rhythm
• Shorter sprint leads to faster impediment solutions
• Product is designed, coded, and tested during the
sprint

12. No changes during a sprint
• Plan sprint durations as long as you can commit
to keep change out of the sprint
Change

13. Scrum framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Rituals
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts

14. Scrum framework
•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Rituals
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Product owner
•ScrumMaster
•Team
Roles

15. Product owner role
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results

16. ScrumMaster role
• Not a project manager but a facilitator
• Responsible for Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences

17. Team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between sprints

18. •Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Rituals

19. Sprint planning meeting
Sprint planning
• Analyze and evaluate product backlog
• Create sprint backlog from product
backlog items (user stories / features)
• Estimate sprint backlog stories in
relatives Story Points
• Decompose stories in tasks
• Evaluate tasks in days or hours.
Sprint
backlog
Sprint
backlog
Business
conditions
Business
conditions
Team
capacity
Team
capacity
Product
backlog
Product
backlog
Techno-
logy
Techno-
logy
Current
product
Current
product
Inputs Outputs

20. Sprint planning
Team selects items they can commit to finish from the
prioritized product backlog
• Sprint backlog is created
• Stories are identified and decomposed in tasks
• Each task is estimated such as it does last 1 or 2 days
• Collaboratively, not done only by the ScrumMaster
• Business value is considered (eg: Web travel agency)
As a “tourist”(1), I
want to “see photos
of the hotel”(2) so
that “I am sure it is
near the sea”(3).
As a “tourist”(1), I
want to “see photos
of the hotel”(2) so
that “I am sure it is
near the sea”(3).
Code the database access (1 d)
Code the user interface (2 d)
Write test (1 d)
Code the foo class (0.5 d)
Update performance tests (2 d)
(1): User role, (2): what to do, (3): business value

21. The daily scrum
• Characteristics
• Daily
• 15-minutes
• Stand-up
• Everyone may come
• BUT Only team members including ScrumMaster can talk
• Goal
• Keep the team synchronized and focused
• Update the work done and burndown chart
• Create a team spirit

22. Everyone answers 3 questions
• These are not status for the ScrumMaster
• They are commitments in front of peers
What did you do yesterday?What did you do yesterday?
1
What will you do today?What will you do today?
2
Is anything in your way?Is anything in your way?
3

23. Sprint Demo/Review
• Team presents what it accomplished during the
sprint
• Typically takes the form of a demo of new features
• Informal
• 2-hours prep time rule
• No slides
• Whole team participates
• Everyone may come and discuss

24. Sprint retrospective
• Take a look at what is and is not working
• Typically less than 1 hour
• Done after each sprint
• Whole team participates
• ScrumMaster
• Team
Start doingStart doing
Stop doingStop doing
Continue doingContinue doing

25. •Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Daily scrum meeting
•Sprint review
•Sprint retrospective
Rituals
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts

26. Product backlog
• The requirements
• A list of all desired work on the
project
• Ideally expressed such that each
item has value to the users or
customers of the product (user
stories)
• Prioritized by the product owner
• Reprioritized at the start of each
sprint
This is the product
backlog
This is the product
backlog

27. A sample product backlog
Backlog Stories Estimate
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
reservation.
3
As a hotel employee, I can run RevPAR
reports (revenue-per-available-room)
8
...
... 30
... 50

28. Managing the sprint backlog
• Individuals sign up for work of their own
• Work is never assigned by someone to someone
• Estimated work remaining is updated daily
• If work is unclear, define a sprint backlog item with a larger
amount of time and break it down later
• Update work remaining if you get more information
– Either thanks to your work
– By discussing with the Product Owner

29. Sprint backlog

30. Sprint Burndown Chart

31. Reading List
• http://agilemanifesto.org/
• http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
• http://www.scrumprimer.com/
• Lots of weekly articles at www.scrumalliance.org
• www.agile-Lean-et-compagnie.com
• French Scrum User Group:
http://fr.groups.yahoo.com/group/frenchsug/

32. Questions ?

33. Copyright notice
• Adapted from Presentation of Mike Cohn
www.mountaingoatsoftware.com
You are free:
to Share―to copy, distribute and transmit the work
to Remix―to adapt the work
• Under the following conditions
• Attribution. You must attribute the work in the manner specified
by the author or licensor (but not in any way that suggests that
they endorse you or your use of the work).
• Nothing in this license impairs or restricts the author’s moral rights.
• For more information see http://creativecommons.org/licenses/by/3.0/