If development methodologies were a religion – and depending on who you’re talking to, they are – we here at the uTest blog would be agnostic. That is to say we believe no methodology is inherently better than another. As we’ve learned from our customers, almost any approach can work given the right personnel.
That said, there seems to be a strong preference among the industry’s movers and shakers for the Agile methodology. Seen as a more flexible and efficient approach, Agile is now entrenched in dev and testing shops all over the world for a number of reasons – too many to list here. But what if all those reasons are wrong? What if Agile isn’t really more efficient? What if Agile is actually – gasp! – a hindrance to dev and test teams?
That’s the case being made by analyst firm Voke, who just published a report on the hidden (and not-so-hidden) costs of the Agile methodology. In “Market Snap: Agile Realities” they summarized the experiences of over 200 companies who had recently transitioned to Agile. Here are a few clips of what they found, courtesy of TechWeekEurope:
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.
Is this a problem with Agile or with implementation of Agile? In other words, are they doing it wrong? I’ll leave that for you to decide. In the meantime, here’s Elisabeth Henderickson with her explanation of ”fake agile” from a past Testing the Limits interview:
When I meet victims of fake agile, my first advice is to stop accepting the role of victim. No matter what our role in an organization, we have the power of influence. We can educate our colleagues and managers about the difference between fake and real agile. And we can help the key business decision makers understand that if they want the potential benefits of agile — capabilities delivered sooner at higher quality — they have to support the practices that provide those results and not just support “compress the schedule” and “change everything up to the last minute”.
To close, I’d like to focus on one Agile problem area – the transition – and propose a solution. It’s clear from the report (and countless other sources) that transitioning to to Agile may be the most difficult aspect of the methodology. This makes sense, especially for teams that had become stuck in their ways. So, to help make that process a little smoother, I’d like to revisit a solution from eBay’s Jon Bach called Agile-Fall.
“Agile-fall” refers to having the principles associated with Agile (daily stand-ups, sprints, burndown charts, etc.), done in a waterfall-y series of development steps. Example: Sprint 1: Gather requirements, Sprint 2: Design your tests, Sprint 3, Run those tests, Sprint 4, Fix bugs, Sprint 5 regress those bugs. There’s no shame in that if that’s what works, and when you’re going through a transition from Waterfall to Agile, that may be the best thing as opposed to a sudden lever-pull one day where you show up and your desk is next to someone else with no walls and there’s a stack of sticky notes and markers on your chair with an email to report to your first standup in 30-minutes.
What do you think? Is Agile worth the costs? Let us know in the comments section.
[Image credit: accurev.com]