Slides from Practical Scrum course September 2016

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. THE EXPERT

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. What are we going to cover today?
TABLE OF CONTENTS
10
31
46
60
83
90
What we thought vs. What
we know
What is Agile?
What is scrum?
What is the manager role
within agile environment?
What is Lean Thinking?
How does scrum eliminate
waste?

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

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. 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

15. 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

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

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

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

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

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

21. 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

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

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

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

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

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

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

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

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

30. Wishful thinking

31. WHAT IS AGILE?

32. EXERCISE
Rewrite Each Agile Principle With 3 Words

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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

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

42. 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

43. 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

44. 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

45. EXERCISE
Command and Control
Vs.
Self Manage

46. Where Scrum Fits?

47. • 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!!!

48. 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."

50. EXERCISE
What Would You Do ?

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

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

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

54. THE HIGH MOON STUDIO

55. 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

56. 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

57. 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)

58. 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

59. 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

60. 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

61. CAT HERDERS?

62. 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

63. EXERCISE
Cross Functional
Vs.
Specializing Team

64. Round 1

65. Round 2

66. 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

67. 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

68. EXERCISE
The story about
Ofer Eini and EBay
(completely imaginary)

69. Ofer wants to know:
Can your team build this skeletal system for him?
The unions marketing division wants to set the press
conference to one month, do you agree?
What should he announce in this conference ?

70. EXERCISE
Debate in your teams and decide:
what do you tell Ofer ?

71. WELL DONE!

72. “A lack of transparency results in distrust and a deep
sense of insecurity”

73. Transparency
Stop taking risks for our customers (without even letting them
know)
Share the risk
Maximize the chances of success
Create a common interest
Know (not assume) the status of our projects - share it with the
customer

74. How encourage transparency?
Avoid the 90% done syndrome
Face hard facts - Early
Working Software - unfinished work is waste
Track progress with burn down charts

75. What Reduces Visibility?
Gantt charts
Hierarchy
Low Quality
Core code
What Reduces Visibility?

76. Core Code
AKA infrastructure or legacy code
Most functionality depends on it
Usually fragile, does not have a test harness
only a few people really know it
Changes are time consuming
Becomes a bottleneck

77. “Once you put on a suit, no one tells you the
truth anymore”
[Philip Crosby – 1995 – Reflections on quality]
Hierarchy

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

79. KEN SCHWABBER, “SCRUM ET AL”

80. 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”

81. 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

82. 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

83. “THE TOYOTA STYLE IS NOT
TO CREATE RESULTS BY
WORKING HARD. IT IS A
SYSTEM THAT SAYS THERE
IS NO LIMIT TO PEOPLE’S
CREATIVITY. PEOPLE DON'T
GO TO TOYOTA TO 'WORK'
THEY GO THERE TO
‘THINK'."
Taiichi Ohno

84. Lean Thinking
Continues Improvement
Respect for People
[Mindset]
My work is to do my work and to improve my work

85. Waste Value
Opportunity for
improvement
Traditional
improvement

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

87. Round 1
Context Switch

88. Round 2
No Context Switch

89. 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

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

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

92. EXERCISE
Find one example of waste
from your work and design an
experiment to try eliminate it

93. Over Production of Features
1. Features or services the
customer doesn’t want
2. Large engineering
documents, more detailed
designs than can be quickly
implemented
3. Duplication of data
* THIS IS ONLY EXAMPLE
Wave

94. Waiting and Delay
1. For clarification
2. Documents
3. Approval
4. Components
5. Other groups to finish something
* THIS IS ONLY EXAMPLE

95. Handoff
1. Giving a specification from an analyst to an engineer
2. Giving a component to another group for testing
* THIS IS ONLY EXAMPLE

96. Over Processing
1. Relearning, lose of information
2. Forced conformance to centralized process checklists
3. Recreating something made
* THIS IS ONLY EXAMPLE

97. Partially Done Work – WIP DIP
1. Designs documented but not built
2. Things built but not integrated or tested
3. Things tested but not delivered
* THIS IS ONLY EXAMPLE

98. Task Switching
1. Interruption
2. Multitasking on 3 projects
3. Partial allocation of a person to many projects
* THIS IS ONLY EXAMPLE

99. Under-realizing People
1. People only working to single speciality job
2. Do people have the chance to change what they see is
waste
* THIS IS ONLY EXAMPLE
Information Scatter or Loss
1. Information spread across many separate documents
2. Communication barriers such as walls between people,
or people in multiple locations

100. Wishful thinking
1. “We MUST follow the plan”
2. “The estimate cannot increase;
The effort estimate is what we want it to be, not what it
is now proposed”
3. “We’re behind schedule, but we’ll make it up later”
* THIS IS ONLY EXAMPLE

101. Parking lot

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

103. THE EXPERT SOLUTION

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