Scott Ambler delivered the keynote at Agile Tour Toronto 2009. I could have sworn I have met him before, but I’m not sure anymore. He is, umm, unique it seems and I think I would have remembered it clearer. Scott is the Practice Leader Agile Development at IBM and it would seem that his views are, not unsurprising, widely tainted by the size of customer IBM Consulting attracts. I’m also not sure where he fits into the political structure of Agile; he seemed rather anti / bitter / pissed at a number of people in the community at large. But I might be the only one who interpreted it that way and perhaps he was striking his tone to help reinforce his points of the talk.

  • We don’t know what the laws of IT physics are, but they haven’t changed
  • Agile Scaling Model
    1. Core Agile Development – construction focused, small teams with a straight-forward systems
    2. Disciplined Agile Development – full lifecycle from conception to release, retire risks early, self-organization with adult supervision
    3. Agility at Scale – one or more scaling factors are being controlled
  • That stack of requirements have come from somewhere — up front modeling and planning
  • Scaling Factors (All are a scale, not binary. Easy to hard.)
    • Geographic distribution
    • Team size
    • Compliance requirements
    • Domain complexity
    • Organization distribution
    • Technically complex
    • Organizational complexity
    • Enterprise discipline
  • Agile teams are good at delivering high-quality siloed applications
  • Traditional teams are good at delivering low-quality siloed applications
  • Different teams/projects are at different places, so how can you have a repeatable process across all of them.
  • Repeatable results beat repeatable process every time
  • Scott’s theory: Agile scales better than traditional and we are only 5 – 10 years away from having hard evidence to back t up
  • In distributed Agile, don’t use colocated team tools
  • Agile needs to ‘grow up’ – his survey number show less than 50% of teams are working with legacy data. The implication being that they are building new silos
  • In meetings, focus on the value aspect rather than the status
  • If there are technical dependencies, there are functional dependencies
  • Our tools should generate the metrics we need
  • Bureaucracy is bureaucracy. AUtomate the heck out of it to get accurate and timely results
  • Part of failing early is to do the risky parts first