When not to use Agile


When Not to Use Agile

When Not to Use Agile

Agile methodology, postulated back in 2001 in Agile Manifesto by the prominent software developers, has occupied the minds of thousands of project managers around the world. Offering a flexible, reiterative approach to software development, Agile methods suit well for complex projects which change fast during the development process.

When best to use Agile methodology – this question depends on many factors, including the number of available resources (Agile projects are quite demanding), type of development project (some of them work best with traditional development methods), trained professionals (teams members are crucial for a successful Agile project), etc. We have covered strengths and weaknesses of Agile methods in the previous article, so you should definitely take a look at it to understand Agile better.

Here we would like to explain when not to use Agile methods and why:


1. Your project is not very urgent, too complex or novel

Agile methodology is quite demanding, as we mentioned previously, so there is no need to use it for simple or typical projects. They can be easily accomplished with traditional Waterfall methodology. Long cycles, clear development goals, and typical cycles – all of these aspects will make your life easier with traditional methods.

Agile methods allow you to create a lasting, well-organized software development process, highly adaptable to the changing requirements and environment. If you have a clear goal and enough time to accomplish your project, this is when you should consider not using Agile development methods.


2. Your team is not self-organizing and lacks professional developers

A well-trained team, aware of Agile principles and practices, is one of the most important aspects of any Agile project. The agile process requires a lot of crucial decisions to be taken by the team members during the project. And if your developers are not experienced and responsible enough, this may ruin the whole project.

Do not forget that Agile methods require constant interaction among all stakeholders – development team, testing unit, management, and the customer. If one of the teams shows poor performance, this will definitely affect the overall result. If you have doubts as to your development team – this is when you should not use Agile software development, since it can backfire at you at any stage of the process.


Scrum team


3. Your customer requires neat documentation of each development cycle

In many cases, your customer will prefer your company to submit detailed documentation of each phase of the project. These requirements mostly hold for infrastructure applications, which are designed to support a process for a long period of time. Unlike business process applications, which are continuously adapted to the changeable business environment, infrastructure applications will remain unchanged for quite some time.

Therefore, they should be clearly structured and supported by profound documentation. If this is the case, avoid Agile methodology, as it relies upon constant interaction and on-the-way adaptations without clear documentation of the development process.


4. Your customer requires approvals at each stage of development

Maybe your customer is a vivid adherent of Waterfall methods and demands you to deliver software pieces for approval at each development cycle. Or maybe you develop software for a bureaucratic organization with strict rules or procedures. Anyway, if your deliverables have to go through a chain of tollgates at every stage, you need to forget about Agile methods. These bottlenecks will kill all the momentum, so crucial for a successful Agile project.


5. Your customer wants you to use the traditional methodology and doesn’t want to hear about Agile

A customer is always right, and in many cases, it is impossible to pursue your client to use a better approach to develop software. Sticking to traditional methods is a comfortable path for the customers, and this is their choice.

If you have laid out all the advantages of the Agile methods for the given project and the customer is reluctant to follow you, do not try to use Agile methodology against his will. Without your customer’s continuous feedback and high involvement in the development process, your project will be doomed to fail.


Agile development


6. Your organization does not invest in spreading Agile practices among the developers, testers, and management

Some organizations prefer to work with customers who stick to the traditional development practices. And when the time for Agile arrives, it turns out that the communication links and resource base for a successful Agile project are lacking.

Try to avoid resorting to Agile methods with a poor foundation, as it will negatively reflect upon your work. If you are a true fan of Agile ideology, try to find and create a good team of like-minded developers.


Regardless of its huge popularity among software developers and many advantages, the Agile methodology should not be used for every project you encounter. A thorough planning should be accomplished at the start of any Agile project to understand if you have enough resources, a powerful team and a real need to use this set of development practices.

Do not take Agile methodology as a panacea which will make any of your development projects a huge success. If you are not sure about your prospects with Agile practices, stick to the traditional approaches, as they are more straightforward.


When not to use Agile


Will Killyou

about 4 years ago

Agile is the most over applied, mis understood even by so called practitioners "method" of development ever concocted. It's roots are with RAD and as such it has merit but mainly for smaller development projects, especially Java based web "dev" which is in constant flux in terms of scope. Where it is extremely difficult to ensure compatibility with all client browsers, changes etc... It is not suited for mission critical OS development where real programmers are involved. it is not suited for infrastructure development, deployment or moves. I had used RAD in the old days "inside" what was then referred to as full SDLC. Now AGILE is considered a form of SDLC depending on who or what is referenced.



about 4 years ago

I would not use Agile to build a Mars Rover or a fighter jet. Not necessarily because they are complex (although they are) but because requirements are well known and it has to work perfectly the first time. Also, integration complexity might be a bigger driver than problem complexity. If you have to integrate with hardware, you might not be able to start small. The bottom line is you have to understand the problem you are trying to solve and don't just take Agile as a recipe. You still have to apply good engineering judgment.


Matt D

about 3 years ago

NASA has been using Agile for their mission critical software way before the Agile Manifesto and Saab uses Agile in both software and hardware development of their fighter jets. Humans are terrible at predicting the future which is why requirements are never well known. The best way to understand a problem is through trial and error.


Leave a Comment

Please be polite. We appreciate that.
Your email address will not be published and required fields are marked

Share via
Send this to a friend
We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.