The AO (agile organizations) principle
Once I’ve been asked during a conference, what comes after agile? I found that tricky question very interesting. I thank that person, and I confessed in public that I don’t have a clue.
I don’t have a clue because you can improve specific concepts. At that moment in time, it was six years ago, and some agile researchers were still experimenting with the limits of Agile.
From that question that some student asked me came the crucial necessity to clarify not what happens after Agile, but what might be the pinnacle of Agile, the “Done” of Agile.
AO is the result of that research. For me, it is the “end in mind” that all my transformation projects are starting.
The ultimate agile Organization is one where value creation is ninety per cent of the activities. That creation can only occur in a collaborative “complex” context with a minimal Structure. That Organization is self-managed in a safe-to-fail container, the Structure.
Self-management has a precise meaning. It appeals to the engagement of all agents (people) in that system. The side effect of self-management is that traditional management supervision is no longer required: all participant in a system is managing.
When I experimented AO at SAP, during a meeting, one of my colleagues asked me if I wanted to attend a call with her team. They tried to get some information about Agile. I asked her when that meeting will happen, she told me in the next five minutes. So, without any preparation, I jumped in a Skype Meeting with an unknown team.
The team member wasn’t a software developer, but eighty CFOs or Vice-Presidents. And the first question raised: “what is your vision about Agile in our company?”. That’s a tough question for a 100 000 people big company, but I gave my smartest guess possible: “Look. There is a rule you have in all your meetings. That “Tell it like it is” rule.”. “Yes”. “What is happening with that rule? Usually, you tell like it is one time and then you shut up, right?”. “Absolutely”.
“Now, in Agile, you are allowed to tell it like it is every time you find it is necessary.”. “Got it!”. “On the other hand, you understand that “transparency” has a price. That price is that you have to deal with people, not only telling you what works. You have to deal with people criticizing or saying “No” to you. It is easy to understand if those people are your bosses or your colleagues. What’s happening if those persons are your subordinates or service providers?. That’s the challenge of Agile. It is creating an environment where secure information can be shared. That information is crucial to take the right decision on the right based on facts and not assumptions.”.
Then the conversation moved to a whole another level. “Pierre. You are speaking about the self-organization, right?” “Correct.” “If people are self-managed, where is our role though?”. “With your permission, I will reformulate your question through another question. Imagine that you keep your status, your salary and you have the choice to keep your job or to do something else? What do you do?”. “We will do something else.”. “Now, if you keep your status and your salary. And I’m a member of the Board what is happening if I give you some budget to create something that matters to the enterprise. Would you accept that?”. “Wow. It means, in an agile organization, we can become intrapreneurs?”. “Yes, sir. That’s one of the goals. If all teams are behaving like internal start-ups, former managers are intrapreneurs, and the governance model will evolve to something similar to venture capital in charge of the funding and the management of a portfolio of activities.”.
From that meeting, a new model emerged that I will explain in the pages to come.
On the one hand, we have a system called “Structure”, and on the other hand, we have a system called “Organization”. Each system has a particular design for a specific purpose.
“Structure” design hardcoded in our DNA as I explained in Part One with the “Farmer´s metaphor”. That DNA has been deteriorated in time. In the beginning, the King was a lord protector. This intention changed when the King wanted to stay forever. So, he created dynasties.
Since that historical times, this belief is almost part of our culture, and some tried to challenge it in Revolution. Fact is that even Revolution just replaced one dynasty by another.
The change from one system is an empirical process. All part of the new system has to find its place. From the dialogue before, I can understand that some people “in charge” have some “imposter syndrome” or weirder, they reached their level of incompetence (Peter´s law). These feelings are expressed in some negative behaviours like excessive use of authority, micro-management, “hi-jacking” words. These reactions are just showing the fear of change.
“If I had asked people what they wanted, they would have said faster horses” is a famous quote of Henry Ford. It means that if you want to be more agile, you have to remove something.
Changing the paradigm is almost missing.
If you are from the “Agile world”, since 2018, scaling is a vast topic that we are talking about. New methodologies are emerging to try to solve that issue of multiples teams, multiple locations working together. It is a real challenge. And that challenge seeks to address the complexity of work with old patterns.
A couple of weeks ago, I watched the comedian Trevor Noah making a hilarious stand-up on British colonization. The principle of colonization, and here I include all the nations on Earth, is to impose to the colonies a one-sided truth. Since the End of World War II, most of the settlements have become independent nations. And some other countries artificially created by colonial countries are still struggling to find their ways like in Africa and the Middle East so far, I know.
On the other hand, one conqueror created the biggest empire, after all. That conqueror was Genghis Kahn. He used assimilation. Assimilation means that your core culture will be enhanced by all the new cultures assimilated. For coherence, your initial culture will become one of all others. The consequence will be a new overarching culture that resonates with all the others. That overarching culture should again more straightforward than the previous one to ensure the perfect accomplishment of that “federation”.
On the picture above, I illustrated the point that most of the existing methodologies are just trying to get “faster horses”.
SAFe is a good example. That methodology is the new Project Management Body of Knowledge (PMBOK). It is a catalogue collecting all the recipes and patterns possible to get you “agile”. Fact is they “legalize” the micromanagement part using the same language, the same tools from obsolete management. It means it postpones the transformation of a 20th-century model by enforcing “complicated” instead of supporting “complexity”. That model is a typical recipe book for recipe users and never makes you a “Chef”. It is scientific management with an agile body smell.
LESS is a bit more advanced. That methodology is Lean based and like explained previously, and it is fit for mass customization. Lean intends to reduce variability in a system. The consequence of that lean process structure is to believe that the process remains static. LESS is more mature than SAFe, but it is not agile. Instead of breaking down silos, you redesign them in Line-of-business or value streams.
Discipline Agile, Nexus, Scrum at scale or even Enterprise Scrum, which I contributed have the same intention to come with patterns instead of resonating with the systems.
Agile is difficult because its heard is in resilience: what you know today might be wrong tomorrow.
A couple of decades ago, I made the same mistake twice — one time with Lean and another with PMI. The intention was to create a common language through the organization with methods and tools. The reality is that it never worked.
In his book “Maverick”, Ricardo Semler told a story about looking on a method that could help him to organize his enterprises. He explains that visiting a Japanese company in the morning, and he saw all the people aligned and doing some exercises. Semler asked himself “can we do that?”. And his inner answer was “No, we are Brazilians not Japanese” and he started his journey to transform his group.
On the same vein, new opportunistic concepts are emerging like agile marketing, agile sales, agile finance, agile whatever.
Changing the paradigm doesn’t mean to put agile everywhere. The change form “Structure” to “Organization” inherits to break-down silos. An Agile Organization is working on ventures with people having different talents. Even IT and Support will disappear at the end.
The common pain points.
Most of the companies today understand that I have to move to “agile”. “Agile” here, means to accept a constant capacity of adaption. The company becomes a polymorphous system of empowered and engaged people from operations (bottom) to governance (top). That behaviour will move from apparent robustness (keeping the status quo of ancient structure) to effective responsiveness. Moving from surviving to living. Most common weaknesses or pains are:
How can we interpret these elements?
Even if we can have the feeling that the old paradigm didn’t evolve, the change already occurred.
Using the five steps of grieving, most of the managers I’ve met are:
- Anger. Because of their actions, the blame is given to the operation and the agile approach. Expressing anger sounds weird, but it can be a constructive emotion to move out of “Lock-In”.
- Bargaining is the next step. Management is needed, and most of the agile coaches are not able to start to negotiate the mission of management from control to protection. Bargaining is a negotiation in the heart of “praxis”.
- Depression will occur once Management discovers that the role they thought playing isn’t helping in value creation. New options have to help them to find their place in the new paradigm.
The AO phases are creating the conditions to shift rapidly in the five steps for the sake of the enterprise and its people.
While designing the AO paradigm shift, I had the grieving process in my mind, like in the following picture.
Another angle to take into account is the adoption curve. That curve follows an empirical process that you can call agile. It is more powerful to live what you preach. You will have more data.
These phases are not maturity phases like in Capabilities Maturity Models (CMMI) or other ISO. It is more a bright beacon on how far you want to go as an enterprise. In the agile context, most of my colleague’s coaches are explaining that agile is a journey. Agile here is barely not defined, and the goal is unclear. This is a point I try to remove through this approach.
Agile has been defined in the first part of this book. It is a resilient system of people, working with a common purpose. That system is empirical and allows a co-creative, collaborative behaviour that I call “Agile” (noun).
On the other hand, a transformation is a path between an old paradigm and the new one. Like illustrated in the picture above:
- I what to stay in “Agility”. It means that you want to use some agile techniques and keep your old working model. Agile is considered here more like “entertainment”. Here you are mostly focusing on “theory”: methods, tools, processes, training. The impact expected from Agile is low to null. “Theory” is understood but not or falsely applied. Unfortunately, this represents more than eight per cent of the agile transformations in 2019.
- I want to shift to “Awaken”. In “Awaken”, the focus is given to both “theory” and “Poiesis” (doing and experimenting). Some teams are focusing on completing one project at a time outside of the matrix structure. The work is end-to-end, and the demand flows into the team backlog and not on individuals. We start to run programs that way. These are including several projects and support activities. To avoid over-coordination effort, all the teams are beginning and ending at the same time. The alignment is made through a quarterly joint roadmap planning session. We are using project management techniques to sort projects from simple queries and limiting the work-in-progress through simple rules accepted by all stakeholders.
- I want to shift to “Rubicon”. “Rubicon” was the bridge to cross to reach Rome. In AO, “Rubicon” is the last stage to experiment before shifting in agile organizations. That phase is a disciplined one using System thinking. Management is now another system of agile teams which activity is to protect and feed the “operations”. The lean technique is used to remove as many obstacles as possible and make every value streams visible. The teams are built around the value streams, and we avoid having non-necessary organizations. Communities of practices are nice-to-have but optional: they are satellite systems. Subject-Matter-Experts (SME) are floaters, floating around the team to support and coach them. They are pairing with at least one team member to transfer their expertise. Unnecessary bureaucracy is automatized, and people are empowered to “unleash” their creativity for the sake of their dedicated system. The ancient managers are finding their way in the new organizational model while leading projects they are passionate about — other managers, which more people-oriented embraces more supportive roles like SME coach or agile coach.
Earned value > Actual costs
You spend less than expected
Actual costs > Earned value
You spend more than expected
Earned value < Planned value
You go over the schedule and deliver date
Earned value >= Planned value
Excellent, you are even ahead.
Originally published at https://myao.blog on September 11, 2019.
