Agile software development emerged in the early 2000s as a new paradigm for delivering quality software products that satisfy the needs of the business in a timely fashion. Throughout the 1990s, the application of traditional project management methodologies to software development products led to considerable frustration. The significant time lag between the establishment of project requirements and the finalized project delivery meant that the resultant software often failed to meet the needs of the business. Many software projects were canceled for this reason, and software developers began to wonder whether there was a better way to manage the product development process.

So it was that a group of 17 thought leaders met in Oregon in the year 2000 and established the agile manifesto, a new way of thinking about software development that has evolved into the methodology we know today as agile software development. In this blog, we'll delve into the key differences between the traditional "Waterfall" development model and today's Agile software development model. We'll also analyze the agile software development life cycle and try to understand why so many developers prefer this model for delivering better software that consistently meets the needs of the business.

Traditional Software Development: The Waterfall Model

In the 1990s, enterprise companies were beginning to recognize that they could use software developers to build products that would improve their organizational efficiency. A warehousing company might want a database software that allowed them to electronically manage inventory or keep track of their shipments and customer data, for example. Many enterprise organizations hired software developers and began the processing of developing applications, either for commercial or in-house usage, using traditional project management methodologies. This is where all of the problems started.

In the world of software development, the application of traditional project management methodologies to the software development process has come to be known as the Waterfall Method or Waterfall Model. In the Waterfall method, the project is divided into steps and each step must be completed, finalized, and set in stone before the project team can move on to the next part of the process. Like a waterfall, this model is unidirectional: the project advances in a stepwise fashion from one stage to the next until complete, just like waterfalls from the top of a cliff to the bottom.

We can summarize the steps in the waterfall development process as follows:

1. System and project requirements are collected and captured in a project requirements document

2. The requirements are analyzed to develop models, schema, and business rules that will inform the design of the software

3. The software design process takes place and software architecture is produced

4. Programmers write the code, conduct basic unit tests, and integrate the code into a final product

5. The final product is tested exhaustively to ensure it functions correctly and satisfies the initial project requirements

6. Installation, data migration, and maintenance of the final software product along with support services are provided in the final step

Early proponents of agile software development realized that the stepwise, linear development approach associated with the waterfall model was too restrictive. For example, software developers could only begin to design a product once the requirements had been reviewed and finalized - but what if the requirements changed during the design process? What if they changed while the code was being written? What if the business organization saw the software in the testing phase and asked for more features? Under the waterfall model, there was no structured process for software development teams to respond to the changing needs of the business, or to collect ongoing feedback that could help to avoid costly redesign and redevelopment activities.

With all of these issues identified by the late 1990s, it was time to create a revolutionary new process for software development - one that would become known as Agile.

The Key Values of Agile Software Development

The unique insight driving the Agile paradigm is that software development is best conducted as an iterative process. Rather than establishing an exhaustive set of requirements at the beginning of a project and leaving no room for changes during the project, the early proponents of Agile recognized that it was necessary to follow a process that could respond effectively to changing business needs and feedback from the customer. The early founders of Agile summarized their new process with four principles that can be summarized as follows:

1. Software development should be defined by the actions of individuals and their interactions, rather than being driven by processes and tools. When individuals are restricted by a rigid process, there is less communication and opportunities to change the project to meet consumer needs can be lost.

2. While it is important to produce adequate software documentation, developers should prioritize the production of working software over the creation of exhaustive technical documentation. In Agile, user requirements are frequently captured as user stories, making it easier for a developer to start working on a feature without an exhaustive list of technical requirements.

3. Rather than providing input exclusively in the initial project design phase, the customer should be involved collaboratively during the project, such that the development team can incorporate their feedback into future iterations.

4. While it is important to follow an overarching plan for the software development project, there is even more value in being able to quickly respond to changes, such as a change in user needs, a new piece of feedback, or a newly requested feature. The need to respond quickly to change is at the heart of the Agile methodology.

Agile methodology was created by a group of software developers who saw an increasing need for customer collaboration at all stages of product development, not just during the initial collection of customer requirements. With Agile, customers are involved in providing feedback and user acceptance testing at every step of the way.

The Agile Software Development Life Cycle

The Agile software development life cycle is an iterative process. Unlike the waterfall method, which progresses in a stepwise fashion from beginning to end, Agile development works in small iterative chunks called Sprints. Project managers employing an Agile methodology must still capture initial project requirements. These requirements can be divided into specific product features that will each become the focus of a future Sprint.

For each sprint, which typically lasts 2-4 weeks, the project manager identifies specific goals for developers to achieve. These could include building a new feature, updating a previous feature, or incorporating feedback from the customer. In each sprint, developers will:

1. Establish working requirements for the specific feature they are building

2. Design and write the software according to the established requirements

3. Conduct internal and external quality testing to ensure the feature is working properly

4. Integrate the feature into the production environment/incorporate the newly built feature into the product

5. Collect feedback from customers and stakeholders about the new feature

Once a sprint has been completed, the project manager can choose another feature from the product backlog that will become the focus of the next sprint. Once feedback has been collected on the results of a sprint, the development team can work to incorporate that feedback into future iterations.

User acceptance testing is incorporated as part of the feedback process in each sprint, meaning that the customer is more actively involved in the software development process than they would be with the Waterfall method. Using sprints to build one feature at a time also means that developers will produce functional features at a much earlier stage in the process.

Rather than having a coding team that builds every feature at once before advancing to the testing phase, Agile encourages teams of developers to build one functional feature at a time before proceeding. This often means fewer issues with system integration, less time wasted on product testing and better adherence to the customer, user, and business requirements throughout the project. In addition, Agile teams frequently incorporate test automation solutions that make it easier to verify software function on an ongoing basis, even after major changes have been deployed.

Software developers working in the Waterfall method produce the code in its entirety before entering a major testing phase that can consume up to 50% of project resources. With Agile, developers use automated testing, unit testing, and user acceptance testing more frequently, with the goal of having a functional (though incomplete) version of the final product at each iteration. As a result, Agile teams reduce costs and save time when testing their final product.

Summary

Agile represents a fundamentally different approach to software development when compared to the traditional Waterfall model. While the stepwise, linear approach of the Waterfall method is considered too rigid, Agile enables developers to progressively build better products that incorporate customer feedback and are more likely to satisfy the needs of the business.

For developers working with embedded systems, agile software development means building out one system feature at a time and testing it thoroughly for functionality and user acceptance before moving on to the next feature. Tools like the Beagle I2C/SPI Protocol Analyzer can help developers verify that their embedded software is functioning as expected before they move on to develop the next feature for their device. Advanced debugging and development tools can help developers build better products and shorten their time to market.