Martin Fowler Keynote

Keynote: Martin Fowler

  • 3 small talks

The Essence of Agile

  • Problems with software development notes in the 1990’s
  • Two camps on solving these problems: Plan Driven Development and Agile


  • agile becomes successful, adopted my many companies, but a Semantic Diffusion is occurring
  • developers claim to be Agile, without really knowing what that means or how to do it

Adaptive vs. Predictive Planning

  • Predictive Planning = plan first, follow the plan
  • requires stable requirements
  • changes in requirements are seen as a problem, or a failure in the plan or execution of the plan
  • “A late change in requirements is a competitive advantage!”
  • The real measure of success for a project should be “did we provide value?” not “are we on time and on budget”
  • Adaptive Planning
  • Continuous, small cycle plan-execute-plan
  • Does not require stable requirements
  • Does require an evolutionary design – a design that is easily changeable


  • See Fred Taylor
  • Case study – IBM – success in a project is directly related to the effectiveness of the team and its members, not any particular process


  • team should continually change process, to find needs

Continuous Integration

  • Integration is hard, so we don’t do it often
  • Feature branches cause large merges
  • Merge tools have been created to help alleviate this
  • Textual vs. Semantic merge problems
  • Textual problems solved with tools
  • Semantic problems addressed with proper testing
  • See Pain Curve
  • If something is painful to do, we should do it more often
  • Continuous Integration
  • integrate into mainline once per day
  • no big scary merges
  • identify clashes early – clash = conflicting change in shared code

Continuous Delivery

  • continually deliver product to production environment
  • use a build pipeline
  • put code into production every day
  • ThoughtWorks Go -> manages build pipelines


  • “Less effort spent on quality to get in more features”
  • Tradable Quality
  • External vs. Internal Quality
  • External = sexy UI, few defects
  • Internal = good modular design, maintainability

Technical Debt

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply