Skip to navigation, content

2 - D A Y  W O R K S H O P
Flexible Product Development:
Techniques for Thriving in Fast-Moving and Uncertain Markets

 Dates & Location:
 August 8-9, 2006
/ Chicago, IL


Course Outline

I. Introduction

  • Definition of flexibility

  • Benefits of flexibility

  • Where it fits and where it is unwise

  • Reducing the cost of change

  • The essence of Extreme Programming

  • Flexibility practices mutually support each other

  • Potential downsides

    • Amplified volatility

    • Indecisiveness

    • Focusing on tactics at the expense of strategy

II. Customers and Product Requirements

  • The fallacy of knowing all requirements at a project’s outset

  • Frozen requirements versus customer feedback

  • Customers don’t use the features we give them

  • Linking with specific customers

    • Use cases

    • Personas

    • Lead users

  • Where customer feedback can lead you astray

  • Obtaining customer feedback quickly and efficiently

  • The power of a product vision

III.  Modular Product Architectures

  • Modular versus integral architectures

    • Advantages and disadvantages

  • Applying architecture as a strategic tool rather than a technical tool

  • Architectural objectives

    • How to choose them

    • Difficulty of having more than one

  • Why enforcing architectural rules is critical

  • Examples of actual architectural choices

  • CD-ROM drive

    • Electric screwdriver

  • Perfect versus imperfect modularity

  • The four steps in designing an architecture

  • Understanding interactions: the design structure matrix

  • The price of modularity

    • Transitioning from modular to integral architecture

IV. Experimentation

  • The different kinds of experimentation: analysis, experiments, prototypes, simulations, etc.

  • The value of failure

    • Implications for experimentation approach

  • Hypothesis-based approach

  • Front-loaded prototyping

    • Traditional versus front-loaded strategies

    • Enabling technologies

    • Economic drivers

    • Where not to prototype

    • Front-loaded strategies

V. How Many Prototypes?

VI. Why and When?

VII. How Many in Parallel?

  • Testing

    • Running your “chicken test” early

    • Test-first approach

    • The value of automated testing

VIII. Set-Based Design

  • Value: delaying critical decisions

    • Reduce the cost of change

    • Have better information later

  • The flexibility benefits of

    • Discovering constraints rather then making choices

    • Maintaining options

  • The design space

    • Understanding it

    • Narrowing it progressively

IX. The Importance of Design Convergence

  • Set-based goes against the way engineers are trained

  • Going beyond the Toyota model

X. Development Teams

  • People are more important than processes and tools

  • The “right” people are essential to success

  • But they don’t have to be perfect

    • Cockburn mastery levels

  • The value of generalists

  • Pigs, chickens, and cows

  • Establishing authority levels in advance

  • The power of co-location

    • How it is done in Extreme Programming

    • Workarounds when it isn’t possible

  • The daily stand-up meeting

  • How to enhance the team’s electronic communication

XI. Decision Making

  • Decisions are at the core of product development

    • For flexibility, decisions must me made in a flexible way

    • That is, at the last responsible moment

  • Uncertainty is characteristic of decisions

    • This suggests collecting information in advance to reduce uncertainty

  • Applying the last responsible moment responsibly

  • Working with linked decisions

  • Using decision trees

    • Sensitivity analysis

    • The value of perfect information

  • Project scope-schedule-resource decisions

  • Project economic trade-offs

  • The benefits of consensus

    • Reaching it quickly

XII. Project Management

  • Flexible project management is much different than traditional project management

    • The project schedule isn’t always the guide

    • Individuals are more important than processes

    • Responding to change is more important than following a plan

    • “Corrective action” often means changing the plan

    • Project completion means delivering value rather than finishing the plan

  • Rolling-wave planning

  • Timeboxing

  • Risk management, rather than being certain steps in a subprocess, is the process (because the whole project is risk-driven)

  • Valuable project metrics

    • Burndown chart

    • Team mood

  • Learning how to say, “no”

XIII. Product Development Process

  • Balancing between structure and flexibility

    • Balancing the opposing risks

    • Different for each project

    • Different for different facets of a project

    • Changes over the life of a project

  • Phased processes don’t mesh well with innovation activities

  • Incremental innovation

    • Advantages and limitations

  • Bottlenecks and queues

    • Importance to flexibility

    • The myth of capacity

  • Useful concepts from agile software

    • Visual controls

    • Refactoring and technical debt

    • You aren’t going to need it (YAGNI)

  • Build up processes, don’t tear down