Over the past 15 years, agile methods have significantly transformed the software development landscape, moving steadily from margin to mainstream. Most agile practitioners attribute the growing influence of agile methods to their effectiveness, but enthusiasts' beliefs about agile practices often fall short of reality. By recognizing and avoiding these five common (yet deadly) fallacies surrounding agile adoption, your organization can avoid missteps and plan and implement agile initiatives more effectively.
Fallacy No. 1: Your team is ready for agile
Agile team members are supposed to be cross-functional, self-organizing problem solvers who can define and continually optimize the processes they are following through the practice of creative experimentation and continual reflection. They demonstrate ownership, challenge convention, and surface problems within their organizations that prevent agile from working well. They do not typically require or benefit from close management of their work by authority figures, as they get needed course corrections from like-minded team members and their own methodical explorations.
Sounds wonderful, but in most organizations, this is rarely the case. The reality is that a team of such individuals, if you could assemble one, would likely be successful using almost any method. If you are in a mostly average organization, surrounded by mostly average practitioners, you may find that many of your folks aren't ready for the demands of agile. That doesn't mean they can't use agile, but that they will require assistance, coaching, and some initial oversight in order to be successful.
Agile provides opportunities for reflection and continuous improvement, but your team's approach is a good indicator of how successful you will be. Are team members already experimenting, inspecting, and adapting? If not, then they probably need leadership and coaching to succeed fully with agile methods, because these methods require that they actually work differently than they may have in the past and not just follow a different process.
Fallacy No. 2: You won't lose anything in the bargain
The agile versus traditional choice is a matter of trade-offs, period. Anybody who denies this is guilty of silver-bullet thinking. Recognizing this reality implies that you have to know why you are implementing agile. If your requirements tend to be correct and stable from the outset, many of the benefits of agile will be minimized. Agile might make you faster, but be sure to identify the reasons you think it will make you faster (e.g., we tend to waste time building the wrong thing, and the regular checkpoints of scrum would help us to stay closer to the product owner's vision). Agile won't just make you faster magically—you're not somehow cramming more work into a sprint unless you are working more efficiently. Too many people talk about sprints as though you can somehow complete whatever you are trying to build in just two weeks, and that's why agile is faster. These people will implement agile the wrong way, and pay a price for doing so.
Detailed, long-term planning is contrary to the agile philosophy of accommodating continuous change. The point of sprints is to make a short-term plan and then continually readjust. Agile methods are most useful when plans are likely to change, so if your plans are likely to be stable, then agile may not be the right choice. Traditional software project management tools such as Gantt charts and earned value management will help you see what's down the road, and with greater clarity. Such long-range tools won't be applicable to every project, but for the times when they do make sense—when you have clear, stable requirements and low amounts of user interface work—they provide great benefit.
Similarly, if your requirements end up being different in agile, they will probably be less specific and detailed, at least initially. That is usually a good thing, given the benefits of collaborative iteration, but it still leaves room for misinterpretation, which more traditional requirements may forestall.
Fallacy No. 3: Consult the agile experts; they'll know what's right for your organization
Too many agile implementations focus on doing things according to the prescriptions of a specific person, group, or method. When that happens, the surrounding discussions devolve into appeals to the authority of coaches or recognizable industry personalities. You don’t need religion, or a priestly class, in agile software development. Rather than saying things like “That’s not agile,” or “That’s not the scrum way,” you should be saying things such as “A different approach would work better for us.”
Don't feel as though you are doing things wrong just because you aren't conforming to what one person or book said. Do what makes sense for your organization. If you have a sound rationale for what you are doing, then it is the right thing for you, regardless of who says you're not "agile" enough. Experiment, inspect, and adapt. If you ever find yourself following the precepts of some authority without understanding why that makes sense for your situation, you will inevitably misapply those precepts anyway.
Fallacy No. 4: The values behind agile are new
The values described in the Agile Manifesto are pretty revolutionary, such as the idea that working software is the best documentation and having large specifications defined in advance actually hurts the development process.
However, many ideas commonly associated with agile are not new at all. Continuous improvement, regular communication, courage, transparency, and a focus on business impacts are just a handful of the values typically cited as characteristic of agile efforts. But these things have always been prized, even within traditional methods.
Not focusing on such things is just bad process and bad management, regardless of your method. If your team did a poor job with these elements in a traditional context, they are likely to do the same in an agile context. The bad status reports of yesterday make for poor stand-up discussions today. Prior laziness about continuous improvement will manifest itself as trite observations during retrospectives ("We need better communication") and a failure to act on observations that are meaningful.
Lesson learned: Simply moving to an agile method will not be enough to make a team do these things well if they haven't been trying to do them all along.
Fallacy No. 5: You will know if it worked
With agile, the metrics and standards you used in the past won't always translate into a post-agile world, which makes it hard to do a clear, point-for-point comparison between your pre-agile and post-agile days. For example, defect leakage to production, a commonly used quality metric, is typically expressed as a ratio of production defects to all known defects. If you catch most software bugs during pre-production testing and have relatively few show up for the first time in production, you will have a low (good) defect leakage to production ratio.
But while agile methods are generally good for quality, they may not be good for this particular metric, as the accepted agile practice is to fix defects as soon as they're discovered. If a team fixes defects immediately, they have fewer reasons to enter those defects into a bug-tracking system, which would make the denominator for a leakage metric smaller and thus make the metric appear to trend in an unfavorable direction. Paradoxically, a positive practice such as fixing defects immediately might make long-maintained metrics, such as defect leakage, look worse. Similarly, a historically useful measure for requirements stability would no longer make as much sense in agile, which strives to accommodate change rather than minimize it.
So adopting agile methods entails shifts in culture and values as well as processes. That means organizations may find it hard to compare pre-agile and post-agile performance because the standards by which they measure themselves will likely change as part of the transition. Agile represents a fundamental discontinuity—it is a chasm to be crossed, not just a hill to be climbed.
The consequences of misconception
These five fallacies hurt agile adoption because they leave teams unprepared for the transition, unaware of trade-offs, needlessly dogmatic, and confused about how to assess their progress. This is just my list; there are plenty of other agile myths and misconceptions. By recognizing and correcting these five things I've seen hold people back, your teams can avoid some common landmines and move forward more confidently and effectively with agile.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
