10 Good Reasons To Do Agile Development

5 Mins read
10 Reasons to Adopt Agile Development

Cowboy, waterfall, agile – these are the common approaches to software development. And all approaches can eventually arrive at a product that works. 

It’s the getting there that makes the difference. And, for businesses that want the “getting there” to be rapid, efficient, and successful, agile development should be “on their radar.” 
Interestingly, organizations seem to be slow in adopting agile methodologies – perhaps because it means a rather major shift in development “culture,” and change is hard when people are comfortable with their current “culture.” Yet, agile development is proving to be the most efficient of methodologies – and who does not want efficiency?

Let’s take a quick look at the three methodologies and then a more in-depth look at agile and its benefits.

Cowboy Methodology

Lots of small startups operate as cowboys- no defined process and maybe just a couple of programmers. A software idea is accepted and that idea is given to developers who build in any way they can, so as to get it to market quickly. When new features are to be added, it happens as time allows and with some priorities related to importance. The QA process is completed by the developers and customers.


This is the most common methodology, certainly used by large organizations, but others as well. It is a highly-documented process, as any developer who has worked with this model knows. A project comes in; it is planned in its entirety from the beginning and a requirements document is generated. One part of development is completed at a time, in sequential order, all “built to spec,” much as a custom home would be constructed.

A separate QA team will test the software and send bugs back to be fixed. Once the QA team signs off on the final product it is deployed/delivered. The entire process can be lengthy.


In terms of documentation, agile use the least amount possible but more than the cowboy method. The goal is to get a high-quality product to market asap. With agile, enough planning occurs at the beginning so that the team can assume individual tasks and complete “sprints,” usually of one-to-two weeks at a time. Then team planning occurs for the next “sprint.”

During the development process, the entire team holds a “stand-up” meeting daily, to report progress, to problem solve, to get and give feedback, and to ensure that everyone is on track. The idea is that the planning is continuous during the entire life cycle of production and involves the entire team. Changes can be incorporated as needed during the process. The beauty of this is that the customer can request changes throughout rather than at the end only.

The Case for Agile

Organizations have been slow to adopt agile, most preferring the standard waterfall process. There has been a lot written about agile, by companies that have adopted and love it. And, if agile can get products to market more quickly; if agile can allow QA all along the way; if agile allows requirement changes to be agreed upon and incorporated quickly, it seems that it might be the better way to go.

Four Basics

The concepts behind agile development are as follows:


The team includes as many stakeholders as possible, not just developers, and they meet in a common space daily. This can be tricky if they are in several locations, but it is doable, through video conferencing and some travel among team members.

Developers write test cases before the beginning programming. This ensures that their code works.

A “stand-up” meeting is held at the start of each day – it’s brief and is used for reporting, feedback, and to list issues for down the road that may take later to resolve.

Prioritized list determines “sprints.” These are iterations determined by the team. These are based on “user stories,” – descriptions of the tasks which the product is to address. The full list is developed in the beginning, and they can be re-prioritized during the cycle of production. A longer meeting at the end of each sprint is used for demonstration, discussion of what needs to be “fixed,” and an updated list of prioritized tasks for the next sprint.

Ten Benefits of Agile

For those considering a migration to agile, here are ten benefits to think about – they may be pretty compelling:

Mistakes are Identified Quickly

Given the use of test cases, the daily meetings and short chunks of development through sprints, errors are found early on. Many call this “failing fast” so that, in the end, the product is to market quickly.

Decisions are Fast

When issues arise; when modifications need to be made, the team can quickly meet in its “agile space” (on-site or remotely through video technology, discuss the issue right then, and come to a collated decision.

Collaboration = “Buy-In”

Because of the team approach and the involvement of all stakeholders, everyone has a vested interested in success. And each stakeholder – project manager, developers, operations, customer, and business rep better understand each other’s unique vantage points and priorities. Issues are transparent to everyone, and solutions may be found from “odd” places.

Millennials Like the Environment

This generation prefers experiences that develop relationships. When these young people can work in collaboration and in open spaces, they are happier and more productive. Plus, they love the idea of being judged on production rather than time spent. They are far more motivated in this type of environment.

Change is Accepted as a “Given”

Working in sprints and modifying user stories and priorities is embedded in agile. The waterfall is far more rigid and results in changes all occurring at the end. These can seem like “mountains,” but with agile, change along the way means it comes in small chunks – it is far more palatable in small chunks.

The Final Product Features are Right

Given that stories and modifications occur all along the way, the product evolution consistently adds value and end-user success. When features are all determined at the beginning and are relatively fixed, features may have been omitted which then have to somehow be added. This is frustrating for all parties involved.

Documentation is Faster and is Most Often Right

Standard waterfall approaches develop full documentation at the beginning. And a lot of it is either not used or maintained. The documentation itself becomes the goal, rather than the actual feature production. In agile, documentation is limited and incremental, based upon the chunks that area to be built as they are planned for. And approval sign-off occurs in increments as well, rather than at the end. This is far more efficient, and “getting it right” the first time is far more likely.

Reduced Number of Defects

Again, when the process occurs collaboratively and in iterative sprints, defects are found early and fixed. The final product has far fewer bugs, and that’s a huge plus.

Customer Satisfaction is Higher

The customer has been involved all along the way. And all changes and features have been discussed with that customer. This is one of the most important aspects of agile – it is so fully transparent all along the way. The customer knows exactly what s/he is getting an end product and has participated in determining that. Happy customers mean more revenue over time.

Maintenance Is Easier

Here’s a common situation: only one developer has been responsible for a large portion of the coding. Now there are problems and that developer has moved on to another company. No one else was involved, and the process of finding the failure point and fixing it is daunting. With agile, all developers have been involved in the cycle of production and all of them understand what the others have done.

The Challenge

Making the migration to agile from the waterfall, or even cowboy, models can be tough. It involves risks that many CIO’s are not willing to take, even though their current methodologies have inefficiencies. Doing some research and reading some books on agile may be a good idea.

The key to migration I not handing it down as a directive, but, rather, finding a team that is willing to give it a try on one project. And training. Agile is not something that is just “done.” Everyone needs to understand the process and their position in that process. They need to have a collaborative attitude and a willingness to take risks.

Start with one project. Find a team willing to experiment and give them the freedom to do so. They may become the best ambassadors for further migration to agile.

Leave a Reply

Your email address will not be published. Required fields are marked *