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.

Summary

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.

7 Areas Scrum Masters & Agile Project Managers Differ

These days you often see ads for Agile Project Managers mixed in with ads for Scrum Masters. Both the Scrum Master and Agile Project Manager will operate in a Scrum setting but these are not the same role. They’ll both want successful projects but how they achieve that success is different. Below I highlight 7 key areas where the roles of Scrum Master and Agile Project Manager are different:

  1. Authority
  2. Project Planning
  3. Sprint Planning
  4. People Management
  5. Reporting
  6. Resource Management
  7. Measure of Success

Before talking about the differences, here are definitions for a Scrum Master and an Agile Project Manager. I’m making the assumption that the Agile Project Manager is a Project Manager working within the Scrum framework.

Scrum Master definition

Mike Cohn defines a Scrum Master as responsible “for making sure a Scrum team lives by the values and practices of Scrum” and “as a process owner for the team”.

The Scrum Guide defines the Scrum Master as “responsible for ensuring Scrum is understood and enacted … by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

Project Manager definition

The Project Management Institute (PMI) defines effective Project Managers as having, “full responsibility and accountability, must apply lessons learned, must define roles and responsibilities, must lead project planning and tracking, must perform risk management, must apply best practices, must communicate to the project sponsor and team, must promote client involvement, must mentor, must promote good working relationships, and must make things happen.”

7 Key Differences

1 – Authority

Project Managers operate in an environment where they are in control of the team and have authority to assign tasks to them. The Project Manager is accountable for the success of the project by meeting schedule-scope-budget. The best Project Managers skillfully apply Command & Control over the developers to achieve results.

An example of authority for a Project Manager:

Facilitating the daily standup

  • Ensure that all team members attend
  • Keep track or tasks and gather a high-level understanding of the tasks.
  • Track if people are constantly underestimating when they will be finished with a task: Raise it with the team leads and work with team leads to resolve the issues.
  • Use a better understanding of the technical issues to know when to pressure deadline and outcome vs just asking the questions.

Scrum Masters operate in an environment where they have no authority over anyone. A Scrum Master is a coach, mentor, and trainer to the Scrum Team, helping them to adopt Agile practices and becoming self-organized. The Scrum Master helps too by removing impediments that can slow the development team. The Scrum Master will help other parts of the business understand their relationship with the Scrum Team including how they can best support the team.

The same meeting from a Scrum Master’s perspective:

Ensure a daily standup happens

  • The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.
  • The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.
  • The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
  • The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.

One quickly sees that unlike the Project Manager’s perspective, the Scrum Master is helping the team become self-managing, self-organizing. One can also quickly see that the Project Manager’s version of the Daily Standup will happen if the Development Team resists taking on these responsibilities.

2 – Project Planning

For the Project Manager, project planning and the resulting project plan is the most recognizable activity and artifact. The project plan becomes a contract for services and deliverables to the business. In the plan, the Project Manager sets down incremental delivery dates for products and services. These dates are based on upfront estimates and are usually incorporated into the company’s business plans. The project risk registry usually has these delivery dates listed as a critical risk to the project if missed. The Project Manager is held accountable to these dates and commits the development team to deliver based on these dates.

For the Scrum Master, project planning, or more often called release planning, is an act of participation with the Scrum Development Team and Product Owner. All estimates are given by the Development Team. Epic user story estimates are usually based on similarly sized user stories from past projects. The release plan is updated at the end of each sprint as the team learns more. There is little accountability for the upfront estimates as these are not thought reliable and dates slipping to the right is not considered a significant risk. The importance of this release planning is to get a team understanding of the most valuable work and ensuring it’s done first. In Agile, it is often the case that scope changes to fit a release date.

3 – Sprint Planning

The major difference between the Project Manager and Scrum Master during sprint planning is who is in control.

The Project Manager will drive the planning session to ensure compliance with the overall project plan; to meet the project schedule and commitments. The Project Manager usually provides direction to the Development Team and will often assign tasks to the members. It is the Project Manager who pushes the developers to take on as much work as possible.

The Scrum Master will ensure sprint planning happens. The Product Owner and the Development Team usually run this meeting with the Scrum Master helping to keep the meeting on time. The Product Owner will present the highest priority user stories to the Development Team but only the Development Team determines how much work they can do in a sprint. The Scrum Master helps Development Team use previous sprint results as a guide for the team’s capacity as they ‘pull’ in work from the Backlog. The Development Team plans how they’ll do the work necessary to meet the goals of the sprint. It is the Product Owner who often pushes the Development Team to take on as much work as possible but the Scrum Master is there to help guard against the team over committing.

4 – People Management

The Project Manager has traditionally had direct control over the people working on their project. The Project Manager often provides day-to-day work assignments and decides what tasks to do and when tasks are complete. This is done in accordance with the project plan. In most of my experiences with project managing, the Project Manager is less concerned about the growth of people working the project and more concerned about costs and schedule.  However, in some organisations the Project Manager is also the manager of the individuals on the team providing professional and salary reviews.

The Scrum Master has no direct control over the any members of the Scrum Team. The Product Owner is accountable for what is done and the Development Team is fully empowered find the best way to implement. However, the Scrum Master uses coaching techniques to help the team and individuals maximize their effectiveness. Some of these include ‘powerful questions’, ‘impact feedback’, mentoring, and one-on-one or team Agile training. The Scrum Master is there to serve the Scrum Team, to help them be more and more successful.

Agile and Scrum place great emphasis and responsibility on the Product Owner and Development Team. The Product Owner and Development Team become the primary decision makers in all product work. Making the Scrum Team the decision makers will often directly conflict with one or more managers in the organization.

5 – Reporting

I’m not aware of any company that doesn’t have measures and metrics to see how work is progressing. The major difference is how these measures come about and are communicated.

The Project Manager generally is required to report upward in the organization based on the reporting or communication section of the project plan. This is traditionally from the business’s and Project Manager’s perspective. The developers will have little or no input to this nor will they have much say in how these measures are used.

The Scrum Master too is likely to report upwards information about the team’s progress to date, issues or impediments, and new-found risks. However, this is information the Development Team and Product Owner have already provided openly to all. The Scrum Master often packages the information in a format desired by management. If management wants a specific metric, Velocity comes to mind, it’s up to the Scrum Master to help educate the business on the value of such a metric and prevent abuse.

6 – Resource Management

The Project Manager is responsible for costs and generally needs to track daily charges against the project. The Project Manager will negotiate with the business to acquire additional resources necessary for the project if needed. Project resources are usually specialist for a specific area of development and can come and go as the specific need comes and goes.

The Scrum Master does not control the resources of the within the team. In Scrum, the Development Team is thought to be cross-functional; having all the knowledge and skills in place upfront to do the work. If there arises a situation where the team is unable to do the work because of a skill or knowledge gap, the Scrum Master helps resolves this by getting the right training to the team. This advantages the team as the team grows with this new knowledge.

7 – Measure of success

The measure of success between a Project Manager and Scrum Master is very different in context, one’s about an individual, the other is about a team. For the Project Manager, it’s very much about this single person’s ability to make the project happen, hit all the delivery dates, and provide a product as promised up front. For a scrum master, it’s how well they’ve trained the Scrum Team to be responsible for their own success, getting customers involved with each sprint, and delivering each sprint a potentially releasable full or partial solution for the customers’ problem.

Project manager measures of success are often the same measures for a successful project. These are interconnected, interdependent, and generally you can’t have one without the other. Did the project come in on schedule and on budget? Was the promised scope delivered? Are the customers satisfied with the product? Does the product work as promised (quality)?

Scrum Master measures of success are most often directly related to how well the Product Owner and Development Team do in their sprints. Does the Development Team have potentially releasable sprints? Does the business respect that the Development Team is responsible for making the results of each sprint potentially releasable? Does management respect that they no longer give the Development Team direction (no distractions)? Does all work flow through the Product Owner? Does the business respect the Product Owner’s authority of the Backlog? Does the Scrum Team groom the Backlog for ‘sprint ready’ user stories? Are the customers happy with the sprint results at the sprint review? Does the team grow both as individuals and as a team?

Summary

In the end, business culture and needs will drive the hiring of a Scrum Master or Agile Project Manager. A lot of companies adopt the ceremonies of Scrum, (Sprint Planning, Daily Standup, Sprint Review, and Sprint Retrospective), with positive and beneficial results. Jeff Sutherland once told me that just having a Daily Standup should see a 20% – 30% increase in productivity.

So it comes down to having an individual or a team run a project. Agile supports the team as the source of new and better ways of thinking (see Steven Johnson’s video on Where Good Ideas Come From).

In Agile, the Scrum Team assumes the role of Project Manager by taking on the responsibility to manage the backlog, ensuring the most valuable work is done first. The Scrum Team is also responsible to deliver, in every sprint, something that solves or contributes to solving a customer problem. However, this takes time and it might be many months before the team takes on full responsibility for sprint outcomes.

If the business is determined to have an individual held accountable for results then they’ll probably go with an Agile Project Manager. This is especially appealing as there’s little ramp up time needed; the Project Manager is directing the team from day one. A major drawback is an effective Project Manager is often a domain expert. Finding the combination of excellent project management skills along with domain expertise can prove difficult in an increasingly specialist and niche product environment.

New Scrum Master: Problems to solve in your first days

In the previous two posts. First day as Scrum Master and Second day as Scrum Master, I talked about you as a new Scrum Master to a team and some steps you can take to ease yourself into the team’s world. The first post talked about a group meeting with all team members including Product Owner. That meeting set up some introductions and gave you some clues as to how the team interacts and possibly some team dynamics. You followed that up with some one-on-one talks with each member of the team. In this post I’ll talk about interpreting the results of your one-on-one discussions with the team members.

Once you’ve finished your talks with the team it’s time to pull all the information together and begin planning your actions. The problems mentioned by the Product Owner, developers, testers, BA’s, UXD, and others on the team will likely fall into several categories. What’s listed below can be used as a guide but doesn’t take the place of your own analysis based on your unique set of circumstances.

Team’s ability to self-organize and be cross-functional

One Team, One Goal.

One Team, One Goal.

This will be by far the most common area of weakness based on the many discussions I’ve had.  The clue to this will be problems brought up by the team that they can clearly solve themselves but they’ll need your help. Some comments might include:

  • “Requirements are poorly written”,
  • “Working on things before we know what to do e.g. UX Designs incomplete”,
  • “Too many hand-offs”, and
  • “Definition of Ready and Definition of Done missing”.

I’ll look into the first comment, “Requirements are poorly written” in some detail. When the Scrum Development Team say this, I’m thinking there’s both a communication issue and possibly some role based barriers in place. The comment given by the Development Team makes me think they’re not feeling completely responsible for making sure the user stories are backed with heaps of conversation. Both communication and not feeling it’s their job can be resolved through well facilitated grooming sessions. The team can become better at self-organizing by tackling head-on the issue of shared understanding of the customer problem documented in user stories. The team can also build their cross-functional capabilities through greater contributions to the user story including the acceptance criteria. For a developer whose experience may be waterfall and where the sole contribution of the developer was code, helping to write the requirements can be a new and possibly frightening turn of events. You as Scrum Master are there to help facilitate this transformation.

Business or company culture as impediments

We do it that way because that's the way we do it.

We do it that way because that’s the way we do it.

Problems or issues cited by the team that fall into this category might include:

  • “Too many sign-offs and approvals (Designs)”,
  • “Little interaction between test and other departments”,
  • “Business emergencies and no way to stop them”, and
  • “Fixed end date regardless of start date”

It’s clear the company culture is not controlled by the development team but they can have an influence. The comments above could make you think the company is a top down Command & Control shop and you’d be right. One thing I’ve seen in this kind of environment is nothing is written down, it’s all done based on memories of past practices. One way to begin affecting this culture is to document how current work is done paying specific attention to the time it all takes. The Scrum Master and team can do this documenting of existing process and then present an alternative process with the now documented benefits and savings. As Scrum Master, you should also seek out and secure executive support or at least, a powerful mid-level manager who can support change. Without support, you’re chances of success are severely limited as I’ve recently learned first hand.

Technical challenges or knowledge gaps that are impediments

Thomas Edison - Incandescent light bulb

Thomas Edison – Incandescent light bulb

This is something I usually note as a result of listening to the development team but it’s rare that the team will directly say something with the exception of how testing is done. What I commonly see is a team hampered due to:

  • Specialist on team that can’t assist in other technical areas
  • Test treated as a separate group or sub-team
  • Testing always done at the end of sprint

These fall under a team being cross-functional but to get there will require specific training and strong guidance from the Scrum Master.  I once had a team with one tester doing all the testing. I suggested that the developers help out with the testing to speed it up and relieve the pressure on the sole tester. Luckily there wasn’t a rope handy as I’m sure the developers would have hung me then and there for speaking such blasphemy. One developer suggested to the managers that they needed to hire more testers. The managers, GM of Product and GM of R&D both told the developers that hiring wasn’t an option and that they would need to better support test. Once the management support was established, I was able to help get the developers to run acceptance and system tests. Baby steps. It was the opening needed to begin the longer term goal of spreading a little knowledge throughout the development team. When I left that company, the Scrum Teams did all the UX, testing, and infrastructure work themselves whereas in the beginning, each of these areas had specialist teams doing this work.

How this helps

After my first days and weeks with the team, I continued doing one-on-one talks with all the developers and Product Owners, noting what changes they felt had occurred in the previous month or two, how exactly these changes affected them, what further changes they wanted to see, and what makes them happy to come to work. I often find myself listening to the team chatter but asking the team to tell me their struggles and their delights helps me focus better on serving them. That’s my role as Scrum Master, to serve the team.

I welcome your thoughts and comments.