menu
Last updated on
Plutora Blog - Agile Release Management, Digital Transformation, Release Management, Test Environment Management, Value Stream Management

What Is the Agile SDLC Model? A Detailed Overview

Reading time 7 minutes

This post is an overview answering a single question: What is the agile SDLC model?

You may also be wondering how it works and why you should care.

We are one-fifth through the 21st century. We can confidently say that software development—and the technology industry as a whole—in this century is different from the previous one in many aspects. Consider the widespread use of automation to make the software development process more efficient; the advent and popularity of the cloud; fast and omnipresent internet connections. And we can’t overlook the emergence and explosion of mobile devices.

Quality software releases at scale with Plutora

Plutora provides a complete toolkit for application delivery. Schedule releases , track dependencies and maintain compliance while accelerating change.

Learn More

Especially when it comes to software engineering, one of the things that mark the beginning of the current era is the rise to prominence of what we call agile methodologies. In this post, we’ll explain what the agile methodologies are and how they affect the SDLC (software development lifecycle.)

This post starts with some fundamentals. We’ll explain what we mean by “Software Development Lifecycle.” After that, we’ll explain agile. There’s a lot of confusion about agile currently, but as you’ll see, it doesn’t have to be that mysterious. It amounts to a manifesto created by about a dozen software consultants who were experimenting with novel ways to develop software and found out their methodologies had a lot in common.

Finally, we’ll bring the two universes together and explore the ways in which agile has impacted the SDLC. Let’s get to it.

Agile Model SDLC: What Is This?

As promised, let’s start with some fundamentals. Before we can understand how agile and the SDLC interact, it’s important we’re on the same page regarding each of these concepts alone. Let’s split “Agile Model SDLC” into two parts and start with the latter. What’s the SDLC? Why should you care about it? That’s what we’ll see next.

Defining SDLC

SDLC stands for Software Development Life Cycle. It refers to the process of planning, designing, building, testing, and releasing an application. The SDLC process is usually comprised of sequential phases: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

SDLC

The Agile Manifesto

When it comes to agile, many misconceptions are floating around, including the common mistake of mixing up agile with specific development methodologies such as scrum.

As it turns out, agile was born as something very simple. In February 2001, a group of 17 software developers met in Snowbird, Utah, to talk about new ways in which they were experimenting with software development methodologies. Prior to the meeting, many of the participants had already been working on their respective development methodologies, such as extreme programming, scrum, and more.

Prior to and during the meeting, they noticed that those various development methodologies had many properties in common. They were all lightweight approaches that worked incrementally and iteratively. Based on their discussions, they wrote and published the Manifesto For Agile Software Development, which many know simply as The Agile Manifesto.

The Agile Principles

The manifesto opens by declaring its values:

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

The manifesto states that, though each of the categories is important, the signatories prioritize the items on the left over the items on the right. In other words, processes and tools are important, but individuals and interactions should be valued more. Comprehensive documentation has its value, but it’s not as valuable as having working software, and so on.

However, the most important part of the manifesto is arguably the listing of its 12 principles. In much more detail than the values, the principles define the important guidelines one should follow when practicing agile development.

Agile Model SDLC: How Does Agile Affect the Software Development Life Cycle?

We’ll now discuss some of the main ways agile impacts the SDLC, particularly regarding its traditional phases.

Requirement Gathering Is No Longer a Fixed Phase

The second of the 12 agile principles states that we should welcome changes in the requirements, even if those changes are late in the process. This directly contradicts development methodologies in which requirement gathering is a fixed phase that happens upfront, such as the waterfall model.

Software Development Happens in Short Iterations

Instead of having fixed sequential phases, agile champions an incremental and iterative development process. At the end of each of those cycles, the customer should receive a valuable increment of working software.

Testing Moves Left

The third agile principle states that working software should be delivered continuously and in as short a timescale as possible. The seventh principle states that working software is the main measure of progress. Those principles imply that software testing, instead of being a fixed stage that happens at the end of the process, must happen as early as possible and in a continuous way. This notion is sometimes called “shift left testing.”

Documentation Moves Down

Software documentation loses a lot of its importance under agile. Not that it’s not important, but the priority is to have working software as a measurable proof of progress. Having huge volumes of documentation is frowned upon for two reasons. First, the effort spent on creating such documentation would be better applied elsewhere—for instance, in creating working software. Second, the problem with many documentation types is that they easily get out of sync with what’s being documented.

Evaluation Happens More Often

Agile, in a nutshell, consists of three steps:

  • First, you do a little bit of work.
  • Then, you stop and evaluate your progress.
  • Finally, you change the way you work based on what you’ve learned by evaluating your progress.

Rinse and repeat.

That’s why, under the agile model, evaluation can’t be a fixed stage in the process. Instead, evaluation is something that has to happen all of the time. It’s only based on the learnings acquired through evaluation that the process itself can improve.

Summary

There are a lot of misconceptions surrounding agile. Some people think it’s just a passing fad, even though the original meeting in Utah celebrates its 20th anniversary in 2021. Others dismiss agile as some kind of marketing gimmick, even though many developers and software organizations around the world generate value every day by applying the lessons of agile.

As you’ve seen in this post, agile isn’t a service or a product you can buy. Agile isn’t even a methodology per se. Rather, The Manifesto For Agile Software Development was, at its dawn, just that: a manifesto. It was a publication in which experienced software consultants outlined a set of ideas and principles they believed could lead to a better software development process.

The agile methodologies propose extreme changes to the way organizations have been developing software for decades. Instead of complaining about the changes to requirements, let’s accept and even embrace the fact that they change. Let’s dramatically shorten the feedback cycles so our clients get some value earlier, and so they can interact with it, critique it, and we can learn from their experience. We can then use that learning to better inform our next iteration. Through that iterative process, step by step, we can then produce software in a way that embraces and accepts the shortcomings in human communication and estimation abilities, and by doing so, generate value faster and more predictably.

Thanks for reading. Until the next time.

Carlos Schults

This post was written by Carlos Schults. Carlos is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.