In a number of posts over the last few months, Glen Alleman (Herding Cats) has been saying that Agile comparisons to “waterfall” or “predictive” are bogus, because the practices that they compare themselves to are simply BAD practices or anti-patterns in the domain of project management.
While I don’t disagree with Glen in the slightest, I want to start an argument about it. Just because they are bad practices, doesn’t mean they aren’t prevalent. There are many organizations with a software development life cycle (SDLC) that is waterfall-ish. And there are many organizations that have responded to regulations (Sarbanes-Oxley) by increasing the documentation requirements without thought to impact on software productivity or quality, that have effectively polluted their software development lifecycle with audit/regulatory oriented policies.
There are thousands of PMP certified morons who do not know (in practice) how to measure a project using any other tool than a gantt chart and a ruler. There are many software development managers who use project plans and process gates to indemnify themselves when things go wrong, who think that by mandating that requirements be “signed off” and requiring “change control” that they are immune to needing to deliver anything more than the minimum specified in the requirements.
There are thousands of software practitioners who have refused to give reasonable estimates because those estimates have been repeatedly weaponized by managers. (If I give you a stick and you hit me with it, next time I won’t give you the stick, or at least will wrap lots of padding around the it.) Many organizations have used “process” as an excuse to move much of the coding work “offshore” leaving ex-developers onshore in unacustomed roles as liasons, managers, project managers, analysts, and testers. They have imposed “process” in order to get work to “cheaper” resources, but have not invested in process maturity.
The thing about agile is that it appears to ALL to be a game changer. It makes it easy for us to drop all our anti-patterns at once. While I recognize that Glen is right – the dumb things that agilists say are similar to the dumb things that born again Christians say (“I don’t know how I would make it through the day with out Jeeesus.”) Agilist are often like ex-smokers – they can’t stop telling you how great they feel since they quit. Yeah – alot of the claims are based on comparisons to bad practices and known anti-patterns.
So Glen, to riff an old joke – why is using enterprise project management anti-patterns like hitting yourself in the head with a ball-peen hammer? Because it feels so good when I stop.
When your experience as a developer or project manager is fraught with project management anti-patterns, and you are a couple of pay-grades below the decision makers who are instituting said anti-patterns, what are your options?
a) Tell senior management that they don’t know their project management keister from a hole in the wall?
b) Find a new job at a better firm (oh wait – that assumes that there really is a better firm…)
c) Find some industry literature that shows a better way – a way that without faulting the folks who instituted the anti-patterns, can be adopted in small doses. A way that tries to put all members of a software development team on equal footing, creating collaborative realtionships rather than emnity.
So in the Dilbert world that most software projects are found in, – option C sounds like a huge winner. You really can’t fault the agilists whose primary exposure to project management practices has been in these environments from making those comparisons – that is their reality.