When we say agile transformation, we all have some hidden expectations in mind (read this). In change management, a transformation is a milestone to reach your expected goal. By reading what is made available on the web on agile organisations, I was a bit concerned that agile is set as a goal for the best, or only used as a brand in its worse.
So, I tried to clarify with thoughts in order to be as coherent as possible with myself for the sake of my customers:
- agile is the goal for agile coaches, scrum masters and organisational developers only to identify how your system (organisation) is behaving
- agile is the how and never the what. The what is the problem you try to solve like: improve your operations, increase customer satisfaction, increase engagement at work, clarify activity portfolio, improve the working model, align globally distributed organisations, create a corporate culture, initiate change, set up and manage the transition to digital, etc…
To understand where agile behaviour takes place, let´s take a look at what you have in an entity (I use this term to avoid further confusion). An entity is composed of a structure and an organisation. I learned a decade ago that structure is not an organisation (ROBERT H. WATERMAN, JR., THOMAS J. PETERS, AND JULIEN R. PHILLIPS).
The structure is represented in your entity by an organigram. Actually, for my customer SAP, the structure is SAP with all their position, roles and functions. A simple question like “who is your boss?” or “who is your manager?” is enough to understand where you are situated in a structure.
The opposite of “structure” is “organisation” and it is represented by a sociogram. The organisation is the social network within a structure where you are interacting with on daily basis. Here the question, to be more explicit, is “who are you asking for help when you have a problem?”.
The source of “structure” is in royalty or paternalistic structure where the king is on the top and all subordinates have to support the king´s requirements and demands. “Structure”, in a more soft approach, has been used as a model to ensure the continuity of the entity by enforcing its robustness.
Even if “structure” has been created at the beginning to protect the entity from external threats (ex VUCA), it evolves in over-controlling the interactions within the entity. “Structure” paradox in the banking industry: “At the beginning, the whole company has only a front office but our customer distracted us to maximise our goals. Then we created a back office. Back office allowed us to think deeply about our strategies and improve our investments. But some shareholders arrived also to distract us and we needed, even more, compliance and control. Then we created a middle office. Nowadays, we are so far away from our customers of the digital age that we don´t understand them any more”.
To ensure a very secure “structure”, you create functional silos with highly qualified experts within. These experts due to their qualification are competing with each other and never share information. This strategy ensures that an unqualified manager had the capacity to “manage” these experts like manufacturing workers at the beginning of 20th century.
Purpose of a structure is to generate power or a career for individuals and not for the company or the entity. Unfortunately, your “career” is in structure and you have two options:
- fast way: you focus on politics by accessing to main information and increase the number of subordinates in your department (FTE management) and focus to satisfy your boss
- long way: you are looking for accomplishment in “organisation” and you change your department once the project delivered.
“Organisation” in the other is the area of projects teams where usually big companies are looking for third party support to ensure that the work is done. This is the area where agile belongs.
In that area you will find mostly 2 kinds of work:
- projects: are time boxed initiatives
- programs: are a collection of projects and support activities related to current or initial projects
These kind are almost customer driven with a measurable outcome (business case, benefit report, lessons learned).
The Agile transformation paths
This is a step approach.
- you have to sort what activities are “structure” related and what activities are customer related.
- when using the Scrum X framework (here), the Product Owner is fully empowered to work with the customers. Test: if the customer is communicating with “structure” and the Product Owner is only decomposing work coming from another entity, you make it wrong, Customer has to be embedded in “organisation” like any other stakeholder in a partnership relation and not in a “commodity” or “service provider” relation. Key is co-creation.
- team members are fully dedicated to a single team even if they are not working in the same country
- scrum or agile ceremonies (planning, review, daily and retrospective) have priority over “structure” meetings like All-hands, functional team parties, etc…
- one technique for that step is the introduction of project and program management techniques allowing to prioritise different working types or to move from a cost centre model to a profit centre model (look at Scrum 4 programs)
- “organisation” is more and more empowered and “structure” becomes to be supportive
- managers are keen to remove obstacles from the teams like “business as usual” activities (reports, bureaucracy, etc…)
- old management roles are evolving to a new one like People Manager, Enterprise Coach, agile coach, product owners…
- impact of “structure” is reduced
- attention, usually at this moment “structure” will react (arrows). For a certain period of time managers were comfortable with the idea that the teams are self-managed until they discover that they losing power and authority. At this moment, step 2 is not safe and the risk of regression is high. Attention to coach management is highly necessary to improve their position in the new system.
- in step 2, teams are starting performing, customer satisfaction is raising. This is the “rise of productivity”.
- here we can be inspired by Conway´s law to organise the entity
- management is involved in the agile working model
- 2 main management behaviours are emerging: servant-leadership to support the effort of the teams, and constructive-irritant as strategist and visionary
- the organisation starts to be fully complex adaptative
- innovation emerges and new experiments are part of the routine
- keywords are coherence and resilience
- teams are mostly efficient and start to be effective to challenge their impact of value
- the model is fully integrated are the boundary of the structure is reduced at necessary
- teams are working like independent entities or internal “start´ups”
- “structure” is focusing on light governance model and focus on funding and alliances
- For the geeks: the entity is working as a digital platform enforcing the interaction between all stakeholders including providers and customers.
- The entity has learned how to manage freedom and trust in empowered self-managed people.
Let´s take a look at the current scaling methodologies
Most of the actual agile scaling methodologies are keeping the status quo to remain in “structure” without challenging the old paradigm.
Unfortunately, most of them came with good intention but for profit reasons, they lost the ideal of agility. Changing paradigm is a hidden first law of the agile manifesto which is “We are uncovering better ways of developing software by doing it and helping others do it….”
Most of those methodologies are addressing the entities by the single angle of IT without taking all the other parts into account.
The purpose of AO is to take the whole enterprise with all its entities into consideration and during the last 8 years, AO has been tested in Finance, Trading, Board of Directors, HR, Accounting, Sales, Support, Education and more.
Old paradigm means also that what we describe like functional silos (marketing, IT, finance, sales, support, etc…) will disappear to avoid duplicates like a Search Engine Optimisation (SEO) team in both IT and Marketing instead having one with IT and Marketing people.
Big challenges that don´t make it easy
AO cannot be a one-shot, this will be a permanent effort. It´s all about continuous organisation.
In large entities like SAP, the 4 step process is measured at different levels. In the figure below, some organisations are emerging but the whole is still in structure. Some steps have to been reached until arriving at level 6.
You have to consider organisation like team building activities: each time you add new members to the team, you need to adapt that organisation according the new assets enriching it.
And, indeed, the challenge is even complicated if your entity is global and merge new acquisitions.
But, in all these examples, from small to XXL, the loc remains the same.
Feel free to leave your feedback, this is much appreciated.
Posted in: AO method