What is agile? And what is scrum? One day training for new employees

1. PRACTICAL SCRUM
Like us:
Visit:
Follow me:
Tweet:
CONSTANT
HIGHER
MORE
LEARNING
QUALITY
FUN
Day 1
www.facebook.com/PracticalAgile
www.practical-agile.com
@Linkedin
@PracticalAgile1

4. BEING AGILE IS OUR FAVORITE THING

5. Some Working Agreement
If you want to be here - act like you want to be here

6. Some Working Agreement

7. EXERCISE
Let’s Form Teams

8. Respect the sticky note
One item per sticky, use a sharpie

9. What are we going to cover today?
TABLE OF CONTENTS
What is Agile?
What is scrum?
What are the roles in scrum?
What is the manager role within
agile environment?
How to estimate stories?
How do we do long term planning?
What is the meaning of each
ceremony in scrum?

10. “It ain’t what you don’t know
that gets you into troubles.
It’s what you know for sure
that just ain’t so”
Mark Twain
WHAT WE THOUGHT VS. WHAT WE KNOW

11. What we thought vs. What we know

12. Requirements
Design
Implement
Test
Acceptance
Analysis
Deliver

13. WINSTON W. ROYCE 1970
"I believe in this
concept, but the
implementation
described above is
risky and invites
failure"

14. “It ain’t what you don’t know
that gets you into troubles.
It’s what you know for sure
that just ain’t so”
Mark Twain
WHAT WE THOUGHT VS. WHAT WE KNOW

15. 01
WHAT WE
KNOW
The harder we plan and
analyze in the beginning,
the less there’s change in
the project and the more
successful the project
WHAT WE
THOUGHT

16. WHAT WE
THOUGHT
01
WHAT WE
KNOW
There is change always
and responding to it is vital.
Uncertainty is best reduced
by learning from actual
implementation

17. 02
WHAT WE
KNOW
It is possible to “collect” or
even “know” all the
requirements up-front
WHAT WE
THOUGHT

18. 02
WHAT WE
KNOW
Requirements evolve
as customers and our
knowledge increases –
based on experience
WHAT WE
THOUGHT

19. 03
WHAT WE
KNOW
Division of work to
specialized teams
(specification, design and
testing) is efficient
WHAT WE
THOUGHT

20. WHAT WE
THOUGHT
03
WHAT WE
KNOW
Cross-functional teams
reduce the amount of
handovers and are more
productive

21. 04
WHAT WE
KNOW
Multiple parallel programs
speed up the development
WHAT WE
THOUGHT

22. EXERCISE
Exercise: The Name Factory
•
•
•
•

23. Round 1
Context Switch

24. Round 2
No Context Switch

25. WHAT WE
THOUGHT
04
WHAT WE
KNOW
Multiple programs create
big management
overhead and risk of
overloading the pipeline,
R&D works most efficiently
in continuous mode

26. 05
WHAT WE
KNOW
Resource usage and cost
optimization is the key to
increased productivity
WHAT WE
THOUGHT

27. Continues Improvement
Respect for People
Waste Value
Opportunity for
improvement
Traditional
improvement
Lean Thinking

28. Kaizen - Reduce Waste
Value:
The moments of actions or thoughts creating the
product that the customer is willing to pay for
Total value time
Total cycle time
= Value ratio____________
Waste:
All other moments or actions that do not add value
but consume resources

29. Detect and Eliminate Waste
1. Overproduction of features
2. Waiting and delay
3. Handoff
4. Extra process
5. Partially done work

30. Detect and Eliminate Waste
6. Task Switching
7. Defects
8. Under-realizing
people’s potential
9. Knowledge scatter
10.Wishful thinking

31. WHAT WE
THOUGHT
05
WHAT WE
KNOW
Concentrating on value
stream optimization,
removing waste and
sustainable flow increases
productivity

32. 06
WHAT WE
KNOW
It’s possible to transfer
information effectively on
written documents without
much of human contact.
WHAT WE
THOUGHT

33. WHAT WE
THOUGHT
06
WHAT WE
KNOW
Essential knowledge is
lost in every handover
and human interaction is
needed to overcome it.

34. 07
WHAT WE
KNOW
You can save time by
“good-enough”
development.
WHAT WE
THOUGHT

35. Technical Debt
Time
Work
left
20
10 12 14 16 18
Low Quality

36. WHAT WE
THOUGHT
07
WHAT WE
KNOW
Any technical debt will
slow development down
and thus we don’t allow
technical debt to
accumulate.

37. 08
WHAT WE
KNOW
Product development
process can be defined as a
predictable and
repeatable process
WHAT WE
THOUGHT

38. WHAT WE
THOUGHT
08
WHAT WE
KNOW
Product development is an
evolving and adaptive
process

39. THE ORIGIN
• Toyota lean concept
• The new, new software
development game
[Takeuchi & Nonaka, 1986]
• Iterative & incremental
development

40. WHAT IS AGILE?

41. EXERCISE
Rewrite Each Agile Principle With 3 Words

42. Agile Principle 1-4
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software

43. Agile Principle 1-4
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software
2.Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s competitive
advantage

44. Agile Principle 1-4
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s competitive
advantage
3. Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to a shorter timescale

45. Agile Principle 1-4
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive
advantage
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to a shorter timescale
4. Business people and developers must work together daily
throughout the project

46. Agile Principle 5-8
5. Build project around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done

47. Agile Principle 5-8
5. Build project around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done
6. The most efficient and effective method of conveying
information to and within development team is face-to-face
conversation

48. Agile Principle 5-8
5. Build project around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done
6. The most efficient and effective method of conveying information
to and within development team is face-to-face conversation
7. Working software is the primary measure for progress

49. Agile Principle 5-8
5. Build project around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done
6. The most efficient and effective method of conveying information to
and within development team is face-to-face conversation
7. Working software is the primary measure for progress
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely

50. Agile Principle 9-12
9. Continuous attention to technical excellence and good
design enhances agility

51. Agile Principle 9-12
9. Continuous attention to technical excellence and good design
enhances agility
10.Simplicity – the art of maximizing the amount of work not
done – is essential

52. Agile Principle 9-12
9. Continuous attention to technical excellence and good design
enhances agility
10.Simplicity – the art of maximizing the amount of work not done –
is essential
11.The best architectures, requirements, and designs emerge from
self-organizing teams

53. Agile Principle 9-12
9. Continuous attention to technical excellence and good design
enhances agility
10.Simplicity – the art of maximizing the amount of work not done –
is essential
11.The best architectures, requirements, and designs emerge from
self-organizing teams
12.At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly

54. EXERCISE
Command and Control
Vs.
Self Manage

55. Where Scrum Fits?

56. • In our industry people got used to create and use META
solutions to problems.
• The problems we are facing have nothing to do with
technology, it is a people issue.
• In this land the basic assumption is that there is no META
solution, just an empirical framework to allow inspect & adapt
cycles.
• This experience is frustrating for those who are looking for
predefined processes and final answers.
• ENTER AT YOUR OWN RISK!!!

57. WHAT IS SCRUM?
"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 in small
incremental steps. Teams work as tight,
integrated units with whole team focusing on a
single goal."

58. THE ORIGIN OF
SCRUM
• Toyota lean concept
• The new, new software
development game
[Takeuchi & Nonaka, 1986]
• Iterative & incremental
development
• Jeff Sutherland
• Ken Schwaber

59. • Understanding that we
cannot predict the future
• One size does not fit all
• Constant improvement
• Transparency & Visibility
• Team work
SCRUM PRINCIPLES

60. • Deliver business value fast
(max. 30 days)
• Prioritizing
• Empirical approach
• Fun !!!
SCRUM PRINCIPLES

61. THE HIGH MOON STUDIO

62. SCRUM PROCESS OVERVIEW
3 Roles:
Product owner
Scrum Master
Team
4 Ceremonies :
Sprint Planning
Daily
Sprint review
Retrospective
3 Artifacts:
Product Backlog
Sprint Backlog
Burndown Charts

63. SCRUM MASTER (SM)
• Scrum - A framework for
managing the development
lifecycle of software products
• Master - A skilled practitioner of
a particular art or activity
• A Scrum master - the leader of
the Scrum process (& team)

64. What does it means
“The leader of the scrum process”?
• Coach the team with Scrum
• Coach the PO with Scrum
• Help Facilitate effective ceremonies
• Helps removing impediments
• Help the team grow
• He is standing at the nexus between:
The product management
that believes that any
amount of work can be
done
Developer’s that have the
willingness to cut quality to
support the managements
belief

65. The English verb “to manage” was originally derived
from the Italian maneggiare, meaning to handle and
train horses
The SM has no authority over the team or the PO

66. WHAT IS THE MANAGER ROLE WITHIN AGILE ENVIRONMENT?
A change in Manager’s role
Stop:
• Assign task and verify completion
• Micro manage to have the “illusion of control”
• Makes decisions for the team
• Limit the information & resources available to the team
Start:
• Trust the team to get the job done
• Gather data
• Coach - observe and ask questions
• Challenge
• Give feedback

67. SCRUM TEAM
• Self organizing
• Typically 5-9 people
• Cross functional (Preferably a
feature team)
• Provide estimate for the tasks
• Decides how much it can do
• Decides how to reach the sprint
goal (within the project’s boundaries)
• The team is responsible for the
outcome

68. CONCEPT CHANGE
• Decides what it can do
• Decides how to do it
• Responsible for the quality
• If the job is successful the team
gets the credit
• If the job is not DONE the team
is responsible
ALL OF US
ARE SMARTER THAN
ANY OF US

69. THE TEAM IS
WRONG?
• Let the team fail
• Create an environment where it
is ok to fail
• Failure amplifies learning
• Where failure is allowed,
innovation and experiments are
encouraged
• Increases trust
THERE IS NO FAILURE
ONLY FEEDBACK

70. PRODUCT OWNER (PO)
• Defines the features of the product
• Defines release dates and content
• Responsible for ROI
• Prioritizes feature according to value
• Can change features and priority
once every predefined interval
• Decides what will be worked on in
each iteration
• Accepts or rejects results

71. Manage the product Backlog
1. Clear
2. Ranked
3. Optimize
the value
4. Visible
transparent
5. Ensure
understanding

72. Traditionally throws content “over the fence”

73. The PO takes an active role throughout the
development lifespan
Traditionally throws content “over the fence”
NO MORE!
CONCEPT CHANGE

74. How?
• Talk directly and frequently with your
customers
• Talk directly and frequently with your
development teams
• Engage the development teams in
creating value for your customers
• Maintain your product’s quality and
agility – do not let technical debt
accumulate

75. Product Backlog Refinement = Grooming
The team and the PO together review the backlog in order to
make it ready for the next 2-3 sprints
How?
Grooming = Clarifying, Estimating, and Splitting
Recommended to allocate ~5% of the sprint time

77. Sizing Requirements

78. KEN SCHWABBER, “SCRUM ET AL”

79. What is Definition of Done (DoD)
Terms of satisfaction of the product owner
Defined by the PO with the team
reflecting the technical abilities of the team
Items that are not Done “do not count”

80. This is just one example
Expending the Definition of Done over time
Designed
Coded
analyzed
Unit tested
Perf. tested
Code coverage
Live
Deployable
Acc. tested

81. This is just one example
Expending the Definition of Done over time
Undone
Undone
Undone
Undone
Stabilization
sprint(s)
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Undone = risk
Undone = no visibility
Can we
release ?
Unfinished Unfinished Unfinished

82. Agile Effort
Estimations

83. EXERCISE
Estimate The Following Based On Weight In
Kilograms [No Google Please!!!]
• Chihuahua
• Great Dane
• Staffordshire bull terrier
• Appalachian mountain dog
• Border Collie
• American Cocker spaniel

84. “IT IS BETTER BE
ROUGHLY RIGHT
THAN PRECISELY
WRONG”
John Maynard Keynes

85. Persistence of Time

86. 34.4
Relative Estimations

87. • We are:
- Not good in measuring absolute values
- Good in comparing things
• We have the basic math skills (or a
calculator)
• High accuracy has a high toll
• Estimates become
commitments
• Time is not persistent
Why Relative?

88. Story Points:
They reflect the “bigness” of a user story
How hard it is ?
How risky it is ?
How much of it there is ? 5
?
3

89. 1. Each person gets a deck of cards (Fibonacci)
2. The item to be estimated is read to all
3. Attendants ask clarifications for the item
4. Each person selects a card and puts it on the table facing down
5. When everyone is done, cards are exposed
6. If the estimations do not match a short discussion is done:
Highest and Lowest estimators speak first -> return to step 4
7. Handle next item
Planning Poker:

90. EXERCISE
Estimate The Following Based On Size
Using Planning Poker
• Spain
• China
• Luxembourg
• Denmark
• South Africa - 8 (Reference
point)
• Belize

91. • Those who do the work estimate it
• Emphasizes relative estimation
• Estimates are within one order of magnitude
• Modeled for open discussion – forces thinking
• Reduces anchoring - Everyone's opinion is heard
WHY USE PLANNING POKER?

92. One page spec
Group A
7 Pages spec
Group B
173 hours
117 hours
Specification Length

93. Group A
Customer thinks 500
customer has no technical knowledge
Don’t let the customer influence you
Group B
555 hours
456 hours
Same as B
customer thinks 50
Group C
99 hours
Anchoring

94. WHY USE
PLANNING
POKER?
IT IS QUICK!
IT IS FUN!

95. Spain 3
China Too big
Luxembourg 0
Denmark 1
South Africa 8
Belize 1
Chihuahua 3
Great Dane 90
Staffordshire bull
terrier.
17
Appalachian mountain
dog.
???
Border Collie 23
American Cocker
spaniel
13
The Results

96. Velocity =
Speed + Direction
How many points can the team
complete in one iteration
Easy to measure
Fixes estimation errors
Easily reflects the project status
Primary parameter in planning

97. SP
8
priority 5
priority 4
SP
8
priority 3
Planning
Iteration Planning
As Anat, scrum Master, I
would like to calculate
team velocity so that I will
be able to estimate how
much work I can do in the
following iteration
SP
5
priority 2
Planning
SP
2
Iteration 1:
SP Done = 5+8+2 = 15
velocity = 15

98. SP
8
priority 5
priority 4
SP
8
priority 3
Planning
Iteration Planning
As Anat, scrum Master, I
would like to calculate
team velocity so that I will
be able to estimate how
much work I can do in the
following iteration
SP
5
priority 2
Planning
SP
2
Iteration 1:
SP Done = 5+8+2 = 15
velocity = 15
priority 7
SP
5
priority 6
Planning
As Elad, product owner, I
would like to calculate
team velocity so that I will
be able to estimate how
much work we are going to
complete in two months
SP
8
priority 5
Planning
SP
2
Iteration 2:
SP Done = 8+5 = 13
velocity = (15+13)/2 = 14

99. SP
5
priority 8
What will happen if support is needed?
SP
2
priority 7
Long Term Crisis:
Planning
Iteration 3:
SP Done = 2+5 = 7
velocity = (15+13+7)/3 = 12~
SP Done:
Iteration 4 = 5
Iteration 5 = 7
Iteration 6 = 6
Velocity = (13+7+5) = 8
Velocity = (7+5+7) = 6
Velocity = (5+7+6) = 6

100. Planning For Support:
Alternating team each sprint
Alternating person each sprint
Limiting the hours per team
Use velocity - Ignoring it completely

101. Agile
Planning
With
Scrum
Daily
Iteration
Release
Product
Portfolio
Strategy

102. Release
Planning#Story
points
Time
Velocity

103. Calculating Release Time
Given that:
The items for the release are estimated
The velocity is known (or predicted)
We know the scope or deadline
#Story
points
Time
Velocity

104. Calculating Release Time
We can estimate:
How much content can we do
until the deadline
How many sprints it will take
to complete the content
# Sprints X Velocity = # Story Points
# Story Points
Velocity
= # Sprints____________
#Story
points
Time
Velocity

105. Scrum
Ceremonies

106. Sprint Planning
The first meeting of the sprint
Length: 2-8 hours
Participants: PO, Team, Scrum Master
Preconditions: Product backlog should be in good shape
Divided into two parts

107. Sprint Planning Goal

108. Sprint Planning - Part I
Decide what the team takes to part II
1. PO Explains the top items from the backlog
2. Team decides what takes to part II in order to commit for sprint
content
3. Team and PO selects the sprint goal

109. Sprint Planning - Part II
Generate the sprint backlog & commit on the sprint’s content
How?
Splitting each of the stories into smaller tasks
Estimating each task (maximum length 8 hours)
Design decisions
Verify that the goal is achievable
Commit

110. Sprint Backlog

111. The sprint Backlog
Belongs to the team
Assists the team in tracking the sprint’s progress
Maximum task length should not exceed 16h (2 days) for a 2
week sprint
Updated throughout the sprint
• Every team member can add, remove or change the sprint backlog
• Status of tasks & remaining work is updated daily
• Sprint content emerges

112. To do In progress Done
PBI # 1
PBI # 2
Task Board

113. To do In progress Done
PBI # 1
PBI # 2
Task Board

114. To do In progress Done
PBI # 1
PBI # 2
Task Board

115. To do In progress Done
PBI # 1
PBI # 2
Task Board

116. To do In progress Done
PBI # 1
PBI # 2
Task Board

117. Burndown Chart
A simple visual way of tracking
progress
Used in different levels:
Sprint
Release
Product
Shows the amount of work left to
reach target

118. Effortremaining
0
25
50
75
100
Sprint
1 2 3 4 5 6 7 8
Sprint Burndown Chart

119. Daily Scrum

120. Every day, Same time, Same place
No longer than 15 minutes
Stand up
All the team must attend
Only team members are allowed to speak
Daily

121. Daily
3 Questions:
1. What have we accomplished since the
last daily
2. What will we accomplish until the next
daily
3. What are my/our impediments

122. EXERCISE
Daily Scrum From Hell

123. Sprint Review
Show & Tell
Bazaar Review

124. Close the sprint
Participants: The team, PO, everyone (managers, customers..)
Inspect & adapt, focus on feedback - this is NOT a Demo
Focus on shard learning - not reporting
Only Done Working Software allowed
Avoid power point presentation
Sprint Review

125. EXERCISE
Ball Point Game

126. EXERCISE
Ball Point Game
‣
‣
‣
‣

129. Sprint Retrospective
‘The greatest enemy of great is good enough’

130. Goal: Inspect and create plan for improvements
Team time tune & adjust
After sprint review - Before sprint planning
Length: 1-2 hours
Participates: Scrum Master and the team (others are optional)
Generate AI (experiments) to execute the following sprint
Sprint Retrospective
Things to Stop doing
Things to start doing
Things to Keep doing

131. Retrospective Model Example
Opening (2-5 minutes)
Data collection (15-25 minutes)
Generate insights (15-25 minutes)
Decide what do do (15-25 minutes)
Closing (2-5 minutes)

132. THE WRONG WAY TO DO RETROSPECTIVE

133. Parking lot

135. “THE VALUE OF
AN IDEA LIES IN
THE USING OF IT”
Thomas Edison

136. THE EXPERT SOLUTION

137. Reading List
1. Clean Code
2. Scrum Guide
3. Delivering happiness
4. Peopleware
*RECOURSE