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.
Alberto, you are spot on here. In my company we have to choose the position on the sliding scale from "start coding while I go ask them what they want" to "we don't budge until I have 8 kilos of requirements". Much depends on the kind of customer and the kind of contract. Because we typically do fixed price contracts for large organizations that are geared for fully agile engagements, we have to be take a reasonable approach to up front requirements.
ReplyDeleteI think the correct approach has always been that requirements must be 'good enough', but the interpretation of 'enough' can vary widely. When there are a few million on the table, 'good enough' needs to be 'bloody good', for the sake of both parties to the contract.
Hi Brendan,
ReplyDeleteOne of the keys to agile practices success is trust. Once your stakeholder trusts you, you can also show him that the newly discovered requirement B provides more business value than requirement A. You also discovered this earlier than he thought, so you're both happy with this. As a project manager you can work to increase trust towards the team. What's a lot more difficult is establish trust relations between the various faces of the customer itself.
A small customer is often a piece of cake in this sense. Once you start to know him and vice versa, planning new features just goes along. Most difficult customers have been large and scattered organizations where the one who paid was not the one who used the software. After a while we realized that there hasn't been a requirements gathering phase but just a requirements definition, and no active communication channel between users and official stakeholder (before releasing, of course, after releasing the blame was ready... ;-) ). So we had real requirements from somebody that was not allowed to be a stakeholder, and signed off requirements that were completely useless.
Often, what we end up doing is a small cheating, meaning that we try to establish unofficial feedback channels with some real users to try to deliver something useful and not only signed off.