Just as with any product or service, there are many ways to develop software. Technological advancements, including the proliferation of internet technologies, have only accelerated the development of software applications. In today’s modern age, individuals and organizations download and consume applications as fast as they delete them, further driving the need for well-established yet flexible software development processes.

In response to constantly evolving markets, software developers and engineers have created various methodologies to improve product delivery and enhance organizational capabilities for developing robust, scalable and cutting-edge software at a rapid rate. One particularly prominent method, the Agile methodology, is a direct response to the classic approach to developing software, or what is better known as the Waterfall methodology.

While Waterfall relies on the setup of sequential product development stages and extensive planning to build software systems, Agile represents a more radical approach. Organizations creating software under the Agile doctrine operate according to iterations, or single development cycles following weekly or monthly sprints. Long-form meetings are replaced with brief scrums (or “standups”) that cover what was achieved, what will be tackled next and any issues faced. Instead of implementing a lot of changes at the very end of the development process, Agile allows for the ongoing integration of new features and requirements throughout the development process.

Agile Methodology

The Agile methodology emerged based on a meeting of 17 programmers in February 2001. What resulted was the creation of “The Manifesto for Agile Software Development,” a response to the shortcomings of Waterfall.

Based on a set of principles rather than concrete processes, the Agile doctrine emerged from four main values:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Though the creators of the Agile Manifesto state that the italicized items on the right are valuable, they emphasize the greater value of the points in bold.

The Agile Manifesto is further supplemented by 12 principles, which are meant to further guide developers in creating software that embodies a commitment to collaboration between business experts and programmers, as well as promotes technical excellence and smart design. Among these principles, the Agile Manifesto encourages:

  • Customer satisfaction through continuous development and fast delivery of software
  • Flexibility to accept and embrace changing product requirements, regardless of the stage in the development process
  • Face-to-face conversation as the preferred method of communication within the development team
  • Using functional software as the primary measure of progress and success
  • Promotion of a constant and sustainable pace of development among developers, stakeholders and end users
  • Constant attention to simple, user-intuitive design
  • Dedication to fine-tuning and adjusting software to make it more effective, producing a final product with the best possible architecture and design

Though constant last-minute changes can be stressful, they are encouraged in Agile to successfully meet shifting customer needs and industry standards. Agile proponents believe that by constantly altering the software program so that it transforms into a better application, both the consumer and the marketplace benefit. For the developer and the organization, it also leads to a higher competitive advantage.

Benefits of Agile

The Agile methodology is a rebuttal against the trend of assigning greater importance to software processes and tools versus the wants and needs of the people who will be using the software. For example, you’ve likely heard of organizations selling software as a “solution” (also called “SaaS,” which stands for “Software as a Solution”). Though companies should certainly create and sell technologies that solve overarching issues, Agile rests on the foundation that software development starts with people and the interactions that happen between them.

Agile practitioners also believe these same users face challenges explaining exactly what they need to help solve their business or professional problems. This is where Agile developers enter the picture, engaging prospective customers throughout the software development process by seeking input after every iteration of the product.

Agile encourages developers to speak directly with the users to figure out what they need before deciding on the process or tools required to develop software that can help them. In some cases, users may not know what they need, and developers can benefit from direct observation of users’ activities and processes in order to find steps that can be optimized. Once the developers build a basic solution, they solicit continuous feedback from users via demos, interviews and/or quality assurance testing. Ultimately, Agile techniques facilitate constant communication, interaction and teamwork between users and the developers and engineers.

The Agile methodology is also based on the need to develop software that can match the speed and needs of the marketplace. Flexibility and the ability to adapt and evolve throughout the software development process are encouraged under the Agile doctrine, since it allows programmers to change the direction of their coding according to user requirements.

In summary, the main advantages of Agile include:

Releasing products early and often. Following code sprints, products are constantly being tested for bugs. Because software is tested extensively and early integration of software components is encouraged, Agile is ideal for quickly releasing software that is production-ready.

Adopting a flexible process that optimizes feedback. Requirements often change during the development phases of a project. Agile is flexible, allowing for the incorporation of feedback and changes during any step of the development process.

Maintaining its primary focus on delivering products, not documentation. One of the complaints around methodologies like Waterfall is the amount of time spent gathering and documenting requirements. Waterfall practitioners rely heavily on documentation, since any changes to product requirements following the planning phase can significantly impact the project’s delivery time and budget.

In contrast, Agile’s focus on principles rather than processes, as well as its lack of upfront architecture or design, promotes the development of software with optimal functionality, irrespective of initial requirements.

Waterfall Methodology

Whereas the Agile methodology relies on short spurts and iterations, the Waterfall methodology is based on traditional software development processes. This means that the development stages – analysis, design, coding, testing and deployment (in that order) – are always consecutive and never change.

Because the Waterfall model is a widely adopted version of the systems development life cycle for software development, it is often considered the traditional approach to software engineering. The analysis and design stages are typically considered the most important, since product and architectural requirements are defined and finalized during these phases. This differs significantly from Agile, which strives to keep the architecture and design as simple as possible, leaving room for revisions as early or as late in the process as needed.

Furthermore, goals are assigned to each phase of development under a Waterfall methodology. Once these goals are completed, development moves on to the next phase. In other words, once a development phase is completed, it cannot be redone or revised.

The inability to rearrange the steps in the development of a software product or to revise a product once a phase (e.g., installation, testing, troubleshooting, etc.) is finalized is one of the major disadvantages of Waterfall that Agile attempts to address.

Agile makes the development process informal and simple, so that if the design can be improved or needs to be corrected, developers can go back and change it. Waterfall practitioners admit that, once an application has reached the testing phase, it’s difficult to change any aspect of the product that wasn’t introduced or fully developed during the concept stage.

Additionally, Waterfall focuses on completing each module of a software product first, then integrating those components once each milestone is reached in the development process. Developers often work in silos, specializing in one area rather than sharing ownership of the code (like in Agile).

Benefits of Waterfall

Despite its drawbacks, Waterfall is beneficial for long and complex development projects. For instance, practitioners recommend Waterfall if:

  • Customers require a contract that commits to delivering specific product requirements. With a Waterfall approach, the delivery team documents requirements that must be approved by the customer. The product is developed and tested based on these documented requirements.
  • Analysis must be completed before the coding phase. If your team is tasked with developing a complex system that requires multiple approvals, then a Waterfall approach may be more appropriate than Agile.
  • Multiple deliverables are required. If your customer asks for not only documented requirements, but also a user manual and other aspects (in addition to the software itself), then Waterfall can help deliver these items.

Heavy engineering projects that require external certification or which contain highly sensitive and closed requirements are typically well-suited for Waterfall. Not surprisingly, large and complex institutions, such as government agencies as well as industry organizations subject to strict regulations, tend to prefer the Waterfall methodology for software development projects. Waterfall and Agile are similar in that the type of development activities performed remains the same throughout. It is when and how these activities are performed that make these methodologies different in their approach.

Is Agile Right for Your Organization?

As a small business competing in a fast and volatile market, incorporating some or all aspects of Agile can help you release software more quickly and frequently.

Agile is ideal for startup organizations since it demands continuous testing to produce software that meets customer and industry needs. If the final product is the most important deliverable (rather than the creation of documentation or adherence to contractual obligations), consider Agile – or possibly a combination of both Agile and Waterfall – when organizing your software development process.

Returning to the four main values forming the underpinnings of the Agile Manifesto, consider the following:

  • Individuals and interactions over processes and tools. Remember, Agile is based on collaboration and close working relationships between users and technical experts. If you plan to incorporate Agile, you’ll want to devote more time and attention to customer comments and complaints, so make sure you are prepared to increase those interactions (this may involve building out your customer service team).
  • Working software over comprehensive documentation. Instead of building a product based on extensive requirements, Agile builds products in releasable increments. Make sure your team is prepared and excited to continue innovating and that nobody gets too get attached to a single product or vision.
  • Customer collaboration over contract negotiation. All business dealings require contracts to establish trust and confidence between the two parties involved. However, Agile should introduce enough flexibility that the customer understands there will be both room for change during the development process and an element of control over the final deliverable.
  • Responding to change over following a plan. Sometimes, project planning around software can become so detailed and complex that it becomes nearly impossible to implement successfully. Release schedules, which allow for flexibility and shifting requirements, can help move projects forward while allowing the product to transform as you go.

Nonetheless, you may find an Agile-only methodology too lax and lean more toward Waterfall. To determine how and where to incorporate Agile principles into your software development process, you can also ask the following questions:

  • Do you need to release your product quickly in an industry with rapidly changing competition or regulations?
  • Are you open to crowdsourcing ideas and accepting criticism from customers and non-technical stakeholders, even if it changes the scope of the project?
  • Do you want to build a development team that is self-organized, adaptable and able to think independently?
  • Are you prepared to deliver a product that is significantly different than the initial concept so long as it delivers the functionality promised to customers?

Unlike Waterfall, projects developed under Agile can turn out significantly different than the project initially conceived. As a result, don’t be afraid to mix principles from both methodologies. For example, some Agile projects may require significant documentation. Introducing best practices from Waterfall to tweak your Agile processes will enable you and your development team to combine the best of both methodologies and deliver a final product that will satisfy your customers and build brand loyalty.