“Agile consultants ruined the software group I work in. Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up.” – Anonymous Agile Victim
I want to start this post by making one thing perfectly clear: Agile development and testing practices have worked wonders for thousands of organizations. Whether it’s decreased time to market, improved communications or lower costs, the positive aspects of Agile are well-known through the software development industry. And since so many software professionals have had so much success with approach, who I am I to tell them they are wrong? No, this piece is not meant to discredit Agile or the people who promote it.
Instead, I wanted to take a deeper look at all the times when Agile fails. For all its proponents, Agile has its fair share of skeptics and detractors. These are people who have a much different Agile experience – one characterized by chaotic processes, lower quality, miscommunication and numerous other problems. As you might expect, these people tend to have extremely strong opinions on what they consider to be the shortcomings of Agile. Here’s one comment from our very own software testing blog:
“This system is bloated with meetings, excel spreadsheets and anemic of any real documentation. Agile and the people who support it are full of themselves and their aversion to documentation is detrimental to real active communication. The disinterest to documentation presumes humans will retain meeting to meeting barrage of verbalized ideas. Agile is full of egotistical self congratulating ideologies over used buzz words like “flexible” and “living”. People can’t remember what they said from one over stated meeting to another.”
Ouch. Clearly, there’s a disconnect here. How can one approach work magic for one group and fail miserably for others? The full answer to that question is admittedly beyond the scope of one blog (or perhaps even one book), but I wanted to address some of the most obvious reasons. Let’s take a look:
Old Habits Die Hard
Based on my observations and those of several noted experts, Agile seems to “fail” whenever it’s forced on a team or organization that is accustomed to other methods. After years of developing and testing in a certain manner, one cannot expect an entirely smooth transition. Want proof? Here are a few results of a recent survey that interviewed 200 companies that had recently transitioned to Agile:
Out of over 200 participants, 64 percent said that switching to Agile Development was harder than it initially seemed. Forty percent of respondents did not identify an obvious benefit to the practice. Out of those who did, 14 percent thought it resulted in faster releases, and 13 percent – that it created more feedback. Seven percent of participants noted that Agile developers were happier due to reduced future planning and documentation.
According to Voke, since the global financial crisis of 2008, the average cost of software projects has seen a sharp rise, even though developer teams have become smaller and the deadlines tighter. Meanwhile, the risk of software failures associated with Agile Development has remained high.
“While many people assume that Agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. They may not realize that today’s solutions are tomorrow’s problems,” said Theresa Lanowitz, lead analyst at Voke. (link)
I think it’s fair to say that the process of “going Agile” must be clearly explained and outlined (more on this shortly), otherwise your development practices will change, but in name only.
“I don’t think most people need convincing about agile principles, even if they’re just attracted to the idea of frequent delivery,” said Nate Oster, an Agile Player-Coach and Founder of CodeSquads LLC. “In practice, however, a lot of waterfall behaviors survive by hiding behind the new agile jargon. If we want different results, it’s not enough to change our jargon, we have to actually change the way we collaborate!”
He continued: “I think the deep-down objection to agile is that it challenges our hidden assumptions. A lot of our cherished ‘best practices’ from waterfall are actually optimizations of ‘our job’ – they make us ‘efficient’ but actually undermine the agile goal of frequently delivering high quality software as a whole team.”
In terms of waterfall legacies, Nate gave me the example of how some test teams still request that a feature be 100% complete before it’s ready to be tested.
“That’s a verification mentality, a holdout from waterfall when it was the tester’s job to efficiently find all the bugs,” he explained. “On agile teams, we prevent those bugs by specifying the feature as a team using testable examples, then we build those behaviors in small slices. When we work in small increments like this, we test continuously instead of at the end. That’s how we prevent ‘mini-waterfall testing.”
So is making an Agile transition impossible? Not at all. Is it difficult? Yes. Is it necessary? Here’s what Agile expert Scott Barber once had to say on the matter:
I believe that the trend to “go Agile” is misguided. If a company is developing good software, the people involved in developing that software are happy working there, the software development is sustainable, and the business is being adequately served by that software, there’s really no need for them to try to be more or less Agile. Agile has challenges like any other culture, but the single biggest challenge I find is companies trying to solve development, process, management, and/or schedule problems by “going Agile.” Teams who have grown up in a culture that is fundamentally different than Agile simply will not find it easy to “go Agile.”
Another reason why Agile sometimes fails has to do with unrealistic expectations of the Agile actually is and what it can help you achieve. Agile is commonly believed to be a set a practices, processes and tools, when in fact, Agile is really more of a mind-set and culture.
Processes vary depending on the company, the product and the personnel, so it’s no surprise that they sometimes fail when they are misapplied. A mind-set and culture, on the other hand, can transcend those factors. Here’s a good analogy of this problem from Scott Ambler (emphasis added):
Would you take the same approach to create a web page describing your family and the embedded software for a NASA space probe? Of course you wouldn’t. What about a business application and a NASA space probe? Likely not. Would you take the same approach with a team of six people that you would with a team of sixty people? Or six hundred people? Once again, likely not. Different situations obviously call for different approaches.
It’s easy to see that you need to take a different approach developing a web page as compared to developing a space probe. Your company likely doesn’t develop both web pages and space probes, so it’s easy to stand back and recognize that there’s a difference. It would be clearly foolish to follow similar approaches on these projects – a very simple process is sufficient for the web page development effort whereas a complex and rigorous process could be appropriate for the space probe. You would put the space probe project at serious risk following the web page process and you would incur significant costs following the space probe software process to develop your web page. Clearly it is important to follow the right process.
Basically, if you expect Agile to perform miracles or instantly transform your software development process, then you’re likely to view the method as a major failure.
What happens when a development and product team adheres to the principles of Agile, but the QA team does not? Conversely, what happens when a QA team wants to be involved early in the dev process, but the engineering and product teams resist? What happens when executives want everything to be Agile even if they don’t really understand what it means?
“When I hear ‘we have an agile test team,’ I think that’s a contradiction in terms,” said Oster. “If all they do is test, then they’re not really an agile team. Agile teams frequently deliver high quality software, and that includes testing. An agile ‘feature team’ needs all the skills it takes to deliver software, and that includes programming, analysis, and testing skills, regardless of who performs these tasks. I love it when new agile team members start cross-training outside the role on their business card. Mature agile teams know there isn’t a sharp line between ‘my job’ and ‘your job.’ There are just tasks we need to complete, and everyone brings different skills to the table, so that we can complete them as a whole team.”
As mentioned previously, Agile is not a playbook. It’s not a set of directions. It’s not a checklist. As Scott Barber said, it’s a mindset and a culture – and it needs buy-in across an entire organization in order to succeed . Here’s a great presentation by Agile coach Mike Cottmeyer that explains the importance of agile being adopted by multiple departments:
Giving Up Too Easily
As we’ve covered, the transition to Agile isn’t easy. I’m sure every department thinks they have the steepest climb, but since this is a testing blog, we’re going to focus on the QA department and its ability (or lack thereof) to move to an agile process. As Nate Oster points out, the problems of the agile transition have less to do with Agile and more to do with existing practices.
“In my experience the biggest challenge with adopting agile is how it just relentlessly exposes what we’re not very good at yet, and in a lot of organizations, that includes testing,” he said. “When the goal is frequently completing new features, that forces teams to work in small batches with short timeframes, so agile exposes how traditional testing is optimized for ‘throwing a big pile of code over the wall.’ Traditional testing is really a broken system, because these huge piles of work arrive late in the game.”
When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what Elisabeth Hendrickson calls “fake agile.”
I wanted to close this post with an open-ended question to all of the testers, developers and product people: Have you experienced Agile failure? If so, what were some of the reasons why? The same goes for those who have Agile success. Either way, please share your thoughts in the comment section below.
*Special thanks to Nate Oster for taking the time to answer my questions.