Enterprise Agile, Business Agility, Agile Transformation, BizOps, Adaptive Organizations, AgileSHIFT, SAFe, Nexus, LeSS. Just keep it going, there are so many buzzwords and frameworks with nuances over the same thing. There are many opinions about what’s what and what’s not, but in the end the only things that really matter are: What outcome is coming from the business —how is the enterprise actually run and perceived, and what does it achieve.

Doing and understanding Agile is easy, because the activities are simple and structured, and the principles are understandable and closely related to common sense — even if common sense also is subject to change. But it does not make you more adaptable, which is the primary goal of agility.

Being Agile, however, is about changing how people think and act — internalizing a new mindset, not just for an individual, but for an entire organization. This requires training, drilling and coaching. Countless iterations, failing and learning from failures — and even then, people tend to fall back and need more iterations. History has proven, though, that it is possible, and in fact when in great need, the transformation can go relatively fast.

This is the first article in a series that describes why this is important and how your organization could start the journey towards agility.

Every organization has an enterprise architecture — whether it knows or not, whether it’s described or not, and whether it’s planned or not. Just like every building has an architecture. But what is really enterprise architecture? What defines it? To really understand the concept of enterprise architecture, we’ll stick to building architecture a bit more.

A building can have beautiful architecture, even though is wasn’t drawn by an architect, or was planned in detail. Sometimes wonderful architecture seems like it appears out of nothing, like it was there all the time. Other times it’s a result of comprehensive planning and detailed work of an architect. In either case, the only thing that really matters is how the building is perceived by it’s users, how it’s used and how it actually works.

Many architects carefully plan these elements, but it has happened more than once that they haven’t understood their users well enough. Even though an architect creates a lot of different drawings from different perspectives, with different level of detail and those certainly are important for the craftsmen and developer, I believe it’s easy to understand that those drawings and models are not architecture. Almost none of the users will actually see them, and they are only a representation of some parts of the actual building.

First when the building is actually there, they will see all the visual elements and details — they will feel the materials — they will experience the acoustics and the surroundings — walk through the rooms and use the built-in solutions. The colors and furniture can change a perception of a room or a building entirely. All these elements — and probably many more — are elements of the building architecture, that you and me and all the other users actually will experience and perceive. Architecture is the real thing, what really matters. Beautiful solutions that doesn’t work are useless no matter how they are perceived, and well functioning solutions that are perceived as messy, ugly or complex tend to not getting used — even though it’s easier to convince the users about usefulness over time, and usually their perception changes as well.

Well, the exact same thing applies for an enterprise. The enterprise architecture are the actual perceived and underlying elements that define the enterprise. Every enterprise has people who do something that should create some kind of value. They have knowledge, a way of working and tools to perform their job. There are structures and processes — including leadership and management. These people work somewhere —and where and how you organize office space matters. Last but not least, there is an organizational culture that influence the entire enterprise. The perceived enterprise architecture is the sum of all these, and it is a system where everything depends on everything. One change somewhere, influences other parts of the system.

What about TOGAF, Zachman, DoDAF then? Isn’t that Enterprise Architecture?

The simple answer is no, not really. They are frameworks to work with enterprise architecture, and provide taxonomy, methodology and good practice, but as with all frameworks — there are lots to be filled within the frames that no framework will provide you with specific details about. And descriptions, models and drawings will never be the actual architecture — it’s only the real thing that will. Most frameworks actually define enterprise architecture the same way, but not all enterprise architects do — neither the customers. Many consider enterprise architecture as the discipline of creating architectural descriptions, whether it’s describing the current situation or the target. Even though it’s not precise, you don’t get arrested for it either.

OK, but what on earth has this to do with Business Agility or what buzzword we choose to use?
In the introduction I mentioned that what really matters in Business Agility, was “What outcome is coming from the business — how is the enterprise actually run and perceived, and what does it achieve.”. Well, this is the enterprise architecture, and when an organization wants to be more agile, they have to change the way they work, tools, mindset and culture. Probably organization and surroundings as well.

A well known agilist, Karim Harbott, mention 6 Enablers of Business Agility, and describes in the article that we should strive to move towards the agile “side” of each of these enablers.

Mr. Harbott does not include technology in his list of enablers. Personally, I think it should be included, as we need agile systems and technology as well, meaning we need to be able to add, change, improve and remove parts of the system without affecting other parts of the system uncontrolled. In most enterprise architecture frameworks, technology is an important part too.

Business Agility is a major and never ending change to the enterprise architecture — even though it might not be planned by enterprise architects — and in many cases it isn’t. You may come to a high maturity level, where your organization

Business outcome is the ultimate goal — the What — of any organization. For many companies this mean money, for most governmental organizations and non-profits this mean some kind of service level. You might say that outcome overrules everything, however this tends not to be true. Most organizations have value propositions that include elements like customer and employee satisfaction, value contribution to the society etc.

The actual Enterprise Architecture, like we’ve defined it here (and not the discipline of refining it) is the tool — the How — to create business outcome, and is the target of change when wanting to become more agile. There are legal and ethical regulations that affect how you can get your outcome, and luckily most organizations care about complying to those as well.

Even more important though — is the matter that we haven’t covered at all yet. The Why. You may understand the What and the How, but if you haven’t got the faintest clue of the Why, it’s very unlikely that you will succeed with anything— also with becoming more agile.

So why should many companies want to become more agile?

I believe many business leaders actually don’t know and certainly don’t understand the answer to this question. Initially, I wrote that when the need is great, this transformation can go reasonably fast. General Stanley McCrystal describes in “Team of Teams” how the Joint Special Operations Task Force transformed their organization in the midst of war in Iraq. The American Forces were great in numbers, great in technology, and great in practice and experience. The American SEALs are considered to be among the best special forces in the planet. Still, they had a hard struggle fighting Al-Qaeda in Iraq. They faced an enemy that did not think the way they supposed it did, with different logic, motivation and organization than predicted. This forced the Task Force to change how they operated, simply because they experienced that their old way didn’t work. They understood that the need was great, then the desire and willingness also was great.

The Norwegian Special Forces, FSK, are well known world wide, and were in Afghanistan along with the Americans. Since establishment in mid 70’s, they have built a culture of continuous improvement, a culture of trust, a culture of excellence. The Chief of Command of the Norwegian Defence, General Eirik Kristoffersen, wrote a book in Norwegian, called “Jegerånden” (that can be freely translated to “Ranger spirit” or “SEAL spirit”) where he describes the culture and leadership in FSK. He has been a special ranger, comparable to the American SEALs and both deputy and head of FSK during operations in Afghanistan. One of his key points to FSK’s success, was their obsession to understand the mission in every assignment. Not only the tasks to be done, but why those tasks were important. This was not a leadership thing, each soldier had to understand this, and be able to communicate it. When in battle, that made it much easier to prioritize what to do.

In some industries the answer is so simple: either you become more agile or the organization won’t exist in the future. And the future might not be five or ten years away, but maybe only a year, or even months. This is well known, but many leaders don’t understand the need in their organization. Then the desire and willingness for becoming more agile is not present either. Others lack the knowledge and ability to change. This is easier to deal with, however, they need to know that they don’t know. When you have an agile mindset, this is actually easy to see — but as these leaders might not have gained this mindset yet, they might be struggling to search advise — and are trying solutions that are not likely to work. These industries are the industries that are far within a digital transformation, or disruption you may say.

For other industries, that has not come that far on the digital transformation journey, the answer isn’t that simple, at least not in a short term future, and the need to apply changes isn’t that hard, because the competition is also lagging behind. However, there is a hidden threat too — that should apply more pressure to those companies: start-ups and companies from other industries that want to extend their operation in new fields with disruption. We’ve already seen this happen multiple times — Apple in the cellular industry, Spotify in the music industry and Tesla in the car industry to mention some. For those industries that hasn’t come that far, the answer to the question is different. They might have : the market and the competition change in a way you are not able to control, so you need to adapt — quickly.

But wait — wasn’t this an article about agile transformation, not digital transformation?

Well, yes, in a way. For some companies everything starts with a digital transformation that extends into an agile transformation, for other companies it’s the other way around. However, these are two sides of the same thing: the How to solve the Why.

Both are major changes to enterprise architecture, and are connected. Both are changes that solve the same problem: to be able to respond to a world that changes faster and faster, because everything is based on technology.

Ok, I understand why my organization should become more agile, and really want it — but how do I make it happen?

One of the most used agile frameworks is Scrum, that is based on three pillars: transparency, inspection, and adaptation.

These pillars will also be the tools for becoming more agile. First we must assess our organization (inspect), so honest as possible (transparent), and then change piece by piece in the right direction (adapt), then repeat. Not everything will work, so we’d better do small things, and inspect often, if not continuously. Then we’ll be able to reflect and learn, and hopefully go in the right direction next time.

There are several requirements for this to work — I’ve already described the understanding of why, honesty and acceptance of that you will fail sometimes. Another really important factor though, is a blameless culture. It’s connected to failing — you will fail, and it’s nobody’s fault. Obviously any change will be somebody’s idea, and somebody else might fail while implementing, or forget something important. It might cost money — lots of money. Even so, an environment where it’s safe to suggest new things, try and even fail hard, is so important that this needs strong emphasis.

Because not starting the journey, might cost more. Likely much more, perhaps everything.

With an understanding of why, a desire of change towards business agility hopefully is triggered as well. In part 2 you can read about how actually start this never ending journey, while part 3 discusses the use of frameworks.

Published first time August 3, 2021 on Medium.com