Agile practices have enabled software development teams to create more relevant software much more quickly than have past practices. But too often, more common-sense approaches to some types of development efforts have been shoved aside in favor of bending agile principles to inappropriate projects. The results are not ideal.
The majority of development projects now say they are agile in some manner. But agile processes are not a panacea for all that is wrong with software development.
Agile can also put pressure on individuals and teams to deliver. Agile sprints typically last two to three weeks, and working code and demonstrations are staples at the end of those sprints. But performing one or more demos of the results may not be realistic.
In defense of the bias toward agile, it's difficult today for any team that doesn't expound and practice agile principles. For developers and testers alike, agile experience is a career requirement, and any consideration of other approaches might not mesh with the expectations of individual contributors.
Newer generations of software professionals are experienced only in agile, and introducing other methodologies might be culturally difficult. In any case, the learning curve for alternative methodologies may be too steep for individual projects to consider.
Most practitioners believe that agile, especially Scrum, requires time-limited scrums, daily standups, software demonstrations after scrums, and retrospectives after projects or major releases. To do otherwise is to go against the tide of belief with agile.
But there are legitimate reasons to reconsider using agile. Here are eight of them.
1. Your team doesn't understand agile
It's a common refrain, but many teams know only what they have read about agile, which may be wrong but is almost certainly incomplete. Many practice the terminology without appreciating the underlying values. If your employer isn't willing to invest in agile training and infrastructure, it's probably a lost cause.
2. Your team is resisting agile
There might be several reasons for this. Culturally, agile may threaten some team members, including those who feel they had obtained an informal leadership status under the previous process that disappeared under agile. If team members use the terminology but insist on doing it their way, you may want to back off on pushing agile until you can address your team's needs.
3. You are using agile to appear more modern
If another process has worked well for you in the past but you think you need agile for the sake of change, or because agile is the hot approach, that's not a good reason to go agile. Your experience with past processes may make them worth continuing to use, even if they aren't agile ones.
4. You processes would be expensive with agile
If the products you're developing are regulated, consider the costs of moving to agile. While most regulatory bodies, such as the Food and Drug Administration in the United States, give you some flexibility to incorporate agile methodologies, your teams have probably developed extensive documentation and tests focused on their existing methodologies. This documentation and accompanying team mindset would have to be reset in order to become agile.
5. Two-week delivery schedules are overkill
This one may be the rub. If your application cannot easily be broken into chunks on which you can show completion or at least discernable progress over the course of a sprint, then significant parts of agile can't be applied.
Agile does teach teams discipline in breaking down the component parts of an application into manageable parts. But if you find that your application doesn't easily fit into the agile model, you may want to think about whether the approach is right.
6. Expectations don't support agile
Agile assumes that you have a product owner who directs the priority of features and consolidates feedback from demos and actual product use. Even if the team is practicing agile, there may be forces outside of the core team that don't appreciate or encourage agile principles. Users may want to see only a completed application, and management may release funds for further development only upon a full release.
7. Your agile approach is combined with waterfall
If your team has combined agile with a legacy methodology such as waterfall, creating a 'water-scrum' approach, you may have the worst of both worlds: You have combined the rigid structure of the traditional approach with the terminology of agile. Determine if that approach is working for you. If it isn't, back out of agile until you fully understand the goals of your process and how to best achieve them.
8. You say you're agile to attract team members
If you really don't have an agile methodology but call it agile to attract and retain developers and other team members, you are in trouble. Do code development and software delivery happen frequently, but haphazardly? Do you call your requirements "user stories" and the time between releases "scrums?" If so, your team may have adopted this form of schizophrenia, but you may be better off stepping back and deciding what you really want to be.
Agile is not for every team
Agile has the flexibility to adapt to a wide variety of projects, and it is certainly what your team should do under most circumstances. However, due to training or cultural issues, or because the technical aspects of a project don't easily lend themselves to many of the accepted agile practices, agile may not be the best fit.
If a software system requires a lot of infrastructure, it won't be possible to deliver working software at the end of every sprint.
Projects that include a substantial amount of behind-the-scenes code, such as embedded systems, may not be amenable to having buildable and working code at the end of each sprint. Code for safety-critical systems, such as modern automobiles or airliners, can involve many teams whose code isn't functional until it has been integrated into the operational system.
And that's really at the heart of the matter.
You might argue that agile doesn't require two-week sprints or live demonstrations after each sprint. But that's not the way agile is commonly practiced, and blaming the practitioners won't get you anywhere.
However, in some development projects, delivering working software every two weeks and conducting a demonstration of that project may not be possible.
Teams must be able to recognize when they are trying to put a square peg into a round hole, and to look for alternatives to agile when that happens.
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.
