Building the «Agile Organization» – Don’t imitate. Innovate.
Agile organization?
Tribes, guilds, squads… without any doubt the organization map of an «Agile company» shows some patterns that clearly reveal its nature. However, it has nothing to do with these catchy names from the wrongly called «Spotify’s model». Sadly, this non existing model has become a reference that is copied by almost any organization planning to launch an «Agile transformation».
We come across companies that believe that this organizational model with multiple roles and functions is the key to success of an agile organization. This belief explains why many companies embark on this journey to agility by developing training programs. Usually, they do that at the outset to ensure that all employees understand their new roles and accept them in the new organisation chart. Nothing to do with Agile nor with agility.
However, in most companies the implementation of a new organizational structure like this does not deliver the expected results. Neither does it improve the customer focus in the teams nor does it increase the company’s capacity to react to change in the environment.
Why?
There are a number of reasons for these shortcomings, but the root of them all lies in the mindset itself. It is usually characteristic for most organisational transformations, that companies invest huge efforts in copying the methodologies and imitating the behaviours of their referents.
On the other hand, very little time is invested in understanding the essence of the system, the values that underlie all these artefacts and methodologies. Often, we want to obtain the results of a system without the firm commitment to accept the values of the new working culture.
In this particular case, The key is to understand that this whole structure of roles and functions is not what makes Spotify an agile organization.
In reality, it’s just the opposite. The organization had an evolving mindset based on agile values and principles before it had all these functions. Then, all these roles emerged progressively in a specific moment of their evolution. As a matter of fact, the teams themselves and some leaders of the organization found that they were necessary to provide value. They experimented and learned as they have continued doing experiment after experiment. Today they might be dozens of experiments away from that. Therefore, copying that has absolutely no sense for any other organization.
An example
In this sense, we specially like this reflection from Taiichi Ohno:
“Stop trying to borrow wisdom and think for yourself. Face your difficulties and think and think and think and solve your problems yourself. Suffering and difficulties provide opportunities to become better. Success is never giving up.”
So, if not by way of describing roles and functions: how should the shaping of an agile organization begin?
The Agile Organization: next steps.
First steps
Well, in 1968, Dr Melvin Conway published an article to spread some characteristics of those organizations that are engaged in the design of systems.
In the article, Dr Conway explained that organizations intending to design complex systems are totally committed to copying their own internal communication structures into this design. According to Dr Conway, the product or service resulting from an enterprise reflects like a mirror in their organization chart.
The fact that there may be a relationship between organizational design and the structure of products or services is key to understanding how we should proceed in designing an organization.
How to design the Agile organization?
First of all, we should start by thinking about the value of our operations and the needs of our customers. Instead of designing the organization chart like a puzzle, trying to integrate the new roles that Spotify and others have added, we should think how we may achieve this. This is the only way to get an organizational design that efficiently meets your needs.
It is very likely that the teams resulting from this analysis of value flows will be multidisciplinary teams focusing on this same value network. However, we should not fall into the trap of thinking that each team in the organization will adapt to this model. In some areas of the organization, the most efficient organizational model will be a completely different one, depending on the value contributed:
- Value oriented teams: are multi-functional teams geared to meet the particular needs of a complete flow, from start to finish.
- Enabling teams: are teams that normally support specific operations in the value chains. They are geared towards developing capacity, ensuring that the organization’s knowledge is updated to offer the best all the time.
- Subsystem: teams with a very specific technical knowledge that is inaccessible to the rest of the organization. Their role is to handle and (re)solve all issues that depend on this knowledge. In fact, this is not a type of team that organizations want to keep permanently because it tends to become a bottleneck in times of peak demand. But in certain situations this is the only way to deal with specific issues.
- Platform: finally, teams that prepare by-products or generally standard solutions and keep them at disposal for the client or other teams to develop a customization.
Dependencies between the teams.
Agility and speed of response are the results of an efficient interconnection between teams.
Different relations in an Agile organization
Regarding relations between teams, we can differentiate the following relationship models:
- Collaboration. In this format two or more teams work together on a solution.
- Facilitation. One team provides a product or solution so that another team can do its job efficiently.
- Supplier-customer relationship. Here, in this most traditional and official format, one team raises a need to another that responds with the requested solution to an explicit demand.
Conclusions.
As explained in this article, it is obvious that organizational design can never be the result of copying the roles or artifacts others have built into their organization. After all, we cannot hope that everything will synchronize naturally as if it were a perfect gear.
Finally, as we learned from our colleague David P. Hanna, it is essential to recall that “all organizations are perfectly designed to obtain the results they obtain”.
Consequently, it makes sense to initiate an organizational design change by thinking about the purpose of the organization, the customer needs, and what are the results we want to achieve.
