Why Your Users Hate Agile

Esther Schindler writes "What developers see as iterative and flexible, users see as disorganized and never-ending. This article discusses how some experienced developers have changed that perception. '... 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.' The premise here is not that Agile sucks — quite to the contrary — but that developers have to understand how Agile processes can make users anxious, and learn to respond to those fears. Not all those answers are foolproof. For example: '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.' How do you respond to user anxiety from Agile processes?"

Comments

doesn't work

[nten]

"Proper software engineering" doesn't work. Code that actually does work is invariably ugly and violates any best practices you can possibly imagine. Code that follows those best practices and whatever the current paradigm fad is, are over budget, over schedule, and even though they incorporate all the correct patterns for abstraction and maintainability, this results in such a huge volume of excess sloc, that it is less maintainable as a function of sheer size. You don't need process or patterns, or even documentation (though it would be nice). The only thing you need are good engineers that actually communicate with each other, and if you don't have that, then no amount of process or patterns or paradigms or practices can save you. I should note however, that if you just want to generate billable hours then you absolutely want every last one of those Ps and mediocre (but not bad) engineers.