Manager as Scrum Master
Note: This article was originally published as an experience report in Agile 2011.
Abstract
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.
Context
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.
Sustaining
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.
Summary
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.
