I've received a deep-hearted comment to this article (in Italian) from a former collegue. The project estimation process pointed out that "changing requirements" were the most dangerous risk factor for a software project. Even if I proclaim myself an "agilist", which means I should "embrace change", the temptation to "fix the requirements" is still there. Two main reasons for that:
- You've gotta start from somewhere
- Most of the contracts are structured on a fixed price basis, which can be accommodated by change request, but the base price is crucial.
Agile philosophy states some principles. Fixed requirements are utopia: external situations evolve, and more than everything else, stakeholders learn something more about what they want as long as you show them some progress. It's not that change is more efficient than fixed requirements. In some cases, if your requirements are stable (which means you made a pretty good job in the gathering phase) a waterfall might even be more efficient, but if something changes – and 99% of the times it does – you're screwed.
Knowing him, and having been working in the same context he was, I knew that his temptation to fix the requirements was not a "waterfall revenge", but something else. In many projects, especially in the public sector, the initial requirements are not evolving during the life of the project. They're just wrong. They're written by the wrong people, with a wrong goal in mind. Still they're written, ant there's a contract based upon them.
It's easy to smell a situation like this: try asking for a real user (something really XP)… I've been answered: "You can't meet the user". Reasons may vary: "there are too many", "they don't agree with the management" (I bet so), "it's a waste of time", "they have different opinions" (this is interesting), but basically the case is that who is paying is not who needs the software. And who wrote the requirements is often none of the two.
It's interesting to note that an agile process helps dealing with this situation: every agile process eagerly seeks for real feedback. If you have a fake requirements writer, you have to start asking him questions about the application. I mean …a lot of questions. In this case there are probably two options: one is not answering, but the contract should say somewhere that some support might be given; the other one is finding somebody that can provide the answers. They might be surprising, but early surprises are better than last-minute ones.
