- Ziryan Consulting - https://ziryan-consulting.nl -

How standardization and using Agile frameworks can harm your organizational agility

Most large organizations are determined to become Agile and turning the ship around in order to adapt to changes faster, focusing on employee satisfaction and increasing customer satisfaction. Prominent scaling frameworks such as LeSS, SAFe, Nexus, and Scrum@Scale are often used by organizations to become an agile organization. After the awareness of getting Agile, the next step in the process is usually finding a way to turn the company structure around. Agile consultants are contracted and the possible frameworks are examined. Next, a very arbitrary decision is made to use one of the scaling frameworks to be the standard implementation framework throughout the organization. Although there are many benefits in using these frameworks in supporting organizational agility, it is more often not a one size fits all solution for the organization. In this article, I will highlight the risk of this one-size-fits-all approach and address the role of leadership in adopting these frameworks.

Before I get into details, I first highlight two important Agile values which set the basis for the risk of using the above-mentioned scaling frameworks and the one-size-fits-all approach. The first value is Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The key to remember in this value is trust. Management does not have to tell the motivated individuals how they should get the job done. Management should have the trust that individuals are all motivated and capable of finding good solutions and carrying them out. Teams and individuals that find solutions and accomplish matters are also known as them being responsible for the “HOW”.

“ It doesn’t make sense to hire smart people and then tell them what to do, We hire smart people so they can tell us what to do”. – Steve Jobs

The second value is “The best architectures, requirements, and designs merge from self-organizing teams. Teams that are self-organizing will find ways to solve issues on the organizational level as well. It is more effective to have various solutions such as architecture, requirements, and designs emerge from teams than having these separate across various departments. Further, it is worth noting that this Agile value is rather broader than architecture, requirements, and design. This value also means that standards should not be forced upon teams as they are self-organizing. It is far more effective to involve the teams in the decision making so they can help and provide solutions to reach organizational goals. Setting Organizational goals is also referred to as the “WHAT”. Again, “HOW” the teams want to achieve the goals is up to them, they are self-organizing.

Although these two values are valuable to strive to, it is fair to mention that self-organizing teams are still far to reach in most organizations. Especially if the criteria is that each self-organizing team having the freedom to organize their work as they fit best to reach the goals. Because most teams are not yet self-organizing, it takes time to really change the organization. To gain time, standard processes and Agile frameworks are implemented throughout the organization. Even though the teams are not yet self-organizing, conforming to organizational processes is in this case not supportive of team’s freedom to organize the work themselves. To put it more radically, this means that beliefs that an organization will achieve efficiency by having standard processes and one way of working in the organization is in fact counterproductive. Unfortunately, changing this belief is very difficult. Especially, in times where results are not readily feasible, the need for command and control, common processes and common way of working grow more and more within large organizations. This usually means that transformations involve many departments. Consequently, the more departments involved, the bigger the implementations and the more complex these Agile transformations get. Therefore, try not to scale up, rather try to scale down to remove organizational complexity.

Try not to scale up, rather try to scale down to remove organizational complexity.

Scaling down will help you know more about the employees and the department cultures. Each department has its own set of values and culture, each department works with different people and a different kind of customers whom they service. Therefore, a process which works for one department may not automatically work for all other departments. As such, rather than having a universal process for all departments within the organization, allow tailored processes for each department(s) as required.

Storytelling time (fictive case):

The households in the city center of Rotterdam decided to take on a new initiative. They created a plan and received a budget from city hall to fund this initiative. The households agreed to sell 75% of their total number of cars and instead use public transport and share the remaining cars with their neighbors. The results after one year are amazing. The city center has reduced the carbon footprint by 70%, people saved up to 25% of expenses and as a result, the household happiness index has risen from 5.2 to an 8.6. Given this great success, the mayor now plans to extend the initiative to the entire city of Rotterdam. So, every resident receives a letter from city hall stating that they need to sell 75% of the cars in their block. To make it easier, blocks were already formed so that every household knows exactly how many households there are in the block, how many cars are available, and so that the residents know whom they need to collaborate with to reach the city goals. Each block has 6 months to start this initiative.

Do you think the mayor’s approach is a good approach? Would this work for all the neighborhoods in Rotterdam? Will they all get the same results and be as happy as the people in the city center? I can imagine you are leaning more towards a NO. This is mostly because the Mayor is not only telling the “WHAT”, but also filling in the “HOW”. And still, this is exactly what leadership teams in most organizations do during the Agile transformations. Companies try to implement processes and require standardized ways of working for all the departments. This is done in the belief that standardization will help them reach organizational goals faster. Chances are that all new departments will definitely not achieve the same results as it has for the initial departments.

I can imagine you thinking, “Ziryan, this is not the case in our organization at all. The city hall has demanded the other residents to copy the city center’s approach step by step. In our transformation, however, we, as managers, only tell the ‘WHAT’ and it is up to the departments to fill in the ‘HOW’. Isn’t Agile about setting goals and boundaries and letting the teams decide how they are going to achieve this?

Evaluating your own transformation, is your leadership teams really telling you the organizational goals or are they actually pushing a solution which has to be implemented?

Well, in a sense that is true. A Leadership team should be about the ‘WHAT’. While providing goals, the teams are responsible to decide ‘HOW’ to reach these goals. However, I tend to argue if this is indeed the case in most transformations. For example, the city hall also believes that they are telling the ‘WHAT’, and it is up to the blocks to self-organize ‘HOW’ to achieve them. But is the ‘WHAT’ in this case really a ‘WHAT’? Is it a goal which can be achieved or is the solution already provided? Evaluating your own transformation, is your leadership teams really telling you the organizational goals or are they actually pushing a solution which has to be implemented?

Clearly, there is some confusion as to the ‘WHAT’ and ‘HOW’ in Agile transformations. Many companies embrace Agile and implement one of the Agile Scaling frameworks throughout the entire organization. By doing so, perfect standardized processes and procedures are created that are then applied to all or many different departments within such organization. The Rotterdam city center initiative demonstrates why standardization should have no place in Agile transformations. This is because standardization does not satisfy the separation of ‘WHAT’ and ‘HOW’ and does not support in creating self-organizing teams. Therefore, such standard scaling frameworks are doomed to fail as this is a clear misapplication to become an Agile organization.

The solution for this mind shift, however, is not easy. Not all organizations can spare the time for self-organization and allow every department to figure out their own Agile journey (at least, that is a common belief). But, in case you as a leader can find some time for this, here is my advice how to go about this. In the spirit of self-organizing, you should have departments with their own purpose in which they can deliver value to the customers independently. The more dependencies between departments in delivering customer value, the more complex the collaboration will be. In this, leadership teams should not try to solve this by implementing frameworks for the synergy of processes. Preferably, they are focusing on creating a learning organization. There are a few ways to create a learning organization I want to mention:

Now, getting back to the statement earlier to not implement any scaling framework. Knowing the power of self-organization, frameworks and best practices can be very useful. But staying open to solutions which are different are more important that one framework in the organization. If the teams or departments think they can reach the goals with a different approach, they should be challenged and helped to achieve them in their own way. You would be surprised how much energy it brings to people when they figure out their own path in the Agile transformation.