Aligned Autonomy — what is it and how may I adopt it?
The larger the organizations in which agile structures are planned or implemented, the more often “classic” agile methods such as Scrum or Scaled Scrum reach their limits. Such methods then no longer fit the complex organizational structure and therefore do not offer the necessary solutions to achieve the goals. One solution to this is to reflect on the original agile principles and look for your way.
The purpose of this article is to explain the method and artifacts of Aligned Autonomy, to discuss the advantages and disadvantages, and to discuss recommendations for action for adaptation. In this post, I outline the structure of the Aligned Autonomy Organization and the basic principles of the model. Based on this, there are three steps you can take to transfer the organization to your company. Kai-Oliver Rittner
Aligned Autonomy — what is it?
In general, the heart of agility and aligned autonomy is to allow teams to autonomously go the best way to the previously defined goal and to provide guard rails for this.
Building the Aligned Autonomy Organization — Squads, Tribes, Guilds, and Chapters
The names of the organizational units in the Aligned Autonomy Model are more reminiscent of a multiplayer online game than a serious organizational structure. However, the interaction of these units shows how well thought out and coherent the model is. And by the way, this naming also succeeds in turning away from a rather antiquated corporate language.
In the following paragraphs I will introduce you to the organizational units of the Aligned Autonomy Organization:
- Squads: Agile teams of 8–10 people
- Tribes: Association of squads (150 people)
- Chapters: Professional networks within a tribe
- Guilds: Overarching voluntary communities
Squads — Agile Teams (8 -10 People)
The core of the organization consists of small, autonomous teams, so-called “squads”. These cross-functional teams of up to 8 people have end-to-end responsibility for a selected area or feature. A squad is responsible for the idea, conception, and development to the commercial success of its work. In essence, you can imagine a squad like a scrum team; the size of a squad is based on Miller’s number. Even if the method was inspired by Scrum when setting up his organization, the squads are free to choose their methods and the procedural design of their cooperation. The autonomy of the squads is only limited by the purpose, the long-term goals, and the basic principles of the organization.
Tribes — Association of squads (150 people)
A tribe is the amalgamation of several squads to form a larger organizational unit. The amalgamation of several squads in a tribe is not random but based on a common context. This means that all squads within a tribe work together on an achievement or their work is at least very closely related to one another. Each tribe is led by one or more tribe leads, for example, a product lead (product manager) and a technical lead (architect). Tribes have a maximum of 150 members. This number is based on the Dunbar number. which says that you can maintain social relationships with a maximum of 150 people.
Chapters — Professional networks within a tribe
Chapters are the aspect of the organization that is most reminiscent of a traditional organization and classic “departments”. Because here the technical merger of all colleagues with the same profession finally takes place. For example, all designers within a tribe belong to the same chapter. The chapter lead also assumes management responsibility for the employees in his chapter. This management responsibility relates to the professional development of employees and the development of uniform standards. However, the chapter lead has no authority to issue instructions on the work to be performed and operational goals. These are defined by the squad in which the employee participates. The organization thus creates an extremely high level of flexibility. Because if an employee changes squad within the same tribe, he always remains assigned to the same chapter.
Guilds — Overarching voluntary communities
Guilds are voluntary communities that go beyond the boundaries of a tribe. The model thus makes the important agile principle of voluntariness and self-commitment an essential part of its organizational structure. Because guilds are created based on the interest of several employees in the same direction, even without management guidelines. The guilds are maintained through regular meetings and mailing lists. It is not only a professional exchange that takes place. It is much more important that there are an exchange and networking across the boundaries of existing tribes.
Basic principles of the organization
The organization is characterized by some essential principles or guard rails. In my opinion, many companies make the mistake of preoccupying themselves with tools, tools, and methods. Or even blindly copying the structure of other organizations, but without dealing with the underlying principles and values. Because only if your organization lives these values and principles can a copy of a model be successful.
Alignment enables autonomy
At first glance, the autonomy of the squads and a strategic alignment of 3,000 employees seem impossible. In the model, the purpose and the executives, therefore, have a special task. Because executives mainly talk about the why problems to be solved or the mission. The model thus achieves a high level of alignment in its overall orientation. This alignment of content in connection with a clear framework for the design of the cooperation is the prerequisite for each tribe and squad to be able to live out their autonomy.
Agile methods in the Aligned Autonomy Model
In the beginning, the organization is very much based on the Scrum Framework. However, employees quickly discover that Scrum alone does not provide satisfactory answers to challenges that arise. Since then, Scrum has been a choice, but no longer a requirement for squads. Scrum Masters are now agile coaches and teams are encouraged to try new methods and tools to gain their own experience. The model relies on “cross-pollination”. This means that instead of ritualizing “best practices” and pressing them into a framework, the organization relies on the word that superior and value-adding tools, methods, and tools get around. In this way, valuable experiences automatically “mutate” into the standard in the model.
Error culture — experimentation encouraged
The model relies on a pronounced error culture. Errors and the resulting learnings are part of a long-term strategy. The faster mistakes are recognized, the faster the learning and the chance to improve. That is why errors are carefully analyzed. Not to identify those responsible and point your fingers at them. But to identify the cause and to prevent the same error from occurring again. “Fix the process, not the product” is the mantra in engineering culture.
At the same time, the model encourages experiments. “Think it, build it, ship it, tweak it.” What doesn’t work is left. What works well, further developed until the expansion creates benefits. The lean startup method is the basis for systematic experimentation. Formulate your assumptions, build them, measure the result and adjust your approach. This procedure is also called “fast failure recovery”.
Creativity and innovation
The model encourages employees to think outside the box and to constantly try new things. Employees are allowed to plan 10% of their time on their own “hacks”, also, employees can work on their projects in free teams via so-called “hack weeks”. It is not in the foreground that there is a meaningful product expansion at the end of the hack. Rather, the model trusts that employees will learn something in this process and that this knowledge will at some point be useful for further product development. And if not, employees simply had fun and that shouldn’t be neglected in the model.
Transfer the Aligned Autonomy Model to your organization
First of all, some bad news: It is not enough to simply call your teams squads and your departments’ tribes from tomorrow. The model can only be implemented effectively if you are ready to change more than just environmental conditions. Because the organization demands above all a rethinking at higher levels of its corporate and organizational identity. The following steps serve as an aid to approach the organization step by step:
- What is the purpose of your company? The model gives each tribe and squad maximum autonomy. This only works if the goals and purpose of your company are tangible and understandable.
- How are your customer journeys and value creation structures? In my opinion, it is a big mistake to simply turn specialist departments into tribes. Instead, you should analyze your value creation structure, the vertical range of manufacture, and customer journey and see how meaningful classification criteria for your organization can be derived from them. For example, an organization can be created according to service areas, products, or customer groups.
- Who accompanies the change and the introduction of new working methods? Introducing the model is not done with a few funny posters and PowerPoint. You need a group of agile coaches in your organization who will accompany the change and bring the model to life.
If you take these three steps to heart, you have taken the first step to successfully introduce the model in your company.
Anyone who copies this model or simply implements any other blueprint of an agile organization is making a fundamental mistake. Not because the models are bad, but because the top-down implementation of a model of an agile organization selected or devised by a few managers, experts, or consultants contradicts the very essential principle of self-organization. Models of agile organizations are in principle emergent in the sense that they arise from the cooperation of self-organized teams in the direction of a common vision and are constantly developing. That is why a sustainable agile transformation must endure the pressure to deliver short-term successes and empathically and trustingly give people space and time to learn and grow together. As tempting as blueprints appear and as beautiful as their large-scale, actionist introduction may look, this is exactly what leads the agile transformation to a dead end.
The essential and most important unit in agile organizations is the self-organized team. This is what the principles behind the agile manifesto say. And this autonomy of the teams is also the central element in the model. The model was created from precisely this central principle and is therefore successful. Self-organization is the key, but also the challenge.
The responsibility for the model lies with those who have to work with it and in it. Everyone works continuously to make the organization better. That is the logical and necessary consequence of the principle of self-organized teams. Any form of structuring the cooperation between the many teams indeed restricts the freedom of the individual team. But this is necessary to make the organization and its product successful together. The freedom of the individual ends where the freedom of the other begins. The subtle but crucial difference is that these restrictions on the freedom of the individual team result from the cooperation of the teams and are decided by them themselves and the teams are granted and trusted to do exactly that.
The management and leadership task in agile transformation is therefore not to select the best model of an agile organization or to design your own and then roll it out. This massively violates the central principle of self-organization and keeps people and teams dependent exactly where they should act autonomously and responsibly. The actual management task is rather to create a framework in which such an organizational model gradually emerges from the cooperation of self-organized teams. This is a shared learning process that cannot be shortened using blueprints. If you try anyway, you just introduce a new organizational model and carry out a transformation, but agile is neither one nor the other.
Self-organization with a single team or with a few teams is not art. It only becomes difficult when the number of teams increases. Incidentally, that was also the case for one of our current customers, where the platform development team increased significantly from 30 to over 650 people from 2018 to 2021. And exactly then the time had come to introduce this model adapted to the customer organization.
Remarks
It’s our great honour to share this article to you, we are welcome to share it with your friends and colleagues. Visit the website of PEERSPECTIVE and find out more about the agile development and implementation of sustainable digital disruptive business models. Or be frequently updated by following the LinkedIn account of PEERSPECTIVE.
Kai-Oliver Rittner is entrepreneur and investor, who has more than 20 years of experience in top-tier management consulting. As CEO of PEERSPECTIVE, he promotes sustainable digital disruptive business models mainly for medium sized companies. Prior to that, Kai was working for leading organizations as an executive. He holds an MBA from Strayer University and completed several executive strategy programs at INSEAD. Kai acts as an agile program manager and holds different certifications, e.g. as Professional Scrum Master, Professional Scrum Product Owner and Scaled Scrum. You can contact him via Linkedin.
