What is Agile?

Agile is a term that describes approaches to software development that emphasize incremental delivery, team collaboration, continual planning, and continual learning. The term Agile was coined in 2001 in the Agile Manifesto. The manifesto set out to establish principles to guide a better approach to software development. At its core, the manifesto declares four value statements that represent the foundation of the Agile movement. As written, the manifesto states:

We have come to value:

• 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 doesn't imply that the items on the right side of these statements aren't important or needed. Rather, items on the left are simply more valued.

Agile methods and practices

It's important to understand that Agile isn't a thing. You don't do Agile. Rather, Agile is a mindset that drives an approach to software development. Because there's no single approach that works for all situations, the term Agile has come to represent various methods and practices that align with the value statements in the manifesto.

Agile methods, which are often called frameworks, are comprehensive approaches to phases of the DevOps lifecycle: planning, development, delivery, and operations. They prescribe a method for accomplishing work, with clear guidance and principles.

Scrum is the most common Agile framework, and the one that most people start with. Agile practices, on the other hand, are techniques that are applied during phases of the software development lifecycle.

• Planning Poker is a collaborative estimation practice that's designed to encourage team members to share their understanding of what done means. Many people find the process fun, and it has proven to help foster teamwork and better estimates.
• Continuous integration (CI) is a common Agile engineering practice that involves integrating code changes into the main branch frequently. An automated build verifies changes. As a result, there's a reduction in integration debt and a continually shippable main branch.

These practices, like all Agile practices, carry the Agile label, because they're consistent with the principles in the Agile manifesto.

What Agile isn't

As Agile has gained popularity, many stereotypes and misinterpretations have cast a negative shadow on its effectiveness. It's easy to say "Yes, we're doing Agile," without any accountability. Keeping this point in mind, consider a few things that Agile isn't.

• Agile isn't cowboy coding. Agile shouldn't be confused with a "we'll figure it out as we go" approach to software development. Such an idea couldn't be further from the truth. Agile requires both a definition of done and explicit value that's delivered to customers in every sprint. While Agile values autonomy for individuals and teams, it emphasizes aligned autonomy to ensure that the increased autonomy produces increased value.
• Agile isn't without rigor and planning. On the contrary, Agile methodologies and practices typically emphasize discipline in planning. The key is continual planning throughout the project, not just planning up front. Continual planning ensures that the team can learn from the work that they execute. Through this approach, they maximize the return on investment (ROI) of planning.

"Plans are worthless, but planning is everything." — Dwight D. Eisenhower

• Agile isn't an excuse for the lack of a roadmap. This misconception has probably done the most harm to the Agile movement overall. Organizations and teams that follow an Agile approach absolutely know where they're going and the results that they want to achieve. Recognizing change as part of the process is different from pivoting in a new direction every week, sprint, or month.
• Agile isn't development without specifications. It's necessary in any project to keep your team aligned on why and how work happens. An Agile approach to specs includes ensuring that specs are right-sized, and that they reflect appropriately how the team sequences and delivers work.
• Agile isn't incapable of accommodating unplanned work and other interruptions. It's important to complete sprints on schedule. But just because an issue comes up that sidetracks development doesn't mean that a sprint has to fail. Teams can plan for interruptions by designating resources ahead of time for problems and unexpected issues. Then they can address those issues but stay on track with development.
• Agile isn't inappropriate for large organizations. A common complaint is that collaboration, a key component of Agile methodologies, is difficult in large teams. Another gripe is that scalable approaches to Agile introduce structure and methods that compromise flexibility. In spite of these misconceptions, it's possible to scale Agile principles successfully. For information about overcoming these difficulties, see Scaling Agile to large teams.
• Agile isn't inefficient. To adapt to customers' changing needs, developers invest time each iteration to demonstrate a working product and collect feedback. It's true that these efforts reduce the time that they spend on development. But incorporating customer requests early on saves significant time later. When features stay aligned with the customer's vision, developers avoid major overhauls down the line.
• Agile isn't a poor fit for today's applications, which often center on data streaming. Such projects typically involve more data modeling and extract-transform-load (ETL) workloads than user interfaces. This fact makes it hard to demonstrate usable software on a consistent, tight schedule. But by adjusting goals, developers can still use an Agile approach. Instead of working to accomplish tasks each iteration, developers can focus on running data experiments. Instead of presenting a working product every few weeks, they can aim to better understand the data.

Why Agile?

So why would anyone consider an Agile approach? It's clear that the rules of engagement around building software have fundamentally changed in the last 10-15 years. Many of the activities look similar, but the landscape and environments where we apply them are noticeably different.

• Compare what it's like to purchase software today with the early 2000s. How often do people drive to the store to buy business software?
• Consider how feedback is collected from customers about products. How did a team understand what people thought about their software before social media?
• Consider how often a team desires to update and improve the software that they deliver. Annual updates are no longer feasible against modern competition.

Forrester's Diego Lo Guidice says it best in his blog, Transforming Application Delivery (October, 2020).

"Everything has dramatically changed. Sustainability, besides green and clean, means that what we build today has to be easily and quickly changed tomorrow. Strategic plans are short-term, and planning and change are continuous." — Diego Lo Guidice, Forrester

The rules have changed, and organizations around the world now adapt their approach to software development accordingly. Agile methods and practices don't promise to solve every problem. But they do promise to establish a culture and environment where solutions emerge through collaboration, continual planning and learning, and a desire to ship high-quality software more often.

Next steps

Deciding to take the Agile route to software development can introduce some interesting opportunities for enhancing your DevOps process. One key set of considerations focuses on how Agile development compares and contrasts with an organization's current approach.