Pig, satisfied

a blog belonging to Ben Butler-Cole

Why Software Development Methodologies Rock

(This post was insprired by a sneak preview of a blog post by Jez Humble.)

Methodologies or other defined practices can have value in so far as they cause people to reflect on and criticise what they are doing. Often it’s the adoption of a new approach that brings benefits, rather than the approach itself.

This is why consultants are all convinced that their approach is the one-true-way. They tend to meet teams that have stopped reflecting and so are in trouble. They introduce change and see that everything magically starts to improve. A spot of attributional bias and they’re convinced.

The subjects of their advice, however, see that things get worse again after a while (because they’ve stopped reflecting). So they conclude that methodology X is all very well, but in practice it doesn’t work in the long term.

It takes a special kind of person and team to keep reflecting even when there is no change agent. People who can do this without any prompting are gold dust and don’t need a methodology. People who can nearly do it benefit from any methodology that they can be convinced by, because the existence of an ideal keeps them thinking about how they are deviating from it (and it’s the thinking that matters, not the extent of the deviation).

My experience has informed my opinion. My first job was for a small software shop that followed a rigorous waterfall approach: strong hierarchy, lots of documentation, estimation-by-loc-guessing, separate development phases. They were extremely successful and repeatedly delivered on-time and within-budget; I was miserable. My second job was as a consultant (with ThoughtWorks).