Some users are overwhelmed at how collaborative and interactive Agile projects are, Semeniuk says. They have jobs to do as well. Your user may be apprehensive, worrying about the increased workload from his project involvement. "This is a very valid scenario, and the only consolation is that investment during development will save them a lot of pain as a result," Semeniuk advises.
Agile requires a shift of process and relationships. "We are taking people from different generations, genders, races, and backgrounds and changing how they do what they do day to day. We are asking them, at times, to step outside their comfort zone and communicate in ways many are not accustomed to... especially in IT," says Agile trainer Robert Woods. Users now are being asked to collaborate with a developer who can sometimes have zero communication skills. (Not that you know anyone who fits that description.) "They try to give input but it's not listened to," says Woods. "They are asked to review and prioritize a backlog but 'What the heck is a backlog?'"
Agile "failures" or "lack of understanding" may not be the user's fault, but rather a response to their business environment. For example, I've spoken with corporate users who kept trying to shoe-horn more and more functionality into an initial iteration. That sounds like they didn't grok what "iteration" means, when in reality it was a response to their own corporate culture: The users knew full well that the funding would go away after the "first phase," with excuses like, "We'll do that in phase 2, next spring," when history demonstrated that phase 2 never does get funded. The developers move onto some other project and the users never get that must-have requirement.
Know your stakeholders
Another problem can arise when developers incorrectly identify stakeholders. They interview the department managers, who might care about things like reporting and dashboards, but the developers never have the opportunity to talk to the day-to-day users -- say, payroll clerks -- who might have reasonable requests to improve the data entry process. To those people, "Agile" is just another way to ignore their needs while claiming that the process is to serve them. The solution here for Agile developers: Make sure you talk to all the stakeholders, not just the ones who claim to represent their needs. Though this, too, is harder than it initially appears, since it's the managers who sign consulting agreements and paychecks, and they know what the payroll clerks need. Sure they do.
But beware: Some stakeholders do lose their power, Kutschi points out. "Very technical project managers might not like watching a daily stand-up meeting in complete quietness until being asked a question. Or leaving implementation decisions to the developers."
Recognize that change isn't easy
Don't ask for overnight success. It may be necessary to adopt Agile techniques gradually. "Organizations have to recognize Agile requires change, often a cultural one," says Mike Mikuta, VP of Technology Strategy at Dynamics Research Corporation. "Change makes people anxious, therefore organizations should look to implement Agile techniques incrementally, in adaptable chunks, prove success and expand."
Developers have an advantage in that they understand the need to change and the benefits to be gained by it. "Software projects are almost impossible to predict anyways, so it's folly to think that the traditional approach doesn't leave much to fate. In Agile, we just accept that fact and face it head-on," says Hecker. "With enough examples, anxious clients will see that even though they don't know exactly how the project is going to unfold they will always be in the driver's seat and can make decisions along the way. At least, most anxious clients will learn that; Agile development isn't for everyone!"