No doubt Agile development methodologies are making inroads in today's enterprises, but the road to Agile is far from straight and narrow. It's more like a multi-lane highway, with all types of drivers taking a variety of routes to their destinations. And according to respondents to SearchSoftwareQuality.com's 2008 Agile Trends survey, the waterfall methodology is not always the road less traveled.
For those survey respondents developing with Agile techniques,
Many organizations use the parts of Agile that work best for them rather than taking a purist approach.
"Agile has lost some of its more technical meaning. So, on one hand I think Agile is growing, but not the strict XP or Scrum, but some modification of them," said Justin Gehtland, president and co-founder of Relevance Inc., an Agile consulting and development company in Chapel Hill, N.C.
"Scrum is fairly straightforward and simple and is easy to adopt," said Scott Ambler, practice leader for Agile development at IBM. "The main focus is on team leadership and requirements management. It doesn't get into the technical practices XP gets into, nor does it [cover] the lifecycle details of the Unified Process."
No methodology covers everything, Ambler said. "My advice is [a methodology like Scrum] should be part of an overall palette of processes. The process you follow has to fit the situation you're in. Everyone is finding Scrum is not sufficient, XP is not sufficient, Agile modeling is not sufficient. They all address subsets of the overall process. So you have two choices. You can put together your own process, which seems to be the flavor of the day, taking the best of Scrum, XP, etc., and reinvent it; or you can take RUP [Rational Unified Process] and tailor it down to something that meets your needs."
Toronto-based LYNXDev Inc., which provides business solutions to the financial services industry, is a good example of this a la carte approach.
"Although we do not use a formalized methodology or process, I would consider the development process that we do use to be aligned very much with the concepts of an Agile methodology," said Steve Whatmore, a Java architect there. "We used certain aspects of a RUP methodology injected with a much shorter development cycle and much less formalized requirements."
He continued, "Since we are a small ISV that works directly with a large number of financial institutions, we are finding that typically our clients are requesting a RUP-based development methodology. However, we have found that the overhead and process inherent in a RUP-based methodology doesn't fit well in our application space, and thus the effectiveness of a RUP-based methodology is somewhat limited. Typically, we end up with a modified RUP/Agile methodology."
Nari Kannan, CEO of Ajira Technologies Inc., a Pleasanton, Calif., developer of service process management solutions, also mixes and matches Agile methodologies to fit his organization's needs.
"We really don't believe in a lot of named methodologies," he said. "We pick and choose whatever works for us. We're also not dogmatic about doing all those rituals, at the same time every week. Sometimes we do weekly builds; sometimes we do them every few weeks. If you have a lot features sometimes it makes sense to wait a few weeks. We keep it flexible."
Holding on to waterfall
Other organizations have not gone the Agile route yet.
"To my knowledge Health Net has not formally rolled out any agile methodologies, though I believe some of our Web teams use a more iterative approach informally in some of their smaller projects," said Cooper Zale, business systems analyst at Health Net Inc., a managed health care company in Woodland Hills, Calif. "Health Net is still very process immature and is just grappling with agreement to consistently follow any methodology at all."
Zale continued, "As our first step forward in consistently following a methodology, we have adopted a traditional waterfall system development lifecycle that we are working to implement across the enterprise."
Zale's organization is not alone. Among the SearchSoftwareQuality.com Agile survey respondents, waterfall is neck-and-neck with Agile. Among the respondents, 45% follow Agile methodologies, while 44% use waterfall. Other development methodologies cited were test-driven development (19%) and RUP (15%).
"Waterfall is not going away," Ambler said. "It's definitely shrinking in popularity because it's not as effective, but a lot of organizations still cling to the old ways. A lot of organizations are comfortable with that. It's what they know, and they're happy with their success rates. There's an opportunity there to do better, but it takes time. Iterative is a step in the right direction."
According to Ambler, organizations can't flip a switch to Agile.
"For IBM it's a multiyear transition," he said. "We're the largest organization in the world transitioning to Agile. We definitely have some waterfall teams, and we probably still will five years from now."
For those organizations that haven't started down the Agile path, there is an appeal, however. Among the survey respondents who don't currently use Agile methodologies, over 60% said they had some interest.
Industry observers suggest, though, that not all organizations will be all Agile all the time, and that it will depend on the project and the developers themselves.
"Large organizations that used to have heavy top-down development are branching into trees with some projects that are Agile and some that are not," said Relevance's Gehtland. "So a person working on projects that aren't Agile might not know that there are Agile projects going on at their company, and in a survey will say the company is not using agile."
In addition, "Not all projects will be Agile," Ambler said. "Going Agile across the board is going to take some flexibility. You have to understand what the problems are and what the challenges are."
And finally, "agile" can mean different things to different teams. "Agile means different things on different projects," said Per Kroll, chief architect, Rational Services, IBM. "What works for one project may not work for another."
Editor in Chief Michelle Davidson contributed to this report.