Agile at Risk

Agile is all around us: Just open LinkedIn, Facebook, Instagram and recently even TikTok and you will see everybody asking you to join their Agile Certification program to prove, that you can follow a certain framework or methodology. And yes: Most certification programs are about following the framework, it is rarely about implementing them. We believe, it is time to claim back the Agile Manifesto.

And in my humble opinion, it is still true: To survive the complexities of the 21st century and to be ready for future challenges, the ideas behind the Agile Manifesto are still a state-of-the art mindset (among others such as the 8 guidelines of Complexity Thinking in Management 3.0 or the principles behind the #betaCodex). It has been proven to support minimizing risk and responding effectively to a constantly changing context. However, you do not need a certification in SAFe, Scrum, LESS or another framework to become Agile (even though some of those frameworks might inspire you).

The Agile Industrial Complex

When starting with a new team or organization, our first question is: “Why do you want to be Agile?” And most teams (often even the company leaders) are actually unable to answer that. In one case, a director even told me: “It is good for our brand”. Agile has become a self-service.

When we ask about the greatest challenges about introducing Agile, most teams use immediately terms from Scrum: The PO is not available, the team does not want to attend the Sprint Retrospective, The Sprint Backlog changes within the Sprint, etc. In other cases, the teams complain about well-intended but flawed concepts, such as Velocity or Planning Poker for estimations.

PO, Sprint Retrospective, Sprint Backlog, Velocity or Planning Poker – none of those terms are part of the Agile Manifesto. Some of them are not even part of the Scrum Guide. In Vietnam, we often meet individuals, who use Agile and Scrum interchangeable. Albeit not the fault of the teams nor the organization, those examples show, that the frameworks and methodologies have claimed the term Agile.

Consequences of focusing on frameworks

And that can become disastrous, when we look at organizations. In one of our agile Assessments, we used the term “Frameworkitis” when we observed them switching back and forth between different Agile frameworks (from “Spotify” to LeSS to Scrum@Scale). The organization had a high turnover rate and team members were afraid to try new things as they thought, it would mean changing to yet another framework. Instead of building the fantastic product, the teams were hesitant to look at improvements in the fear of changing too much.

In another instance, I talked to a friend, who was interviewing for a big company to become one of their Agile Coaches. In between different interview sessions, my friend walked through the offices with an already employed Agile Coach and suddenly hesitated in front of a wallpaper explaining the desired final state of agility. While figuring out the details of the wallpaper, the other Agile Coach remarked: “Yeah, we paid a million USD to a big consultancy for this picture”.

This is the biggest flaw: Agile Transformations are seen as transactions with an end state. We transform from one state into another state the final state). With this mindset, we are making the same mistakes as the KODAKs and the NOKIAs in the world. We believe that we do have all the answers for the future, and all we need to do to prepare ourselves for these answers of the future. But to achieve that, we can only rely on information from the past.

Two defining Agile sentences

Agile transformations (or journeys for the lack of a better term) should be defined by the 2 following sentences:

• Facts are only from the past: In complex environments, we cannot predict the future. We never know what the future will bring. Therefore, we need to be open to explore the future and then learn from the past. Only, what happened in the past, is the absolute truth. Everything in the future is an assumption or best guess.
• Every organization is a construct of human interactions, and every interaction is different from the other. Frameworks work, when we have predictability. But if all interactions are different, then that means, that all the challenges might look similar, but have different solutions. There is no predictability. Hence, a one-size-fits-all does not work then.

Both sentences are based on the absolute foundations of Agile: Supporting a sense-making mechanism in an increasingly complex environment. The success of creating and implementing Agile structures is very tightly coupled with the ability to understand complex adaptive systems.

Agile is not just an idea or a theory. It is the lowest common denominator of long-term applied practices in the real world*. But it is also based on interdisciplinary scientific principles of systems, complexity, game and motivational theory.

(*) nearly all signatories of the Agile Manifesto applied the Agile mindset through (parts of) their frameworks before signing the Manifesto as early as the mid-1980s.

Claim back the Agile Manifesto

The original ideas behind the Manifesto of Agile Software Development in 2001 were about “uncovering better ways of developing software by doing it and helping others do it”. You can replace the word ‘software’ with ‘solutions’ in case you are not in Software / IT). It is about UNCOVERING, not PRESCRIBING. Frameworks prescribe (sometimes even promising magical results). If we truly want to uncover, then we need to enable and empower individuals.

But there is a problem with that. I remember preparing an Agile introduction workshop for a client some years back. While discussing the agenda with the sponsor of the initiative, I mentioned to introduce the Agile Manifesto with an exercise. The sponsor immediately intervened: “They know that already, we can skip that.” After a brief discussion, we agreed, that I can do a quick experiment in the workshop. I would show the Manifesto on the screen and ask if anybody in the workshop has ever seen this before.

From the 10 participants, 2 hands went up: The sponsor’s and the PO’s. All others never ever have seen the Manifesto. But they all hated the Daily Scrum and the Retrospective. How can we ask individuals to make better decisions themselves, if we show them only results of the decision? Why are we not focusing on the guidelines to empower them to make better decisions? Wouldn’t that be more sustainable?

Changing ways of working cannot be mandated

Change does not happen because Management, Coaches or Scrum Masters tell other people to change. But this is still the prevailing method of introducing change. When talking to Managers, Change Agents, starting Agile Coaches, Scrum Masters or Product Owners about bringing change into the organization, there is one statement, which constantly comes up in the discussion: “We need to convince our team to do the right thing.”

If you need to constantly convince someone to do the right thing, is it then really the right thing? If a new way of working is too much work for your team to implement, is it then really helping you to improve?

Change does happen, when individuals and teams understand the context they are in by themselves and have tools at hand, which helps them to navigate through that context. When we start with Agile transformation, empowerment and invitation is more important than processes and tools. We need to support understanding of the Agile values & principles instead of following some processes and tools.

“Agile” is irrelevant, the way of working counts

Since Agile became a mantra and is overused, organizations and individuals are more and more tired of hearing about Agile. But that is not significant. I am an Agile Coach and believe the word “Agile” is over glorified. The word “Agile” is irrelevant. The ideas of Agile are based on scientific principles of System, Complexity, Game and Motivational Theory. The 4 values and 12 principles are adapted from over a decade of testing and adapting different ways of working. Only then, we claim back the Agile Manifesto.

When we are confronted with an increasingly complex environment, doing, what we always did, will never work for the future. If we do not know, what the future will bring, copying & pasting what worked in the past does not prepare us for the future. The ideas of the Manifesto of Agile Software Development were not to change the old way of working into one defined new way. through one or many frameworks.

The idea was to enable individuals, teams and later also organizations to look differently at their work. It should help to uncover ways of doing that. Then, they would see, what their individual challenges are, so they would change their way of working for better effectiveness in the company. And this is not a transformation – it is a constant journey.