Users want technology predictability
The user wants to control far more than the budget. Stress levels rise if the software doesn't solve the business need. "Scope used to be defined at the beginning of the project, so one knew what would come out at the end of this thing. Now we tell them that we make it up as we go," says Thomas Kutschi, a senior manager at Infonova, an Austrian vendor of a telecom business support system platform.
There are reasonable technical issues that a wholly iterative approach may not address, Kutschi points out. "Agile methodologies leave out huge areas a CTO would be concerned about. How do you ensure that the architecture scales? How do you balance maintenance versus new features (especially in phased deployments)?" Drafting an extensive, detailed requirements document might reveal traps that would appear in an Agile project at a very late stage.
But the solutions to users' need for predictability can bring new challenges for all concerned.
Detailed designs and planning done prior to a project seems to provide a "safety net" to business sponsors, says Semeniuk. "By providing a Big Design Up Front you are pacifying this request by giving them a best guess based on what you know at that time -- which is at best partial or incorrect in the first place." The danger, he cautions, is when Big Design becomes Big Commitment -- as sometimes business sponsors see this plan as something that needs to be tracked against. "The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.
Or as Tomasz Smykowski, CEO of Social Media Marketing Agency Websoul in Bydgoszcz, Poland says succinctly: "Agile gives you the ability to make temporary solutions that will eventually be the final ones."
You say iterative, they say disorganized and never-ending
Early in Agile's history, says Semeniuk, many shops saw Agile as an excuse for development teams to avoid providing estimates, documentation, and plans. Things are far better, nowadays, but I'd argue that these bad reputations lurk far longer than we prefer -- even in the development community itself.
For example, what you see as flexible and responsive your users may see as disorganized. Anne Shroeder, the owner of Language Works, a web development company in Maryland, has 17 years of web development experience. She's been frustrated by her Agile experiences -- and so have her clients. "There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process."
"Businesses might be anxious that constant iteration = never-ending," says Josh Oakhurst, from Skookum Digital Works. Sure, to an educated client, "open-ended" is an advantage, with flexibility that can be celebrated. But most clients just want to know what they're buying, he says. "With Agile, software developers are selling a process, not a product."
"For clients without a defined budget, transparency is key," Oakhurst says. "Two or three sprints are planned out in advance (with room to slot in features/fixes of course), and the client has control of the throttle to tell us how far to go or when to stop."
The message, especially for clients with a finite budget (but big wants), is that Agile development puts them in charge of feature requests. "If their eyes are bigger than their mouth, they get to be the one to decide which features are must-have," Oakhurst adds.
Sometimes that "Agile means disorganization" mindset encourages users and clients to interpret the process as "It's okay to be capricious." Yes, Agile does permit users to swap priorities even towards the end of a big project. But developer Sorin Costea observed the downside when things worked smoothly: "These users could not believe there are also limits to the delivery power. They could not really grasp velocity or timeboxing, but expected to throw in stories any moment and also get them in time." With the reasoning that, "Hey, we are Agile aren't we?"
The "obvious" solution -- easier to say than to implement -- is that all the stakeholders need to understand one another's needs. Perhaps more pragmatically, Semeniuk suggests: Allow users to change their minds, he says, but also make it clear what impact this has.