Transcript Document

Essential
Agile
Software
Development
Jeff Patton
[email protected]
AgileProductDesign.com
Origins of Agile
Development
The identification and naming of a
“quality” of successful software
development.
Winston Royce is generally credited with
first describing what’s known as the
waterfall model in his 1970 paper
“Managing the Development of Large
Software Systems.”
3
But, in that paper this diagram is
followed by the quote:
“I believe in this concept, but the
implementation described above is risky
and invites failure.”
4
It’s this model that the paper goes on to
describe as being best.
I wonder why it didn’t catch on?
5
What we call Agile Development today has come from many
years of identified best practices
Managing the Development of Large Software Systems, Winston Royce,
1970 (first description of the waterfall model and why it’s a bad idea)
The Psychology of Computer Programming – Gerald Weinberg, 1971
The Mythical Man Month, Fred Brooks, 1986
Scrum, Ken Schwaber, Mike Beedle, 1986
PeopleWare, DeMarco & Lister, 1987
Borland’s Software Craftsmanship, 1994
Dynamic Systems Development Methodology, 1994
Crystal Methodologies, Alistair
Cockburn, 1997
Feature Driven Development, Jeff
DeLuca, 1998
Adaptive Software Development,
Jim Highsmith, 2000
Extreme Programming, Kent Beck,
2000 (origins in 1996)
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
6
Since there’s been
software development,
there’s been an
undercurrent of people
believing it could be
done better
7
Coining the Agile Software Development label
(instead of lightweight development)
XP’s success acts as a catalyst
Workshop of 17 practitioners at a Utah ski resort in
February 2001
All the participants disagree on specifics
All agree they have something in common
The four statements in the Agile Manifesto emerge
The Agile Alliance non profit was formed the
following year
The 17 practitioners that disagreed
on specifics have been joined by
thousands more… who continue to
disagree on specifics
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
8
Agility is a Value System – More Esthetic
than Process
The Agile Manifesto (2001)
We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:
 Individuals and Interactions over Processes and Tools
 Working Software over Comprehensive Documentation
 Customer Collaboration over Contract Negotiation
 Responding To Change over Following a Plan
That is, while there is value in the items on the right, we value
the items on the left more.
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
9
Agile’s 12 Principles Suggest Practices of
Agile Development
7.
Working software is the primary measure of
progress.
8.
Welcome changing requirements, even late
in development. Agile processes harness
change for the customer's competitive
advantage.
Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant
pace indefinitely.
9.
Deliver working software frequently, from a
couple of weeks to a couple of months, with
a preference to the shorter timescale.
Continuous attention to technical excellence
and good design enhances agility.
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
4.
Business people and developers must work
together daily throughout the project.
11. The best architectures, requirements, and
designs emerge from self-organizing teams.
5.
Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
12. At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts its behavior accordingly.
6.
The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
1.
2.
3.
Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
10
Agile development describes a class of
approaches, not a single approach
Some Agile approaches get named:





Scrum (1986)
DSDM: Dynamic Systems Development Method (1995)
Crystal (1997)
FDD: Feature Driven Development (1998)
XP: Extreme Programming (1999)
 ....and an indefinite number of others
Most organizations assemble their Agile approach from a
collection of Agile practices
Today’s common Agile practice combines elements of all of
the above named processes
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
11
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
1. Frequent delivery
2. Reflective improvement
3. Close (Osmotic) communication
4. Focus (priorities and time)
5. Personal safety
6. Easy access to expert users
7. A technical environment with
automated testing,
configuration management and
frequent integration
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
12
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
1. Frequent delivery
2. Reflective improvement
3. Close (Osmotic) communication
4. Focus (priorities and time)
5. Personal safety
Have you delivered
running, tested,
usable functions to
your users at least
twice in the last six
months?
6. Easy access to expert users
7. A technical environment with
automated testing,
configuration management and
frequent integration
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
13
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
1. Frequent delivery
2. Reflective improvement
3. Close (Osmotic) communication
4. Focus (priorities and time)
5. Personal safety
6. Easy access to expert users
Did you get
together within the
last three months
to discuss and
improve your
group's working
habits?
7. A technical environment with
automated testing,
configuration management and
frequent integration
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
14
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
1. Frequent delivery
2. Reflective improvement
3. Close (Osmotic) communication
4. Focus (priorities and time)
5. Personal safety
6. Easy access to expert users
7. A technical environment with
automated testing,
configuration management and
frequent integration
Does it take you under
30 seconds to get your
question to the
attention of the person
who might have the
answer?
Do you overhear
something relevant
from a conversation
among other team
members every few
days?
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
15
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
1. Frequent delivery
2. Reflective improvement
3. Close (Osmotic) communication
4. Focus (priorities and time)
5. Personal safety
6. Easy access to expert users
7. A technical environment with
automated testing,
configuration management and
frequent integration
Does everyone
understand the goal
and expected outcome
of the project?
Does each person know
what their top two
priority items are?
Are they guaranteed at
least two days in a row
with two uninterrupted
hours each day to work
on them?
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
16
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
1. Frequent delivery
2. Reflective improvement
3. Close (Osmotic) communication
4. Focus (priorities and time)
5. Personal safety
6. Easy access to expert users
7. A technical environment with
automated testing,
configuration management and
frequent integration
Can you give your
boss bad news?
Can people end
long debates about
each other’s
designs with
friendly
disagreement?
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
17
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
5. Personal safety
Does it take less
than three days
from when you
have a question to
when an expert
user answers it?
6. Easy access to expert users
... a few hours?
1. Frequent delivery.
2. Reflective improvement.
3. Close (Osmotic) communication
4. Focus (priorities and time)
7. A technical environment with
automated testing,
configuration management and
frequent integration
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
18
Cockburn’s Properties Describe Characteristics of
Successful Agile Development
1. Frequent delivery
2. Reflective improvement
3. Close (Osmotic) communication
4. Focus (priorities and time)
5. Personal safety
Do your developers
use the
configuration
management
system?
6. Easy access to expert users
Are your tests
automated?
7. A technical environment with
automated testing,
configuration management and
frequent integration
Do you integrate
the system at least
twice / week?
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
19
Agile Process
Framework(s)
People in Agile projects typically fall into
three general roles
Product Owner, or Customer
The Development Team
The Coach or Scrum Master
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
21
The Agile Product Owner or Customer
steers the product
Product Owner role name comes from Scrum
Customer role name comes from Extreme
Programming
While this is a role that can be held by a single
person, it is generally supported by a team:






Business Analysts
UI Designers & Interaction Designers
Architects
Testers
Domain Experts
Users
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
22
The Scrum Master or Coach guides the
process
The Team is generally composed of





Developers
Architects
Testers
Business Analysts
UI Designers & Interaction Designers
Some members of the team support both the
product owner team, and the
development team.
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
23
The Scrum Master or Coach oversees,
facilitates, and helps the team peform
The Scrum Master or Coach helps keep the
process running smoothly
 makes sure everyone understands their roles and
responsibilities
 helps team members get help and training
 deals with problems or impediments that slow the team
down
 facilitates planning, product evaluation, and retrospective
meetings
Often this person used to be a project manager
in a traditional software development
approach
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
24
The Scrum Process Model is The Simplest
of Incremental Development Models
Product Owner
supported by
others creates the
product backlog
Daily
Planning
Meeting
(Daily
Scrum)
The team
synchronizes daily
in a short morning
standup meeting or
daily scrum
Iteration
or Sprint
Product Owner
identified a
potential product
idea
Product
Goals
Product
Backlog
2-4 week cycle
Product Owner &
team plan the next
sprint or iteration
The team works
towards the
iteration/sprint
goals in a 2-4 week
time box
Sprint
Backlog
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
The product owner and
team gather to review
the results of the last
sprint and reflect on
how the product and
process could improve
Working
Evaluated
Software
25
If that seems too simple,
it’s because it is.
Let’s peel back another
layer.
26
The product owner plans the product in
layers
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
27
The product owner plans the product in
layers
Release
Product
or Project
How can we release
value incrementally?
What business objectives
will the product fulfill?
What subset of business
objectives will each
release achieve?
Product Goals
Product Charter
What user constituencies
will the release serve?
Elevator Pitch
What general capabilities
(big stories) will the
release offer?
Iteration or
Sprint
What specifically will we
build? (user stories)
How will this iteration
move us toward release
objectives?
Iteration Plan
Development or
Construction Tasks
Release Roadmap
Release Plan
Story (Backlog Item)
What user or stakeholder need will
the story serve?
How will it specifically look and
behave?
How will I determine if it’s
completed?
Story Details
Acceptance Tests
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
28
The Planning Onion can grow to include
product portfolios and business strategy
Product
or Project
What business objectives
will the product fulfill?
Product Goals
Product Charter
Elevator Pitch
Iteration
Release
How can we release
value incrementally?
Product or Project
What subset of business
objectives will each
release achieve?
Release
What user constituencies
will the release serve?
Iteration
What general capabilities
(big stories) will the
release offer?
Release Roadmap
Story
Release plan
What specifically will we
build? (user stories)
Story (Backlog Item)
How will this iteration
move us toward release
objectives?
What user or stakeholder need will
the story serve?
Iteration Plan
Development or
Construction Tasks
How will it specifically look and
behave?
How will I determine if it’s
completed?
Story Details
Acceptance Tests
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
29
The Planning Onion can grow to include
product portfolios and business strategy
Product or Project
Release
Iteration/Sprint
Story
© 2008
© 2008
Jeff Jeff
Patton,
Patton
All rights
& Josh
reserved,
Evnin, Allwww.agileproductdesign.com
rights reserved, www.agileproductdesign.com
30
The Planning Onion can grow to include
product portfolios and business strategy
Business Strategy
Product Portfolio
Product or Project
Release
Iteration/Sprint
Story
© 2008
© 2008
Jeff Jeff
Patton,
Patton
All rights
& Josh
reserved,
Evnin, Allwww.agileproductdesign.com
rights reserved, www.agileproductdesign.com
31
The basic anatomy of an Agile iteration
What will we
construct?
Keep quality high
and minimize the
cost of change?
What outcome or
benefit are we
striving for?
Keep progress
visible to all?
plan
perform
Pace : how fast are
we moving?
An Agile iteration or
“sprint” is typically 1-4
weeks, or 1 calendar
month
evaluate
objective: plan, create,
and validate potentially
deliverable functionality
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
Product: is the
software we’re
building able to
achieve its intended
benefit?
Process: is the process
we’re using working
effectively?
32
An iteration has it’s
plan-perform- evaluate cycle
perform
Iteration
plan
evaluate
© 2008
© 2008
Jeff Jeff
Patton,
Patton
All rights
& Josh
reserved,
Evnin, Allwww.agileproductdesign.com
rights reserved, www.agileproductdesign.com
33
Performing an iteration means discussing,
writing code for, and validating user stories
code
Story
design
perform
validate
Iteration
plan
evaluate
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
34
Releasing software incrementally means
building software iteratively
code
design
Story
validate
Iteration
plan
evaluate
Release
plan
evaluate
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
35
Chartering a product or project means
determining how to release it incrementally
Notice the layers of
planning and evaluation
code
precise, fine
grained, detailed
design
Story
validate
Iteration
plan
evaluate
Release
plan
abstract, course
grained, and
high level
plan
evaluate
All this planning and
evaluation lends lots of
opportunity for course
correction
Notice how planning
and evaluation moves
from course grain to fine
grain, and from abstract
to detailed
Notice how all this
planning and evaluation
at different levels of
abstraction is going to
take a lot of time?
Product/Project
evaluate
© 2008
© 2008
Jeff Jeff
Patton,
Patton
All rights
& Josh
reserved,
Evnin, Allwww.agileproductdesign.com
rights reserved, www.agileproductdesign.com
36
We can flatten these nested cycles to
see how they look over time.
product
release
release
sprint
daily story
development
cycles
time
© 2008
© 2008
Jeff Jeff
Patton,
Patton
All rights
& Josh
reserved,
Evnin, Allwww.agileproductdesign.com
rights reserved, www.agileproductdesign.com
37
Add “Milestone” internal releases to break up
long periods between public releases
product
release
milestone
milestone
sprint
daily story
development
cycles
time
© 2006-2007©Jeff
2006-2007
Patton, Jeff
All rights
Patton,
reserved,
All rights
www.agileproductdesign.com
reserved, www.agileproductdesign.com
38
Practices commonly found
in Agile development
39
Daily practices
• Daily standup meeting (Daily Scrum)
Day
Iteration
• Detailed Story Discussions
• Pair Programming
Release
• Paired Work
• Test Driven Development
• Refactoring & Simple Design
• Automated Acceptance Testing
• Development Task Walls
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
40
Iteration practices
• Story Writing
Day
Iteration
• Iteration Planning Meeting
• Story Acceptance Criteria Workshop
Release
• Iteration Burn Down Chart
• End of Iteration Product Demonstration
• Iteration Level Product Evaluation
• Velocity & Load Factor Measurement
• Reflection Session (retrospective)
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
41
Release practices
• Release Planning
• Release Level Story Writing
Day
Iteration
Release
• User Observation & Modeling
• Workflow Analysis and Modeling
• Business & Product Objective
Identification & Prioritization
• User Acceptance Testing
• Usability Testing
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
42
Visibility and Tracking
in an Agile Development
Cycle
We can watch an iteration in progress, then
measure velocity when it’s complete
5 developers
planned story
points: 16
in progress
ready to validate
done
3
1
2
3
4
2
1
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
44
Progress at the end of day 1
5 developers
planned story
points: 16
in progress
ready to validate
3
1
done
2
3
4
2
1
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
45
Progress at the end of day 2
5 developers
planned story
points: 16
4
in progress
ready to validate
done
3
3
1
2
2
1
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
46
Progress at the end of day 3
5 developers
planned story
points: 16
in progress
ready to validate
3
3
done
1
1
2
4
2
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
47
Progress at the end of day 4
5 developers
planned story
points: 16
in progress
3
ready to validate
done
1
1
4
2
2
3
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
48
Progress at the end of day 5
Now we can calculate velocity & load factor
5 developers
planned story
points: 16
in progress
velocity: 13
ready to validate
done
3
1
2
velocity: 13 points per 5 day iteration
5 developers * 5 man days = 25 many days
2
25 man days / 13 points = load factor 1.92
1 story point = 1.92 man days
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
3
4
1
49
story points
A burn down chart lets us see progress
during the iteration
time
1
2
3
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
4
5
50
story points
Day 1: no stories complete
time
1
2
3
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
4
5
51
story points
Day 2: 3 story points completed
time
1
2
3
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
4
5
52
story points
Day 3: 5 story points completed total
The trend line
doesn’t look good
time
1
2
3
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
4
5
53
story points
Day 4: 8 story points completed total
The trend line
seems to be
staying about the
same. It’s clear we
won’t hit 16 points
time
1
2
3
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
4
5
54
story points
Day 5: 13 story points completed total
time
1
2
3
4
© 2008 Jeff Patton & Josh Evnin, All rights reserved, www.agileproductdesign.com
5
55
Lean/Kanban Style
Development
Starting with explaining timeboxed development tracking
看板 – Kanban cards help limit excess
work in progress
看板 – Kanban literally means visual
card
In its initial development it was used
to limit the amount of inventory tied
up in “work in progress” on a
manufacturing floor
Not only is excess inventory waste,
time spent producing it is better spent
elsewhere
In software development visual cards
on a board are used to:
 limit work in progress
 point out bottlenecks in process
flow
1. defining a work process flow
This simple process flow has the steps:
1.elaboration & acceptance
2.development
3.test
4.Deployment
Look at the typical flow for features, stories, or work
packages and describe typical process steps
2. Lay out the kanban board
Place an expedite track above the main left to right queue
Place “done and waiting” queues between each work queue
(in this example they’re placed below)
Place a goals column on the left, and waiting queue,
the process steps, and a final “done” column
3. Decide on limits for stories in queue &
work in progress
This board uses painters tape to indicate available “slots” for
work in progress
A good limit might the number of people in a role
that can work on an item in a given process step
4. Place prioritized goals on the left
column of the board
Having goals visible:
•promotes focus
•helps us prioritize
•helps us manage feature scope & requirements
A good goal describes the outcome we hope to
achieve after software ships
5. Start the board by placing stories or
features in queue
Product owners manage the waiting queue
Mark on the story or feature card with the date it
entered the queue
6. Move stories through the process flow
as work is completed
As the story enters the first process step, mark that date on the
card. As it’s finished, mark that date on the card
Use the dates on the cards to calculate
cycle time
Cycle time = finish date – start date
The average cycle time from the date the item enters the
board is the wait time from this point in the queue
Use average cycle time to set wait times from
different points on the board
Kanban Boards
Kanban Boards
Explode large process steps into tasks
When a feature or work task is large:
 Takes longer than a couple days to complete
 Requires that multiple people collaborate on it’s completion
Decompose that step into cards to track independently
Feature to
develop
Tasks in queue
Tasks in
progress
Tasks
complete
Feature
complete
Kanban Boards
Use cumulative flow diagrams to
visualize work in progress
www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
Use cumulative flow diagrams to
visualize work in progress
www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
Agile
Product
Ownership
71
Product ownership blends a diverse set of skills
and concerns – more than can fit in one head
Business Advocate

Understand the needs of the
organization paying for the
software’s construction and select
a mix of features that serve their
goals
Customer Advocate

Understand the needs of the
business buying the product and
select a mix of features valuable
to the customer
End User Advocate

Describe the product with an
understanding of users and use,
and a product that best serves
both
The Product Owner role is generally filled by a person
supported by a collaborative team
Subject Matter Expert
Answer technical questions on the
domain for those creating the product
Designer
•Synthesize business, customer, and user
needs into a product design that satisfied
them all.
•Maintain product coherence while
constructing the product iteratively and
incrementally
Communicator
 Capable of communicating vision
and intent – deferring detailed
feature and design decisions to be
made just in time
Decision Maker
 Given a variety of conflicting goals
and opinions, be the final decision
maker for hard product decisions
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
72
Within the product ownership team, responsibilities are often split
between strategic and tactical product owners
Product owner
 Holds the vision of the product’s
ultimate direction
 Responsible for communicating a
consistent product vision and
direction to the entire team
 Participates in visioning and planning
stages of product design
 Participates peripherally in day to day
product development
 Holds final decision making
responsibility
 An effective product owner
delegates tactical decision making
the tactical product owners
Tactical product owner
 Participates in visioning and planning
stages of product design
 Aids in communicating product vision
and direction to the team
 Participates in cycle level planning
activities
 Works with the team to develop storylevel acceptance criteria
 Available to the team daily to answer
detailed questions on the product
 Works with the team to develop
detailed product design
 Performs acceptance checking on
finished product features
Product ownership team
 Includes the product owner, those serving in a tactical product ownership role, and a
wide circle of subject matter experts, users, business stakeholders and others the product
owners rely on to design and delivery useful tem
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
73
•Communicate Business Goals, Customer Goals, End User Goals
•Coordinate involvement of SMEs, users, and business stakeholders
•Coordinate with other product owners to insure coherence of product and
releases
Product Owner Responsibilities
Participate daily
Evaluate product at
end of Sprint and add
or remove stories from
backlog as necessary
Be available to answer
questions and clarify
details on user stories
Create and maintain the
product backlog
Organize the backlog into
incremental releases
Verify stories are done
based on acceptance
criteria
Specify objective acceptance
criteria for stories
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
74
Sprint 0
Sprint 1
Sprint 2
• planning
• data gathering
• design for
iteration 1
features – high
technical
requirements, low
user requirements
• gather user input
for iteration 3
features
• design iteration 2
features
• support iteration 1
development
support dev
• development
environment
setup
• architectural
“spikes”
Sprint 3
• gather user input
for iteration 4
features
• design iteration 3
features
• support iteration 2
development
• validate iteration 1
features
support dev
Development Team
Product Owner
Team
Design and Coded Features Pass Back and
Forth Between Tracks
implement iteration
1 features
implement iteration
2 features
fix iteration 1 bugs
if any
• gather user input
for iteration 5
features
• design iteration 4
features
• support iteration 3
development
• validate iteration 2
features
implement iteration
3 features
fix iteration 2 bugs if
any
time
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
75
Traditional software development fixes scope then
estimates, and attempts to fix time and cost
Estimate
Fix
Scope
Traditional
software
development
Time
Cost
(resources)
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
76
Agile development fixes time and cost, then leverages
iteration and incrementing to maximize scope
Time
Scope
Fix
Estimate
Cost
(resources)
Agile
software
development
Traditional
software
development
Time
Cost
Scope
(resources)
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
77
Leverage a shared understanding of desired product
goals to minimize scope while maximizing value
Time
Scope
Fix
Estimate
Cost
(resources)
Agile
software
development
Traditional
software
development
Time
Cost
(resources)
Scope
Goals, outcomes, benefits
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
78
Tactically managing the construction of an
incremental product release takes practice and skill
There is a huge amount of details about the software
we’ve deferred discussing and resolving
There are big assumptions in what little detail we
have discussed
From a release plan we’ll begin decomposing our
large task-centric user stories to smaller, more
tactical feature-centric user stories
This is where a number of things can go wrong
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
79
“Incrementing” builds a bit at a time
Incrementing often
calls for a fully
formed idea
1
2
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
3
80
Once development starts, a common failure mode of agile
development is to incrementally design and build each feature
At the end of a release timebox, all features supporting user tasks are not
implemented
The release isn’t useful to end users
End to end functionality may never have been validated: from a functional,
architectural, or usability perspective
This seems like the obvious approach – it’s easiest – but it’s risky – unless you
know exactly what you’re going to build and exactly how long it’ll take
user tasks to support
release
iterations
design & development
1
2
3
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
4
81
“Iterating” builds a rough version,
then slowly builds up quality
Iterating allows you
to move from vague
idea to realization
1
2
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
3
82
Use feature scaling guidelines to grow features
iteratively
user tasks to support
Each feature you design has some measure of necessity, flexibility, safety,
comfort, performance, and luxury
Start by making sure that each feature is designed and implemented to
support necessary, or essential use
After sufficiently completing necessities, continue by adding flexibility and
safety
Conclude by adding comfort, performance, and luxury to the features that
can most benefit
release
iterations
design & development
1
2
3
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
4
83
This strategy has us designing each feature many times over growing
and changing the software as we learn from each iteration’s design
and development
The resulting release has support for all users’ tasks up to a usable level
Complete workflow was visible earlier in the release: this allows for functional,
architectural, and preliminary usability evaluation
There’s never enough time to implement all the flexibility, safety, comfort,
performance and luxury you’d hoped… strive for sufficiency
This is hard work
You’ll design features over many times, but we’ve significantly reduced risk
user tasks to support
release
iterations
design & development
1
2
3
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
4
84
Make quality improvement visible by managing the
“gpa” of your release
Grade the quality of release level stories as your release progresses
Don’t aim for all iteration level stories complete – aim for sufficient
release quality
ABD
C
D
A
B
CBD
B
D
A
B
AD
B
AD
BI
BD
I
user tasks to support
release
iterations
design & development
1
2
3
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
4
85
The simplest method for prioritization is
also a method for splitting
MoSCoW
 Must have
 Should have
 Could have
 Won’t have
What elements
of the feature
must be present?
What should be
present?
Must have
feature
What could be
present?
What did someone
suggest that’s
actually a bad
idea?
86
Considering feature quality characteristics
Given a user task like “swing from tree,” a variety of feature design
solutions exist to support the task which vary widely
Managing feature details appropriately is an important part of
managing scope
When initially planning the delivery of a set of features, the
characteristics of each feature must be considered
Much of detail scope management happens during design and
development
 Close to the time the functionality is needed
 In the context of other features, time
constraints, development
capacity, and
other projects in
the portfolio
low cost
moderate cost
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
high cost
87
Noriaki Kano asks us to consider quality as being
composed of objective and subjective elements
“Discussions of quality have revolved
around the two aspects of subjectivity
and objectivity since the time of
Aristotle.
Embedded in this objectivesubjective split is the idea that
objective quality pertains to the
‘conformance to requirements’ while
subjective quality pertains to the
‘satisfaction of users.’”
--Noriaki Kano
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
88
Kano explains three general classifications for product
features: must-haves, one dimensionals, and delighters
Must-haves
The products must have this
features for me to be consider
the product acceptable
One dimensionals
The more of this I get, the
better
Delighters
“This car has many flaws. Buy it anyway. It’s so much
fun to drive”
-- from a NY Times review of the Mini Cooper
I love this element of the
product!
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
89
Separate objective quality from subjective
quality
Objective quality refers to the visible measurable,
and easily validated characteristics of the product
usually in relation to the products’ specifications.
 Does the product perform bug free as specified?
 Expect objective quality to be high.
Subjective quality refers to the specification or
product design choices made that affect the
product users’ perception of quality
 Is the product simple to use?
 Is the product efficient to use?
 Do I like using the product?
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
90
Use the Kano classifications to both
prioritize and split
Brakes
(must have)
Basic brakes
(must have)
Stopping
distance
(one dimensional)
Anti-locking
(delighter)
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
Cool dashboard
light when
slipping
(delighter)
91
The Car Metaphor
Consider the job of building a car incrementally.
Omitting necessary features may make the product useless – this
makes prioritization difficult.
We need to perform every user task these features are built to support.
Scaling all features to highest quality level increases cost.
To control the cost of the car, we scale the features back to
economical quality levels.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
92
The characteristics of a feature used for
managing scope
Necessity: what minimal characteristics are necessary for this feature?
 For our car a minimal engine and transmission are necessary –
along with a number of other features.
Flexibility: what would make this feature more useful in more
situations?
 For our car, optional all-wheel-drive would make it more useful for
me to take on camping trips. A hatchback might make it easier
for me to load bigger stuff into the back.
Safety: what would make this feature safer for me to use?
 For our car adding seat belts and making the brakes anti-locking
would make the car safer.
Comfort, Luxury, and Performance: what would make this feature
more desirable to use?
 I’d really like automatic climate control, the seats to be leather,
and a bigger V6 engine.
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
93
Splitting stories using the 4 thinning
guidelines
Necessity:
Safety:
For the feature to be minimally
demonstrable – but not releasable,
what is the minimal functionality
What would make this feature safer
for me to use? For both the user,
and for the business paying for the
software?
Example: A form with only necessary
fields and no validation
Flexibility:
What would add the ability to
perform the user task in different
ways? Adding in sub tasks that are
optionally performed?
Example: a form with optional fields,
date lookup tools, input translation
on dates
Example: input validation,
enforcement of business rules such
as credit card validation
Comfort, Luxury, and Performance:
What would make this feature easier
to use? More desirable to use?
Faster to use?
Example: auto-completion, sexy
visual design, speed keys
© 2006-2007 Jeff Patton, All rights reserved, www.agileproductdesign.com
94
The closer we get to implementing features,
the more we know
uncertainty
Barry Boehm first described the cone of uncertainty applying it
to estimation accuracy over time
Steve McConnell applied the same principle to certainty of
product requirements
Defer specific feature decisions to the “latest responsible
moment” as described in Poppendiek & Poppendiek’s Lean
Software Development
uncertainty decreases over time
time
cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements)
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
95
Divide release design & development into
“trimesters”
Build a simple system span of necessary features first
Add flexibility and safety next
Finish with comfort, performance, and luxury
uncertainty
Reserve time in the remaining third for unforeseen additions
and adaptations
Necessity
Flexibility and Safety
Comfort,
Performance,
Luxury, and
unforeseen additions
and adaptations
uncertainty decreases over time
time
cone of uncertainty source: Barry Boehm (estimation), elaborated by Steve McConnell (requirements)
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
96
This product thickening strategy slowly
brings the product into focus
uncertainty
Just as an artist envisions an entire painting by starting with a
sketch or an under-painting and slowly building up detail,
apply the same strategy to “thicken” the product from simple
necessities through to full featured product.
Necessity
Flexibility and Safety
Comfort,
Performance,
Luxury, and
unforeseen additions
and adaptations
uncertainty decreases over time
time
© 2006-2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
97
In Agile development,
we defer many decisions
till the last responsible
moment
98
If we’re product-centric
we make decisions in
the context of product
and user goals always
seeking to maximize
product value
99
Product owner: “We always
finish our software late!”
Jim: “Start sooner.”
Jim Highsmith, author of Agile Project
Management, Agile Software Development
Ecosystems, & Adaptive Software Development
Product owner: “We’re
committed to shipping on
time!”
Jim “Write less software.”
These really are the only secrets I know to being faster.
If the only ways to be faster are to start sooner and build less, then
make everything you choose to build as valuable as it can be.
Start with a clear understanding of where the value comes from.
100
Agile development simulation
(Cycle 1)
Inception
Plan
Perform
Evaluate
(8 minutes)
(8 minutes)
(8 minutes)
(8 minutes)
1. Product owners speak
with your end user to
determine the type of
product he’d like to
build (have drawn)
1. Product owners select
the stories you’d like
to build in first
development timebox
1. Developers code by
performing work tasks
to draw parts of the
product.
2. Product owners
create a backlog of
user stories using
index cards, one card
per story
2. For each selected
story product owners
describe the
functionality to
developers. Write
acceptance criteria
on the back of the
story card.
1. Product owners sum
the estimates of
completed stories to
determine velocity.
(They’re done if your
acceptance criteria
are met.)
3. Product owners
prioritize the user
stories by separating
them into Musts,
Shoulds, Coulds, and
Won’ts.
4. Developers estimate
the user stories by
relative size – 1 to 5
3. Developers create a
work plan by
identifying what work
tasks need to be
done to finish each
story
2. Developers show
progress by piling
completed tasks and
stories where they
can be seen by
product owners.
3. Product owners give
feedback. Is a story
good enough to be
called done?
4. Product owner visit
users at the lawn and
garden show to
better understand
needs.
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
2. Review the progress
as a team. Grade the
product in progress:
A, B , C, D, or F
3. The whole team
discuss this cycle:
What will you try
differently next time
to improve your
process?
101
Agile development simulation
(Cycle 1)
Inception
Plan
Perform
Evaluate
(8 minutes)
(8 minutes)
(8 minutes)
(8 minutes)
1. Product owners speak
with your end user to
determine the type of
product he’d like to
build (have drawn)
1. Product owners select
the stories you’d like
to build in first
development timebox
1. Developers code by
performing work tasks
to draw parts of the
product.
2. Product owners
create a backlog of
user stories using
index cards, one card
per story
2. For each selected
story product owners
describe the
functionality to
developers. Write
acceptance criteria
on the back of the
story card.
1. Product owners sum
the estimates of
completed stories to
determine velocity.
(They’re done if your
acceptance criteria
are met.)
3. Product owners
prioritize the user
stories by separating
them into Musts,
Shoulds, Coulds, and
Won’ts.
4. Developers estimate
the user stories by
relative size – 1 to 5
3. Developers create a
work plan by
identifying what work
tasks need to be
done to finish each
story
2. Developers show
progress by piling
completed tasks and
stories where they
can be seen by
product owners.
3. Product owners give
feedback. Is a story
good enough to be
called done?
4. Product owner visit
users at the lawn and
garden show to better
understand needs
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
2. Review the progress as
a team. Grade the
product in progress: A,
B , C, D, or F
3. The whole team
discuss this cycle:
What will you try
differently next time
to improve your
process?
102
Agile development simulation
(Cycle 2)
Inception
Plan
Perform
Evaluate
(8 minutes)
(8 minutes)
(8 minutes)
(8 minutes)
1. Product owners speak
with your end user to
determine the type of
product he’d like to
build (have drawn)
1. Product owners select
the stories you’d like
to build in first
development timebox
1. Developers code by
performing work tasks
to draw parts of the
product.
2. Product owners
create a backlog of
user stories using
index cards, one card
per story
2. For each selected
story product owners
describe the
functionality to
developers. Write
acceptance criteria
on the back of the
story card.
1. Product owners sum
the estimates of
completed stories to
determine velocity.
(They’re done if your
acceptance criteria
are met.)
3. Product owners
prioritize the user
stories by separating
them into Musts,
Shoulds, Coulds, and
Won’ts.
4. Developers estimate
the user stories by
relative size – 1 to 5
3. Developers create a
work plan by
identifying what work
tasks need to be
done to finish each
story
2. Developers show
progress by piling
completed tasks and
stories where they
can be seen by
product owners.
3. Product owners give
feedback. Is a story
good enough to be
called done?
4. Product owners review
the overall product with
the end-user. End user
grade the product in
progress: A, through F.
© 2008 Jeff Patton, All rights reserved, www.agileproductdesign.com
2. Review the progress as
a team. Grade the
product in progress: A,
B , C, D, or F
3. The whole team
discuss this cycle:
What will you try
differently next time
to improve your
process?
103
Essential
Agile
Software
Development
Jeff Patton
[email protected]
AgileProductDesign.com