A post-class brochure from one of my Certified ScrumMaster trainings in 2016.

1. Growing Agile Leaders
Leading Agile Growth
Alexey Krivitsky, CST
www.agiletrainings.eu, 2015

2. Agile Coach
developer, scrum master,
scrum trainer, free-rider
Alexey KRIVITSKY
www.agiletrainings.eu
1980 – present
Kiev – Hamburg

6. Part 1
Understanding
LEAN
AGILE
SCRUM

10. The “Agile Umbrella”

12. Annual “State of Agile”, 2015
info.versionone.com/state-of-agile-development-survey-ninth.html

13. BELIEF THAT SCOPE CAN BE FIXED
[ SCOPE ]
TIME BUDGET

14. 1. Customers and users know what they want.
2. It can be described with words and images.
3. Engineers know how to build it in advance.
4. Nothing changes.
Sorry….
Wouldn't IT BE NICE?

15. W.T.F.
1. No one really has the overall picture
(not possible to improve the flow)
2. A manager might be the only one who cares for the whole
(becomes informaNon keeper and transporter)
3. Knowledge is inhibited inside departments and silos
(organizaNon doesn’t learn)
4. Every department is op@mizing, but locally
(produces more wastes, system is subopNmal)
5. Conflicts of interests are not rare
(wasted Nme and energy)
6. Blaming culture emerges
(CYA-development, wasted Nme and energy)
7. Customers are seen as an external party
(scope management is problemaNc, delays and budget overruns)
8. No one really manages development
(uncontrollable situaNon, random outcomes, belief in magic)

16. OUR UNDERSTANDING GROWS CONSTANTLY
SCOPE
TIME BUDGET

17. four obstacles to adopting Scrum
1. The tyranny of the waterfall
2. The illusion of command and control
3. The belief in magic
4. The era of opacity
(c) Ken Schwaber, Co-creator of scrum

18. SCOPE
[TIME] [BUDGET]
Reversing Iron Triangle
Traditional Agile
PLAN
DRIVEN
TIME BUDGET
SCOPE
VALUE
DRIVEN

20. ScrumMaster
PUSHES TO NEVER STOP
IMPROVING
Helps everyone
to be heard
asks questions
doesn’t offer
solutions
believes the team
can do it
Helps TO MAKE
decisions
Promotes
experimentation
Prevents analysis
paralysis

21. CONTINUOUS
Process improvements

23. KAIZEN
continuous process improvements

24. 1930-1950
Taiichi Ohno
Deming

25. JIT
DO ONLY
WHAT IS
NEEDED AND
WHEN IT IS
NEEDED
JIDOKA
WHEN SHIT
HAPPENS –
STOP, FIX
AND
IMPROVE THE
SYSTEM
KAIZEN
KEEP IMPROVING EVERYTHING
RESPECT
YOUR
PEOPLE
WHATEVER YOU DO
YOU DO IT FOR YOUR CUSTOMER
Toyota ProducNon System (TPS) and Lean Manufacturing, simplified
backlogs
pull systems
user
stories
unit-tests
5 whys
conNnuous
integraNon
code refactoring
automaNon
fast releases business prioriNzes
clean code
minimize work-in-progress
managers
who teach
cross-funcNonal teams
eliminate waste

27. Lean classifies 8 Wastes
“Tim Woods”
Transportation moving parts, people, informaNon
Inventory storing parts, documenNng
Motion bending, turning, reaching, licing
Waiting for parts, info, equipment, tools
Over production making more than is immediately required
Over processing Nghter tolerances and more efforts than necessary
Defects rework, scrap, incorrect documentaNon
Skills under uNlizing capabiliNes, inadequate trainings

28. Wastes in Software Development
1. Add more features to a release
2. Deploy to producNon manually
3. Make business analysts write specificaNons and
then pass them to developers
4. Make architecture configurable and extensible
keeping in mind possible features of next releases
5. Run bug-fixing sprint(s) before releasing
6. Do tesNng later in sprint when all features are done
7. Do regression tesNng manually
8. Collect bug list of 300+ items
O
M
T
O
D
W
S
I

29. The CHAOS Report
hkp://www.standishgroup.com/Reports2015

30. “All organiza@ons are perfectly designed
to get the results they are now ge]ng.
If we want different results, we must
change the way we do things.”
Tom Northup

31. Scrum is …
Scrum is a framework that
helps you kick off and then
con@nuously improve your
d e v e l o p m e n t p r o c e s s e s
together as a team.

34. Which Terms from the List
Are Not Part of Scrum?
User Stories
Velocity Metric
Grooming Meetings
Continuous Integration
Automated Testing
Monthly Releases
Visual Task Boards
Story Points

35. Scrum 101
Scrum Roles:
1. Product Owner “P.O.”
2. Development Team
3. ScrumMaster
Scrum Artifacts:
1. Product Backlog (PBL)
2. Sprint Backlog
3. POTENTIALLY SHIPPABLE Product Increment “PSPI”
Scrum Ceremonies:
1. Sprint
2. Sprint Planning
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective

36. Understanding Process Control
Defined Empirical

37. Scrum is …
Scrum is not prescribing how to do work. It is
based on empirical process control.
In Scrum we see product development as a
complex problem domain - where it is
impossible to define processes in advance that
would work in all situaNons.
Instead Scrum makes you inspect and adapt.

38. SCRUM MANTRA:
INSPECT AND ADAPT

39. Three Legs of Empirical Process Control
1. Transparency
2. Inspection
3. Adaptation

41. SPRINT
BACKLOG
DEV QA ACCEPTANCE
WIP READY WIP READY WIP READY
WHAT CAN YOU SAY ABOUT WORK OF THIS TEAM?

42. SPRINT
BACKLOG
DEV QA ACCEPTANCE
WIP READY WIP READY WIP READY
WHAT CAN YOU SAY ABOUT WORK OF THIS TEAM?

43. SPRINT
BACKLOG
DEV QA ACCEPTANCE
WIP READY WIP READY WIP READY
WHAT CAN YOU SAY ABOUT WORK OF THIS TEAM?

44. Part 2
Understanding
The Role of a
ScrumMaster

47. http://www.agileproductdesign.com (Jeff Patton)
Shared documents ≠ shared understanding

48. http://www.agileproductdesign.com (Jeff Patton)
Help externalize ideas and see differences

49. http://www.agileproductdesign.com (Jeff Patton)
Help to have regular discussions

50. http://www.agileproductdesign.com (Jeff Patton)
That will lead ultimately to shared understanding

51. ACTIVELY DOES
NOTHING
SCRUMMASTER’s FIVE HATS
TEACHES &
MENTORS
PROTECTS TEAM &
CHALLENGES
ENVIRONMENT
ASKS QUESTIONS,
HELPS EXPLORE
HELPS BUILD SHARED
UNDERSTANDING

52. OBSERVER
SCRUMMASTER’s FIVE HATS
MENTOR
CHANGE AGENT
COACH
FACILITATOR

53. PRODUCT
OWNER
NOBODY
STAKEHOLDERS
DEVELOPMENT
TEAM
SCRUMMASTER
SCRUM
TEAM
Scrum Roles Are Played Properly

54. Terminology USED
PO Product Owner
SM ScrumMaster
PB, PBL Product Backlog
PBI Product Backlog Item
PBR Product Backlog Refinement
PSPI Potentially Shippable Product Increment
DOD Definition of done
DOR DEFINITION OF READY

55. Fix The Cause Not Symptoms

56. SPRINT PLANNING 101
Commitment-based PlanningPARTONE
PARTTWO
INITIAL SPRINT GOAL
PRESENTED
PLANNED CAPACITY
DISCUSSED
TOP PRODUCT BACKLOG
ITEMS PRESENTED
PBI REVIEWED ONE BY ONE
NEEDED REFINEMENT
HAPPENS
ITEM ADDED TO SPRINT
PLAN
CONTINUE UNTIL TEAM
SAYS “ENOUGH”
SPRINT GOAL GETS ADJUSTED

59. Retrospectives 101
Time-box: 1 hour per 1 week of work
1. SET THE STAGE
– ask everyone to share one word about the sprint
– review last retrospecNve’s acNon items
2. GATHER INFORMATION
– collect post-its: achievements, failures, appreciaNons
3. GENERATE INSIGHTS
– collect post-its: stop doing, start doing, do more, do less
– voNng: 3 dots per person
4. DECIDE WHAT TO DO
– discuss 1-3 top voted cards: which process experiment we try?
5. CLOSE THE RETROSPECTIVE
– fist-or-five on saNsfacNon from retro
– find the next retrospecNve facilitator

61. hkp://retrospecNve-cheat-sheet.com/

62. Are You Responsible For One Of These?
ESTIMATE WORK, COMMIT FOR DEADLINES
DEVELOP AND RELEASE FEATURES
Making sure developers know what to work on
Personal evaluation of team members
Collaboration with customers
Design product solutions
ELABORATE system architecture

63. WHAT’S THE RESULT OF
SCRUMMASTER’S WORK?
• A high-performing agile team.
• High-performing agile teams.
• An organizaNon of high-performing agile teams.

64. Coaching
Teamwork
Part 3
“Individuals and Interactions over Processes and Tools”

65. Our goal is to change
ORGANIZATIONAL culture
so that agile thinking
becomes a norm.

66. CULTURE
HABITS
BEHAVIORS
ENVIRONMENT

67. “culture eats strategy for breakfast”
Same structure
New STRATEGY
Old
CULTURE
Old habits
reinforced
Old behaviors
triggered
Old
CULTURE

68. “Culture follows structure”
new
Structure
introduced
Old
culture
New
culture
New
Behaviors
emerge
New
Habits
stick
Craig LaRman's law AND ‘large scale scrum’

69. Scrum Development Team
1. small
2. Collocated
3. Cross-functional
4. Long-lived
5. Full-time members
6. Self-MANAGING

70. Features vs. Components
DATABASE
BUSINESS LOGIC
API
FRONT-END
Feature
Component
Tasks

71. DATABASE
BUSINESS LOGIC
API
FRONT-END
Feature vs. Component Teams
Cross-functional “feature” teams
Specialists

72. “Feature” or “full-stack” Teams
… Are the Building blocks of an Agile
organization.
Scrum requires such Teams to be in place.
it is a structural change.

73. Level Up!
The goal of a ScrumMaster is to bring the team
AND ORGANIZATION to the next level of
maturity.

74. Maturity Model
Tuckman’s Stages of Group Development
FORMING
STORMING
NORMING
PERFORMING

75. Further
Improvements
Further
Improvements
Maturity Model
Scrum Adoption Dynamics
Ceremonial
Scrum
Emerging self-
organization.
Team starts
owning the
process
True self-
organization.
Further
Improvements
are now possible
“DO AGILE” “BE AGILE”
Too many
problems!

77. Be Creative!

79. Ingredients of Self-Organization
1. High Alignment
our goal is …
2. Clear Constraints
Here are some boundaries to follow …
3. High Autonomy
go and figure out how …

80. Agile Leadership
micro-management leadership
chaos
chaos

81. Coaching
CUSTOMER COLLABORATION
Part 4
“Customer Collaboration over Contract Negotiation”

82. Defining Product Owner
A Product Owner is not a new name for a
tradiNonal project manager who delivers a
scope and date contract of work. Rather, (s)he
has the independent authority to choose and
change content, release dates, prioriNes, vision,
etc.
Of course, (s)he collaborates with
stakeholders and teams, but a real P.O.
has the final decision-making authority.

83. How Many Product Owners do you need?
A company develops a web-shop with services
like: a catalog, user profiles, email subscripNons,
persistent shopping cart, payments and B2B-
integraNon for partner shops.
How many products do you idenNfy?
How many Product Backlogs will you have?
How many Product Owners will you need?

84. Overall Product Backlog
for Web-Shop Scrum Teams Single Product Increment
one sprint
Scrum @SCALE:
One product owner per a product
one demo
one deployment environment
one codebase, one repo, one master
one set of tests, one conNnuous integraNon

85. Find Your Product Owner
You work for a company “Best SoluNons” in the Eastern
Europe that receives a project from a company
“All Possible” in Belgium.
“All Possible” works for “MediCare” that owns some
hospitals in the U.S.A. and need a paNent keeper soluNon
on tablets for its hospitals. A hospital in Alabama is the
one to start piloNng the new technology.
In groups – talk:
- draw a picture of the chain
- in which of the organizaNons “sits” your P.O.?
- who can (s)he be?

87. Product Owner IS RESPONSIBLE FOR
RETURN ON INVESTEMENTS.
SCRUM PRODUCT BACKLOG IS THE TOOL
FOR MANAGING IT.

88. Product Backlog Iceberg
Priority2-3 Sprints
Release
Next
Releases
Refined User Stories
Non-Refined User Stories
Epics

89. PRODUCT BACKLOG SHOULD BE DEEP
Detailed Appropriately
Estimated
Emergent
Prioritized

90. Types of PBIs
VISIBLE
FEATURE
VISIBLE
DEFECT
HIDDEN
ARCHITECTURAL
FEATURE
TECHNICAL
DEBT
PositiveValue
Visible Invisible
NegativeValue

91. Backlog Management BUGS
1. Avoid bug inventories. Introduce limits (<30)
2. ‘Clean up’ sprints: kill’em all
3. Zero-bug policy: kill’em before they grow

92. MIXING WORK IN PRODUCT BACKLOG
HIDDEN
TECHNICAL
DEPT
VISIBLE
FEATURE
HIDDEN
ARCHITECT.
IMPROVEMENT
VISIBLE
DEFECT

93. Product Backlog Refinement
Item
size
Level of details
LARGE &
UNREFINED
SMALL &
UNREFINED
CLEAR, TESTABLE
& FEASIBLE
© Roman Pichler
1. ESTIMATE
2. SPLIT 3. REFINE

94. PRODUCT BACKLOG REFINEMENT
IS THE PBI 1/10 to 1/6
OF TEAM’S VELOCITY?
SPLIT IT
REFINE IT NEXT PBI
NO
IS THE PBI CLEAR, FEASIBLE
AND TESTABLE?
NO
YES
YES

95. USER STORY FORMAT
As a <role>
I want <action>
So that <outcome>

96. 3Cs with user stories
Card
Conversation
Confirmation

97. DEFINITION OF READY
An agreement within a Scrum team on what a
good PBI is - when is it ready for Sprint Planning.
• Been discussed with all team members
• Value is clear
• Small enough
• Detailed enough
• Can be started next sprint
• All inputs provided
• No blocking issues

98. I.N.V.E.S.T. in User Stories
Independent
Negotiable
Valuable
Estimatable
Small
Testable

99. Overall Product Backlog Scrum Teams
Payment DB
Payment API
Payment
ValidaNon
Payment UI
Technical Split
one sprint

100. Overall Product Backlog Scrum Teams
Payment DB
Payment API
Payment
ValidaNon
Payment UI
Technical Split
one sprint one more sprint one more sprint

101. INSTEAD Split BY BUSINESS VALUE
Payment
Payment with
Visa
Payment with
MasterCard
Payment with
PayPal
User is informed if
card data is not OK
User is taken to
success page
User is taken to
retry page
User can store his
card data Too big for a sprint SNll too big for a sprint

102. Overall Product Backlog Development Teams
Payment with
Visa
Payment with
MasterCard
ConfirmaNon
Email
Payment with
PayPal
SCRUM @SCALE
v1
1 PO
Common Sprint
Single PSPI

103. Track Release Progress
Time (sprints)
Amount
of work
(points)
rate of backlog change
when
you
will
release
amount
of work
remaining

104. Manage Release Scope
Time (sprints)
Amount
of work
(points)
Deadline
MOVE THIS MANY
POINTS TO
NEXT RELEASE

106. Scrum Inception
The bare minimum to start scrum
1. Common understanding of Scrum roles
2. Team arrangements
3. Initial Product Visioning
4. Initial Release Planning: MVP, next releases
5. User Story Writing Workshops
(minimum: Product Backlog for the 1st sprint)
6. Definition of Done
7. PLANNING the minimal infrastructure
8. Sprint Planning
Product
Visioning
Release
Planning
Sprinting
Process
Agreements

108. USER ACTIVITIES
(BACKBONE)
USER TASKS
(WALKING SKELETON)
time
priorities
RELEASES

109. Benefits of Relative Estimates
+ Easier to agree.
+ Faster to esNmate.
+ The more you esNmate, the faster it goes.
+ Can be a whole-team learning acNvity
+ Make it impossible to play the blame game
+ Can be fun! (using games like Planning Poker)
- Harder to explain to others
- Harder to see impediments and interrupNons
NB: EsNmaNon techniques are not part of Scrum

110. COACHING DELIVERY
Part 5
Working Software over Comprehensive Documentation

111. extreme Programming SAYS
“If it is hard, do it more ocen”

112. Sprint Is Not Mini-Waterfalls
analyze
design
test
code
Sprint Sprint Sprint Sprint

113. SCRUM IS NOT A SERIES OF MINI WATERFALLS
Feature A Feature B
PLANNED:
A,B,C,D
DONE:
nothing
DESIGN
PROTO
MORE CODING
TESTING
Sprint done wrong
CODING
Feature D Feature C
(next sprint)
PLANNED:
A,B,C,D
DONE
A,B,D
Sprint done right
Discussion Point
[PO + Dev Team]

114. Done. or Done-Done-Done?
Feature A Feature B Feature D
COOL: A,B AND D ARE DONE!
CAN WE DEPLOY THEM NOW?
(poker face)
OK.. SO WHAT’S LEFT?
1.
2.
…
10.

115. SAMPLE Evolution of Doneness
user tests
automated
tested,
accepted
con@nuously
integrated
deployed
to staging
it is live
feature
by feature
it is live
by the end of
sprint
coded,
unit-tested

116. Sprint commitment
Product Owner and Development Team
together believe all planned PBIs that are taken
to the Sprint can be finished, given the DoD and
what is known up to the moment.
As soon as new informaNon is discovered that
makes the plan unrealisNc, a Development Team
and a Product Owner engage in a discussions to
make necessary scoping decisions.

125. Agile Coach
developer, scrum master,
scrum trainer, free-rider
Alexey KRIVITSKY
www.agiletrainings.eu
1980 – present
Kiev – Hamburg