My agile product development training set. Please visit http://improvementstory.net

1. LEADING AGILE
PRODUCT DEVELOPMENT
By Arto Saari
v. 1.0 beta5
It has been my sincere aim to respect all copyrights and reference the
authors as appropriate. If however you feel I’ve not succeeded in some
aspect of this, kindly contact me and allow to me correct my error.
Thank you.
Used by permission

2. Foreword
This is my training course targeted to project and product
managers interested in Agile and Lean.
It’s a collection of known best practices and personal
methods and models that have all been utilized and proven
in real-world product development challenges.
My guidance to anyone participating the course or reading
this material is to explore and find their own views of Agile
and Lean best practices, possibly with the help of concepts
presented herein.
2

3. MOVING TO AGILE & LEAN

4. "Don't know what I want, but I know how to get it."
- Johnny Rotten, Sex Pistols
http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
4

5. Agile
Lean
Fit
iStock royalty-free photo
iStock royalty-free photo
Dealing with complexity
iStock royalty-free photo
Focusing on Value
Re-innovating Value
5

6. Agile is about understanding the problem and
finding the right solution via exploration.
Traditional Agile
Presumed Problem Unknown Problem
Understood Right
Planned Solution Problem Solution
Inspect-Adapt
OODA
PDCA
6

7. When making the transition, don’t get off
the train at Ad-hoc station.
X V
Traditional Ad-hoc Agile
Linearized Chaotic Complexity-aware
Plan-driven Reactive Adaptive
Disciplined and
Specialized Undisciplined
cross-functional
Scope-constrained Unconstrained Time-constrained
7

8. All organizational transformations, including agile,
require a combined top-down & bottom-up approach.
Top-down provides
required alignment for the
transition to happen on all
dimensions of the Bottom-up creates the
organization operative foundation for
new product development
principle.
Agile capability grows bottom-up to the full potential limited only
by the incompatible management principle of organization layers.
8

9. Functions learn to collaborate Effectiveness
with development and take benefit
of early and regular releases. Functions
Development organization
learns to exploit change and invest
in continuous improvement. Development
Organization
Teams learn to plan and deliver Team
in a steady cadence.
Efficiency
9

10. Customers, Partners
Intimacy Focus on value
Functions
Collaboration
Project / Project /
Development Development
Transparency Organization Organization
Team Team Team Team
Cadence
10

11. An inwards-oriented An outwards-oriented
organization focus is on control of organization focus is on customer
activity and improvement of internal value and market opportunities.
performance metrics.
It is very possible that majority of the Unnecessary control is replaced by
organization is supervising the trust.
minority that creates the value.
11

12. Management has a crucial role in Agile
world but it requires to re-innovate itself.
Value Creation
Enablement Management
Old orthodoxy
Those who do not create value directly
themselves enable the others to do so.
12

13. Command & Control
FAIL
Motivation Skill Efficiency Focus
Agile Leadership Style
13

14. Traditionally organizations
consider efficiency as
‘best-practices’ like .. Thinking good overall results
come from functional excellence
(locally optimizing organization)
Efficiency comes from Interfacing between
large batches stakeholders over non-
collaborative documents
Competing in the market Optimizing on cost and
with exceeding commitments resource efficiency
first(utilization etc).
14

15. My definition of business/organization agility..
Problem scenario: market moves Agile scenario: product development
faster than product development cycle as able to fit inside the market cycle
Market cycle Market Cycle
Product development
Product development cycle Cycle
Business Agility is the capability of your company to exploit shortening
market cycles instead of being victimized by them uncontrollably.
Read more about it here: http://improvementstory.net/2011/10/18/what-is-enterprise-agility-my-definitive-answer/
15

16. DIFFERENCE OF AGILE & WATERFALL

17. Whether your next project is a success or a failure
is not a matter of change
but the matter of choice
(Mentioned by Bill Gaiennie as a quote by “Anonymous wise agile coach”)
17

18. Traditional Development Project Agile Development Project
The things we’re
The whole big thing we
Level 1: Vision identified to be done to
have planned to do
meet the success
Task Task DL Level 2: Product backlog
(Feature breakdown)
Task
Task
Level 3: Release plan
(Time breakdown) Time-box 1 Time-box 2
Level 4: Sprint plan Story
(Work breakdown) Task
18

19. Waterfall is everywhere..
..in process models
Phase 1 Phase 2 Phase 3
..in structures ..in organization
Requirement
Function A
Level 1
As waterfall is one-
Requirement directional relationship,
Function B lacking early and continuous
Level 2
co-dependent validation.
Requirement
Function C
Level 3
19

20. The problem with
waterfall is..
Risk is not reduced
“Planning”
Changeability is
reduced over time Development
Testing
Visibility builds late
Learning collected at the end
20

21. Agile solves this problem by reducing batch size
of how the software is developed
Changeability much Visibility builds with
less if at all reduced each batch
“Planning” “Planning” “Planning”
Development Development Development
Testing Testing Testing
Learning collected and used Risk reduced by every batch
within the project
21

22. Schedule and Resources act as
constraints (control variables) to Scope.
Resources Schedule
Schedule controls the delay
for expected value.
Scope Value Cost of Delay
Secondary focus how well Primary focus is on amount of
scope translates to value value and the impact of delay
Risk
Scope is the source of both Risks associates to both value
value and risk. expectation and cost of delay
as increased uncertainty.
22

23. We iterate to improve We increment to get
the solution based on the solution earlier and be
learning and feedback. able to change plans.
Feedback Learning
Release 1 Release 2 Release 3 Release 4
23

24. Planning
Planning activity
itself is iterative &
incremental.
Changes during
development are
Release 2 Release 3 Release X reflected in current
and future release
Development plans.
Agile potential is
unlocked with
interaction between
Release 1 Release 2 planning and
Release 3
development.
24

25. CONTINUOUSLY IMPROVING
(BY ELIMINATING WASTE)

26. Waste As listed by Mary & Tom Poppendieck:
Extra steps
Information finding
Handovers
Task-switching
Defects (not caught)
Extra Features
Waiting
Photo by Crimson (Pieter Janssen), used by Creative Commons license on site www.dreamstime.com
26

27. Wall of Waste Wall of Improvements
Waste €
Waste Improvement Improvement
€
Visualization and radiating both waste and improvements help the
organization to collaborate on development.
Quantification in monetary impact gives correct weight and priority.
27

28. CREATING A FLOW

29. Variability and capacity utilization
Manufacturing both impact the queue size:
process Variability has linear impact
Utilization has exponential impact
Variability in (a) “service time”
and (b) “arrival time”
(a) Product Agile is all about absorbing
Development and exploiting this variability
(b) process for the benefit of the product.
Adopted from Donald G. Reinertsen, The Principles of Product Development Flow
29

30. Average Cycle time
Wait-in- Wait-in- Wait-in-
queue development release
Product
Development
process Release
Design inventory Feature inventory
Adopted from Donald G. Reinertsen, The Principles of Product Development Flow
30

31. Business value
Release Feedback
Product value
Development Release Feedback
effort
Effort turns into value only when it is released.
Value is understood only by feedback generated of a release.
31

32. Traditional single-iteration, scope-constrained, large batch project..
A Long Development Project (Late) Value Realization
Agile multi-iteration, time-constrained, small batch project..
Release 1 (Early) Value Realization
Release 2 (Added) Value Realization
Release 3 (Optional) Value Realization
Staged delivery realizes value earlier, reduces risk and
increases control and agility on all levels.
32

33. PLANNING PRODUCTS

34. Leffingwell’s product abstraction defined three abstraction levels:
Epics, Features and Stories
Each level as co-dependent relationship i.e.
one cannot exist without the other
Following is my personal adaptation of the structure:
Epics are the value-context of development:
Epic
they are what we want to achieve.
Features provide the solution to Epic and are beyond
Feature
optimal solution a cost-factor. Features we need to do.
Stories extend the feature solution and provide link to
Story
stakeholder value (users, providers etc).
34

35. Optimization towards (Epic) value context provides
maximum product development potential.
Epic (=business value)
€
Features (=investment to gain business value)
€
Value efficiency = Maximized epic value
delivered with optimal feature cost.
35

36. Prioritization of Epics and Features can be done in a matrix in which vertical
prioritization is based on Epic value and horizontal on feature priority.
More important towards the Epic
Epic 1 F F F F F F
Epic 2 F F F F F F
More value per
Epic Epic 3 F F F F F F
Epic 4 F F F F F F
Two queues can be formed out of the matrix:
Epic queue and internal Feature queue.
36

37. F Features in top-left are most valuable
More important towards the Epic
Epic 1 F F F F F F
Epic 2 F F F F F F
More value per
Epic Epic 3 F F F F F F
Epic 4 F F F F F F
While features in the bottom-right will not
F
be likely ever done
37

38. Optimized product plan
Unoptimized product plan Epic 1 F F
Epic 1 F F F F F F Epic 2 F F
Epic 2 F F F F F F Epic 3 F F
In unoptimized plan, epics (value) Epic 4 F F
is produced in large, slow batches
of unnecessary features (waste) In optimized plan, epics are
delivered via a core set of features
and released in a quick cadence.
38

39. Level 1: Unorganized backlog Level 2: Prioritized backlog
Top-priority
Level 3: Groomed backlog
loren loren
impsum impsum
loren loren
impsum impsum
loren loren loren
impsum impsum impsum
loren loren loren
impsum impsum impsum
loren
impsum
loren
impsum
39

40. Backlog prioritization is an on-going
Prioritization model should be both
process on all backlog levels,
simple and meaningful
peaking at the start of a cycle.
Must-have Must-have’s we don’t release without.
Should-have’s we aim to
Should-have Should-have
maximize per delivery.
Could-have’s are valuable
Could-have Could-have Could-have
candidates or “extra”.
Won’t-have’s we’ve
Won’t have
decided to left out.
40

41. OPTIMIZING BACKLOG

42. We don’t want overly complicated and costly
solutions compared to the size of the problem.
Problem
Problem
Solution
Solution
But instead innovative and effective solutions that
solve a more valuable problem.
42

43. Problem Product structure can be viewed as a
chain of Problem-Solution pairs.
Solution
Epic Each of the abstraction layers
Problem
contains both a solution to upper layer
and poses a problem requiring a
Solution solution on lower layer.
Feature
Problem
On top-level there is a business
Solution problem that is being addressed with
Story
Problem production solution. Further down the
chain problems and solutions become
Solution more technical reaching lowest
interest point, tasks a solution.
43

44. Solution needs to be defined
in full to match the problem Part of Part of Part of
Solution Solution Solution
before it may be optimized
reductively.
Part of Part of Part of
Solution Solution Solution
New composition of the
solution requires it to be Part of Part of Part of
checked for integrity as it was Solution Solution Solution
a completely new solution.
44

45. Sensitivity analysis on changing problem and
solution definition may reveal better opportunities.
Bigger
Original Original Problem
Problem Problem
Value : Cost
Ratio
Smaller
Solution Original Slightly Bigger
Solution Solution
45

46. time
PDCA-cycle
Original Better Problem-Solution
Problem Defined Correct definition evolves over
Problem Problem time and requires full
recheck periodically
(preferably between
Optimal sprints) to validate the
Improved
Original Solution optimal solution to
Solution
Solution correct problem.
CHECK CHECK CHECK
46

47. PLANNING RELEASES AND ROADMAPS

48. The highest level of the backlog
in the Product Backlog
Time and release oriented
level of backlog is know as
Release Backlog
Within a release the delivery plan
is known as the Sprint Plan
(or Sprint Backlog)
48

49. Visual planning helps to identify the constraints and their impact over
the expected result. The strongest constraint is time, second resources, as
combination Resources Over Time.
Prioritized, ordered flow of features
FEATURE FEATURE FEATURE FEATURE FEATURE ....
R R R R R R R R R
Resource constraint to next release
Reserve Risk of uncertainty and ability to do incremental
change can be achieved by holding some of the
R R R R resources in reserve.
49

50. Epics can be used to model value offering to customers which each
require certain Features realized in a set of Solutions.
F F Solution Epic 1
Value Offering Customers
F F Solution Epic 2
50

51. V1 V2 V1 Total value: 4
Epic 1
C2 C5 C3 Total High-level road-mapping using Epics
complexity: 10
can be done by identifying simple
Features
value and complexity points to give
them comparability and character.
V2 V3 Total value: 5
Complexity is elaborated into
Epic 2 features at later stages of planning.
C1 C2 C2 Total
complexity: 5
Features
51

52. AGILE ROLES & OWNERSHIP

53. Transfers the
product vision
Team
Product Owner
Grooms backlog Plans releases
loren loren
impsum impsum
loren loren
impsum impsum
Release 1
loren loren loren
impsum impsum impsum
loren loren loren
impsum impsum impsum
loren
impsum
Sprint 1 Sprint 2 Sprint 3
loren
impsum
53

54. Upholds Scrum Process
Sprints Demos
Scrum Master Retrospective
Daily-standup
Promotes Agile Culture Protects the Team
Team
54

55. Seeks to maximize the
product value
Team loren
impsum
loren
impsum
loren
impsum loren
loren impsum
impsum loren
impsum
Continuously analyzes and
Self-organizes the tasks to
improves the working practices
meet Sprint goals
Team Team
55

56. Governs constraints of the
project to meet business goals.
Project Master
Aligns priorities of the Coaches collaboration and
organization into the project and ownership of stakeholders
(Product Owner, Business Owner, Scrum Masters,
vice versa. Teams etc)
loren loren
impsum impsum
loren loren
impsum impsum
56

57. CREATING AGILE TEAMS

58. Software project is a creative process that
takes place in a people-centric system
Quality of collaboration
greatly impacts the quality of result
58

59. Putting random people together and
calling it “a team” is a management fallacy
Also, individual ?
competences do not ? Fundamentally,
add up to team teams build them selves.
competence 1:1
As managers, we create the hot-bed
for great teams to emerge.
59

60. If you wish to be agile, make sure your team is
motivated by the challenge itself.
Complex
Home of Adaptive
Intrinsic Agile
Predictive Extrinsic
Simple
Adopted from “Drive” by Daniel H. Pink
60

61. Self-organizing is an agile principle in which the
team finds the necessary tasks and processes
to reach the goal.
Boundaries (Constraints)
Self-organizing
Goal
Team
However, for self-organizing to be effective, clear
boundaries in a form of constraints are
required to steer the efforts.
61

62. Self-organizing
Team
Autonomy Mastery Purpose
Craftsmanship
Adopted from “Drive” by Daniel H. Pink
62

63. Why does self-organizing
fail so often?
Unorganized group
of people
Autonomy Mastery Purpose
Individual and collective
Organization culture fails to
purpose for the activity is
cater intrinsic motivation
missing
Responsibility of the team
performance has not been in the team
63

64. Prediction of result is derived from team velocity.
It tells us how much the team is producing.
42 38 36 38 38 38
Known velocity is better than expected velocity.
This is why tracking of performance and estimation accuracy are crucial.
Team A 42 ?
Team B 32 ?
Team C 35 ?
And when team composition is changed the velocity changes.
64

65. Gradual team-driven commitment to growth provides
successful on-time delivery from the beginning.
22 25 24 25
20
Whereas non-committed goals result in missed deadlines,
failed expectations and bad atmosphere.
28
26
25 24 25
20 22
Funny enough, the team achieves the same result in both
scenarios. It’s just a matter of perspective.
65

66. AGILE DEVELOPMENT PROCESSES

67. Product Owner
Definition of Workable Definition of Done
Acceptance criteria that a backlog Acceptance criteria that a backlog
item must pass before it can be item must pass before it can be
worked on by the Team. delivered to Product Owner.
Team
67

68. Kanban board visualizes the flow of effort towards value.
Todo In Progress Done
Definition Work in Definition of
of Workable Progress Limit Done
68

69. Work progress is monitored in a
form of a burn-down chart
Remaining effort
Start of Sprint End of Sprint
69

70. Scrum of
Scrums
(2nd level)
Scrum of
Scrums
(1st level)
Daily Scrum
Team Team Team Team Team
70

71. Between sprints, team shows demonstration of the product based
on sprint results & performs a retrospective on working methods.
Demo provides a loren loren
feedback loop allowing
impsum impsum
loren loren
impsum impsum
the product to grow
iteratively & incrementally.
Sprint 1 Sprint 2
Retro provides a
feedback loop allowing
Team Team
the team to grow
iteratively & incrementally.
71

72. SCALING AGILE

73. Horizontal scaling refers to
scaling a larger product backlog to
several teams. Product Owner
Product
Product Owner
Product Owner Product Owner
Product
Product Product
Team
Team Team Team Team
73

74. Vertical scaling refers to
scaling agile towards higher levels Within clusters individual teams work on a
of product management. Flow of Features
Team
Team
Team
Team cluster A
Epic Epic Epic
Team
Team
Clustering teams Team
allows them to work on a Team cluster B
Flow of Epics
74

75. One product = One Product Backlog
One product = Synchronized Cadence
Team
Scrum Master is in the Team
Product Owners are close to Business
Scrum Master
Product Owner(s)
Product Team
Team Backlog
Scrum Master Scrum Master
75

76. Hierarchical, Separated Nonhierarchical, Separated
Product
Architecture
driven 1
1.1 1.2
1.1.1 1.1.2 1.2.1 1.2.2 Feature
Specialists
Hierarchical, Joint Nonhierarchical, Joint
Top-level
driven “Product Council”
1
1.1 1.2
1.1.1 1.1.2 1.2.1 1.2.2
76

77. QUALITY IN AGILE

78. Product owner is responsible of the product
- and its level of quality.
Product Owner
The expected level of quality is agreed
between the product owner and the team.
Quality principles may be embedded to
Team backlog items in a form of acceptance criteria..
..and by the team in their definition of done.
78

79. Bug Bug Bug Bug Collecting an inventory of bugs can be more
time consuming than fixing them - and you
Bug Bug Bug Bug would still have the bugs.
Bug Bug Bug Bug Agile Quality Management principle:
✓ Decide fast per found bug - fix or not
Bug Bug Bug Bug ✓ Decentralize decision making
✓ Involve the team and product owner
Bug Bug Bug Bug and not only tester or developer
✓ Use economic thinking when deciding
Bug Bug Bug Bug - every effort taken is an investment
away from something else
Bug Bug Bug Bug ✓ Not every bug needs to be fixed -
only the necessary ones.
Bug Bug Bug Bug
79

80. Found issues Resolved issues Total number of issues
Three critical quality effort
60
trends:
(1) how many issues we find
(2) how many we resolve
45
(3) how many there’s in total in
inventory
30 Three focus areas:
(1) find issues early with declining
trend of new issues
15 (2) resolve issues
(3) keep inventory small and steady
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4
80

81. AGILE GOVERNANCE
(COMING UP)

82. AGILE LEADERSHIP STYLE
(COMING UP)

83. METRICS IN AGILE
(COMING UP)

84. Arto Saari
LinkedIn:
http://fi.linkedin.com/pub/arto-saari/b/b03/546
Blog:
http://improvementstory.net
Twitter:
http://twitter.com/#!/ImprovStory
84