Stephen Freeman Rotating Header Image

December, 2007:

Potemkin Agile

I’ve been meaning to write this post for a little while and now I feel triggered by Keith Braithwaite’s especially grumpy contribution.

I’ve had a few discussions around the “Has Agile Lost Its Mojo” session, including with Keith. One person called me an elitist, which is an interesting term of disapproval around an investment bank. Clarke Ching wrote that he bailed out of the related session after five minutes because he was so upset.

First the “Mojo” session, which was intended to be a contentious topic with a cute title that would get people talking on their way to the pub. In that respect it seems to have succeeded. It was also intended to flag what looks like a shift in the community as ideas that were treated as ludicrous less than ten years ago have become accepted, and even dogma, in some communities. Is this the moment where the venture capitalists oust the founders to bring in experienced management? Maybe it is judging by the number of organisations with proper sales people who have started using Agile terminology.

It’s true, as Keith points out, that the Agile manifesto is largely platitudes—except that there are still plenty of organisations that don’t act as if it were true, particularly the one about people over process. But I claim that some of the success that Keith, Clarke, and others have been having (apart from the fact that they know what they’re doing) is because the hot-house clique (including Keith) and others went out and made it work, and generated enough noise to make terms like “incremental” acceptable in polite conversation. Very little of the kind of improvements we’re introducing today could not have been introduced before, so something must have changed. I, for one, would be sorry to see the extremists of the Agile movement wither away because, if nothing else, that’s where the ideas get to be “well-tried”. As Dave Snowden just wrote in a much heavier post than this,

Multiple small initiatives showing that there is a different way of doing things are vital, and people prepared to make sacrifices of convention to establish them are to be praised. The witness of community is a part of the history of humanity and one that continues and needs to continue today.

He also has some warnings about Model Communities, but that’s for another day.

As for the “Compromised Agility” session. Again, this was intended to be contentious. I know the presenters and they appear to have been attracting favourable attention from some very senior people at their current client because they’re offering real value instead of faffing around like their competitors. To quote from the client’s CFO, “This is the first time I’ve visited a team where everyone clearly knows exactly what’s going on in the project.” They got the job because they don’t compromise on the stuff they think is important and they managed to find a client that likes that. Is this every client in the world? No, but then it doesn’t have to be. That said, part of Simon and Gus’s point is that too many people burn out early, letting their organisation continue to haemorrhage value because they just can’t face the struggle any more.

Now to the slightly darker part of this posting. The phrase “Potemkin Agile” is a reference to the apocryphal (but untrue) story that Prince Potemkin rigged up fake villages along the Dnieper River to show Catherine II and her court how well his development of the Crimea was going.

As Agile becomes regarded as a good in itself, we should expect to see organisations claim they’ve successfully adopted Agile when the attempt is so half-baked that the result is worse than what came before. I’d include some of Clarke’s horror stories in that category. A long time ago, I went through the Total Quality training at a large corporation. There was good content in the material but most people treated it as a box-ticking exercise to be endured until they could get back to some Real Work, which took the topic right off the agenda. More recently, I’ve seen situations where hit-and-run training has left teams officially “Agile” but lost and miserable; somebody somewhere met their transitioning targets but left out the hard stuff, the follow-up and necessary structural changes. I’ve also seen projects which had all the visible characteristics of an Agile project except that the working code they delivered had no value to the company, because no-one knew what it was for. Think this is just me moaning? Here’s a paper from a respectable business school professor complaining about CIOs who measure value based on a system’s delivery not its use.

Any approach where what people do is misaligned with the organisation is compromised, whether it’s management burning value by only watching costs or technical polishing the wrong code. This begs a huge “How do we get there from here?” question which leaves plenty of room for dissensions like this.

Teaching to aspire to

I know this is the right way to teach, it’s just taking me quite a while to get there.

Stockhausen later said: “In many respects Messiaen did the opposite of what I wanted. He never tried to convince me. That made him a good teacher. He did not give instruction in composition, but showed me how he understood the music of others and how he worked himself.”

via On an Overgrown Path

Software Defect Reduction Top-Ten List

Just bumped into this paper via Kathy van Stone on the TDD list

The summary (in garish yellow and red) is:

  1. Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.
  2. About 40-50% of the effort on current software projects is spent on avoidable rework.
  3. About 80% of the avoidable rework comes from 20% of the defects.
  4. About 80% of the defects come from 20% of the modules and about half the modules are defect free.
  5. About 90% of the downtime comes from at most 10% of the defects.
  6. Peer reviews catch 60% of the defects.
  7. Perspective-based reviews catch 35% more defects than non-directed reviews.
  8. Disciplined personal practices can reduce defect introduction rates by up to 75%.
  9. All other things being equal, it costs 50% more per source instruction to develop high-dependability software products than to develop low-dependability software products. However, the investment is more than worth it if significant operations and maintenance costs are involved.
  10. About 40-50% of user programs enter use with nontrivial defects.