Software Quality Insights

May 21 2009   1:53PM GMT

Why waterfall developers still shun Agile

Jan Stafford Jan Stafford Profile: Jan Stafford

Tags:

Jon Kern, co-author of the Agile Manifesto, told me recently that many companies won’t adopt the agile development methodology soon. Why? Some companies are doing just fine with waterfall, he said, because it has worked in the past and is still working. Also, they see little chance that their business analysts and leaders will agree to get involved in the development process.

Intrigued by Kern’s assessment, I asked some software development and testing veterans for their views. I asked about their work with and opinions on why companies stick with waterfall development.

It’s true that waterfall methodologies can work quite well, said Mike Kelly, a software testing and development consultant and a fan of the agile methodology.

“I know this will surprise some people, but I’ve worked on several successful waterfall projects,” Kelly said. “It’s crazy, I know. Seriously, I’ve been a member of teams that do roughly the same thing, with minor variation, again and again. The business context is well understood, the requirements are mostly right upfront, and the team kind knows what needs to be done to be successful. If it’s working, it might not make sense to change it.”

Bernard Golden — CEO of IT infrastructure consulting firm, HyperStratus – has worked with development teams that don’t think the agile methodology can be effective in large-scale, enterprise projects. They think that agile is a good micro practice that should live within a good macro project management/planning process. To an extent, he agrees, and thinks agile is “best suited for scoped projects that have small user populations — built on top of robust system infrastructures built as traditional projects.”

Golden is also doubtful that having a “business person be part of the development process ensures that systems will achieve user satisfaction.” Thinking that “one guy can subsume all end user viewpoints and prevent end user political unhappiness strikes me as quite naive about the way organizations works.”

In this short video clip, Golden explains more about why agile may not stack up.

Kelly has also worked on projects where business managers just didn’t want to do more than turn in a list of requirements. “The business [people] didn’t get into business to talk about development methodologies, and to them, it’s often a distraction,” he said.

Requirements analysis expert Robin Goldsmith believes business managers don’t believe that doing systems work is their job.

“Agile is very much driven from a programmer’s perspective, and business folks don’t identify, understand, or agree with it,” said Goldsmith, president of the consultancy, Go Pro Management Inc. “ As an analogy, I have many years of experience working in the most technical of programming roles within IT; but these days I have no interest in fooling around with software internals—I just want stuff to work, and that’s not unreasonable.”

Goldsmith sees the agile-versus-waterfall debate as the subtext behind a larger business-versus-IT cultural issue that causes continual problems for software projects.

Do you agree? I’ll be continuing this discussion with software testing and development experts, and your input would be very valuable. You can share your experiences and views by commenting below or writing to me at jstafford@techtarget.com.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: