In my (albeit limited) experience, failures attributed to development processes – be it Agile, XP, DSDM, Waterfall or whatever – fall into two groups. Firstly, that those involved assume the process itself can succeed without making it work – that because there is a process, you don’t have to be organized, disciplined or put the effort in. Secondly, that people abdicate the responsibility of thinking in favor of the process itself – that is to say that they blindly follow a particular process without at any stage engaging their brains. To paraphrase Douglas Bader – “rules are there for the guidance of the wise and the obedience of fools”.

A tool which seems to help the process along – that makes it easier to manage, keep disciplined and track, appears to help us avoid that first category of failure. The problem is when these software tools become too prescriptive, is that they limit the ability of the team to adapt to adapt the development process to a given context. The process stops being what is needed to deliver, and starts being what the tool will allow.

To borrow an example from nature, those species which are generalists will thrive in many areas, but rarely dominate any particular niche. Species which have evolved to take full advantage of a specific environment can dominate that environment, but are ultimately vulnerability to change. If their environment changes quicker than they can adapt, they become extinct. Think of the tools you use everyday – email, spreadsheets, instant messengers, even tools like MS Project. All of them are useful, but what they do is incredibly generic, and as such they can be used in more situations. The temptation is to specialize a tool to gain more and more benefit from its use in a given environment – but just as in nature, specialized tools might work fantastically for a specific context, but if the context changes the tools can become useless.