Try Googling “hate Agile” and “Agile sucks” and “Agile fails,” and hundreds of pages will show up. Some contain...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
articles on how to avoid Agile software development failures and problems, and others are by development pros who have tried Agile and just don’t like it. Read the mostly anonymous comments on these articles, and you’ll find the hate being put on Agile right and left.
That’s the Agile backlash, another instance of any action causing an opposite reaction. Not everyone is on board the Agile train, despite the wave of almost-fanatical evangelism for and quick adoption of it. What’s written on the Web is the tip of the iceberg of dissatisfaction with the process, according to some of the users and experts cited in this series on the so-called backlash. Others think it’s the by-product of rapid and poorly-planned adoption.
In this article, we’ll explore the reasons why some software pros hate Agile, based on interviews with Agile coaches and consultants -- including Mike Dwyer, David Whalen, and Jon Kern – as well as software test and development veterans Scott Barber, Chris York and Lisa Crispin.
Too much Agile too soon?
Picture this: A CEO/CTO/CIO/CXO sitting in an airplane reading a magazine article that’s gung-ho about Agile. He or she goes back to the office and issues an order to adopt Agile development and, perhaps, to use the Agile process in application lifecycle management (ALM) and all business-side processes. Managers rush to obey.
This opening scene in the Agile backlash story was suggested without solicitation by almost all of this article’s sources. The chief executive’s decision sets the stage for mistakes to be made and has led to project failures and disgruntled development, systems architecture and project management pros. Frequently, the blame is place on Agile..and, of course, the media.
“Nobody has been writing about the problems with Agile,” said Chris York, a 15-year software test and development pro. “Every manager reads the same publications, and all the articles say Agile is good. So, the managers want to do it, even though a lot of them have no idea what it really is.”
Enthusiasm for Agile principles and real need, fueled by the economic downturn, has led to rushed adoption and project failures, according to software tester Scott Barber. “Folks got caught up in the idea or the ideal around Agile,” he said. “They decided, without knowing very much about it, that it was going to solve whatever problems they had. Barber is president of PerfTestPlus, a software testing services firm, and co-author of both Performance Testing Guidance for Web Application. and Beautiful Testing.
On various development projects, York has seen first-hand results of too much Agile too quickly. “No one at the top really knew in any depth what Agile is,” he said. Barber adds that non-development executives often don’t understand all the implications of a methodology change. They require the switch, but say: “Do whatever you want, just don’t make things hard on us.”
Many of the pro Agile articles have been written by early adopters who have had success in Agile or Agile consultants promoting it as the answer to all problems, Barber said. “No one thing can be the answer to all problems.”
Too little analysis is being done of Agile’s appropriateness to the projects’ or organizations’ people, culture, management structure, sales cycle, business needs, development processes and tools and other key aspects, sources said. “Failures and problems with Agile can simply be because that it’s the wrong decision for that organization,” said Barber. “Is that because Agile is broken? Not fundamentally.”
Too strict with Agile principles?
Leaders and organizations who insist that teams adhere too strictly to perceived Agile principles can create problems.
York has worked on Agile projects for more than one strictly Agile company. “Everything’s about the process and it’s not about the process being helpful. It’s about fitting into the process. That’s just backwards,” he said.
Development consultant Dave Whalen saw this same thing happen so often that he wrote the widely-read and controversial article, I Hate Agile.
Knowing the principles of Agile isn’t the whole ballgame, Whalen told SearchSoftwareQuality.com. Understanding the philosophy, which is still developing, is a must. Anyone who believes that all Agile practices must be done as written is missing the point. “Every environment is not best served by a completely Agile notion,” he said. “Probably only a few are.”
Mike Dwyer, a 30-year IT and development veteran, sees “a conservatism in some of the Scrum and Agile community that you have to do it a certain way, and if you’re not doing it that way, you’re not Agile.” Dwyer is principal Agile coach for BigVisible Solutions in Boston and a significant contributor to the Scrum, Agile, and Lean software community.
The Agile philosophy is about flexibility and using what works for particular projects, not implementing the exact same practices even when the project isn’t a fit for them, Whalen said.
Yearning for the silver bullet
Done well, Agile can help organizations streamline development, cut costs, improve software quality and more; but it’s not a shortcut or a universal panacea to all that ails Agile.
“People want the Agile Manifesto and the 12 principles to be more than just a bunch of principles,” Dwyer said. “They don’t understand in the simplicity of Agile. There’s a need for discipline, and they’re looking for something to take the place of discipline.”
Reading about Agile for the first time could be a “Eureka!” moment, but making Agile work well calls for leaders to do more than make top-down ultimatums for Agile adoption, these experts and developers said. Without discipline every step of the way, Agile can be yoke on the development teams’ neck and fuel the rebellion against it.
Have your experiences with Agile been good, bad or in between? Do you agree or disagree with the statements made in this article? Let us know. Write to us at firstname.lastname@example.org.