DevOps is a culture and methodology that an organization can prescribe to aid in velocity, consistency, stability, and flow of value to the market. Often confused with "automation" being the only benefit of DevOps, the core principles behind DevOps offer a common set of ideals that a team can align under and strive to achieve.

Big (A) Agile is a project management methodology that pairs well with DevOps to aid in rationalizing work delivery against a set of guardrails. Agile also provides prescriptive visibility to work being performed ensuring engineers are not being overloaded by overwhelming business priorities.

With those descriptions out of the way, "What term best describes both Agile and DevOps?"

Related Articles


The goal of any organization going through change is to drive consistency in delivery. Without consistency, a technology group cannot adapt to change and a business cannot meet the market where it is at.

By driving consistency, a business gets predictability which is powerful when scoping and planning new work. By understanding real velocity, not aspirational velocity, a business can invest in its people and products to grow at a more sustainable rate.

By driving consistency, technologists get the predictability that they need to make sound and rational decisions about how to approach work. When working against an unpredictable cycle, technology groups will quickly get overwhelmed by the rate of change and produce solutions that do not meet the demands of the market.

▶ Key Insight

In a previous life, I would hear the term "Consistency is Key" and it drove me crazy because nothing was ever consistent. Even though the circumstances of the time did not let that phrase hold a lot of weight, it is actually pretty accurate if you are able to achieve consistency.

Customers, business partners, management, and individual contributors all thrive under consistency. When you can achieve a consistent flow, the number of negative valueless conversations tend to decline and high value conversations that are beneficial to everyone consistently increase. This means you have more time to really analyze what is important in the market ensuring that delivery is the highest quality and value that it can be.

Why Consistency Matters and How it Influences Velocity

Consistency is important for a couple of factors. First, individual contributors like their jobs and are not really interested in persistent interruptions or unplanned requests. While some people may look at those facets as an everyday part of doing business, they can be avoided if mitigation steps are put in place.

When people are constantly interrupted, quality suffers. There is no way around it. It is an absolute like death and taxes. Technology is complex and people need time to focus and go through their problem-solving routines.

Second, inconsistency in delivery has impacts on customers and their delivery. In technology, you are generally not just working on your system. There are consumers of your systems who have expectations of either utilization or integration. By being inconsistent in delivery, you cannot manage the expectations of your consumers.

Lastly, a lack of consistency means that you will never really understand your velocity. Velocity is important because it tells you how much of X you can get by spending Y. Think about it like auto manufacturing, they could turn the manufacturing dials up to 11 in their facilities but then you will end up with cars with 3 wheels or loose nuts and bolts.

A trap that we fall into frequently is confusing aspirational velocity with real velocity. Aspirational velocity is the speed that someone thinks something should get delivered. Real velocity is a measurement of what can be delivered at a given speed.

Real Velocity vs Aspirational Velocity

Aspirational velocity is when a leader says "We need this product to launch by X date!". We have either all been in that position or will be in that position sometime in our careers.

Without proper support, investment, and foresight in planning; aspirational velocity will almost always end with sub-standard products that greatly increase the future cost to the business. Leaning harder on anyone in the delivery space always leads to decisions that are short-sighted toward a narrow goal.

I believe aspirational velocity is firmly rooted in the idea of needing to "take a shot". Checks are constantly being written that others are expected to cash. Sometimes this works out and I would say can be necessary for a startup or green field project. Any organization looking to grow over time should be looking for its tipping point when aspirational velocity needs to transition into real velocity to offer a more reliable work environment for their employees.

Real velocity is based on the idea that you are going to make hard choices about which work is important to feed into a model where delivery is consistent. When more work needs to be done than can be achieved by the current velocity, hard choices will be made to cut work, increase staff, defer work, or invest in current technology to increase velocity.

Any business should have a firm goal of understanding its real velocity and do everything in its power to tamp down or extinguish aspirational velocity.

▶ Key Insight

Velocity matters.

I think we spend too much time in this industry trying to hyper optimize what we have instead of taking a step back and looking at how we are delivering objectively.

Taking an objective look, or utilizing a third party to help you take an objective look, can really make a difference to your delivery flow. Starting with a broken system and trying to optimize is synonymous with redneck engineering: "Just keep adding metal until that thing stands up straight".

Rednecks have given us some amazing inventions like the motorized barstool or motorized coolers, but I would argue a broken clock is also right twice a day.

Taking a step back and asking one simple question can help you understand your velocity and if you need to make a decision around change: "Is my delivery on a straight line conveyor belt?" If the answer is no, then you have some problems you should look at wholistically instead of looking for min/max optimizations of your current flow.

I have another article that describes how DevOps and Agile are related to each other. Primarily, Agile is about lean work being performed against targets and goals with frequent demos of the work being completed to influence pivots. Agile was in need of a technology delivery methodology that could help realize the fundamental mission of Agile.

Check out the card below to read more about how DevOps and Agile are related here!

Runners Up

This question is also asked on a few official exams. I want to make sure that my perspective on DevOps does not overshadow exams that do not have as much wiggle room in their answers.

Brainly answers the question like this:

Agile is refers to an interative approuch which focuses on collaboration, costumer feedback,and small rapid releases,DevOps is considered a practice bringing development and operations teams together.

The problem is, I don't think this answer refers to a specific term. We can look at this and assume that they are looking at Agile and DevOps as two holistically different approaches which are getting merged together instead of looking for commonality between the project management methodology and the technology delivery methodology.

While this may sound really good on a test, there are real business influences that come from each of the facets that they list in their answer.

  • Collaboration: Greater collaboration brings more of a hive-mind approach to problem-solving. Too much collaboration on very large problems can bring analysis paralysis. By breaking problems down into tiny and lean releases, everyone can stay more focused on achieving goals instead of trying to eat an entire elephant all at once.
  • Customer Feedback: Agile focused on getting valuable work products out to the market quickly to reduce investment risk. Getting feedback from customers is a great way to manage risk and pivot quickly if needed.
  • Small Rapid Releases: To further the idea of managing risk, lessening the size of your releases helps you containerize risk into much smaller units. If something isn't working as expected, or the market shifts drastically, it is far less painful to throw that work out and pivot to something more palatable. Additionally, the risk is lowered on incremental improvements to new features for existing functionality since the introduced change should not pose as great of an impact on an already healthy ecosystem. This is something Facebook could learn a thing or two about.
  • Bringing DevOps and Operations Teams Together: This is the typical textbook definition of DevOps. The reality is, DevOps and Agile are about breaking down silos and creating fully cross-functional teams who are able to fully deliver work in a highly efficient and lean way. DevOps and Agile help drive decision-making down as close to the work being performed as possible while offering up a management framework to transparently keep other interested parties informed while work is being completed and shipped.

As you can see, there are a lot of nuances packed into each one of those bullet points.

Intellipatt answers the question like this

A set of values and principles. Because both follow a set of principles and offer the value that is similar.

I believe that this answer is a primarily business-focused answer looking to understand the idea of value in the market. While it is not an incorrect way to look at things, I do not believe it is the most important way to look at DevOps and Agile.

Value is a byproduct of DevOps and Agile. The real benefit to DevOps and Agile is the consistent way that said value gets delivered to the market. This means that you can calculate and quantify value through data-driven decision-making. You are also able to manage market expectations and take potentially larger leaps to satisfy your customers.


The key to any technology product's success is consistency. DevOps and Agile offer consistency while remaining flexible and focused on common non-functional requirements like reliability and stability. Other facets of Agile and DevOps like value are byproducts of a team or teams of teams who fully embrace the complementary delivery methodologies.

How would you boil DevOps and Agile down to a single term? Contact me and let me know!