Why Prioritizing Continuous Delivery in Agile is a Must

These days it seems like a foregone conclusion that every team should probably be using Agile for software development. 

You read that right: I’m capitalizing Agile (as if it’s really a thing) because time has proven it’s essential to software development. We all know that Agile development delivers value to stakeholders faster and with fewer issues. 

We don’t want to rely on a single software launch to determine success. Instead, Agile gives us a framework to deliver in smaller increments, from source code development to full-on production.

Agile is also flexible and allows us to continuously evaluate project requirements, assess results, and create action plans that help us adapt to change. 

However, like all things, Agile evolves. 

That’s where the emphasis on Advanced Continuous Delivery (CD) comes in.

Let’s review the key points of Continous Delivery.

Continuous Delivery is the part of the software development process where you actually deliver the code you’ve been working on. It’s the part of Agile we all love because it closes the feedback loop. 

As a refresher, Martin Fowler, author of Continuous Integration, outlined some key points of continuous software delivery that include: 

• Continuous Delivery practices ensure the software is deployable throughout its entire lifecycle
• Development teams should prioritize deployability over new feature development
• Developers should receive fast, automated feedback on system production readiness any time changes are made
• Teams should be able to perform push-button deployments of any software version to any environment at any time

Continuous Delivery is at the core of Agile methodologies.

At the core of Agile is the desire to satisfy clients by continuously delivering value-adding software while communicating effectively with all stakeholders and team members. 

Dozens of methodologies sprang up from there, including:

Scrum

Scrum is one of the most popular Agile methodologies that maximizes development time towards achieving a goal (referred to as the “Product Goal”). Cycles or stages of development are called “sprints”, which are completed in succession as the development team achieves the Product Goal.

Kanban

Kanban is a word derived from Japanese that links to the “just in time” concept. The methodology unfolds on a “Kanban board” or table divided into columns illustrating flows within the software production project. 

Information on the table changes as the project evolves, and new “cards” are created as new tasks arise. With an emphasis on communication, this method lets everyone know the project's status at every stage of development. 

Crystal

Crystal is a flexible framework that allows team members to develop their own processes. Rather than focusing on existing guidelines or tools, this methodology is based on individual interaction within a unified environment. Central to this development process is synergistic collaboration to unlock the creativity and efficiency required to complete the project successfully. 

Lean Development

Lean development was created by Lean Manufacturing, a division of Toyota. This framework contains seven essential principles: 

1. Removing things that don’t bring value to the project
2. Quality software development
3. Creating knowledge
4. Prioritizing commitments within the project
5. Fast delivery
6. Team respect
7. Perfecting the development sequence to create real value

Extreme Programming

Extreme programming improves software quality and team responsiveness through short development cycles, frequent releases, and numerous checkpoints where new requirements can be integrated. Some XP principles include:

• Programming in pairs
• Not developing features unless they are requested
• Extensive code reviews
• Unit testing of all code
• Flat management structures

You might fall short if you don’t emphasize Continuous Delivery in your chosen Agile framework.

You may be using one of these methodologies, or a Frankenstein built out of a handful of them. But no matter how Xtremely Scrumified your Kanban process is, you’re falling short of practicing Agile if you aren’t practicing Continuous Delivery.

Worse still, you’re cheating end users out of the bliss they’ll feel while using that super-awesome game-changing feature you just finished building!

Now let’s look at all that in the context of the Continuous Delivery Pipeline.

The Continuous Delivery Pipeline

The Continuous Delivery Pipeline organizes all the activity required to transform new functionality or features from the ideation stage to user release.

The four main parts of the CD pipeline include:

Continuous Exploration

Continuous Exploration (CE) is the process where we identify and revisit the original market problem or customer need and devise a solution that meets that demand. This leads to the creation of a Minimum Viable Product (MVP) or Minimum Marketable Feature (MMF).

Throughout the process we continue to refine those concepts via market research, revisiting user stories, and customer feedback. This allows us to explore if the solution or existing architecture requires modification. 

Any new features or capabilities are then defined and prioritized in the program backlog.

Continuous Integration

Continuous Integration (CI) is where we take action to implement features or capabilities identified in the previous phase. Once completed, the work is integrated into the product and committed to version control. It is additionally subjected to unit testing using software (i.e. Kubernetes) that determines if the commit passes various integration tests. 

If successful, the resulting changes are released to a staging environment for monitoring and validation.

Continuous Deployment

The Continuous Deployment process (CD) takes the changes made in the previous phase and moves them to the production environment. During this stage, the organization decides when these new features will be rolled out to customers. In addition, developers can roll back, fix, and respond to critical issues at this time. 

The process from Continuous Integration and Continuous Delivery to Continuous Deployment is a step toward automated deployment in the software development lifecycle. Practicing Continuous Deployment requires that every change is solid enough that manual intervention is not required before release.

Release on Demand

Release on demand is where the organization decides the optimal timing required to release feature changes. Depending on the business, the changes can be released to all users at once or staggered to mitigate any possible risks. 

In summary, Continuous Exploration seeks to continuously validate the scope and purpose of the project. Continuous Integration is where developers frequently test new code commits to a project’s main repository to ensure compatibility. Continuous Deployment takes CI/CD further by ensuring new features are automatically deployed, and Release on Demand is where the business times the release of new features according to their requirements.

Let’s not forget how Continuous Delivery shaped the Agile movement.

The Agile Manifesto emerged from a desire to develop an alternative to current complex and unresponsive development processes. The top principle reads as follows: 

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” 

So even back then, the manifesto authors emphasized the importance of Continuous Delivery. By making it a key tenet in the document, CD helped shape the movement and all of the flavors of Agile that are out in the wild today.

Wrapping it Up

Your stakeholders have told you exactly what they think they want, and you’ve built it. 

So why wait to ship it? 

The sooner you ship it, the sooner they can either start gleaning business value from it - or tell you that it doesn’t measure up. Either way, delivering code produces tremendous value.

As the manifesto says, our highest priority is to satisfy the customer through early and continuous delivery of valuable software. That means delivering software frequently, from a couple of weeks to a couple of months - with a preference for the shorter timescale.

So now that we’ve identified the problem, it’s up to us to refactor our processes, so we start delivering early and often. 

That way, everyone wins.