Q&A on The Book AO, Concepts and Patterns of 21-st Century Agile Organizations

The book AO, concepts and patterns of 21-st century agile organizations by Pierre Neis explores the concept of designing systems to allow for agile behaviour. It provides patterns to establish agile organizations that are able to respond to 21-st century challenges.

InfoQ readers can download a free copy of the book AO - offer valid until the end of December 2020.

InfoQ interviewed Pierre Neis about agile organizations, sociograms, Cynefin, new paradigms, agile transformations, intrapreneurship, scaling agile, managing projects, and becoming agile.

InfoQ: What made you decide to write this book?

Pierre Neis: The decision process took me ten years. I was waiting for the right moment to publish it. Ten years ago, most of the concepts were designed and tested. I gave a conference and got positive feedback and someone in the audience asked me about the book. At that moment in time, the idea of a book was far from my mind.

After my work with SAP and several bank and insurance companies, I felt legitimate enough to share my vision of Agile.

The format was also a big challenge. In all these years, I had collected a lot of data and documented all my work. Deciding what to keep and what to remove in order to be more inspirational rather than prescriptive was the hard part.

To summarize, the real decision to write this book is an acknowledgement of the work achieved by all the teams, organizations, and people trusting me during the last fifteen years and the will to handover the relay stick.

InfoQ: For whom is this book intended?

Neis: There are several levels of lecture possible. The book is intended first for agile coaches and organizational developers. The book is a theoretical catalogue allowing you to focus on what matters.

Leaders and executives are the second audience. They will understand what challenges they will face and where to go from there. It will help to design the alliance between management, business and operations. The five experience bases metrics are an outcome of strategic planning with executives.

HR people are also interested in this book. Through the agile4hr project, I had the opportunity to interact with plenty of HR people. The great takeaway for them was Agile Systems Dynamics.

These are the target audiences that I already know at this moment in time.

InfoQ: How would you define agile? And agile organization?

Neis: I put my definition of Agile in the book. Agile, capital A as a noun, is for me the nature of how people are interacting together in a system called team or organization. It is the “individual and their interactions” part of the Manifesto. Agile as an adjective is still accurate, but for tools and techniques. I can be agile as an individual, but this doesn't necessarily change the system in which I’m evolving. The opposite is true: you can have an agile system without agile people.

My definition of an agile organization is a system designed for engaging people; a system based on negotiation where win/win/win is the driver: win for management, win for business and win for operations. An agile organization is for me a collection of swarms and hives with a simple design, full of designers rearranging themselves from one deal to another.

InfoQ: How can a sociogram help to get insight into our organization?

Neis: The sociogram is considered as the “real structure”. It highlights the real networks in your company and not the virtual one. Considering that Agile is a sensemaking system with the ability to situate a network, we should consider that network seriously. The sociogram is a way to make this network explicit.

As an example, in Scrum, you care a lot about impediments. One of the biggest impediments is not engineering; it is any distraction- distraction coming from other managers or because you can't focus to solve one problem at the time, but you have to switch between different projects. If you use it to draw the interaction of each of your team members, you will discover an insane spider web. The bigger the network the greater the risk.

In the book, I use the Apple Tree example. The Appletree is a retrospective to reorganize ourselves based on the activities and distractions we have. Here you find also the idea of emergent design. In the end, the sociogram will show concentrated interactions mostly around the team and their stakeholders. 

A sociogram is a tool that you use all the time because your teams are evolving all the time and don´t stand forever. The “forever” is in the Enterprise Experience layer; the Organizational Experience is in constant evolution to allow work to flow into teams, and not individuals.

InfoQ: In the book, you described how you use Cynefin in a dynamic way. How does this work?

Neis: Well, I always dynamically saw Cynefin and I was confused when people were considering it as static. My model is based on the Cynefin learning curve and the “linking the dots” part. I felt sad and lonely seeing it like that.

If you consider Cynefin as static, you are analyzing a situation at a particular moment in time from a single perspective.

From a dynamic way, things are a bit different. 

Let's consider our COVID-19 times. People are no longer collocated, and they are working from home. From a Cynefin perspective, we can say that the organization design is CHAOS: a collection of decoupled individuals. The very nature of management is COMPLICATED with the idea that tasks are SIMPLE. Unfortunately, management is working from home office, by extension also in CHAOS. The consequence is a freeze of organization, and management is applying best practices such as cost-cutting, firing people and increasing controls. As a side effect, this results in more disengagement, fear and DISORDER.

What to do? This is an unknown-unknown situation where analysis doesn't matter. What matters is to start moving forward again, but maybe not at full speed. You know that you have to get options to experiment. You start with a shared goal, a crystal clear vision or intention. You start SIMPLE; everyone agrees and knows the WHAT. 

Then, you move into CHAOS. CHAOS is the brainstorming part of the problem-solving process. It is the personal commitment, engagement through the creation of individual ideas. 

Then rapidly, based on these ideas, you ask people to gather into teams. Then at the team level, let them build something else on the top of each other’s idea. Now you are in COMPLEX where innovation occurs. 

Once prototypes are available, then it's time to analyze at different levels like enterprise. This is COMPLICATED. At this stage, decisions are taken to focus on a single option or to dive deeper. That decision is collective and the outcome is SIMPLE again. 

Then you relaunch the loop.

I called this model Agile Systems Dynamics (ASD) because of the backfire I received from the Cynefin community, and I considered it as an exaptation of the initial model. ASD has also been updated from my different experimentations and enhanced with complex systems theorists like Kruse and Niedschmitt. In the initial model, management was almost at the top of the dotted triangle. The idea was to highlight the system supporting self-managed people. Cynefin was built around the opposition of structured systems (COMPLICATED, SIMPLE) and unstructured systems (CHAOS, COMPLICATED). This was a great support to emphasize that organization isn´t structure.

InfoQ: How has the nature of work changed in the 21st century? What are the new paradigms?

Neis: Let´s define the context. In the early 20th century, the work was mostly linear. You had the top of the company planning what to do and the workforce executing that work. It is called scientific management, where you have a clear distinction between Leadership, Tactics and Operations. The linear model follows the recipe of patterns preceding data to support mass production.

After WWII, the demand moved, and there was a greater need for mass customization. At the moment, our new paradigm was system thinking. Here you find models such as Kaizen, TPS and Lean. System thinking is based on information control where scientific management is on function control. System thinking is also a linear approach where patterns precede data. You still have a three-tiers management structure like Front, Middle and Back Office.

With the emergence of the internet at the end of the 20th century, a very deep evolution has occurred. Information has been widely shared and accessible. A consequence of that emergence was that the knowledge moved away from the Top and the Middle, to the Operations. Before that time, you assumed that your boss knew everything. Now, your boss knows less than you.

This new paradigm is a huge shift. We are shifting from the patterns-precede-data to data-precedes-pattern model. It means that your organization has to produce more data and the solutions are emergent. This state is called Sense-Making, and it is all about the ability to situate a network. In that paradigm, the old structured systems models don't work and we talk about Complex Systems. Agile is a way to address complex systems.

These systems, as described in ASD, are self-managed and you can´t control them. If you control a complex system, you make it complicated and you’re stopping your innovation journey.

Another challenge is in leadership. Because you can´t control such a system, you have to learn to resonate with it. This is not linked to servant leadership; this is management related. To resonate means being a constructive-irritant. It means having the ability to understand at what moment in time you intervene to accept or reject options.

As you can see, that shift is huge. A vast majority of companies are stuck in scientific management, and sometimes in system thinking. Words like production line, business line, factory, and scaling are not considering Complex System as an opportunity, but as a thread.

In my book, I gave some patterns to move into Sense-Making or AO. And, I explain that there is a learning curve for organizations in moving from “Unknown” to “Scientific”, then to “Systemic” and to “Agile”.

InfoQ: How can organizations deal with these changes and new paradigms?

Neis: I was missing tools to start the conversation with my clients to avoid the debate about “that's agile and that's not”. So I created the Switch model which you can find in my book. It explains that by default, we are in Structure with different steps to reach AO as a fully agile organization. I intended to explain how the goal might be (AO), not to reach it but to design with clients their “high dreams”.

The Switch starts in Structure, where you do agile entertainment. Then the first step is Awaken, where you start your first experiments in a waterfall manner. Then, when you are ready, you move to Rubicon where you move into system thinking, using Lean techniques as examples. Then, when you feel ready you move into A-Venture, where teams are considered as profit centres and are behaving like internal startups and governance is managing a portfolio of investments. The ultimate agile organizational model is called AO. In AO, the company is working like a multi-site platform supporting transactions like Airbnb.

Having such a high level roadmap helped my clients. During our conversations, they are deciding how far they want to go. At the executive level, we are also considering what required level of agile there should be to support the strategy. It becomes OK to address support, infrastructure, finance, and shared service as linear at the beginning. It also makes visible the risks of misalignment between services.

The Switch is a timeline with five steps to move from structure (managers assigning tasks to individuals) to AO (only self-organized people), through Awaken (waterfall), Rubicon (Lean), and A-Venture (agile teams as internal startups).

The Experience Metrics are customer experience (CX), service experience (SX), people experience (PX), organizational experience (OX) and enterprise experience (EX). In agile organizations, most activities have a customer (not an internal customer). The outcome of the project is documented and may be automatized as a service (SX) consumed by customers who are not interacting with people from the company. Great CX is achieved by empowered and engaged teams (PX). The result of great PX is the constantly evolving team sizes adapting to changing purposes (OX). EX is the container allowing fail-safe experiences. It is the last necessary structure left.

With SAP as an example, we used this naming convention to highlight the portfolio of activities. After some workshops, there was common agreement to decide to improve CX from 10 to 25%, and to reduce SX from 70 to 50% in 2020 (before Corona).

Combining the Switch and the Experience Metrics has become a clear and simple language to express the strategy. For example, if the company decides that having mostly CX activities means that the company has been mostly at least in “Rubicon”, or if a company is mostly selling services through a platform, then SX is crucial, etc…

Organizations have to consider these paradigms because they involve the way you are working with your people and your partners. In a VUCA world, growth and partnership are Complex by nature. In the past, when I was a Lean coach, we imposed the methodology to people and partners. This was very colonialistic. Agile or Complex systems don't work like this; growth and partnership are part of an assimilation process where both sides are improved. This is true whether you are global or in the Merger/Acquisition department of the company.

InfoQ: What causes agile transformations to fail? Is there a way out?

Neis: My answer will be short. Hybridization is the most common failure. Accepting to mix oil and water doesn't work. Water always wins.

Most so-called Agile Transformations are stuck in Structure, where good willing people have no power to switch from one paradigm to another. One great measure is the Gallup report on Engagement at work. If agile transformations delivered their intentions, the level of engagement should rise exponentially. In reality, it does exactly the opposite.

I like to say that agile transformations are like the Yeti; everyone talks about it but no one has seen it.

At the end of last year I met one product owner from SAP and asked if everything was going well. She told me that once I completed my contract, senior management hired a LeSS coach, and then a SaFE coach. I asked her, “What are you doing?” She answers, “We are doing what we always do. We are following the design we created together.” At this moment in time, my purpose wasn’t to assert a brand like “AO,'' but I was satisfied it being “their model”.

That's the reason why so many transformations are failing. They are not transformations, but methodology implementation. That's a completely different topic.

If you want to play smart, the heart of failure is to believe more in chronology than in kairology.

InfoQ: You mentioned in the book that an agile organization makes it possible for managers to become intrapreneurs. How does that work?

Neis: It is exactly how I described it in the book. You don't touch the salary, bonuses, or position because they are structurally related. You consider the corporate strategy as a product roadmap and the SVPs as product owners or Agile coaches. That's it.

And you can ask them what they want to do to create value for the enterprise.

Managers are just another kind of developer. You have to move them out of transaction work to value creation. This way of working has strongly resonated in the finance industry, and some impressive advances have been achieved.

This idea is not new. IBM in Belgium proceeded this way twenty years ago.

InfoQ: How can we scale agile to make it work in large organizations?

Neis: Scaling is a red-herring. It is a word related to structure. Agile is non-linear.

The difference between scaling a couple of teams and working with hundreds of teams is the pace. Fifteen teams globally distributed in Agile can be handled in six months or less. Five thousand people in finance will take maybe two years.

My customers are mostly that big and global. The biggest challenge is not in methods and structure: you can find plenty of free tools helping you. The big challenge is coherence and alignment: if the message is diluted or disturbed, you won’t be aligned.

The how is also not complicated. You always start small, look at your system and adjust collectively.

When I read about scaling, I discover new words for old concepts. You still have programs, projects and transactions. And, program management or even Hoshin Kanri are still accurate.

InfoQ: How should we manage projects in an agile organization?

Neis: In AO, projects are managed in a typical agile way: product owners are working on needs and not on requirements. They are part of the team and not an authority.

Projects are starting in Swarming. Swarming is a way to explore, test ideas and create options. 

Swarming helps also to limit the work in progress at the project portfolio by limiting the number of parallelly running projects. The outcome of a swarm can be a Proof of Concept, a prototype, or an analysis.

With defined projects where we have funding and a business case, we try to engage the customer early on, even in daily meetings. Once a part of the whole project is delivered, only then is it documented and compiled at the portfolio level.

In my book there is a chapter addressing the way projects are managed in AO.

InfoQ: What are the steps to becoming an agile organization? What's needed to take the steps?

Neis: The story always starts the same way: we gather in a workshop. That workshop is called “design agile organizations”. In that workshop, we visualize the current state of the structure and try to highlight the interactions through a sociogram. With both visualizations, the gap is made visible.

Starting with the corporate strategy, we challenge it with the current state and sociogram. At this moment in time, you have to start and accept early adjustments.

This is a typical quarterly collective decision-making workshop. Management explains the quarterly roadmap. That roadmap is challenged and improved by the business, and then by development. Business and development are creating tactics to reach that strategy.

The outcome is an updated roadmap. Management is then allowed to challenge and likewise adapt that proposal. If no agreement is reached at that moment, you start over again another day. When all the stakeholders come to an agreement, we ask for dependencies and we adjust the roadmap to minimize the impact of such dependencies. Bearing in mind that every team has to be end-to-end, some teams have to be reconsidered in that moment. If you still have dependencies, they will be removed from the roadmap for improvement.

Now, you have a common agreement and it is time to ask the teams where they want to work.

About the Book Author 

Pierre E. Neis, agile coach, organizational designer and company therapist, is a human in process, constantly learning from the people and the contexts he faces. His business card says “Agile Coach”; his Agile coaching is an evolution of systemic coaching, putting himself in the system rather than an outstanding observer. As hundreds of customers seemed to like his work from the last decade, he thought about teaching it to his peers. His portfolio includes #play14, #iplay24H, Enterprise Scrum, Requisite Agility, Agile4HR and his book "The New Normal: AO Design and Patterns of 21-st Century Agile Organizations".