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?
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?