I read a bunch of project management blogs - they (almost) all take agile approaches as read. I'd hoped this meant that everyone now understands that agile methodologies give better results than waterfall with lower risk. But maybe agile types are more likely to blog. Or maybe I'm just selecting content that I already agree with.
Last week I was handed a project spec to read that was decomposed into 4 themes:
- Integrate the microsite fully into our website's strategic architecture
- Do some interesting archive exploration work
- Do some more really flashy archive exploration work
- Add some really really flashy UGC and social network features
This is intended to go a number of agencies to tender for lots and lots of money. There's something wrong with this picture.
What's the problem?
You don't need to know the project or the host site to see that this spec is looking to deploy rather more than the Minimum Viable Product. We're probably not in a position to go live with a beta, and we're commissioning this site from an agency so we can't launch then keep releasing new features. That pushes the boat out, but this spec is clearly well beyond the MVP even under our circumstances.
The risks are familiar:
- Less likely to have a complete release on time
- More likely to incur poorly controlled changes and change-request costs
If we reduce the scope to parts 1. and 2. we can deliver a really great site, using an agile approach, and consider further down the line whether the site needs these particular fancy features or if something else would work better.
Retaining parts 3. and 4. automatically means Big Design Up Front, with complex features planned before basic ones have even been delivered.
Who thinks this is a good idea?
In a word, clients. They still seem to think if they specify the solution up-front they can get exactly what they're asking for.
This is a slightly separate problem from their thinking they're in a good position to specify solutions. A client may well take my advice that "we can't offer you this (at acceptable cost / within the timescale / without breaking the laws of physics) but we can offer that instead". But either way they think we can and should promise something specific. Six months before we code it.
I think the problem's one of education. I've seen scads of books, seminars and websites extolling the virtues of agile, all aimed at technologists. I doubt anyone's ever even explained to my project stakeholder what the difference is, much less why one might be better than the other.
I guess I'd better start educating them!
And then there are the agencies...
True coincidence - the very same day I read this spec I bumped into a non-technical friend who had just been commissioning a new website for his charity. All specified up-front, waterfall all the way. I told him the agency are going to murder his budget on the change requests. He already knows their change-request charges are high.
We know there are some agencies who want to write valuable software well and who battle to educate their clients and exercise agile methodologies.
I'm sure there are many more who'd like to do so, but find it easier to sell work with a waterfall plan.
And I'm just as certain that there are plenty of black-hat agencies who strategically promote waterfall plans to their clients and extract high change costs. Frankly they give our professions a bad name.