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