through the looking glass
DESCRIPTION
Agile methods are based on short iterations delivering functionality in increments, with small, well-defined work requests consisting of just enough requirements definition at just the right time. But with such a short-term focus, how can agile teams manage a product portfolio over months or even years? We'll talk about the building blocks of an effective agile portfolio management strategy, starting with the core tools of the Product Owner, and extending these to look beyond the next few weeks of work into planning and tracking a product release or portfolio over several months.TRANSCRIPT
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
...or its much easier to steer a moving car
Through the Looking GlassAgile Product Management & Planning Methods
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
iterative & incremental development is the norm
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
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.
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.
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.
http://www.archives.gov.on.ca/english/on-line-exhibits/d-day/big/big_03_airline_assembly.aspxArchives of Ontario, Reference Code: C 190-5-0-0-21
Assembly Line Manufacturing has a high cost of change
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
• 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
Inclusive thinking
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
Software Development has commoditized cost of change
Continuous Delivery
Ruby on Rails
Coffeescript
jquery
Object-oriented languages
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
• 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)
Changing paradigms
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
Cost of Change
Detail of Requirements
Validated Requirements
Evolving Requirements
Hypothesized Requirements
Lean Startup experiments
Emerging needs as development
progresses
Capture all possible needs
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
portfolio planning in an uncertain world
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
Vision Planning
Roadmap Planning
Release Planning
Release PlanningItera3on Planning
Daily Planning
Five Levels of Planning
AnnuallyExec Management, Stakeholders
Bi-‐annuallyProduct Owners, UX, Engineering, Architecture
QuarterlyProduct Owners, UX, Architecture, Analytics, SEO, Production
Bi-‐weeklyProduct Owners, Delivery Team
DailyProduct Owners, Delivery Team
Vision Planning
Roadmap Planning
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
Ini$a$ves
Requirement
Epic
User Story
Expressed as User Stories and sized by the teams
Defined by a one-‐page project descrip3on
Increasing detail
Vision
The Requirements PyramidStar3ng 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:-‐ Requirements within a year-‐ Epics within a quarter-‐ User Stories within a sprint
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
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.
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.
Vision Roadmap Release Plan Iterations ReleaseInitiatives Requirements Features/Epics User Stories Code
Ini3a3ve Vision
SMART Requirements
Epic Stories
User Stories
Appropriate documenta3on at each level captures key
informa3on
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
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.
OWNERSHIP
6+ months 1-‐3 months <1 month <2 weeks CADENCE
Ini$a$ve Vision
SMART Requirements
Epic Stories
User Stories
DOCUMENTATION
Vision Roadmap Release Plan Iterations ReleaseInitiatives Requirements Features/Epics User Stories Code
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
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.
• 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.
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.
thank you
[email protected]: dave.sharrockfollow us on: @agile42
follow me on: @davesharrock