The fallacy of the Waterfall anti-model
Not so long ago I realised how many of the agile characterisations done by opposing Agile and Waterfall do not apply in my experience. In other words I have never encountered a waterfall development management process. What I have seen is plenty of ad-hoc processes derived from the vague knowledge that in a project you have requirements, developments and tests in that order. These activities apply under Agile methods as well.
In my experience (other experiences may vary…) the opposition is really between Agile (a well documented set of self reinforcing principles and practices) and the processes that managers have been empirically evolving for years after possibly learned from their mentors. It is much harder to make these people abandon their home grown methodology and do a leap of faith. It is much easier to help them evolve it by teaching things from the Agile toolbox, from engineering practices (TDD, CI) to useful metrics (Work in progress, inventory) to practices (Stand ups, retrospectives). Many of these tools have measurable positive returns and some are a small evolution from the existing ad-hoc practice.
The deadly poison here is to attach those tools to a specific methodology, unless the managerial hierarchy itself is pushing it (à la salesforce.com). A formal checklist of what is needed before a project can be called agile feels like a bad idea. We should instead thrive to put in place a well chosen set of the proven tools that Agile helped popularise. That will bring immediate benefits without a leap of faith. You may not be Agile in the end but you, your team and your customers will be happier.
