• 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
• 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
• 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
• 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
  • How many prototypes?
  • Why and when?
  • How many in parallel?
  • Testing
    • Running your “chicken test” early
    • Test-first approach
    • The value of automated testing

Day 2

• 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
  • The importance of design convergence
  • Set-based goes against the way engineers are trained
  • Going beyond the Toyota model
• 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 collocation
    • 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
• 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
• 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”
• 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