Defining C-suite agile with Requisite Agility
Requisite Agility (RA) is an evolution of Requisite Organization (RO) adapted to the complexity of a global connected world.
The common denominator of both RA and RO is the initial problem that RO tried to solve like “ lack of effectiveness of bureaucracy within a stratified hierarchical organization “ (Wikipedia) including specialization of function.
Function control is related to scientific management, assuming that patterns are preceding data. Agile, on the other hand, is “Sense-Making” where you are looking to situate a network and where data precedes framework.
They are several points that don’t make any sense in “Sense-Making/Agile”, like management or accountability because of the self-managing nature of that complex system.
Organizations like SAP or Daimler are looking about the Stern Steward model applied under cover of “digital transformation”. That model is appealing “Sense-Making”. They are using the multiple sides platforms model with three principal layers like platform (mid and long term programs), swarms (short term projects) and plexus (Governance).
In my eyes, there is no clear “agile” concept responding to that new challenge that companies are already testing. There is, maybe, where RA has a role to play.
Create meaning not tools
I don’t think that RA will come out with a set of processes and methodologies on RA because it is off the grid or maybe we all have our methods and processes. What matters is, like Kasmir mentioned in one of our meetings, that strategy and Northlight will be incorporated again at C level and not outsourced to a tiers. It is all about engaged C Suite and not bureaucratic management.
Why Requisite Agility is different that Requisite Organization?
I believe that RO is totally command-and-control and perfectly designed for the industries of the 1950s.
At that time, demand was more significant than the offer. People operated in a complicated Sense/Analyse/Respond relationship even if science demonstrated that that model doesn’t work for over 20 years.”Cognitive capability and social, emotional maturity of employees” is an odd sentence, but I give you hear how things happen in CAS.
In agile or responsive systems (CAS), you are building a system allowing emergent behaviour, and we are using “Flocking behaviour” as “process” to create the dynamics in that system. “Flocking behaviour” can also be understood by “organic growth”, it is based on Boids research and applied since the 1960s. In Flocking, you care about alignment, dynamics, avoid collision, focus and separation ( https://medium.com/@pierreneis/when-if-agile-is-nothing-more-than-the-dynamic-of-a-system-8c8d02db3de1).
Once you understand Flocking behaviour, you see that:
- focus or true north or North Star is key
- alignment is the starting point
- dynamics and collision are operational
All these governance topics have already been addressed in Kaizen and Lean Management through Hoshin Kanri ( https://www.infoq.com/news/2014/11/agile-hoshin-kanri/). Not the tool, the coordination process.
What is the challenge?
Agile is the challenge and not requisite. An agile organization is flat, and non-agile is a segregate monolith shaped for robustness designed a long time ago.
In our preparation meetings, we came to the point to add “O” to VUCA. We went to the idea that an organization is in continual evolution, and RA tries to address governance issues on that move.
Because my all have different ways to address that complexity, we already designed the first version of RA to link our various initiatives without interfering between our believes. During our last three meetings, we experimented what RA might be. Now we roll out to test it during the coming Unsymposium.
Join us the 5–6th of December 2019 in Heidelberg (Germany) to define together 21st-century C-suite: https://requisiteagility.org/raunsymp/
More to read:
Originally published at http://agilesqr.com on August 20, 2019.
