1. SCRUM Workshop May 2009
Presented by Manfred.Friedrich@AdScale.de
May 5th, 2009

2. Scrum Overview
2

3. Workshop Objections
By the end of the workshop you will:
• Have a clear understanding of Scrum
• Know how to apply Scrum to our project
www.adscale.de
3

4. 3/4 SW Projects Fail
• Uncertainty Principle of SE
• Did not understand requirement
• No change management procedure
• Problems or failures occur to late
• Budget has been dropped
• Unreliable integration and release
cycles
[c't 2001]
[Standisch Group1994-2002] Based on 40.000 projects between 1994-2002
www.adscale.de
4

5. Common Examples of
Uncertainty and Change
Uncertainty
• I won’t know if it’s right until I see it
• I don’t know what will go wrong
• We don’t know what the competition will do
• We don’t know what the customer will like
Change
• I just had a great new idea
• The customer just changed his mind
• The competition just changed his mind
• Our CEO just changed his mind
www.adscale.de
5

6. Common Project Management
Myths
• One Process guaranties success
• One process is never the
problem of bad interaction, it
optimizes interaction
• People grow together as a good
team by them self
• People are interchangeable „Plug
Compatible Units“
• We did not archive our goals ->
lets go and get a better “heavy
weigh” process
www.adscale.de
6

7. A Defined Process
Muffin Mix Yummy Muffins
www.adscale.de
7

8. Following a Plan
www.adscale.de
8

9. Following a Plan
A – Start B – Planned Result
www.adscale.de
8

10. Following a Plan
A – Start B – Planned Result
C – Guided Result
www.adscale.de
8

11. Following a Plan
„...following a plan p
roduces the product
just not the product y you intended,
ou need“
Jim Highsmith [Hig 20
00]
A – Start B – Planned Result
C – Guided Result
ered
eede d & what we deliv
“what th ey thought they n ey w ere 100% satisfie
d
were complete ly different, but th ”
with what we delivered
www.adscale.de
8

12. Planned Iterative ...
www.adscale.de
9

13. Planned Iterative ...
www.adscale.de
9

14. Planned Iterative ...
www.adscale.de
9

15. Planned Iterative ...
Requirements
Analysis
www.adscale.de
9

16. Planned Iterative ...
Requirements
Analysis
Design
www.adscale.de
9

17. Planned Iterative ...
Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

18. Planned Iterative ...
Integration,
Test Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

19. Planned Iterative ...
Integration,
Test Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

20. Planned Iterative ...
Integration,
Test Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

21. Planned Iterative ...
Integration,
Test Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

22. Planned Iterative ...
Integration,
Test Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

23. Planned Iterative ...
Integration,
Test Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

24. Planned Iterative ...
uct
P rod 0
.
V. 1
Integration,
Test Requirements
Analysis
Coding,
Unit Testing Design
www.adscale.de
9

25. ... but degenerate to waterfall
www.adscale.de
10

26. ... but degenerate to waterfall
A A A A
D D D D
C C C C
T T T T
www.adscale.de
10

27. ... but degenerate to waterfall
A A A A
D D D D
C C C C
T T T T
A
D
C
T
www.adscale.de
10

28. ... but degenerate to waterfall
A A A A
D D D D
C C C C
T T T T
A t
se a
ng relea cycle
D Bi g ba of the
d
th e en
C
T
www.adscale.de
10

29. ... but degenerate to waterfall
A A A A
D D D D
C C C C
T T T T
A t
se a
ng relea cycle
D Bi g ba of the
d
th e en
C
T
www.adscale.de
10

30. ... but degenerate to waterfall
A A A A
D D D D
C C C C
T T T T
A t
se a
ng relea cycle
D Bi g ba of the
d
th e en
C
T
www.adscale.de
10

31. ... but degenerate to waterfall
A A A A
D D D D
C C C C
T T T T
A
D
C
T
www.adscale.de
10

32. ... but degenerate to waterfall
A A A A
D D D D
C C C C
T T T T
? ? ? ?
A
D
C
T
www.adscale.de
10

33. Iterative Development
Visibility & Adaptability
All-at-once Development
Time
www.adscale.de
11

34. Iterative Development
Iterative Development
Visibility & Adaptability
All-at-once Development
Time
www.adscale.de
11

35. Development Cycle
Scope
Classic Iterative
Test
Code
Design
Analyse
Time
www.adscale.de
12

36. Development Cycle
Scope
Classic Iterative
Test
Code
Design
Analyse
Time
www.adscale.de
12

37. Development Cycle
Scope
Agile Cycles
Test
Code
Design
Analyse
Time
www.adscale.de
12

38. Timeboxing
Requirements
Requirements Design Coding Unit Integration,
Analysis
Analysis Testing Test
Project Management
Quality Management
Systematische Test -
Acceptance /
Validierung
Verifikation
Testobjekte/ Regression Regressions -
Other QA
Vollständigkeit Integration Tests Load Test
Testfälle durchführung
Tests Tests Tasks test
der Struktur
Short iterations of 1-4 weeks; Incremental releases
www.adscale.de
13

39. Control Variables are crucial
• 61,5% of all finished projects were out of time, cost,
scope and quality
• 29,5% of all projects have been cancelled
• 9% of all projects have been finished within the project
boundaries.
www.adscale.de
14

40. Project Dimensions
www.adscale.de
15

41. Project Dimensions
www.adscale.de
15

42. Project Dimensions
www.adscale.de
15

43. Project Dimensions
www.adscale.de
15

44. Project Dimensions
www.adscale.de
15

45. Project Dimensions
www.adscale.de
15

46. Influence
www.adscale.de
16

47. Top Scope, Top Quality but crappie
time and cost
www.adscale.de
17

48. Management by Quality
www.adscale.de
18

49. Management by Quality
www.adscale.de
18

50. Quality is the Top Priority
If it didn’t have to work, you could build it pretty
quickly.
It is always fastest to do the job right the first time.
Rework and repair is wasteful.
The sooner you fix it the better.
Focus on quality from the beginning of the job.
Quality without numbers is just talk.
www.adscale.de
19

51. Management by Scope
www.adscale.de
20

52. Empirical Processes
“It is typical to adopt the defined (theoretical) modeling approach
when the underlying mechanisms by which a process operates are
reasonably well understood. When the process is too complicated for
the defined approach, the empirical approach is the appropriate
choice.”
[Process Dynamics, Modeling, and Control, Ogunnaike
and Ray, Oxford University Press, 1992)]
Abstract: Inspect and Adapt
www.adscale.de
21

53. Agile
22

54. Agile
Agile is a great
buzzword. Who doesn’t
want to be Agile?
No one says, “Thanks,
I’d rather be inflexible
and slow to respond.”
www.adscale.de
23

55. Agile
• Umbrella of different frameworks and
practices driven by common values
• The most popular are Scrum, XP and Lean
www.adscale.de
24

56. The Agile Manifesto
individuals and over Process and Tools
interaction
Working over
Comprehensive
Software documentation
Customer over
Contract
Collaboration negotiation
Responding to over Following a Plan
Change
While we value the items on the right, we value the items on the left more.
www.adscale.de
25

57. Agile Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect
www.adscale.de
26

58. Agile Myths
• No Design
• No Planning
• No Documentation
• Poor Quality
• “Hacking” Code
• Only Works on Small Projects
www.adscale.de
27

59. Agile Myths
• No Design
• No Planning
• No Documentation
• Poor Quality
• “Hacking” Code
• Only Works on Small Projects
www.adscale.de
27

60. Scrum
28

61. Scrum is NOT
www.adscale.de
29

62. What is Scrum
A flexible framework that is:
• Collaborative
• Iterative & Incremental
• Very simple but very hard; it
causes change
www.adscale.de
30

63. Origins
The New, New Lean Iterative, Incremental
Product Development Development,
Game* Timeboxes
Smalltalk Engineering
Tools
Scrum
(Schwaber & Sutherland 1993)
*Harvad Business Review, Jan.
1986, Takeuchi and Nonaka
www.adscale.de
31

64. “The problem we face has nothing to do with process
and technology, but with people.
Scrum and Agile are based on the hypothesis that there
is no meta-solution for software development. Just a
framework within which we will be empirical –inspect
and adapt.
This is very frustrating for those looking for procedures
and final answers.”
- Ken Schwaber -
www.adscale.de
32

65. Scrum Process
www.adscale.de
33

66. Module: Roles
Product Sprint Sprint Daily Sprint Sprint
Roles
Backlog Planning Tracking Scrum Review Retro
34

67. Scrum Roles
Product Owner
Scrum Master
Scrum Team
www.adscale.de
35

68. Role: Product Owner
• Defines the features of the product,
• decides on release date and content
• Is responsible for the profitability of the product (ROI)
• Prioritises features according to market value
• Can change features and priority every 30 days
• Accepts or rejects work results
www.adscale.de
36

69. Role: Scrum Master
• Ensures that the team is fully functional and productive
• Enables close cooperation across all roles and
functions and removes barriers
• Shields the team from external interferences
• Ensures that the process is followed.
• Invites to daily scrum, iteration review and planning
meetings
www.adscale.de
37

70. Role: Scrum Team
• Cross-functional, seven plus/minus two members
• Selects the iteration goal and specifies work results
• Has the right to do everything
• within the boundaries of the project
• guidelines to reach the iteration goal
• Organizes itself and its work
• Demonstrates work results to the Product Owner
www.adscale.de
38

71. A Self-Organizing Team...
• is group of peers assembled for the purpose of bringing a software
development project to completion
• shares a goal
• shares belief that their work is interdependent => therefore
collaboration is the best way to accomplish goal
• reduces their dependency on management through empowerment
• accepts accountability
• takes ownership and controls close to the core of their work
• shares responsibility for managing their own work
• shares responsibility for problem-solving and continuous improvement
of their work processes
www.adscale.de
39

72. Self-Organizing Team
• When we say an Agile team is self-organizing, we mean that a group of
peers has assembled for the purpose of bringing a software
development project to completion. The team members share a goal
and a common belief that their work is interdependent and collaboration
is the best way to accomplish their goal.
• Empowered team members’ reduce their dependency on management
as they accept accountability, and the team structure places ownership
and control close to the core of the work. Rather than having a manager
with responsibility for planning, managing and controlling the work, the
team members share increasing responsibility for managing their own
work and also share responsibility for problem-solving and continuous
improvement of their work processes.
•
www.adscale.de
40

73. self-organizing
The team collectively selects requirements from a prioritized list, selecting only as
much as it believes it can turn into an increment of working product functionality
during the next Sprint. The only constraints on the team are any existing
organizational standards, conventions, and previously constructed product
functionality. The team commits to management that it will turn these requirements
into working product functionality by the end of the Sprint. The team is the left alone
to do so for the duration of the Sprint. Left alone! No one to tell the team what to
do? No methodology to tell the team how to transform the requirements into
functionality? No one to blame if the team fails? No one to grab the glory if the team
succeeds? That’s right, left alone. It is solely and utterly the team’s responsibility to
figure out what to do, and to do it. The old saying, Be careful what you ask for,
because you might get it! describes the dilemma and opportunity of the team. In my
experience, every team is at first shocked by this responsibility. However, as the
team realizes that it has the full authority to do whatever it deems necessary, a
sense of liberation and empowerment (that usually trite phrase) occurs. The team
starts talking, drawing designs on whiteboards, figuring of what work needs to be
done. People start defining what work they’ll do, and what help they need to do it.
Some people ask to do work that they’ve always wanted to learn, signing up for
other additional work to offset their learning curve. The team collectively simmers,
brainstorms, and works to meet its commitment. The team self-organizes. -- Jeff
Sutherland
www.adscale.de
41

74. Scrum Team Metaphor
A scrum is a team of eight individuals in Rugby.
Everyone in the pack acts together with everyone else
to move the ball down the field. For those who know
rugby, the image is clear. Teams work as tight,
integrated units with each team member playing a
well-defined role and the whole team focusing on a
single goal. In development teams, each team
member must understand his or her role and the tasks
for each increment. The entire team must have a
single focus. The priorities must be clear. As we now
describe, the Scrum development process facilitates
this team focus.
www.adscale.de
42

75. Software development is a cooperative
game
„Software development is a (series of) cooperative
game(s), in which people use markers and props to
inform, remind and inspire themselves and each
other in getting to the next move in the game. The
endpoint of the game is an operating software
system; the residue of the game is a set of markers
to inform and assist the players of the next game.
The next game is the alteration or replacement of
the system, or creation of a neighboring system."
---Alistair Cockburn
www.adscale.de
43

76. Module: Product Backlog
Product Sprint Sprint Daily Sprint Sprint
Roles
Backlog Planning Tracking Scrum Review Retro
44

77. Product Backlog
• List of functionality, technology,
issues
• Issues are placeholders that are
later defined as work
• More detail on higher priority
backlog
• Product Owner responsible for
priority
• Anyone can contribute
This is the Product
Backlog • Maintained and posted visibly
• Derived from Business Plan or
Vision Statement, which
sometimes have to be created
with customer 45
www.adscale.de

78. Planning
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
www.adscale.de
46

79. Estimation over Time
Roadmap Product Back-Log Sprint Back-Log Sprint Plan Implemented
www.adscale.de
47

80. Module: Sprint Planning
Product Sprint Sprint Daily Sprint Sprint
Roles
Backlog Planning Tracking Scrum Review Retro
48

81. User Stories
• A short description of the behavior of the system from
the point of view of the Customer
• Use the Customer’s terminology without technical
jargon
• One for each major feature in the system
• Must be written by the users
• Are used to create time estimates for release planning
• Replace a large Requirements Document
www.adscale.de
49

82. Sample User Story
Create new Customer
As an Supporter I want to be able to
create an new Customer-Account
Acceptance Criteria:
+ EMail address valid and Unique
+ User Name Unique
www.adscale.de
50

83. User Story as Automated Test
www.adscale.de
51

84. Sprint Planning
• Team plans out what
they will commit to
delivering for the next
Sprint
• Team creates tasks,
estimates, and
volunteers for them
This is the Sprint
Planning Meeting
www.adscale.de
52

85. Sprint Planning - Step 1
1 As a Guest, I can add one
photo to my profile
2 As a premium member I
can add up to ten photos to
my profile page
Product owner and team
3 As a premium member, I
can add video to my
profile page
4 As a Guest, I can add one
photo to my profile
discuss the latest
5 As a User I can add photos
to my profile page product backlog and the
6 As a user I can create a
profile to display
goals of the Sprint
information about myself
7 As a User I can add
people I like to a “hot list”
www.adscale.de
53

86. Sprint Planning - Step 2
The team works out their collective hours available for the Sprint
Name Base Less Less Less Total
Hours Holidays Vacation Other
Anne 6h 1d --- --- 54h
Warwick 3h 1d --- --- 30h
Tom 5h 1d 2d --- 42h
Ben 8h 1d --- --- 52h
www.adscale.de
54

87. Sprint Planning - Step 3
• Team breaks Product
Backlog items into tasks
• Each Task is estimated
(Done! incl. Test )
Task: Configure
Database
(7h @ Scott)
• Each Task has a
volunteer
www.adscale.de
55

88. Sprint Backlog
• Before each Sprint, the highest
prioritised goals are transferred to
a Sprint Backlog.
• List of tasks to turn product
backlog into working product
• Tasks are estimated in hours
• Tasks >1day are broken down
later
• Team members sign up for tasks,
they aren’t assigned
Sprint Backlog
• Estimate work remaining is
updated daily
www.adscale.de
56

89. Sprint
A time-boxed iteration
During the Sprint:
• Analysis
• Design
• Coding
Sprint
• Test
www.adscale.de
57

90. No Changes During Sprint
• No Changes to Deliverables
• Once team has committed, no changes
• Details will emerge during Sprint, but no work or
substantionally changed work
• No Changes to Sprint Duration
• Sprint ends on planned date whether team has
comleted all its commitment or not
www.adscale.de
58

91. Module: Sprint Tracking
Product Sprint Sprint Daily Sprint Sprint
Roles
Backlog Planning Tracking Scrum Review Retro
59

92. Tracking Progress
• Scrum tracks the work remaining.
• Does not track actual time worked Updated
daily
www.adscale.de
60

93. Scrum Task Board
www.adscale.de
61

94. Task List Updated Daily
Hours of work Remaining on Each Day of the Sprint
Task Task Day Day Day Day Day Day Day Day Day Day
Owner 01 02 03 04 05 06 07 08 09 10
Use test data to tune the impression handler Warwick 4 3 6 1 0 0
Set-up Teracotta Server Ben 2 1 1 1 1 0
Implement pre-login handler Amanda 6 3 3 2 2 1
Merge RB branch Jason 8 5 4 2 2 2
Rework login page - use email Joost 4 4 3 2 3 3
Configure Database and Stored Procedures Markus 2 2 0 0 0 0
Total 26 18 17 8 8 6
www.adscale.de
62

95. Burndown Chart
Where the team is
now
Steady pace
www.adscale.de
63

96. Module: Daily Scrum
Product Sprint Sprint Daily Sprint Sprint
Roles
Backlog Planning Tracking Scrum Review Retro
64

97. Daily Scrum
Daily Scrum
~ 15 minute meeting:
• What I did yesterday
• What I plan on doing
today
• What is blocking me
www.adscale.de
65

98. Standup Meeting
Why
get a sense of the trouble spots
identify who might be able to help
communication surprises to exploit or prepare for
make sure you are starting the day right
What
What did you do yesterday that might affect others?
What progress did you make yesterday?
What do you plan to do today?
www.adscale.de
66

99. Daily Scrum
• Scrum Master facilitates Stand-Up
• Side conversations are put on the parking lot
• Blocks and issues are identified, and action plans are
created
• Follow-up on resolutions
www.adscale.de
67

100. A Standup Meeting is a Starter's Gun
The standup meeting is a practice borrowed from the Scrum process.
The team stands, and each person briefly reports what they did
yesterday, what they plan to do today, and what's in their way.
Well, 25 years, and 50 kilograms ago, I ran track. Before a race, the
runners do a little warmup running and a few practice starts, but
they're not starting to race yet. When it's time, the starter says, "On
your mark, get set, go!" and everybody starts running full speed, at
the same time and in the same direction.
A morning standup meeting feels like that to me. Without a meeting,
people trickle in; some people hear things and others don't. With a
standup meeting, we get everybody together at the same time,
pointed in the same direction, and the day's race begins in earnest.
-- [William C. Wake 2002]
www.adscale.de
68

101. Module: Sprint Review
Product Sprint Sprint Daily Sprint Sprint
Roles
Backlog Planning Tracking Scrum Review Retro
69

102. Sprint Review
This is the Sprint
review
www.adscale.de
70

103. Sprint Review
A demo by the team of:
• Complete
• Fully tested
• Potentially shippable
features
• High quality
This is the Sprint
review
• Tested
• “Done”!
www.adscale.de
70

104. Module: Sprint Retrospective
Product Sprint Sprint Daily Sprint Sprint
Roles
Backlog Planning Tracking Scrum Review Retro
71

105. Sprint Retrospective
A meeting at the end of each Sprint so the
Team can Inspect and Adapt the process
www.adscale.de
72

106. Sprint Retrospective
Topics covered are:
•What progress did the team make during the
Sprint
•What worked well during the sprint, and the
team should continue doing
•What improvements can the team make for
things that didn’t work so well
www.adscale.de
73

107. Sprint Retrospective
• Capture all input
• Aim for 1-3 improvements for next Sprint
• Review past retrospectives, to see how team
is doing.
www.adscale.de
74

108. What a Retrospective is NOT
• Retrospectives are NOT about blame
• Retrospectives are NOT a witch hunt
• Retrospectives are NOT about gathering
specific information
www.adscale.de
75

109. Our Process ...
... not just SCRUM
76

110. Scrum with XP
complementary
practices and rules
Scrum XP
Management Practices Engineering Practices
Product Backlog Simple system design
Sprint Backlog Test-Driven-Development
Sprint Continuous integration
Burn Down Re-factoring
Daily Scrum Pair programming
Sprint Retrospective Collective Code Ownership
overlap at the planning game (XP)
and sprint planning (Scrum)
www.adscale.de

111. Scrum
 Product development methodology consisting of practices and rules to
be used by management, customers, and project management
 Maximize productivity and value of a development effort.
 Takes the responsibility for development projects out of engineering
and IT and puts them squarely back in the business.
 Businesses own and manage projects rather than "tossing them over
the wall" to IT and hoping for the best.
 Reintroduces accountability for IT projects to the business, requiring
the business to maximize the ROI, without excuses.
 NO engineering practices. When engineering practices are weak,
overall productivity is lessened.
www.adscale.de

112. eXtreme Programming
 eXtreme Programming (XP) is an engineering
methodology consisting of practices that ensure top-
quality, focused code.
 It builds up to a dozen practices, weaving them into a
synergistic whole in which each one is reinforced by the
others
 Teams that use XP practices are adhering to strong
engineering disciplines. Like guilds, the teams that follow
these practices generate good products.
 NO management practices. XP tells management where it
needs them, but offers few insights into maximizing value.
www.adscale.de

113. SW Development Rules
Planning Coding
User stories are written The customer is always available
Project is divided into Sprints Code must be written to agreed standards
Sprint planning creates the schedule
Code the unit test first
Sprint planning starts each Sprint
Make frequent small releases All production code is pair programmed
Project-velocity is measured Integrate often
Move people around Use collective code ownership
Stand-up meeting starts each day Leave optimization till last
Fix ASP when it breaks No overtime
Designing
Testing
Simplicity (Innovative but Sufficient to
Purpose) Follow TDD principals
Choose a system metaphor All code must have unit tests
Create spike solutions to reduce risk All code must pass all unit tests before it can be
No functionality is added early released
Re-factor whenever and wherever possible When a bug is found tests are created first
Acceptance tests are run often and the score is
published
www.adscale.de
80

114. Discussion
What are your
challenges?
How can we learn
from and support
each other?
www.adscale.de
81