6 Tips For Scrum Masters Without Authority

For the scrum master, scrum is the tool to help the development team increase productivity, meet delivery dates, improve teamwork, and to better satisfy the customer. The scrum master is meant to help create an environment where the development team is trusted, empowered, and given the appropriate autonomy to get the job done. Once in place the development team can soar if they collectively agree to do so. The scrum master’s job it is to help the development team soar, to become high-performers and hyper-productive. But how can scrum masters achieve this without authority? Here are 6 tips for scrum masters to help improve both the environment and the development team without authority.

  1. Guide management to actively trust and empower the development team
  2. Guide management and the business on how work flows to the development team
  3. Develop an understanding with management for supporting scrum and the efforts of the scrum master
  4. Workshop with managers and development teams to understand limits and boundaries
  5. Train the development team on Scrum
  6. Have the development team create the metrics and measures they’ll use to know they’re doing better, worse, or neutral

Guide management to actively trust and empower the development team

For trust and empowerment to occur, the manager must let go of the team. The scrum master can help the managers cross the bridge between being a leader to becoming a servant leader. This can be difficult and time-consuming but it can happen. This was the topic of a talk I gave at Scrum Australia 2016, The Journey to Servant Leadership.

As scrum master, use yourself as a mirror to reflect back to the manager how they behave. I used a camera to record the manager’s interactions with the team to great effect. It is often surprising to the manager to see how they interacted with the development team.

Guide management and the business on how work flows to the development team

In scrum, all work to the development team should flow through the Product Owner. However, in all organizations I’ve been in there’s always some emergency or critical work that needed to be done immediately. How this is handled can vary widely.  The best situation is there exists a team that exclusively handles these interrupting work requests. The least desirable method was direct contact with the developers by management ‘telling’ them to do the emergency work, essentially overriding the Product Owner. The scrum master can greatly influence how this comes to the development team. The scrum master and management can develop a detailed process that allows for emergency work to come to the team but only if:

  1. the work is more important than any of the work in the current sprint and
  2. could not wait until the next sprint.

If the work passes these two tests, the Product Owner discusses the work in detail with the development team to come to a consensus on the best way forward. This would generally mean dropping a story not already in progress and adding the new work. When this happens, the development team can discuss the emergency work at the next retrospective to see if there’s a way to minimize or prevent this from happening in the future.

Develop an understanding with management for supporting scrum and the efforts of the scrum master

The scrum master will not succeed if flying solo. Development teams will be watching and looking for signals from management, those who pay them, on how they should act and react to the scrum master. If management ridicules or openly disagrees with the scrum master, without due process, the scrum master could lose credibility and once lost, will be very difficult or impossible to recover. The scrum master and managers need to work very closely together. They are both working to achieve the same goals but will have different methods and approaches to meet these goals. The scrum master needs to make talking with the managers a daily habit. In the past, I had worked closely with the development manager, meeting daily to discuss progress and new ideas. The development manager also went to the daily standups for all 7 scrum teams. He showed his support and commitment to scrum every day. If there was something I had done (or not done) that warranted discussion, we would talk privately and come to an agreement on how best to proceed.

Workshop with managers and development teams to understand limits and boundaries

One goal of scrum is for the development team to be self-organizing. This means being responsible for sprint outcomes, meeting expectations and commitments, and finding the knowledge and strength within the team to overcome obstacles.  What the scrum master can do is work with management to establish boundaries where the development team is free to do whatever they deem necessary to solve a customer problem. The workshops are attended by team leads and managers to set clear boundaries which eventually can become part of the teams’ Definition of Done. These can include security, test coverage, quality standards, and coding practices. The workshops created the environment where everyone could propose, understand the intent, and  agree on expected results from these boundaries. These workshops worked well and created boundaries that became standard across all teams. The boundaries can also serve as a challenge to the development teams to improve upon over time.

Train the development team on Scrum

This might seem obvious but I often see that giving overall Agile/Scrum training without constant follow-up is a waste. The scrum master can provide an overall introduction to scrum but should re-enforce the learning with multiple workshops on specifics including the ceremonies. The scrum master facilitates the workshops but the team designs the specifics on how the scrum framework is implemented. I had one team where both the development team and scrum master wrote down a set of expectations for the other during retrospectives. The development team defined what openness means as well as how they’d track improvements defined during retrospectives.

The idea is to incrementally improve the development team by picking up parts of the scrum framework and letting the development team figure out how to implement it. The areas that need improving will usually surface during the retrospectives but will also become known during the daily standups.

Have the development team create the metrics and measures they’ll use to know they’re doing better, worse, or neutral

How is a development team more likely to self improve: by having improvement metrics thrust on them or developing improvement metrics themselves? In my experience, the development team will better buy-in and track to metrics they created. Below is a list of metrics that the scrum master might suggest but leave it up to the development team to decide which, if any, they want.

MetricHow scoring worksWhat this measures
Number of Tasks added/removed during iterationOnce a user story is tasked out, count of tasks add and removed (a task that changes is counted once) - countHow well team knows the work and what done means for the story - INVEST criteria being followed and stories are small
Number of stories forecast Vs actually completed during iterationCount of stories forecast from iteration planning meeting and the count of stories completed and "Done" by end of the iteration - ratioHow well the team understands the work of the iteration - INVEST criteria being followed and stories are small
Average size of stories in iterationsSize in Ideal Days or story points against a common reference storyThe ability of the team to make the stories as small as possible and still provide some value to customers/users
Average score of "Value" per user storyHow happy was the customer for each story or group of stories completed during the iteration. 3-happy (stories solving their problem); 2-Neutral (not sure stories are solving their problem); 1-Stories did not help solve their problem; 0-no customers/users presentHow well the team understands the customer problem and understands how the customer wants it solved (or what success looks like from the customer/user POV)
Percent of user stories in iteration covered by automated System/Solution testsEnd-to-End test coverage using automated system/solution tests-percentageThe team's journey to automate end-to-end tests at the System/Solution level.
How independent is each user story in the iterationCount of stories in iteration that have dependencies-countHow well the team understands how to remove complexity
Test First Vs Test Last testing done in iterationScore per user story of Test First/Test Last strategy: 3-Test First; 2-test First and Test Last; 1-Test Last; 0-No Sytem/Solution level testsMeasure the team's journey to be outcome driven at the System /Solution level.
Number of hours in iteration spent helping team members grow and be betterTotal hours per iteration where the team spends time learning new skills, honing existing skills, teaching other team members new skills (T-Skills), interviewing and discussing customer/user problems with the customer/user-hoursMeasure of an aspect of a self-organizing team: caring and improving the team.
Number of hours in iteration waiting for somethingfor each story, track value adding time and wait state timeMeasure of cycle time for same sized stories, epics - time
Partially done workCount of user stories in progress at end of iteration - countBy counting stories that are in progress at the end of a iteration we highlight the potential waste of incomplete work. This count is minimized by having small stories and having the development team managing their iteration backlog.
How happy are team membersOnce per iteration assessment of how happy each team member feels-scoring - 10-very happy; 0-I'm thinking of quittingThis measures the general fun factor of work for the team. A happy team will work smarter and deliver a better product.

The team will probably ask the scrum master to collect these but be aware that the development team needs to own the metrics they have selected. By doing all the collecting, the scrum master may find the development team growing indifferent to the metrics.


Scrum masters don’t need authority to help the development team become better but will need to cultivate strong backing by management for Agile/Scrum. Highly visible management support can make a huge difference in the team’s ability to adapt, change, and improve.

The scrum master must resist the temptation to ‘tell’ the development team what to do, although suggestions may start the conversations. By respecting the development team and allowing them to make a majority of the choices, the team is much more likely to buy-in and adopt change. As scrum master, you are serving the development team, helping them help themselves.

Author: Robert Boyd

I'm a CSP (Certified Scrum Professional), CSM (Certified ScrumMaster), and CSPO (Certified Scrum Product Owner). For 30 years I've been streamlining processes and systems. I've introduced agile methodologies to software and product management departments, resulting in a 300 percent increase in feature deliveries.

Leave a Reply

Your email address will not be published.