In Certified ScrumMaster (CSM) courses, many Scrum myths are busted. One such myth is that the ScrumMaster is somehow an administrative assistant to a development team, to a product owner or to an organization.

The Scrum Guide notes that the ScrumMaster is the servant leader to a development team, to the product owner and to the organization:

The guide describes this service as coaching, guiding, enabling understanding, enabling outcomes and so on. It does not talk about the ScrumMaster typing or writing.

Get Your Hands Off the Team’s Work

When ScrumMasters describe writing down “notes” for the team or scribing the team’s tasks at sprint planning this is what I advise ScrumMasterss everywhere: “Get your hands off of the team’s work!”

Will the team ever learn accountability and collective ownership if there’s an admin who will simply scribe everything for them? What will the team do if their ScrumMaster / Secretary is off for the day? Typically nothing is noted in these situations because the team has not assumed any level of accountability or ownership for tracking their own work.

I have the pleasure of working with high performing Scrum teams. Rarely is there a case where the team members expected someone to write down what they were saying or doing. The development team members make notes, type and do all that is necessary. They see it as just “work they have to do,” as opposed to falling into dogma from traditional system development lifecycle roles. The ScrumMasters serving in those situations, truly understand that they are focusing on the outcome, listening for impediments and pulling interactions back on track. When ScrumMasters feel like they have to “scribe,” their focus is split and they rarely pick up on the items that a great ScrumMaster notice.

Get Your Hands Off the Product Owner’s Work

A great ScrumMaster also needs to serve the product owner. I recently performed an assessment in which the ScrumMaster “kept” the product backlog. The product owner had not only never touched the product backlog, they did not even have access to it. Yikes! Once again ScrumMasters who are falling into this dysfunction, I advise:“Get your hands off of your product owners work!”

The product backlog is for the product owner. It is the way they manage the work that is needed for the product. While anyone can add items, this should not be interpreted as “just send your items to the ScrumMaster and they will take care of adding them to the product backlog.” Many dysfunctions are created out of this type of activity. Not only is the product owner not taking responsibility for the list of items to work on for the product, they are also more than likely are not actively refining and getting items to a state of ready by sprint planning time either.

Service to the Organization

Many associate the ScrumMaster with only a development team and a product owner. This tells me that these ScrumMasters are missing a third of the job. The ScrumMaster has responsibilities in the organization to teach, coach and guide the right outcomes.

In Certified Scrum Product Owner (CSPO) classes, I hear product owners describe interactions with steering committees or leaders that get heated, go down rat holes and never have a definitive outcome. “Where was your ScrumMaster when this was going on?” I ask. They go on to explain that no note taking was necessary so the ScrumMaster was probably not needed for the meeting.

The ScrumMaster is a neutral. They are a facilitator. Who better to come along when the product owner expects emotional discussions? As a skilled, neutral facilitator, a great ScrumMaster can keep the discussion fact-based and focus on the outcomes. If good ideas are generated during the discussion, he or she can suggest that these ideas be captured in the product backlog, so that ideas that can be discussed at a later time and don’t detract from the focus of the conversation at hand.


The ScrumMaster is not an administrative assistant or a secretary. They are the master of the Scrum framework. A process enabler. An advocate for the development team, the product owner and the organization. Great ScrumMasters who focus on servant leadership and outcomes will enable delivering of business value with each sprint.

Check out VersionOne’s upcoming CSM and CSPO training classes.


Join the Discussion

    • Peter Jetter

      I interpret enabling as Capability Creation. I headed global Capability Management Programs in large enterprizes. “Enabling” requires more resources than just “team time”. For example time and decisions from executives as the owners of the business environment, time&collaboration from peers above unit levels to break silos between units. (That´s big money we are talking). Which SM is authorized to make use of resources other than “team time” or change structures and processes above team level? Practically none. Thats why we always seem to need more powerful Agile Coaches as substitutes for empowered SMs (at least until maturity level has raised enough, so that decision authority has been truly delegated and distributed to self-organising teams). How many SM are in a position to effectively influence systemic dysfunctions, let alone “remove impediments”? PO and SM roles in ScrumGuide are largely superheros, IMO. Thats why we find so few in reality.
      Sure a Jeff Sutherland or some other Guru can make an Agile Transition work. But they are not really operating from a SM power base. In a power-based org, the org changer most be powerful enough to alter existing structures and processes to create an environment, where self-organized change may actually happen.

      • Angela Johnson

        Hi, Peter,
        Thanks for your post. That’s kind of my point. When ScrumMasters relegate themselves to an administrative position, they are enabling the wrong outcomes and behaviors. Every one of us has the potential to be a “Jeff Sutherland guru”…you just have to want to and then behave congruently. One of the Scrum values is Courage. It’s not Fear. I’ve seen people in the ScrumMaster role embrace it as intended and help bring about positive change in many organizations. It’s just becoming the norm that many default into administrative assistant mode and perpetuate the status quo. Which is not what working differently is about.
        Best regards,

    4 + 5 =