Nimble Vs Agile: Why is a unique term not enough?

Agile and nimble are not the same thing. An in-depth look at the key differences between nimble and agile, and an overview of how to be nimble.

I recently came across an article (1) with a concept I didn’t know about yet:

NIMBLE: an organization’s ability to navigate unpredictable business environments and operationalize innovation through a scalable ability to understand and respond to change with precision and speed.

I went to the dictionary to look up the translation and there it was:

NIMBLE (adjective): agile.

At this moment I asked myself the same question that you must be asking yourself:

Why the hell did they invent a new word if it was already hard to assimilate the other one?

The movement that flourished with agile software development(2) has been hammering into our heads for over two decades that we need to act in a certain way so that we can react and change direction quickly.

The 4 values ​​from the agile manifesto for software development:

  • individuals and Interactions more than processes and tools.
  • working software more than comprehensive documentation.
  • collaboration with the customer more than negotiating contracts.
  • respond to changes more than following a plan.

I learned that this concept could be applied not only to software but also to other areas of an organization calling it business agility and, so far, I was satisfied with the concept and just calling it “agile“.

But concepts are abstractions that exist in our minds to understand the real world. When we give the same name to different concepts, our ability to understand and articulate the world is restricted. The ability to articulate complexity depends on naming and associating definitions that clearly represent our ideas.

Let’s see an example:

We’ve heard that the Eskimos have more than 50 words to describe snow. Some researchers from the University of Glasgow who are creating the first historical dictionary of the Scottish dialect say they have already gathered 412 terms just to talk about snow in different terms: The most obvious, “snaw”, standard snow; “sneesl”, when it starts to snow; “skelf”, for a large snowflake; “snaw-ghast”, for the images that snow forms; and “snaw-pouther”, for fine snow; and so on…

There are so many nuances! This is difficult to understand for someone like me, who lives in a tropical country and saw snow for the first time only after the age of 30 and for a weekend trip abroad. But for those who live in a cold country, the ability to communicate about the climate and its nuances is essential, and this requires a larger set of terms to represent different concepts.

In order to better articulate our ideas, we need a broader vocabulary. If you deal with the management of initiatives, organizations, or businesses, it’s worth differentiating between “agile” and “nimble”.

The difference between agile and nimble

I recently did an interview with Keith Ellis about the difference between these two terms and you can watch the result here.

The terms Nimble and Agile have frequently appeared in the context of scientific publications on methodologies and practices used in project management and product development. However, they are presented in different ways in their approach and objectives.

Agile is a management philosophy that emphasizes flexibility, collaboration, and customer satisfaction. It was originally created by a group of software developers who were frustrated with the traditional, rigid approach to software development. This group met in 2001 and created the Agile Manifesto (2) with a set of values ​​and principles. Since then, Agile has been embraced by organizations across industries as an approach that emphasizes iterative and incremental product delivery, close collaboration between customers, business stakeholders, and the development team, and a focus on delivering the highest-valuable features first. 

Nimble, on the other hand, is a capability made up of speed of understanding and adequate responsiveness. It’s probably what companies that adopt an agile approach usually look for, but it doesn’t depend on how to do it, but on the result obtained. There is no single person or organization credited with creating this concept, but it has been used more recently and is often used to emphasize the importance of speed and flexibility in the business environment and differentiate this ability from the way how it can be achieved.

In summary, Agile is a way to add value through collaboration and flexibility, while Nimble is the ability to react quickly and efficiently.

Agile vs Nimble companies

The table below distinguishes these 2 concepts in a matrix that clearly shows why it is necessary to distinguish them. The matrix asks a question on each axis and expects responses between 0 and 100%:

  • X-axis: Does the company work in an agile way?
  • Y-axis: Is the company nimble?

matrix nimble vs agile

Quadrant IV of this matrix represents companies that work in an agile way and are not nimble. You certainly know some of these. These are companies that strictly use the practices and concepts of the agile approach such as backlog management, decomposition of user stories, short-term iterations, retrospectives, etc., but are not flexible and have difficulty understanding and reacting to a new business situation.

Quadrant I, on the other hand, presents companies that do not follow the agile approach but are extremely skilled in understanding new needs and reacting quickly to them. You may have seen some of these too. They follow a traditional approach, oriented towards detailed long-term planning, but manage changes to their plans quickly whenever a new reality imposes itself on their business context, understanding the impacts and mapping appropriate solutions to maximize value.

Like a lot of people, I had been calling everything agile: both the capacity and the form of work. The lack of the term Nimble made it difficult for me to clearly articulate the situations shown in this matrix and thus be able to deal with these issues more clearly. What companies really seek is to be nimble.

How to be nimble

The IIBA carried out an in-depth study on companies that stand out in relation to their competitors and found that those that are recognized as the best among their peers have 2.5 times more nimble capability than the laggards.

That’s right, the nimble is measurable. But its measure is different from the assessment of the maturity level of an organization’s processes under a certain working method.

  • Maturity measures how well the organization’s processes are structured and can be repeated and continuously improved.
  • Nimble measurement does not look at processes, but at results. Nimble is a measure of performance.

Interestingly, the study does not show a direct correlation between companies that adopted agile practices and those that developed nimble as a capability. Following a method is indeed important and is considered one of the key dimensions for an organization to become nimble (see later), but it doesn’t necessarily have to be an agile method. The important thing is that the method must be adequate to the needs of the organization.

For a company that wants to develop a nimble capability, IIBA points out four dimensions that need to be developed so that an organization becomes adaptable with both precision and speed, in other words, nimble:

The 4 dimensions of a nimble organization (IIBA, 2022)

Enable and empower people

Develop skills, processes, techniques, technologies, and environment so that employees can perform their work efficiently and provide psychological safety, decentralized decision-making authority, openness to a respectful challenge of ways of working, ending unproductive work and being results-oriented.

Nimble practices

IIBA lists 8 observable and measurable practices that support the skills, methods, and characteristics needed to effectively enable and empower people to do their jobs.

The 8 practices for the nimble organization (IIBA, 2022)

Work methods

Assuming that a single specific method will drastically change performance is a mistake. There is no “silver bullet”. Not having any method and doing it one way each time (ad-hoc) is even worse. Companies with less nimble capability are those who cannot institutionalize any method to be used regularly.

To develop the nimble capability, companies should institutionalize a small portfolio of methods and adjust them to the specific needs of the organization. Based on the researched data, no specific method stands out over the others. The important thing is the appropriateness and consistency in its use.

Business Analysis

It is essential to develop a Business Analysis Mindset in the organization and to empower employees with business analysis skills, tools, and practices to support the 8 nimble practices previously described.

Business analysis is defined in the BABOK® guide (3) as“the practice of enabling changes in a company, by defining needs and recommending solutions that add value to stakeholders”.

The role of business analysis is central so that the understanding of needs and the design of solutions are aligned with the strategic goals of the organization. Those responsible for business analysis in a company need to be people who are accountable not only for performing tasks, but for achieving business outcomes. They are transforming leaders and change agents.

Conclusion

Although the terms agile and nimble are often understood as synonyms, in a management context, they are not the same thing. Agile is a specific approach to getting the job done, while nimble refers to an organization’s capability to respond quickly to changes and opportunities.

Articulating these concepts separately allows us to identify the specific situations where each method of work is most appropriate and to investigate other ways of developing the desired capabilities in our organizations.


References

  1. Being nimble – The Scalable Capability for Organizations to Sense and Respond to change; IIBA, 2022
  2. Manifesto for Agile Software Development
  3. BABOK Guide® – A Guide to the Business Analysis Body of Knowledge, IIBA, 2009