The ideas behind agile development methodologies are not new. They were more formally stated in The Agile Manifesto. The ideas behind more basic iterative development are even older, and have their own trade-offs. Both contain the idea that you can not know everything upfront. The agile methodology states this idea explicitely:
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Iterative, on the other hand, allows for change between iterations, though not within them in any meaningful fashion. Each has it’s advantages, and largely they are cultural differences. Some organizations simply aren’t capable of one or the other, and that’s OK.
The project I’m working on now is attempting to be iterative. We are trying very hard to be iterative, but the difficulty is that the client is absolutely insistent that we define every single requirement up front before we do anything. For example, we are developing use cases to document the external actor’s interactions with the system. A simple enough idea, and one that is very useful in a large system such as this. The problem is two-fold however. First, we are expected to complete the use case in one iteration and never touch it again. Touching it again requires a contract change. Brilliant. Equally bad, but more subtly so, is the fact that there is entirely too much detail in the use cases.
To me, use cases represent value when they “tell a story” about how an actor (user) interacts with the system. They are told clearly from the actor’s perspective, and discuss how the actor accomplishes their goal, but not how the system works underneath. Unfortunately, here we are putting in detailed entities, attributes and service (SOA) calls that will be considered part of the contract. This makes it nearly impossible to “do the right thing” when the time comes, and forces an inordinant amount of design detail into a period of time where not enough information exists to make the decision.
In the end, it feels like a waterfall process, but with useless labels applied. You can pretend it’s “agile”, or it’s “iterative”, but when the client looks at you in a meeting, and with a straight face and no sense of irony says: “This project is too big to be agile” you know something is going to go terribly wrong. The larger the project, the more important it is to be agile and adaptive. The scope is entirely too big to ever know everything up front. When they say they want to define every single requirement before beginning the design, and will not allow revisiting of the requirements, you know it’s going to be a long uphill battle.
There has to be a better way. I’m no Martin Fowler, but this just doesn’t feel like a good idea.
Tagged: agile, iterative, methodology, waterfall