Leading Agile Product Development

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
Saturday, November 19, 2011

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 ﬁnd their own views of Agile
and Lean best practices, possibly with the help of concepts
presented herein.

2

MOVING TO AGILE & LEAN


"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

Agile
Lean
Fit

iStock royalty-free photo

Dealing with complexity
Focusing on Value
Re-innovating Value

5

Agile is about understanding the problem and
ﬁnding the right solution via exploration.

Traditional Agile

Presumed Problem Unknown Problem
Understood Right
Planned Solution Problem Solution
Inspect-Adapt
OODA
PDCA
6

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

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

Functions learn to collaborate Effectiveness
with development and take beneﬁt
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.
Efﬁciency

9

Customers, Partners

Intimacy Focus on value

Functions
Collaboration
Project / Project /
Development Development
Transparency Organization Organization
Team Team Team Team

Cadence
10

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

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

Command & Control

FAIL

Motivation Skill Efﬁciency Focus

Agile Leadership Style

13

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

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

DIFFERENCE OF AGILE & WATERFALL


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

Traditional Development Project Agile Development Project

The things we’re
The whole big thing we
Level 1: Vision identiﬁed 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

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

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

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

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

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

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

CONTINUOUSLY IMPROVING
(BY ELIMINATING WASTE)


Waste As listed by Mary & Tom Poppendieck:
Extra steps
Information ﬁnding
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

Wall of Waste Wall of Improvements

Waste €
Waste Improvement Improvement

€
Visualization and radiating both waste and improvements help the
organization to collaborate on development.
Quantiﬁcation in monetary impact gives correct weight and priority.
27

CREATING A FLOW


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 beneﬁt of the product.

Adopted from Donald G. Reinertsen, The Principles of Product Development Flow
29

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

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

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

PLANNING PRODUCTS


Lefﬁngwell’s product abstraction deﬁned 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

Optimization towards (Epic) value context provides
maximum product development potential.

Epic (=business value)
€
Features (=investment to gain business value)
€
Value efﬁciency = Maximized epic value
delivered with optimal feature cost.

35

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

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

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

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

loren
impsum
loren
impsum

39

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

OPTIMIZING BACKLOG


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

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

Solution needs to be deﬁned
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

Sensitivity analysis on changing problem and
solution deﬁnition may reveal better opportunities.

Bigger
Original Original Problem
Problem Problem

Value : Cost
Ratio

Smaller
Solution Original Slightly Bigger
Solution Solution

45

time
PDCA-cycle

Original Better Problem-Solution
Problem Deﬁned Correct deﬁnition 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

PLANNING RELEASES AND ROADMAPS


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

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 ﬂow 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

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

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

AGILE ROLES & OWNERSHIP


Transfers the
product vision
Team
Product Owner

Grooms backlog Plans releases
loren loren
impsum impsum
loren loren
impsum impsum
Release 1
loren loren loren
loren loren loren

loren
impsum
Sprint 1 Sprint 2 Sprint 3
loren
impsum

53

Upholds Scrum Process
Sprints Demos
Scrum Master Retrospective
Daily-standup

Promotes Agile Culture Protects the Team

Team

54

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

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

CREATING AGILE TEAMS


Software project is a creative process that
takes place in a people-centric system

Quality of collaboration
greatly impacts the quality of result

58

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

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

Self-organizing is an agile principle in which the
team ﬁnds 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

Self-organizing
Team

Autonomy Mastery Purpose
Craftsmanship

Adopted from “Drive” by Daniel H. Pink
62

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

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

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

AGILE DEVELOPMENT PROCESSES


Product Owner

Deﬁnition of Workable Deﬁnition 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

Kanban board visualizes the flow of effort towards value.

Todo In Progress Done

Definition Work in Definition of
of Workable Progress Limit Done

68

Work progress is monitored in a
form of a burn-down chart

Remaining effort

Start of Sprint End of Sprint
69

Scrum of
Scrums
(2nd level)

Scrum of
Scrums
(1st level)

Daily Scrum

Team Team Team Team Team

70

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

SCALING AGILE


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

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

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

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

QUALITY IN AGILE


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 deﬁnition of done.

78

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

Found issues Resolved issues Total number of issues
Three critical quality effort
60
trends:
(1) how many issues we ﬁnd
(2) how many we resolve
45
(3) how many there’s in total in
inventory

30 Three focus areas:
(1) ﬁnd 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

AGILE GOVERNANCE
(COMING UP)


AGILE LEADERSHIP STYLE
(COMING UP)


METRICS IN AGILE
(COMING UP)


Arto Saari

LinkedIn:
http://ﬁ.linkedin.com/pub/arto-saari/b/b03/546

Blog:
http://improvementstory.net

Twitter:
http://twitter.com/#!/ImprovStory

84

Leading Agile Product Development

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Leading Agile Product Development

Similar a Leading Agile Product Development (15)

Último

Último (20)

Leading Agile Product Development