Posted on 24 Comments

Scrum Master – A Manager

Manager – Traditionally

Traditionally an individual is declared a ‘manager’ when having hierarchical control over other individuals. A traditional manager exerts power. A traditional manager commands people through the assignment of to-be-done work; expressed as tasks or work packages, given on a daily base or via to-be-followed plans. Subsequently a traditional manager follows up on the execution of the assigned work. The traditional manager does not wait for the results of the work but wants to see how the work is being carried out, who is doing it, when the tasks are being performed and how much time it is taking. The time it takes is in general compared to the time that was instructed the task should take.

This and other performance information is recorded and stored, mostly in reports and other forms of documents. The traditional manager (in)frequently uses the stored information to evaluate a subordinate in order to steer that person’s career; via carrots like education, promotion, incentives, bonuses, salary. The traditional manager acts as the one who knows it all, and is supposed to act in the best interest of the company and its shareholders, even if that interest is obscured from the people assigned with the actual productive work.

Not limited to, but certainly in a context of agile, there is not only no need for a ‘manager’ behaving according to this authoritarian pattern and traditional expectation, it is even highly counterproductive and extremely discouraging. Dan Pink - DriveIt undermines enthusiasm, disregards intrinsic motivation by focusing solely on extrinsic motivators, kills job satisfaction, is an open door for politics and bribery and is therefore catastrophic for an organization depending on people. It is without doubt disrespectful and inhumane.

Is the notion of ‘manager’ therefore forever corrupted? Evil by default? A lost case?

Management – Actually

Scrum, like all things agile, has a very different viewpoint on working with people and on the aspect of management, but it does not the disregard that the activity of managing is required.

Let’s explore this different perspective upon the statement that “Scrum Master is a ‘management’ position”.

Indeed:

  1. A Scrum Master is a manager. Contrary to the traditional idea of a ‘manager’, a Scrum Master has no formal power over the people in the Development Team, not deciding over their careers, incentives, etc. A Scrum Master does not manage the people or their tasks. But a Scrum Master does manage (via) the Scrum process. Within an organization a Scrum Master is accountable for the maximization of Scrum, for ensuring that people, teams, departments and the organization realize the highest benefits possible from using Scrum. A Scrum Master is accountable for the way Scrum is understood and enacted. This requires management skills, traits and insights.
  2. A manager is a Scrum Master is a manager. A Scrum Master is explicitly responsible for removing Impediments. Impediments are elements that limit the efficiency and progress of a Development Team in areas that are beyond the reach of self-organization of a Development Team. Impediments are most often found in the wider organization, in company processes, procedures, and structures. Removal of Impediments works better if the Scrum Master is a manager turned Scrum Master, thereby adopting facilitation as the primary management tool and seeing the workfloor as the primary habitat.

A Scrum Master indeed is a manager, albeit not in the traditional sense. It is clear that a Scrum Master does not manage budget, people, work and tasks. Product Owners manage investments. Teams manage themselves. However, self-organization as promoted through Scrum does require goals and boundaries. A Scrum Master manages the boundaries that Scrum provides to augment self-organization; time-boxing to limit risk, focused efforts, cross-functional collaboration, releasable results, validated learning.

The Scrum process does no more than framing the creativity of people in their joint creation of valuable software. The process of Scrum lays out a foundation for rhythm and discovery. A Scrum Master manages the Scrum process through the provision of specific services like removing Impediments, facilitating teams, educating the organization, coaching people and keeping the road open to perform, to work, to innovate, to be creative. The services that the Scrum Master provides, needs to provide or is allowed to provide become a mirror to the state of Scrum in an organization.

Scrum Master can be seen as a management position because the Scrum Master role holds what is expected from a manager in an agile context, not because it reflects what traditionally is expected from a manager. A managing Scrum Master is a wise leader that engages people through organizational purpose and vision.

Manager – A Scrum Master

A manager who acts like a Scrum Master optimizes the value of management to the organization. The optimization lies not in commanding and controlling tasks and detailed work items. The value a manager brings lies in identifying wasteful activities, eliminating waste, removing impediments, embracing complexity by assuring Scrum is understood and enacted, from its principles and roots in empiricism, building on the core Scrum Stance, propelling on opportunistic experimentation, setting goals, and maintaining purpose.

The Scrum Master-manager is strongly affiliated to the Lean idea of “Go See“. A manager turning Scrum Master is a person that does not hide in a far-away office. Not hiding is much more than merely creating an open door policy. An open door is a fake measure, as it still lays the burden with the people wanting to see and talk to the manager. The workfloor buzz does not enter through that door. The flow needs to be reversed. The Scrum Master-manager walks around, is part of the workplace with the teams, the place where the real value is created. In Lean this place is referred to as Gemba.

It can even be taken some steps further with the idea of Empirical Management.

Management – Definitely

Even in an agile context, the act of managing remains a valuable activity. The act of managing is performed by managers.

Teams manage themselves. They organize their work autonomously. They are managers too. Product Owners manage the product’s vision and the investments in the product. Others manage boundaries, company objectives and identity, technical environments, the Scrum framework. ‘Management’ is the collection of all such activities. Management done properly thrives on servant-leadership. ‘Management’ is not a collection of people executing hierarchical powers. It is an emergent, networked structure of co-managers, people with complementary skills, focus and accountability, mutually exchanged services. All seek direction. Collaboratively. Continually. Skills and meaningful conversation prevail over title, hierarchy and position.

“What you say has priority over how you look.”

Is a manager who turned Scrum Master still a manager then?

Posted on 5 Comments

A Mirror of the Scrum Master’s Work (so far)

Introducing “ScrumAnd”

Jigsaw Scrum

Adopting Scrum best starts by doing Scrum in the first place, getting all the formal elements of Scrum in place. It is like a jigsaw that isn’t complete until you have fitted all the pieces together. Luckily Scrum doesn’t have many pieces: 3 roles, 3 artifacts and 5 events. A simple set of rules can emerge complex behavior.

This ability to say “Yes, we do Scrum” however is only the start, not the end. Scrum is not the goal, Scrum is a mean to a goal. In order to increase the benefits, the way Scrum is used is to be maximized, thereby moving to “Yes, we do Scrum. And…“. There is a “ScrumAnd” for a myriad of elements. In the post Illustrations of ScrumAnd this was demonstrated through (1) the Product Owner role, (2) the ability to create releasable Increments and (3) the level of collaboration within a team.

Note: in 2018 I elaborated on the topic by describing how the ScrumAnd stance requires though and discipline.

Applying the “ScrumAnd” model on the role of the Scrum Master.

The Scrum Master facilitates Product Owners, Development Teams and the wider organization with services. The benefits gained through Scrum depend on the services provided by the Scrum Master. Or is it the other way around?

ScrumAnd - Scrum Master

It is unfavorable, difficult and probably impossible to forcefully command people, teams and organizations into higher performance. In a “ScrumAnd” view on the Scrum Master role, there is less of a deliberate choice or strategy involved to increase benefits.

Teams though can be facilitated and wisely lead into benefits that will last. Yes, you do Scrum if you have a Scrum Master. And the level of services that the Scrum Master provides probably reflects the state of Scrum:

  • A Scrum Master teaches techniques for others to use; how to manage Product Backlog (syntax, sizing, splitting, grouping, descriptions, refining, dependencies), how to create visibility of progress (burndown charts, Scrum boards, cards, velocity, release plans), creating a definition of Done, how to plan and execute a Sprint, how to do a Sprint Retrospective meeting, the value of time-boxing.
  • A Scrum Master helps teams and their wider environment optimize the use of Scrum through Scrum’s foundation in empiricism; how Scrum implements transparency, inspection and adaptation, how Scrum helps when only the past is certain and the future is uncertain and highly unpredictable.
  • A Scrum Master shifts the focus from using Scrum to deliver on a set expectations (scope against time and budget) toward organizing work for creating the most valuable outcome; shifts focus from the process itself to the goal of the process.
  • A Scrum Master focuses on behavior, instead of ‘process’ and even outcomes. Accountability drives behavior, and behavior becomes grounded in the Scrum values, and Scrum is understood and applied through the values and principles expressed in the Manifesto for Agile Software Development.
  • A Scrum Master is present with a team, and within the organization; a silent, non-intrusive, mentoring, comforting, observing presence.

Scrum Masters are often expected to operate on the practices end, to be teaching techniques. Development Teams might want it because they have always been told what to do. Managers might want it because it is as close as they feel a Scrum Master can get to executing control in this new way of working. Scrum Masters themselves have the intrinsic desire to be invisibly present.

Whenever a service is needed, by the Scrum Master’s observation or by explicit request, a Scrum Master assesses the service level required depending on the requester, context, time. The happiest moment for a Scrum Master occurs when teams push back for being provided with too low level services.

The service that the Scrum Master is providing becomes a mirror for the Scrum Master’s work so far. Complexity equals instability, by default. Staffing changes (in the teams and in the organization), relationships change, strategies and objectives change, technologies change. A Scrum Master keeps going back and forth, up and down through the range of services possible. A Scrum Master cannot expect to steadily provide only one type of service.

Where are you, as a Scrum Master? What services are requested from you? Do you provide services that reflect the actual maturity of the team and the organization’s understanding and usage of Scrum?