One of the greatest advantages of Agile is the ability to release early and often. It stands in stark contrast to the waterfall approach where you finally deliver at the very end if you deliver at all.
Though ROI is notoriously difficult to calculate with many IT software projects, releasing as soon as you have customer value dramatically shortens the payback period for your effort. So even given a project where the expected ROI is pretty much a guess by the sales team delivering some of the necessary functionality in the first few months is a big win. And despite the negative aspects delivering failing faster on a product thats going to go nowhere is also quite a benefit in reducing waste.
A subtle effect involves the ability to deliver much closer to the just enough target. If you release a product and find that it pretty much meets the needs of the customer base, then maybe you end up leaving out that long product backlog. This avoids building a lot of functionality that will never be used. It also makes maintenance and future enhancements easier because the base product is simpler.
With all of these obvious selling point it can still be a very difficult sell inside many organizations. The problem stems from a general lack of trust from customers. They have been involved in a contractual battle for years even with their own IT department. It works something like this:
- Customer: We have this great idea for this new CRM product.
- IT: OK, well just get the requirements together and signed off and we’ll build exactly what you want, but it may take a while.
- Customer: No problem, we’ll put everything in so we don’t have to do change requests. I hate change requests.
- IT: That’s good, but remember we need to control the scope. You know it costs 10x as much to change a system after you start coding, so it really helps to have the requirements fully defined. Give us a really good spec and we can produce miracles.
- Customer: This is great so we can launch this in 6 months.
The unsaid part is that the customer is tossing in everything they might need in the future. If you know you have to wait a long time to get a new system, you have to protect yourself by asking for everything you might want even if you’re pretty sure many of them won’t turn out to be necessary. You really want to avoid the change control process.
IT on the other hand knows the customer will never define the requirements well enough because they never know what they want. They’ll produce some crappy wishlist with a lot of ‘system shalls’ and then we’ll have to be forced into a change control process.
This is a recipe for failure and both sides know it, but it continues because sometimes its hard to imagine something outside of the waterfall. Both sides have long since stopped questioning the value of heavy documentation. (Just yesterday I had a brief conversation with an analyst about what they were working on. They explained for a very small change to an existing product they were writing a 44 page requirements document. I exclaimed about how this seemed like an awful lot, and they just sighed and said “we’ll it’s not so bad, a lot of it is screenshots.” The worst part was the code had already been done and was ready to be QAed, so the document itself has almost no value.)