Most software developers I know really like Agile. There are a lot of advantages: The iterative process gives developers confidence that the application reflects the users' needs and wants; by tackling one thing at a time, you can make one thing work -- and get feedback on it -- before going on to the next; if something big comes up in one iteration, you can address it before it turns into a hairball. Plus, for consultants, iteration implies milestones that can be billed on completion, so you find out about a deadbeat client sooner rather than later. I bet you can add to this list.
Clients and users, however... not so much. Users have their own concerns -- and sometimes Agile developers don't recognize them.
If you truly want to build quality software that reflects users' needs (as well as their desires), it behooves you to learn from people who have gained wisdom the hard way. Here's their advice.
[ What's wrong with agile development: Culture, people top the list ]
Users want budget predictability
Most non-computer businesspeople are already intimidated by spending money on something they don't understand. They have to report to someone who wants an answer to, "When will this be ready, and what budget do we need to allocate? And incidentally, if it's late, it's your job on the line."
Agile requires a huge leap of faith for clients used to hard budgets and fixed bids, says Dave Hecker, who owns Sagewing, an Agile development software consulting business in Colorado. "Clients ask, 'How much will it cost?'" says Hecker. An Agile-style answer is frustratingly ambiguous, he points out, along the lines of, "We think we can do it as described in about two months plus one month of bug-fixing so that's about three months unless we choose to make refinements and improve the product along the way, in which case it will be longer."
"Then the client responds, 'Umm… but, how much will it cost?' and I begin to hear the anxiety in their voice," says Hecker. "They wanted a crystal clear answer to a seemingly simple question, but it's hard to supply that answer because Agile projects are always a shifting sand."
Underlying that uncertainty is a trust issue. If the user has worked with a developer for years who reliably delivers what's promised, it's easier to agree to more flexible targeting. But if you don't know each other, that's not quite so easy.
"The less trust a customer has with you, the more they want to have a plan up front and hold you to that plan," says Joel Semeniuk, EVP at software tools provider Telerik. "As you gain that trust, this need goes away and you can begin being more Agile."
Earn trust incrementally, Semeniuk suggests. For example, never under deliver on an iteration; always meet expectations.
One answer to the "What will it cost?" nervousness is to suggest fixed-cost and fixed-duration projects. What can be accomplished with that time-and-money might vary, but users get some predictability.
Hecker has another technique to help clients work through this anxiety. He explains that although the user won't get a hard date for a specific deliverable, the developer will provide ongoing updates about what is to come, and those updates become more accurate as the project goes on. Then, he says, "I give examples until they start to get it (hopefully)."
For example, four weeks into a 12-week project Hecker might tell a client, "We are 99% confident we'll hit all your phase 1 requirements by week 8, so we should plan to start bug testing and polishing on week 9. We might be able to slip a few more features in if things go well!" A few weeks later, at week 9: "The bug testing is going great. We have some extra time to add a few more (not too complex) features. Which would you like to consider?" The update is transparent when things don't go quite so well, too. Hecker might have to say, "The integration with [some API] has turned out to be rather unstable and it's eating a lot of time. With only 6 weeks left, we should consider dropping a few features if we want to safely release on time. Or, we could extend the schedule by two weeks to accommodate everything."
In both these cases, you notice, the user is in control of the software, the schedule, and the budget consequences.