waterfall

Ways Agile beats waterfall development, boosts software quality

“How many of you are agile-ists?” Agile expert and author Damon Poole asked attendees this at the SPIN local user group meeting near Boston this week. Then he said: “Agile-ists look like normal people… but if you don’t believe in agile, let me assure you, there is nothing wrong with you.”

Poole gave various examples and analogies of how agile development methodology works, noting that group involvement was a key of agile success. Agile developers benefit from receiving more frequent feedback from customers and having short-term, reachable deadlines, Poole said.

“Agile versus waterfall or any other methodology can be compared to touchdowns versus yardage,” he said. “Where is the credit given? Clearly you can’t win the game based on ridiculous yardage without scoring.”

This analogy points to the major downfall of waterfall, a process in which the team scrambles in all different directions and gains some ground, but often fails to complete the project on time. Agile, he said, is different; you set reachable goals for short phases, or iterations, of development.

This process of “continuous integration” involves completing one set of functional code, getting feedback and then adding new coding to it and retesting. Doing projects in phases assures a higher quality because of multiple tests and retests carried out during the SDLC (Software Development Life Cycle).

“With agile, there is an absence of confusion,” Poole said. “Do you guys remember the childhood game ‘telephone’?” As nearly every hand in the room went skyward, Poole smiled: “How did that game go?” The audience chuckled, and appeared follow his point. If one person tells a group a direction or a goal and the group collaborates there is less chance for project digression. The project is more likely to be what the customer is looking for which is the equivalent of success.

Agile doesn’t only benefit the industry or a company alone, Poole concluded. It also can benefit the individual. He listed these benefits for the agile team member

1. Less cancelled and or shelved work
2. Less pressure or stress over project duration, especially during crunch time as testing is done throughout SDLC
3. More individual ownership and feeling of involvement in a project
4. Increased project success

Poole frequently repeated the phrase, “the simplest thing that could possibly work.” Agile is the simplification of complex tasks, he said, satisfying the customer today and tomorrow, allowing for full software development team collaboration and good returns on investments.

<
Boston SPIN presenter, Damon Poole (on right) speaking with SearchSoftwareQuality.com contributing writer Matt Heusser

Why waterfall developers still shun Agile

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 at techtarget.com.