Agile vs. agility. What are the differences?
7 min read
The terms ‘Agile’ and ‘agility’ are frequently used in the context of business transformations these days. Some folks use Agile and agility interchangeably as adjective and noun. Others treat them as different concepts. So what should you exactly aim for in your organization — Agile, agility, or both? This post will clarify.
In the context of digital transformation, businesses are expected to stay relevant if and only if they possess agility. But should agility really be the sole focus for every organization? Context matters. So it is vital that you mobilize your organization for truly good reasons. And, even more tricky, that you choose the right kind of agile or agility targets.
In this overview, you will get to know all the relevant aspects of agile and agility. Here is what I’ll cover:
1. Initial definitions
2. From Agile 1.0 to Agile 3.0
3. The business agility hype
4. Agile and agility have dimensions
5. Agile and agility can be combined
Initial definitions
Let’s start with some initial definitions of the two concepts:
Agile is a way of thinking with a focus on collaboration, frequent delivery of value, and the ability to deal with functionality changes. It consists of values, principles, methods (e.g. Scrum), and practices.
By default, Agile methods (such as Scrum) are for single teams. Larger organizations use Agile scaling to extend Agile processes and team structure to multiple teams, for example in the form of the SAFe or LeSS framework. Agile was invented in the software industry but nowadays businesses in all industry sectors make use of it.
Agility is the ability of a business as a whole to respond quickly to changes, especially external changes. For example, by adapting business processes or changing customer experiences.
Agility is a crucial factor for businesses that are in a digital transformation. There are many ways to achieve agility, including digital technologies, innovative product design, process agility, and culture shifting.
From agile 1.0 to agile 3.0
Agile first of all optimizes teams
Agile, aka single-team Agile or “Agile 1.0”, became a mainstream software development approach since early 2000 and at that time the scope of Agile was single teams. Traditional teams suffered from functional silos, centralized decisions, document-based hand-offs, and weak customer links. The main gain that Agile brought was higher team performance. Also, through the Product Owner (PO) role, teams became more connected with the business and started to have a higher awareness of business value.
I remember as a coach seeing new Agile teams often busy with implementing Scrum, the dominant single-team Agile lifecycle method. Setting up cross-functional teams, creating backlogs with stories, and planning iterations. Scrum also includes elements from the Lean world such as flow and continuous improvement. So this Agile approach also embedded some important Lean elements.
As a coach, I have often found that new Agile teams tend to “do Agile” rather than “be Agile”. Of course, it’s tempting to concentrate on the Scrum process to get started with your first iterations. But process alone isn’t enough. You also need mindset and culture shifts. Note that the Agile Manifesto articulates the Agile values and principles. Treat them as enablers. Only with this Agile way of thinking will you truly achieve new collaboration, empowerment, communication, and more. Causes of this negligence include time pressure, a strong existing culture, and the Scrum-focused certification classes that many Agile newbies take. We will see later that the holistic agility dimensions take this weakness into account.
Agile scaling addresses multi-team constraints
Due to the scalability constraints with multiple dependent teams, Agile scaling became a new (read: additional) focus for larger organizations. There was a need to have these high-performance teams align on value and collaborate despite team technology focus and inter-team dependencies. With frameworks such as SAFe and LeSS, businesses started to add additional elements such as Agile release trains with program-level backlogs and planning. Spotify demonstrated how people engagement and distributed leadership in tribes, squads, and chapters became useful.
So as you can see, Agile scaling is an addition of Agile elements for multiple teams. In fact, Agile scaling requires single-team Agile methods such as Scrum or Kanban as the basis. Interestingly, we again saw the helping hand of lean in order to align the multiple teams on the same business goals, because single-team PO’s talking with the business was often not enough. We needed a path from business strategy decisions to feature roadmaps. Lean portfolio management is one of the mechanisms to accomplish that.
Agility tries to make the entire business more nimble
Agility can take many forms as we’ll see soon. On the surface, it may only seem to concern the business strategy, i.e. the ability to pivot when market changes happen. But this is not only a question of nimble leadership or marketing teams. You can be nimble in many ways.
What’s also to consider: to achieve agility, you need some Agile elements at the least. If a traditional organization has slow or unreliable planning or slow execution, you may want to start with single-team agile and agile scaling. And once you address execution, you may find that the business or marketing side becomes your weakest area. Focus on the most important constraints, which you can determine through an Agile assessment.
And then there are some necessary support elements. Funding for example. Traditional organizations invest in releases, with a fixed scope consisting of a feature list. Agile and digital businesses are more interested in customer value outcomes rather than outputs. So we need to adapt the funding model on the business side, entrusting product teams (not project teams!) to deliver the maximum value possible in a given amount of time. And this is typical. Agility and Agile are linked, and improvements demand changes in more than one area.
The business agility hype
Business agility versus enterprise agility
Let’s first clear up another ambiguity: enterprise versus business agility. Enterprise agility, like enterprise agile, applies to the entire organization. Enterprise agility thus includes strategic agility, technological agility, all the production-related agilities, and not to forget cultural agility. Business agility is the subset of enterprise agility that relates to the business side: business and marketing strategy. In the meantime, business agility has become such a hype that some have started to treat it as enterprise agility, i.e. for everything. The Business Agility Institute for example has even proposed a business agility model that now contains so-called domains that include all the other agility types.
Regardless of what everyone exactly means by business agility, it’s a term that is definitely trending. And it is often talked about as the silver bullet for making today’s businesses thrive. Is this hype justified? I believe it depends on the situation that your business is in. Does every organization need to pivot its strategy or technologies? I don’t think so. Context matters.
What is true is that the impact of business agility is often more disruptive. Imagine new business models, customer business processes, or new technologies. And businesses that embark on business agility are often in a life-and-death situation.
Another aspect to consider is that agility forces you to have a more serious look at your company culture. That is very important for the Millennials and Gen Z’s in our workforce. These generations flourish in environments that are flexible, social, and technological. Agility helps to drive those shifts.
Talking about generations, we often call agility also ‘Agile 3.0’, after two earlier generations with team-level Agile methods (Agile 1.0) and Agile scaling frameworks (agile 2.0). Looking at the timeline of the introduction, the sequencing is correct. However, in my opinion, they are not really generations because agility is not a replacement for single-team agile or program-level Agile scaling. Agility is simply another dimension that can help as an addition to a particular business context.
Agile and agility have dimensions
Agile and agility capabilities
Both performance and nimbleness can apply to different dimensions. Performance can mean many things. Is it about speed, quality, productivity, customer satisfaction? Nimbleness can relate to strategy pivotability, and product innovation, but also to organizational responsiveness, or workforce flexibility during vulnerable times like COVID-19. So we see here a set of organizational Agile and agility ‘capabilities’.
In order to build these capabilities, you need to develop and roll out both the changes and the skills. Changes affect your work methods, organization structure, governance and culture, and I recommend you drive this in incremental waves. Agile ways of working require different mindset, knowledge and behaviors so upskilling the involved teams should be an integral part of any Agile change or transformation effort.
Agile and agility can be combined
To sum things up, Agile and agility have different targets. Agile’s primary focus is operational performance. Agility on the other hand tries to make the business more nimble. Agility requires agile elements, it’s a sort of agile+. As an example, if you want to pivot a product strategy, you need short delivery cycles. And vice versa, short delivery cycles are great but your benefits are limited if your strategy is slow or static.
To thrive as a business, you therefore should look at both dimensions. How much weight you put on each dimension, and which type of Agile and agility elements you enlist, that should depend on your business goals.
The context of digital transformations is a perfect example where you need both Agile and agility. In a related article, I explain how Agile Way of Working takes the holistic approach where Agile and agility provide key organizational capabilities to catalyze digital transformations.
What’s next? An Agile Way of Working.
What you see more and more in today’s organizations - software and non-software - is that we take a holistic approach to Agile, called Agile Way of Working. Still mindset-based, this is now a total work approach where we focus on building an Agile organization tailored to the strategic objectives and current context. In my Pragmatic Guide to Agile Ways of Working, you can find all factors that you need to consider to adopt such a work approach. Also, check out my article 9 Changes to Build an Agile Way of Working Backbone in which I describe concrete changes that you can start off with.
