Part 8: Autonomy and Alignment

As mentioned in previous posts in this series, Agile teams should have a high level of autonomy. This autonomy has in some cases gone so far, that it has become impossible to steer the efforts in a good way. This happens because the teams have the impression that no one except the team members can decide what they are to build and deliver. This is of course a very bad situation and will not make the company successful. It also means that the product owner has forgotten that her reason for being is to serve the stakeholders.

Therefore, lets see how we can create a balance between team Autonomy and common goals. We start by looking at how we see ourselves organized in an organic organization where we have different teams and tribes.

Teams, Tribes and the Company

Modern companies, and especially tech driven ones, have a more organic way to organize themselves.

The image above tries to explain that we have several tribes with different purposes in the company. In each tribe you have one or more teams and these teams are to various degrees dependent on each-other. The same way different tribes may or may not have dependencies.

For this to function it is important to work with guardrails that tells each tribe and each team what falls under each one’s responsibility. This is important and helps us to avoid conflicts. It also helps us to avoid that two teams are working on the same or similar solutions/projects.

Since the teams should be autonomous but still aligned, we now need to find balance between these two “extremes”.

Finding a balance

There are different ways of working, and the way we work is to a very large degree affected by the leadership culture and upper management’s maturity. Schematically we can describe the various situation as the grid below:

1. Low Alignment – Low Autonomy
   This way of working is essentially micromanagement of the team and leads to a situation where the goal/purpose is only specified for that team; there is no high-level purpose.
   The leader of the team has been given a problem to solve and must work out how it should be solved. Rather than letting the team give input, it is given rules/processes to follow in order to solve the task. The motivation, pride and feeling of purpose will be low or non-existent in these teams. This will lead to high employee turnover and poor results, with no proactivity.
   
2. High Alignment – Low Autonomy
   This second way of working is the way most traditional companies work; where hierarchy and reporting structures are well defined and viewed as important. This structure often also leads to micromanagement.
   The leadership has good communication and can formulate the problem statement. However, the leadership is also the ones presenting the solution to the problem.
   Once again, there is low autonomy, which means that the team members will have little to no input here. The high-level purpose is recognized, yet the team are just following the orders to reach that. Again, motivation will most likely be low in this working culture, and important aspects of the problem solving are lost.
   
3. Low Alignment – High Autonomy
   This is common in new businesses/start-ups; Everyone has a vague idea about the overarching purpose, and the way there is a chaotic journey.
   In this culture, the team has all the autonomy and works however it wishes to. The leader of the team has little to no control, and alignment between teams is not efficient or even wanted. This is the situation in quite a few “tech-driven companies”, and it leads to a lot of problems, usually for the companies’ operational teams. You can read more about this in an article I published on LinkedIn some time ago.
   
4. High Alignment – High Autonomy
   This is the ‘Agile’ culture we should strive for. Here, the leadership’s focus is on ‘what is the problem?’ and the high-level purpose is recognized. Unlike the two first cultures, the team then have the freedom to solve the problem, as it sees fit.
   This means that we away from the classic “rule-following technique” and towards collaboration, engagement, alignment and thinking.
   Motivation will be high in this culture, because the team members are encouraged to come up with solutions. In my experience, high motivation is a key factor for good results. Higher autonomy also allows for faster decision-making, due to decisions being made locally rather than waiting for conformation from higher up.

As you understand it is in the fourth quadrant we want to be, because for agile teams to work efficiently, they need autonomy. This also means that if you are leading the team, you need to take a step back. You should not take the decisions for the team unless absolutely necessary. Especially since you as the lead should not be the expert on all the tasks and topics in your team.
Therefore I usually let the team discuss and come to a conclusion, and only if they are unable to agree I step in to make a decision. After all, a company is no democracy.

Autonomy between teams require the teams to align between them. Otherwise they cannot strive towards the same goals at the same time and in a sequence that brings most value to the company.

For autonomy to be beneficial it needs to be handled correctly, and one of the most important aspects is information; If the teams are well informed and updated about strategy, goals and plans of the company, they know what direction they need to go and what needs to be done when. Since not all information can or should be shared widely in the company, we work with OKRs as one method. Please see Post number 5 for more information.

Day-to-day alignment

For day-to-day alignment, Agile methodologies comes with a framework, which has been discussed in previous posts:

• Daily Stand-ups
• Retros
• Sprint planning
• Initiative boards
• Road-maps

Lets look at a two examples, to put this into practice:

Example 1:

• A team responsible for increasing the number of VMI (Vendor Managed Inventory) relations needs the team responsible for EDI and API integration to engage in order to onboard the suppliers and retailers.
• A representative of the VMI team visits the daily stand-up, at the stand-up/scrum board of the Integration team twice per week to inform about pipeline and what needs need to be catered for and by when.
• The integration team commit to work that they see possible to do. Not more.

Example 2:

• A tribe is responsible for making the supply chain more efficient and automate the flows. This means several digital product teams are involved in the work.
• The Initiative Board is used to display all the different activities and where in the life-cycle each task and each team is.
• Team A is responsible for automation of the order flow, and is creating a dashboard for displaying stock levels, current production and planned production.
• Team B is the team responsible for warehouse systems and is developing an integration to get stock levels from 3PL:s automatically

Hence, we see dependencies here. Alignment between teams, about when to do what, possible blockers and help needed for next sprint are handled at the Initiative Board meeting (or in a subsequent gathering in case discussions are longer than 5 minutes).

Alignment between two teams, that needs to happen in-between the Initiative Board meetings, is handled in the daily stand-ups, where team members from one team visit the stand-up of another team.

Since the teams are autonomous, knows the priorities of the company and have clear OKRs, the alignment and discussions do normally not need any involvement from upper management or even the leads.

How this affects Operational Excellence

Operational Excellence is dependent on teams working together in order to solve end-to-end process issues.

In a company operating as the 3:rd model described in the beginning of this article, it becomes almost impossible to get everyone to work towards this kind of improvements: Everyone owns a small part of the process, and makes changes and adjustments there, but there are gaps and holes in-between the various components which leads to manual work and quality issues.

In the first and second model, you may have greater chances of success, but a common problem is that no one wants to give clear directions, and because we work in silos , no one sees the over-all processes in a holistic way.

OKRs and cross team collaboration gives us a higher chance of success.

In the next post, I will give some tips and tricks on how to implement agile methodologies in non-tech teams, and I will use examples from how I have done this in practice in the past.