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.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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 firstname.lastname@example.org.