June 2020 Archives

Manager as Scrum Master

Note: This article was originally published as an experience report in Agile 2011.


Manager as Scrum Master? You can not do that! It goes against the conventional wisdom, which assumes command and control managers cannot lead and coach as Scrum Masters. However, as an important aspect in Agile change, self-managing means a management transformation from command and control to leading and coaching. This experience report will explain how one large-scale organization adopted Agile over three years, with the focus on the evolution of Scrum Master and manager role and the way they work together. It describes how the change regarding self-management was introduced and adapted, then how we have tried to sustain the change by creating consistency between the values and principles behind Agile into the organization and the management capability to practice them.


I worked in a product development organization in Nokia Siemens Networks, formerly Nokia Networks, from 2002 to 2010. The organization consists of two sites, one in Hangzhou, China, and the other in Espoo, Finland.

In late 2005, we started Scrum pilots in various projects and teams to get focus and flexibility in our projects. We were running parallel projects and the resulting multi-tasking caused people to lose focus. Because teams were organized around components, not customer deliverables, we had a diluted sense of customer focus. The combination of single functional team and component team structure made adapting to change in a flexible way difficult. Because of all these factors, both upper management and the teams were motivated to try different approaches to development, and the agile nature and simplicity of Scrum made it a natural choice to try. I led one of the first Scrum projects in the organization.

In 2007, after initial success in our pilots, our entire product organization (over 500 people) decided to move to an Agile/Scrum model. I was selected to lead one department with ~100 people in the new Scrum-based organization and join the organizational leadership team. The story is about how we have been inspecting and adapting on Scrum Masters, Line managers and how they work and grow together ever since then.

Introduce Self-managing

Many organizations failed to change product management, which is typically a separate organization from R&D. However, in our case, Product management is part of our product organization, with the same boss. We introduced a Product Owner role and created a PO-centered mode of operation. Since traditional project management is distributed among Scrum roles - PO, team and Scrum Master, we eliminated most project managers to avoid the dysfunctions due to overlapping roles. People managers didn't feel threatened with this change, since people management is still essential (if not more so) in an agile organization. Thus, it was relatively easy to get their support. The challenge was getting people managers to understand the deep change needed to transform their role from command and control to leader and coach.

The original department consisted of single-functional component teams, and we reformed them into cross-functional feature teams. There were a few line managers in the department but Scrum Master was a new role. Product Owner was selected for our department. My first task as department manager was to set up teams to enable Scrum development (i.e. cross-functional feature team committing and delivering potentially shippable product increments on sprint basis), and get Scrum Masters to lead and facilitate the team and Scrum implementation. Self-managing is one essential theme in Scrum. I intended to incorporate this principle into the change - could we reform the teams and select Scrum Masters via self-management?

We started by sketching the constraints we faced and decided that we needed an appropriate sized team that was cross-functional and able to deliver customer features. We educated our people in self-organization, and provided opportunities for them to know each other. Our Product Owner also shared the current Product Backlog, which indicated the needed competence from teams. During the planning, one concern was raised, what if it failed to self-organize into teams, how long would we wait for teams to emerge? We decided to timebox the team-forming process and explained this to the potential teams. If teams did not emerge within the timebox, then management would decide the team composition for them.

We invited all the potential team members into a team forming session. Around 80 people were in one big hall room. Flipchart stands were distributed within the room, each of which indicated one team presence. We listed main criteria on the flipchart. After some turbulence, some people started to gather around stands, and others joined to discuss about the criteria. People moved around. Some people who shared good early working experience started to form teams as initial members, and they even added their own criteria to recruit other members, some related to the technical, while others related to the social. The most interesting experience happened in the end. Some "leftover" people finally merged into the last team. I was worried about their future, however, it surprisingly turned out to be one of the best teams later. After one hectic hour, 10 teams formed.

I was thinking of going one step further to ask each team to select their Scrum Master, but did not implement this idea for the following reasons. Line managers were not familiar with Scrum. In order for the change to succeed, they certainly needed to understand Scrum deeply and know how to effectively work in that mode. Practicing as Scrum Master could be good approach to develop that understanding and get them immediately involved in the new mode. Secondly, our people did not yet have the sufficient understanding about what good Scrum Master should be like, and there were few real Scrum Masters in the organization. I was concerned about the quality of self-selected Scrum Masters, thus, decided to recruit Scrum Masters by myself and create a pool of candidate Scrum Masters including all line managers. After the teams formed, the Scrum Masters presented themselves to the teams. The teams and the Scrum Masters mutually agreed for which team the Scrum Master would serve.

One risk to have traditional line managers as Scrum Masters was the tendency of working via authority, rather than influence, by line managers and the perceived authority by team, which may impede the team from self-managing. We instituted a rule that line managers could not be the Scrum Master for the team directly under their line.

Since all line managers including myself were Scrum Masters at the same time, line managers and Scrum Masters, together with Product Owner, worked very closely at both team level and organizational level. The size of this group, less than 10 people, made the efficient work possible. We had grown our capability of leading and facilitating teams through practicing as Scrum Masters and learning from external coaches. Moreover, we had developed deep understanding about organizational impediments to be solved and organizational supports to be established.

Struggling and adaptation

We soon found that line managers struggled with balancing the roles of organizationally-centric role of line manager and the team-centric role of Scrum Master.

During the planning of the transition to Scrum, a hot topic was the role of a line manager in Scrum. The Product Owner decides what, the team decides how, and the Scrum Master supports and enables. In the beginning, some people in the organization were unclear about how the process was supposed to work, and skeptical about the change. Crisis and urgent escalations from customers demanded immediate attention with little room for mistakes; organizational impediments surfaced and demanded management solutions. Making the transition to self-management requires even more management efforts, and more leadership. The dual function of the line manger affected the progress at team level towards well-working self-managing team with continuous improvement, as well as at organization level towards enabling and aligning organizational structure and support.

We moved towards having dedicated Scrum Masters, and let line managers lead organizational change and coach Scrum Masters. Their early experience as Scrum Masters enabled line managers to take on a new role in the Scrum organization that was more outward looking. Line managers became more involved with removing organizational impediments and creating the vision and strategy in organizational evolution. Line managers also transitioned from command and control to coaching Scrum Masters. Some new Scrum Masters were recruited within the organization; others emerged from within teams; others were identified and developed by line managers.

In our organization, line managers had the responsibility of supporting personal development. Once people understood better about Scrum Master role, some of them showed interests of developing into it. In the meantime, line managers were looking for candidates to take over their Scrum Master role. It was a good match. Nevertheless, with the social culture of valuing getting into management position more than continuing to develop into technical experts, we actually encouraged people to stay focused on technical skill development. We made it clear that being Scrum Master is good for learning and growing leadership, but it is neither a position nor related to promotion. In fact, it would affect becoming a technical expert. Line managers paired with the remaining people, who would genuinely like to serve the team and help them become great, as well got the support from other team members. By recommending books and sharing thoughts after reading, coaching and mentoring in the context of the team to which they belonged, letting them facilitate Scrum meetings and giving feedback for improvement, line managers helped them get ready to start. The taking over happened when all parties including team felt comfortable in doing so.

When we had the mixed role of line manager and Scrum Master, we started with a peer group of both line managers and scrum masters. With the evolution towards having more dedicated Scrum Masters, a single group grew above the appropriate size for effective team work. Therefore, we decided to separate them into two groups. One consisted of line managers, whose focus was to specify the ends and create the environment for team to achieve; the other consisted of Scrum Masters (and line managers as optional members) whose focus was the competence development of Scrum Masters.

We made line managers optional in Scrum Master development groups. In addition to keeping the group size small, we thought that the line managers' presence might prevent Scrum Masters from taking the ownership for their own development. We made it clear that it was their platform and line managers would participate based on a pull mode.

We implemented Scrum buddies, pairing a line manager and a Scrum Master, to support coaching and mentoring within the organization. For new Scrum Masters, we also paired them with experienced Scrum Masters, considering that they would learn more from hands-on Scrum Masters, and experienced Scrum Masters would increase coaching and mentoring capability through practicing.


A downside of having two separate groups was the lack of opportunity for Scrum Master to get involved at the organizational level. A good Scrum Master in our organization not only looks at the team, Product owner, and their interactions, but also at the organization. For a Scrum Master's growth, we wanted them to understand the organization. In addition to the line manager's coaching that could be extended beyond the team context, we created workgroups based on organizational tasks, which would not only solve the problem but also grow Scrum Masters. Another downside came from line managers being separated from the teams compared to Scrum Masters, thus, weakening their understanding of the problems teams were facing.

Although we had positioned line manager as organizational centric role and Scrum Master as team centric role, we noticed that the line was sometimes blurred for some Scrum Masters/Line Managers. It made sense to develop the consistency among them for sustainability.

Our organization as well as our department grew. We increased the number of new line managers as well. Besides following the conventional management ratio (one line manager for 2-3 scrum teams), the selection of new line managers provided the opportunity to create sustainability in the change. Those Scrum Masters who had already demonstrated leadership in both team and organization contexts became a good source of candidates.

When they were selected as line managers, they continued to serve one of teams under their direct line as Scrum Master. This supplemented the line management team with good insights from teams. This seems as though we were back where we started, i.e. line managers were Scrum Masters. There were important differences, though. In the beginning of the Scrum transformation, the focus was to implement the change throughout the organization, including creating the vision, communication to get buy-in, removing impediments, etc. At this time, the focus was to sustain the change and ensure that it became part of the organization. The best way to do this is through the people, in particular those who have influence. With great Scrum Masters being promoted to line managers, it created more consistency between values and principles behind Scrum-based organization and management capability to practice them. As teams became more experienced in self-managing, the original challenge of balancing the line manager and Scrum Master roles became less of an issue.

With the growing number, the team of Scrum Masters with the learning focus has evolved into Community of Practice, i.e. Community of Scrum Master. It became less efficient to complete task with big number of people, thus we shifted focus further on growing ourselves into good Scrum Masters via exchanging ideas, sharing experiences, opening perspectives and providing insights. With the new purpose after adaptation, we extended Community of Scrum Master from our department to the whole organization. We set up the mailing group and regular gathering to support the community. We made a few arrangements to cultivate it. A few Scrum Masters and line managers acted as the role model for how to properly behave in the community; we handed out good books and encouraged the sharing after reading and group study; we introduced the internal community to the Scrum China community, thus connecting us to the outside; and so on. Over time, people developed the learning habit and got into self-growing stage. That's where sustainability comes from. Personal continuous improvement from Scrum Masters and line mangers led to the continuous improvement in teams and organization. Moreover, when they started to contribute in wide scope, it created positive reinforcing loop.


The initial drivers for more flexibility and better focus were addressed by creating customer-oriented product backlog and teams accordingly, so that we as organization deliver potentially shippable product increments in every sprint. We experimented how to lead self-managing teams in this context, and discovered the followings.

Successful change needs both vision and down-to-earth. Even though the ultimate state is less management efforts through self-managing, we should not underestimate the management efforts while introducing change; even though we desire for emergent Scrum Master in the long run, we'd better not start with self-selecting Scrum Master; and so on.

Sustainability comes from the consistency between organizational management with servant leadership and the self-managing teams. Although the conventional wisdom assumes a conflict between the focus of the manager on command and control and the Scrum Master on leading and coaching, and may suggest to separate these roles, this is questionable when thinking about creating sustainability. Without changing the organizational management, self-managing teams are more accidental. When managers change, the original conflict disappears.

Finally, sustainability comes from a change in people. Without most of the people making continuous improvement on their own, continuous improvement at team and organizational levels is unlikely.

Once a team responsible for "A" (be it a function, component or customer domain) grows too big, we split it into two teams, responsible for the subsets of "A" (the left side). Why is it so natural to do this, rather than the alternative - we split it into two teams, responsible for "A" together (the right side)?


individual responsibility.jpg


There are a few responses.

  1. we don't know why we do this, with the variants of "we have been doing this", "others are doing this", "is there any alternative", and etc.
  2. we want specialization by letting each team focus on one subset.
  3. we want clear responsibility by letting each team work on one subset.

I don't know what to do with the 1st response, and I have explored the 2nd response in the series of "Number of backlogs and multi-learning". This article is for the 3rd response.


Mental model

The iceberg model is a systems thinking tool. It helps progress our thinking from the obvious event to the patterns of behavior, to its supporting structures, and its underlying mental models. The below diagram is from Michael Goodman's original article that introduced the iceberg model. In other places, mental models may also be illustrated as a separate deeper layer. 


For the topic of specialization, we explored mainly the structure, but mental models, such as "people can or can't learn", were also implied there.

Now look at the topic of responsibility, is the mental model here that "clear responsibility is necessary"? It is hard to dispute about this. Who wants its opposite - unclear responsibility? However, when two teams are responsible for "A" together, is the responsibility unclear? Not really, it is not unclear, but shared. What is the opposite of shared responsibility? it is individual responsibility. The response is actually that "we want individual responsibility" in disguise. The mental model is really that "individual responsibility is necessary".

Why do we want individual responsibility? Because we assume that shared responsibility means no responsibility. When something goes wrong, shared responsibility makes is difficult to find someone accountable, so as to blame or even fire him. By contrast, individual responsibility makes it more "clear".

However, the sole focus on its responsible part leads to strong local identity, and eventually silo mentality. Many people say that they hate silo, but the love for "clear" responsibility in fact helped create it in the first place. Maybe we don't really hate silo, do we?


From Individual responsibility to Shared responsibility

I purposefully make individual unclear - be it individual person or individual team. The underlying thinking is the same. We need to improve our mental model from "individual responsibility is necessary" to "shared responsibility could work, and even better."

This happens in Scrum adoption. One-team Scrum breaks down individual responsibility on the individual members, and defines shared responsibility on the team instead. The team takes shared responsibility towards its common goal. While individual responsibility makes it easier to hold someone accountable, it doesn't make the group a real team working towards a common goal. Individual responsibility creates silos in the group, and leads to local optimization.

This happens in LeSS adoption too. LeSS - aka multi-team Scrum - breaks down individual responsibility on the individual teams, and defines shared responsibility on the product instead. Multiple teams take shared responsibility towards their common goal. It has the same logic as one-team Scrum. This should not be surprising, as LeSS is Scrum.

The shift in this mental model happens at two levels - one-team (Scrum) and multi-team (LeSS), but they are essentially the same shift.


Espoused theory vs. Theory-in-use

Espoused theory is reflected by what we say; while theory-in-use is reflected by what we do. We realize the gap through the discipline of mental models.

When we let the whole team take shared responsibility in adopting Scrum, that is our espoused theory. When we still define clear responsibility for individual members and hold them accountable for their own parts accordingly, we have a different theory-in-use.

When we have already let individual team take shared responsibility, but fail to take it into the next level, i.e. multiple teams take shared responsibility on one product through shared product backlog and shared product increment, there is still a gap between espoused theory and theory-in-use.

The gap is not necessarily bad. When we realize the gap, we ask ourselves - do we really value the espoused theory? If yes, then the gap represents the tension between reality and our vision, so as to help create the path of least resistance. If no, then the gap is not real. As there is no commitment to the espoused theory, we will only manipulate the gap but fail to achieve our vision.

About this Archive

This page is an archive of entries from June 2020 listed from newest to oldest.

May 2020 is the previous archive.

July 2020 is the next archive.

Find recent content on the main index or look in the archives to find all content.