Contenu connexe Similaire à Through the looking glass (20) Plus de Dave Sharrock (20) Through the looking glass1. Through the Looking Glass
Agile Product Management & Planning Methods
...or its much easier to steer a moving car
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
2. iterative & incremental
development is the norm
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
3. First description of
Iterative Development
(1968) Brian Randell
& F.W. Zurcher
“The basic approach
recognizes the futility of
separating design,
evaluation, and
documentation
processes in software-
system design”
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
4. Iterative & incremental development has a rich
history since the 1950s
•1950s - X-15 Hypersonic jet was a milestone 1950s
project applying IID
•1960s - Project Mercury, the first human spaceflight
program in the US
•1972 - IBM FSD (Federal Systems Division) working on
1 million+ lines of code for US Trident command system
•1977 - FSD incorporated the Trident IID approach with
over 2500 engineers as an alternative to waterfall
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
5. decoding the impact of
cost of change
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
6. Assembly Line Manufacturing
has a high cost of change
http://www.archives.gov.on.ca/english/on-line-exhibits/d-day/big/big_03_airline_assembly.aspx
Archives of Ontario, Reference Code: C 190-5-0-0-21
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
7. Inclusive thinking
• In software development high
cost of change leads to inclusive
thinking
• Any and every idea has to be
captured in the first version of a
requirements specification
• Creates waste - bloated
documents, unwanted features
and entitlement thinking
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
8. Software Development has
commoditized cost of change
Object-oriented
languages
jquery
Ruby on Rails
Coffeescript
Continuous Delivery
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
9. Changing paradigms
• If change is cheap, requirements
can change continuously
• We can evolve our thinking as
we learn more about the product
we are building
• High-level, broad requirements
(why we need something) with
focus (how will we know when
we’re done)
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
10. Cost of Hypothesized
Change Requirements
Evolving
Requirements
Validated
Requirements Capture all
possible needs
Emerging needs
as development
progresses
Lean Startup
experiments
Detail of
Requirements
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
11. portfolio planning in an
uncertain world
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
12. Five Levels of Planning
Exec Management,
Vision
Planning
Annually
Stakeholders
Product Owners, UX,
Roadmap
Planning Bi-‐annually
Engineering, Architecture
Product Owners, UX,
Release
Planning
Vision
Planning Quarterly Architecture, Analytics, SEO,
Production
Roadmap
Planning
Itera3on
Release
Planning Product Owners, Delivery
Planning Bi-‐weekly
Team
Daily
Planning Product Owners, Delivery
Daily
Team
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
13. The
Requirements
Pyramid
Star3ng
from
the
objec3ve
for
the
consumer
experience,
an
experience
ini3a3ve
is
defined
in
terms
of
requirements,
epics,
and
user
stories.
Sizing
guideline:
A
single
team
should
be
able
to
deliver
5-‐10:
Vision -‐
Requirements
within
a
year
-‐
Epics
within
a
quarter
-‐
User
Stories
within
a
sprint
Ini$a$ves Defined
by
a
one-‐page
project
descrip3on
Requirement
Increasing
detail
Epic Expressed
as
User
Stories
and
sized
by
the
teams
User
Story
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
14. Where do User Stories come from?
Ini$a$ves
• Describes a large program over years. Corresponds to the Project Chartering level of traditional
PMI-type project management
Requirements
• Describes the needs of the product - the problem
we want to solve – in terms of the
consumers’ experience
Epics
• Requirements are transformed into multiple Epics, were each Epic is a proposal to partially
satisfy the Requirement
• Epics are broadly capability specific, though some cross-capability dependencies will be
unavoidable
User
Stories
• Epics are in turn transformed into multiple User Stories, were each User Story is a proposal to
partially satisfy the Epic
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
15. Delivery Process
• Nested hierarchy of increasing detail, starting with high-
level vision to high-detail user stories
• Four levels of granularity fully describe the product, from
vision to individual user stories
• Features are described just-in-time, in just enough detail,
to be estimated and delivered
• Prioritization and de-scoping decisions can be made at all
levels, at any time
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
16. Vision Roadmap Release Plan Iterations Release
Initiatives Requirements Features/Epics User Stories Code
Appropriate
documenta3on
at
each
level
captures
key
informa3on
Ini3a3ve
SMART
Epic
User
Vision Requirements Stories Stories
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
17. Characteristics of Each Level
• Each level of product planning has a different:
–Cadence: the rhythm at which the content is reviewed
and commitments are made
–Ownership: product ownership cascades through the
team allowing quick and appropriate decisions
–Documenta$on: a specific form of information capture is
used at each level, driving collaboration
–Tracking: transparency is essential for teams to be
prepared and adapt to new information
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
18. Vision Roadmap Release Plan Iterations Release
Initiatives Requirements Features/Epics User Stories Code
6+
months 1-‐3
months <1
month <2
weeks CADENCE
OWNERSHIP
Ini$a$ve
SMART
Epic
User
DOCUMENTATION
Vision Requirements Stories Stories
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
19. agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
20. Change is rapidly
disappearing as a material
cost in software delivery
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
21. • Elicit a guiding vision and
requirements from stakeholders
• Emerge further details based on
experience with delivered work
• Validate ideas before investing
in them using Lean Startup
• Use empirical data to manage
portfolio roadmap
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
22. Further Reading
• Slideshare: http://www.slideshare.net/davesharrock
• Iterative and Incremental Development: A Brief History, IEEE Computer Society,
by Craig Larman & Victor R. Basili
• The Lean Startup by Eric Ries
• Running Lean: Iterate from Plan A to a Plan That Works by Ash Maurya
• Software by Numbers: Low-Risk, High-Return Development by Mark Denne &
Jane Cleland-Huang
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
23. thank you
dave.sharrock@agile42.com
skype: dave.sharrock
follow us on: @agile42
follow me on: @davesharrock
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.