Scott Ambler on Agile

04 Apr
April 4, 2009

scottamblerScott Ambler talking in Cape Town. For free! One of the Agile thought leaders, now working at IBM Rational. Also a notorious Scrum maligner. I had to go. If only to be equipped to do damage control. So I pitched up with as open a mind as any Scrum Coach and Trainer could…

After coffee and muffins, nearly 200 people filled the small Sports Science auditorium. Scott gave a discursive and entertaining three-hour talk that spanned a number of threads. His blunt style evoked laughter as the audience identified with many of his observations. Here are some of the things I heard him say – I think.

Myths and Facts

  • Software development is an art rather than science with people rather than technology at its core.
  • IT organisations all over the world are messed up in more-or-less the same ways; all making the same mistakes, due to all basing their way of working on the same set of false premises.
  • They discover a problem, put a band-aid over it, discover another problem, fit another band aid and so on. Nothing actually gets fixed.
  • Traditional project management is based on lying, and stakeholders know this.
  • Earned value management is another lie – there is no value until the software is delivered. It is just not the right metric.
  • The US has a $600 billion data quality problem. And it’s not getting smaller.
  • We (IT) are not professionals – we don’t get respect from anybody.
  • Most organisations choose to fail – it’s more comfortable to fail in familiar ways than to succeed in unfamiliar ways.
  • Project retrospectives don’t work – the lessons ‘learned’ are not put into practice, because the project has ended and there is no longer motivation to do so.
  • Doing things against natural human behaviour will always fail.
  • Every hand-off is a risk and a point at which defects are introduced.
  • Media richness theory tells us that the best way to communicate is face-to-face and the worst is via written documents.
  • Change management is a euphemism for change prevention and is unethical.
  • Logged defects older than a year are waste and should be deleted.
  • The most valuable artefact to Agile developers is working software; the least valuable is Gantt charts.
  • There is no statistical difference between the success of projects in organisations who implement the CMMI and those who don’t, whether Agile or not. There is a significant difference in success between Agile and not.
  • Collocated Agile teams report a 79% project success rate compared with 73% who are “near located” and only 55% who are “far located” (requires air travel).
  • Collocation results in increased job satisfaction.
  • Near location often needs only a “decorating decision” to save 6% and payback is achieved in one week!
  • Regarding distributed teams: (1) don’t; (2) observe Conway’s Law – distribute in relation to your architecture; and (3) use appropriate tools and techniques.
  • Most distributed development is based on a lack of trust.
  • Beware of off-shoring: if you’re failing now to manage your own people locally, there is no chance you will succeed in managing people off-shore.
  • Fire the evil bastards who hang art on the wall in your IT department! Fill all walls with white boards or whote board wallpaper.
  • A repeatable process in software development is nonsense. In every instance there will be changes for scaling, distribution, domain, people, …
  • The bureaucrats are out of control…and so are the HR people!
  • You can change your organisation [fix it] or you can change your organisation [move to another]!
  • Lean (“optimise the whole”) helps explain why Agile works
  • Two-thirds of software features built are rarely or never used (Standish report) – so don’t build them! The product backlog addresses the risk of building the wrong things.
  • Business wants estimates in order to manage financial risk. Agile makes this unnecessary – we only have to fund one iteration (at a time).
  • The iron triangle – one of scope, schedule and cost has to be variable; if you fix all three vertices, quality becomes the undesired variable.
  • Traditional development is gambling! We need to remind management that they got burned in the past and there is (now) a better way.
  • Fixed price work is unethical. As wannabe professionals we need to stand up to the bureaucratic treadmill.
  • Every developer should attend a two-day “introduction to usability” course. And an “introduction to security” course.
  • There are simple ways to refactor databases – to learn how, buy Scott’s book!

Call to Action

Scott made a clear call to action amongst IT and business managers in organisations:

  1. Start experimenting with Agile. This is the easiest decision in decades for management to make! There is a very big upside with very little downside.
  2. Train your people.
  3. Get some help (coaching).

Despite his sniping at Scrum, I was pleasantly surprised at the sense he made. And I hope local organisations heed his call – my phone should ring off the hook on Monday…

Other blog Posts written by: Peter Hundermark

Tags: , ,
9 replies
  1. Kevin Trethewey says:

    I also went to his talk (in JHB) with a fairly defensive mindset, even feeling the need to prep some of the people I knew were going to be there not to take him at face value (pro vendor, anti true agile).

    I was also mostly pleasantly surprised – in person and in context he is not nearly as confrontational and petulant as he has come across in the audio I have heard him in previously.

    The swipes he took at SCRUM were fairly valid IMHO – specifically that you can’t become a master of anything in a two day course*.

    I did find the constant ibm/rup salesmanship a little disingenuous though and felt it shook his credibility badly.

    * Having attended your CSM course I found excellent and chock full of real value, but certainly wouldn’t call myself a MASTER scrum master afterwards.

  2. Richard Bailey says:

    I attended Scott’s talk in Cape Town and I thought he had an excellent way of summarising the call to arms for Agile in general. Your summary of what he says about the “lies” we have been saddled with in software development are very true.
    We have to stop lying to our stake-holders about expectation and agile addresses that in many ways.
    I thought his approach to scaling agile was very mature – start somewhere small and grow.
    Being quite new to Scrum, I was not particuarly defensive, but I thought his comments on Scrum were insightful and pragmatic – it is a piece of the Agile puzzle, not the silver bullet.

  3. Scott Ambler says:

    Looks like a pretty good summary, although there’s a few miscommunications:
    1. Software development is mostly an art, but there is some science involved.
    2. There’s a lot of lying going on with traditional approaches to project management — they’ll often pad estimates, go into a project knowing that they’ll most likely have to cut scope or ask for more time & money regardless of what they committed to, will force a “change prevention” strategy on stakeholders, and so on. This stuff has been going on for so long many PMs think that it’s best practice.
    3. Traditional projects don’t produce real value until the end of the project, agile ones do it throughout (huge difference).
    4. Project post-mortems don’t work well because people aren’t motivated to change their behavior after the project has ended. Retrospective throughout the project can work very well.
    5. “Change management” on traditional projects is a euphenism for change prevention.
    6. The DDJ 2007 Agile Adoption survey looked at 19 different artifacts. The most valuable to agile teams in that survey was working software and source code (it was a tie) and the least valueable detailed gantt charts. There may be other less valuable artifacts that we didn’t ask about.
    7. The payback from moving from being near located to co-located will vary based on the situation. I was recently in one or where it payed off in a week, but YMMV.
    8. Distribution results in a lower levels of trust because you don’t know the people as well as the people you interact with directly on a regular basis.
    9. Lean’s “optimizing the whole” is an important consideration for making agile work effectively. Just because you think you’re doing agile doesn’t mean that you’re optimizing the whole.
    10. Google the term “BRUF” to find an article about the wastage resulting from doing detailed up front requirements.
    11. Doing fixed-price, up front estimates is often a form of gambling, particularly on traditional projects.
    12. Fixed price approaches are unethical for IT practitioners if they don’t communicate the implications of the approach and provide viable alternatives. Google the term “fixed price unethical” for an article that I wrote on the subject.

  4. Paul Laberge says:


    Aren’t you generalizing a bit too much? This kind of comparison against an organization with no improvement program, therefore development practices that lack efficiency, seems a bit amateurish. A best practice is a best practice for any development type. BTW, The terms ‘traditional development’ seems a bit vague, doesn’t it? But then again, so does the word ‘Agile’.

Trackbacks & Pingbacks

  1. [...] Ambler, for example, considers fixed-price projects fundamentally unethical: Fixed price work is unethical. As wannabe [...]

  2. [...] Ambler beispielsweise bezeichnet Festpreis-Projekte als grundsätzlich unethisch: Fixed price work is unethical. As wannabe [...]

  3. [...] Scott Ambler did in Cape Town a few weeks ago.¬† And Scott had the courtesy of straightening out some thoughts on Peter’s blog as [...]

  4. [...] 4 April , 2009 · No Comments Peter Hundermark about Scott Amblers talk in South Africa. [...]

Comments are closed.