Through the looking glass

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


iterative & incremental development is the norm


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”


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


decoding the impact of cost of change


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


• 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


Software Development has commoditized cost of change

Continuous Delivery

Ruby on Rails

Coffeescript

jquery

Object-oriented languages


• 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


Cost of Change

Detail of Requirements

Validated Requirements

Evolving Requirements

Hypothesized Requirements

Lean Startup experiments

Emerging needs as development

progresses

Capture all possible needs


portfolio planning in an uncertain world


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


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


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


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


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


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


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


Change is rapidly disappearing as a material cost in software delivery


• 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


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


thank you

[email protected]: dave.sharrockfollow us on: @agile42

follow me on: @davesharrock

Through the looking glass

Business

Transcript of Through the looking glass