Want training, consulting or inspirational talks on this subject?
In the beginning of 2018, the organization we worked in roughly consisted of people in two roles: engineers in all shapes and sizes, who ensured maintenance and development of the infrastructure; and managers on different levels, who – well, did what managers do. They tried to be a little bit everywhere, making technology choices, ensuring allocation of people and resources to projects, talking individual development with their employees, and trying to ensure that the overall work climate was good.
We had only just started our agile transformation the year before, in 2017, and we had now read (some of the) books on Scrum and began to understand that we needed special attention to be paid to the way the teams worked together, including ensuring that they were aligned on what they worked on. To facilitate that attention, we introduced the Scrum Master and the Product Owner roles, as the literature prescribed.
We had implemented the two roles of Scrum Master and Product Owner differently in the different teams: in some teams the Line Manager filled out one of the roles while a team member took the other, in other teams both the roles were filled by team members – or members of other teams who took the role in multiple teams.
The reaction was mild surprise when we during 2018 concluded that the Scrum Masters and Product Owners struggled to introduce agile processes and prioritization in the teams. And don’t misunderstand us here – it was quickly clear to us that it was not the people in the new roles who were coming up short. It was the structure that somehow did not set them up to succeed, and we had not been prepared for that as we thought we had “followed the recipe”.
This post is about our considerations as to why we did not initially succeed in introducing the Scrum roles – and the experiment we implemented primo 2019 to turn the ship around. It is about the agile organizational model we came up with and the thoughts behind it.
As a result of our approach to the agile transformation – it was based on an invitation to find the best way we could and not an implementation of a given framework – we saw many different interpretations of Scrum in our teams in 2018, but there were patterns in what happened, especially with the Scrum roles:
- Team member in the role – authority is questioned. When team members filled the roles as SM or PO they often struggled with getting the team to back up their direction. SMs could not get teams to lean in on agile events such as daily stand up, planning and retrospective, and the Product Owners found it if not impossible then very difficult to get an overview of the teams’ tasks – and have the team share the priorities. In other words, their authority was questioned: “who are you to tell me what to do – you are not my leader”.
- Line Manager in the role – not enough focus. When a Line Manager took one of the roles, the issue was not authority – not openly, anyways. Instead, the issue was focus. The team members in the Scrum roles could mostly find the time to attend courses and training and thus had some level of knowledge about the theory of how to execute the new role. The Line Managers were extremely busy and could in many cases not find time – neither for upskilling or for filling out the role – as they were still expected to do all their other tasks.
- Line Manager in one role and a team member in the other. A third set of unintended consequences arose when there was a power asymmetry between the two roles, where for instance the Line Manager acted as PO and a team member as SM. In those cases, it was very hard for the SM to act as the “protector of the team” towards the PO.
We concluded that we had not empowered the people in the roles in the right way to ensure that the team was empowered. The lack of empowerment was not due to conscious ill will but rather the result of introducing a new, flat structure in an organization that had 80+ years of experience with running a smooth machine with formal (traditional) organizational structures and according to traditional thinker-doer hierarchy.
[A side note here: the machine was not smooth due to “thinker-doer” setup. As we will elaborate on in a future blog post on how we developed our Product Catalogue, most managers had did not have a high degree of insight into the projects their team members were involved in or the technologies the very specialized engineers worked on. Managers were perhaps into details of 20 % of the ongoing work and the rest was prioritized and handled by the employees. Thus, we had a huge group of “thinkers” – and very little alignment on where to go.]
The formal hierarchy and organization of the company had for many years dictated that it was the direct manager (the Line Manager) to whom the engineers reported who was ultimately responsible for the performance of the individual, of the team, and of the major deliveries themselves. Whatever went well, could be shared as a success but whatever went wrong was on the Line Manager. This naturally placed decision authority with the Line Manager.
So ultimately, we could “play the delegation game” as much as we liked, call out new roles such as Scrum Masters and Product Owners as much as we liked, but according to the organizational structure, the responsibility was ultimately with one person. The Scrum Masters and Product Owners would – if they were team members – be straw men who would always need to ask his/her superior before making a decision.
And furthermore, we could call out the PO role for a Line Manager, but he/she was still expected to continue handling all of the many tasks that he/she had before and a miracle would have to occur should he/she be able to dedicate him/herself to the new role!
There were two significant impacts of the setup. Firstly, when the role of PO or SM was filled by a team member they did not have the mandate to make decisions alone. Thus, decisions were being slowed down as there was now an extra layer between the Line Manager and the executing members of the team.
Secondly, when the role of PO or SM was filled by a Line Manager, the limited focus on living the role meant that it became inefficient: again decisions were slowed down.
In other words, the setup gave us the opposite of what we needed and wanted, and we asked ourselves if “agile” was simply not for organizations like ours.
We sought inspiration from many sources – agile frameworks and other companies that were further on the agile journey – but we could not find anyone who addressed our problem in a way that inspired us to what we could do about it. We decided to make an experiment on our own. And it all revolved around pushing mandate as close to the team as possible by empowering the POs and SMs by removing some of the hierarchy: we wanted to formally divide the responsibility that traditionally had been with one person, the Line Manager, on more persons.
After deliberating what to do, the CTO (head of the department) was clear on that the new agile leadership model should cater for three purposes: increase the quality of leadership, increase the quantity of leadership, and increase the motivation for leading.
Quality. To become really good at what you do, you need to focus on practicing it. A traditional Line Manager has to be good at
- “People”. Create a pipeline of candidates for hiring, be great at spotting and hiring the talent, ensure well-being with employees, and understand which competencies the employees need to develop – and develop them.
- “Team”. Ensure the team works well together, understand and utilize group dynamics, facilitate collaboration, and help the team remove the impediments they are facing.
- “Product”. Understand the need of the customers and markets, understand the development in technologies, architecture and principles, negotiate with vendors and providers, prioritize on behalf of the team and set a clear vision for the product.
Our hypothesis was that if we separated the responsibilities of the traditional Line Manager, the leaders would have more opportunities to get deep into the subject matter and become more competent, i.e. leadership would be better.
Quantity. We acknowledged that our Line Managers were on a tight schedule and that as there were only 24 hours in a day – and as only 8 of them was supposed to be spent on work – they had limited capacity. Our hypothesis was that if we assigned leaders to handle either technology (products) or teams or people, we would be able to provide the amount of leadership and attention that is actually expected by both top management and by employees.
Motivation. Our experience was that leaders have a preference for working with either technology, people or processes – or a combination of those, but never all of them equally. Our hypothesis was the if we divided the leadership responsibility and cast our POs and SMs right, we would allow leaders to be occupied with the elements of leadership that interested them the most. And following from this, we believed their job satisfaction would increase.
Based on the principles, we took the radical decision of eliminating the role of the Line Manager. We got buy-in from the brave HR department who let us do an experiment that was counter to the traditional way of organizing in the company, and the Product Owners and the Scrum Masters (we called them “Squad Leads”) would now be officially responsible for products and teams.
The only issue left was that we still needed someone to take care of the “people”-side. And we did not want to put that into one of the existing roles (PO or SM) as this would jeopardize the effect of these roles.
Instead, we created a third role who would handle this as well as the overall organizational design of the organization: the Organizational Lead (OL). The final element of the model was to highlight how the team played a vital role in leading themselves, and they were called out as the fourth role; the Squad, with separate and unique responsibilities.
We ended with six chapters, one per Organizational Lead who now had on average 25 direct references. The chapters were built around shared tasks, technologies or industry areas, and the assumption was that there would be economies of scale for the OL leading the chapter as the competency development need, the market for finding new talent etc. in the chapter would be similar. The employees were then spread across the 15 teams and the intention was to keep teams as stable as possible but to enable that employees could flow without losing their “home” – their Organizational Lead.
We ended up with more than double the number of “leaders” from the setup we came from, which was initially something we questioned. On the other hand, we had pointed to the fact that we needed to be better at leading and to do this we believed we needed more and more specialized people to facilitate that outcome.
While the overall objectives had been to increase speed of decisions, motivation for leaders, quantity and quality of leadership, we made a point to make sure that the value proposition for the teams and the employees were clear: those were professionalization, clarity and stability.
How did it go? It worked, is the short answer. But for a long time, the improvements were not visible to us. Issues with understanding “why are we doing this”, uncertainty and overload on the new leaders, and lack of processes for coordinating dependencies overshadowed the positive effects.
Today, however, we believe the conclusion is positive:
- Speed. The speed of decisions is much faster than it was before the organizational change. With few dependencies Organizational Leads hire and introduce new learning paths, Product Owners decide directions and priorities in much greater alignment with the reality as felt by the teams, and Squad Leads facilitate their teams. What we haven’t been able to solve are dependencies that go beyond our department and involve, for instance, HR (how many positions can we get) and top level management (where can we spend money and what is the overall direction).
- Motivation. The motivation in the leadership team has gone up since introducing the model, and a united leadership team are happy with the increased focus. We did have a really significant dive in motivation after introducing the model in 2019, which we spend on finding our feet, but today, the model is accepted and overall the leaders enjoy being able to specialize and focus while the teams are seeing the advantages of being able to draw on different competencies. What we haven’t solved is the question of leader career paths, the intense workload on leaders – especially those with multiple teams, clarification of expectations to the role, and how to coordinate around a team, product or person as more leaders are involved.
- Quantity. The teams experience that leaders are present. The SLs and POs meet at least once a day with teams, and they are in many of the meetings with stakeholders and vendors, to a much higher degree than before where the leader was a distant figure. Especially the OLs, though, had issues as the amount of direct references combined with the responsibility to define the overall organizational layout was a stretch.
- Quality. The engineers are expressing the value of having a non-technical but socially and psychologically skilled OL to spare with on non-technical issues such as collaboration difficulties or personal issues, and the OLs have established a well-oiled Hiring Squad, have raised the professional bar on how to ensure a hiring pipeline as well as screening process. The Squad Leads are educated in agile practices and actively help teams remove impediments – on a daily basis, and the Product Owners are working with value measures and are learning to say “no”. We didn’t manage to install leadership learning programs for all roles and all individuals, however, so some of the leaders have been left to their own devices to ensure that they built the necessary competencies.
- Clarity. The team members now understand which leader to approach with which issues as well as what to expect from the different roles.
- Stability. We have managed to keep chapters and teams relatively stable as opposed to before where there was a new major organizational change every year – now changes happen when they need to.
Curious to learn more?
Want training, inspirational talks of consulting on the topic?