What is Success for a Scrum Master?
Today is your first day. This probably not the first time you take up the role of Scrum Master, but today is different. You are facing a new team, a new organization. A totally different set of challenges.
You have done this before, but not in this context, not with this team, not with this organization. How do you adapt? How do you take on the challenge of this new team? What tools can you use from your past experience to help you succeed in this context? You did take note of the tools you used in the past, didn’t you?
We have all been in a similar situation, or we will be in the future. If we want to succeed as Scrum Masters we have to create our own approach to the different teams and organizations that we will work with. Fortunately we don’t need to create that approach and design our Scrum Master tools alone. We have many useful resources out there that help us create our own Scrum Master toolbox. From excellent hands-on books such as #Workout by Jurgen Appelo, to the classics like Peopleware by DeMarco and Lister, to the more coaching focused Coaching Agile Teams by Lyssa Adkins. But the best way to learn is to talk to many Scrum Masters, with diverse experiences. From this diversity of experiences we can build our own approaches and get inspiration to try different approaches until we find the one that works in our particular context.
A large set of diverse approaches is a key resource for Scrum Masters because we will not face the same situations over and over, but instead we will be constantly facing new situations almost every day. When attending daily standup after a new team member has joined, or planning the Sprint right after a failed demo, we need to access that deep toolbox and come up with innovative and engaging practices, techniques and approaches to help our teams and our organizations succeed.
In order to help Scrum Masters create their own approach we have collected many different views in the Scrum Master Toolbox podcast and have collected some of them here for you to read and refer to in the future. Below you will find a list of 15 tools and approaches that Scrum Masters all over the world use. Experienced Scrum Masters explain how they define and measure their own personal success as Scrum Masters, and share their lessons learned about how to achieve success. From how to deal with stakeholders, to how to improve your coaching skills, to how to help the team achieve a sustainable pace. The lessons shared below come from many years of experience and will help you improve your performance as a Scrum Master.
We’ve also added a few caveats and warnings that you must take into account. The goal: help you succeed as a Scrum Master.
Let’s get started.
The most important lesson learned by experienced Scrum Masters
How do you measure success in the first place? The most common lesson learned shared by experienced Scrum Masters is: to achieve success you must first define success and measure your way there. Each Scrum Master has a slightly different way of doing it, but they all do it. Below are some concrete examples and questions you can use to measure your own success as a Scrum Master.
1. Define your way to measure success, and follow your own development just as you would follow the development of the team. Jeff Kosciejew listed three questions that he follows to assess his own success:
- Did the team deliver production ready software this Sprint?
- Was everyone happy with, and proud of what they achieved?
- Did we improve our way of working (e.g. did we deliver more value than in the previous Sprint?)
This approach of having your own questions as a Scrum Master seems to be popular among other Scrum Masters as well. Dominic Krimmer created his own checklist to assess his performance as a Scrum Master:
- Do we have a Team Vision?
- Do we have a clearly defined Sprint goal or focus?
- Do we keep our Scrum board up to date to make our work visible and transparent?
- Do we have a dashboard to communicate to others the status of our product?
- Do we have good quality stories?
Finally Stefano Porro suggests another list of questions:
- Does the team, and the team members feel that their contribution is valued and seen as important?
- Does the team feel happy to work in this project?
- Does the team, given a choice, want to work with you as their Scrum Master again in the future?
- Is the “index of participation” in the daily standup at the right level? (The index of participation = number of non-solicited interventions that affect how the team works.)
Which questions you use to measure your success is not as important as the fact that you have your own list of questions, or your own checklist that you regularly follow to help you focus your attention on the right topics, the topics that require your attention to develop your skills as a Scrum Master. As Andy Deighton put it: at first you may ignore your definition of success, but sooner or later you need a compass, a way to measure your own development as a professional Scrum Master. Ask yourself: am I ignoring my success as a professional Scrum Master?
The most common of definition of success for Scrum Masters and how to achieve it
What was the most common symptom of a successful outcome for your work as a Scrum Master? I’m glad you asked: by far the most common definition of success listed by the 30+ interviewees in the podcast was: the team “owns” the process. This lesson has come in many different forms, from having teams own the meetings or ceremonies in the Scrum process, to having the team actively interact with other teams and stakeholders in the organization. The tough question for Scrum Masters is: how do we help teams “own” the process? Here are some of the tools listed by experienced Scrum Masters:
2. Be away for a few days and assess how the team took ownership of the process and meetings. Matt Dominici, who suggested this idea, tells us that the level of ownership can only be seen when you are away. If you return from a few days hiatus and find the team lost, and the process abandoned, that’s a clear sign that the team is not yet ready to “own” the process. But don’t despair, this tool is also useful because when you come back you can assess what is missing, or not taken care of by the team and focus your coaching attention on those topics. For example, if you come back to find that the team has abandoned the testing of their changes, then you know that the team still needs help understanding that part of the work, or is missing tools that help them integrate testing into their daily work.
3. Focus on defining and providing a platform for your team. Jeff Kosciejew builds on his experience as a music player to explain how some instruments (or roles) are there to provide the right conditions and the environment that enables others to succeed. He calls that a “platform” on which the team builds. Scrum Masters must do the same; so one important characteristic for Scrum Masters is to be comfortable with being in the background, in a supporting and enabling role. Each different ceremony requires a different approach to creating that platform. In the daily standup meeting, for example, you can simply remove yourself from the circle. Step back while the team is discussing topics related to their work, and step in when they need your support, or you must intervene to facilitate the meeting. This physical withdrawal will help the team realize that you are there to support them, and will encourage them to take ownership of the meeting.
The most common tool used by Scrum Masters
A question that is in everybody’s mind is: what is the most common used tool by Scrum Masters around the world. No doubt you have your own ideas based on your experience. But the answer to this question surprised me a little…
4. Have many 1-on-1 conversations, and take notes. As simple as it may sound at first, the conversation is the most often used tool by the Scrum Masters we interviewed. Matt Dominici explains how he uses conversations as the preferred tool to learn about what affects the team, citing it as the tool of choice for measuring happiness in the team, for example. Conversations are a simple enough tool, but often forgotten and not developed. One way to improve your conversation skills is to read How to win friends and influence people, by Dale Carnegie where the author sets a clear list of things you must have in mind when you want to grow a relationship with the people that you work with every day. Carnegie suggests: always start by talking about something the other person cares about; be genuinely interested in what their views are; don’t start arguments, you can’t win them. In another episode Tim Bourguignon reminds us that we must write down our thoughts on everything that goes on, and writing down notes about each of these conversations is a great way to remember what you’ve learned and be deliberate about managing the relationships with the people you work with.
It’s all about the WHY
5. Help the team define their purpose, so that the team finds their own definition of success. Luis Gonçalves reminds us that having a clear purpose is one of the keys to motivation and to success. Without having a shared purpose the team cannot align their actions. In the podcast Luis suggests a specific workshop to be held with the teams we work with that helps define the team’s purpose. That workshop is inspired by the work of Daniel Pink which you can read more about in Drive: The Surprising Truth About What Motivates Us.
6. The “why” is what defines success; always ask why before you get started. In the same line of thought, Stefano Porro reminds us about the importance of asking “why” before getting started.Stefano tells us the story of how a team failed because they were focusing on the “how” and never really thought about the “why” of their work. Stefano used that learning to change his approach as a Scrum Master and now always asks “why” to ensure that he, and the team understand the reasons of the work. It is only by knowing why we do what we do that we can do our best work, and as Scrum Masters we must ensure that this basic enabler of team performance is clear.
The coaching stance
7. Learning to coach the team is one of the most important journeys for Scrum Masters. There’s no success for the Scrum Master unless the team also succeeds, and for that we must learn to work with the team. Working with the team means that we are constantly enabling the team, and not doing their work for them, not solving their problems for them, and not taking over their meetings for them. The coaching stance is therefore a key aspect of the Scrum Master’s work. In a bonus episode, Bob Marshall describes Nonviolent Communication (NVC), an approach that can help the Scrum Master with concrete tools that will help the interaction with teams. NVC asks that we accept we can’t force anyone to do anything, rather we must ensure that the reasons to do something are clear, and accepted. If the “why” (see above) is not agreed upon, then we must work on that first. NVC is a well of inspiration and direction for the aspiring coach in every Scrum Master.
8. The team you worked with yesterday is not the same you will work with tomorrow; adapt your practices to the development stage of the team. Every team is constantly evolving, literally every day. The way we work with teams must also evolve to adapt to the stages of development of that team. Dominic Krimmer reminds us of Tuckman’s stages of group development, also known as Forming, Storming, Norming, Performing model. When asked about how he deals with teams in different stages of development, Dominic explains his approach for every one of these phases, and why the same recipe cannot be used for all stages. Understanding what stage the team is in, and what is the right approach for that stage is a key skill for Scrum Masters.
9. Coaching happens between consenting adults; get consent before you get started. In the spirit of NVC, we can’t force a team to accept to be coached. Coaching requires the consent of all involved. Steve Holyer asks us to design our coaching alliance with the team before we start our work as Scrum Masters. It is this shared goal and set of expectations that will later on enable you to ask the teams if they are still committed to that initial agreement, and collectively remind them of what they had explicitly agreed to at the start of your engagement with them. This is a very concrete way to gain permission, and regain their consent later on when the situation may be tense. This coaching alliance is your “contract” with the team, and help you refocus the team on the overall goal for your work with them.
Measure all the things
Measuring success implies measuring. And Tim Bourguignon takes this task seriously:
10. Measure all the things, and keep notes about everything. Tim Bourguignon explains that as Scrum Masters we benefit from measuring “all the things”, and keep metrics on everything we can. This way we are able to later look at trends over time. Here’s how you can get started:
Start by keeping notes on everything. In meetings, after conversations, all the time.
Measure everything you can: tasks completed, cycle time, features, interactions, etc.
Get numbers on everything you do as a Scrum Master. How many times did you talk to each team member this week? How many times did you feel lost, or did not know how to go forward?
- Look at trends. Only numbers can help you see trends. So measure and stand back to see the big picture.
Although this may seem daunting at first, you don’t need to start with all the metrics. Instead, look at your context and define 3 metrics you would like to keep track of to understand better the situation. Use the next retrospective as the trigger to your measurements. Consider which topic you would like to take to the retrospective (or ask the team which topic they would like to discuss), and then keep metrics related to that particular topic. This will get you started, and will have a short-term reward: you’ll have the information you need for the next retrospective.
11. Look at metrics that show you how the “system” behaves so that you can help the team understand their own context. Our teams exist within a specific context. They are affected by corporate policies, by the technologies they use, by the interaction with the other teams and by the culture of the organization. Measuring local metrics to the team will not help you understand how the overall system behaves. That’s why Neil Killick suggests that you look at systemic metrics, such as the Lean metrics of Cycle Time and Lead Time. Lead Time will help you understand how much time the requirements or User Stories spend in the system, while Cycle Time helps you understand how much time it takes to deliver a User Story once the team starts working on it. Here’s a concrete example of how these metrics are useful: If a team A completes all stories within the Sprint they were started in, but the Lead Time for stories is much larger (say several months), you know that you should focus on understanding what is keeping the stories from reaching the team (if the delay is before the Sprint), or focus on understanding why the Stories are kept so long before going live (if the delay is after the Story is considered Done). In one case a team I was working with had Stories with an average Cycle Time of weeks, but a Lead Time of many months. These metrics helped the client understand that they had to reduce the time Stories waited to be tested after being completed by the development teams.
It’s all about sustainable pace
Scrum is strong on the sustainability of the work. A commonly heard phrase in software development circles is: “software development is a marathon, not a sprint”. Scrum takes the approach that one of the goals for the team is to find its sustainable pace. But how do we, as Scrum Masters, know if the team is working at a sustainable pace? There are several answers to this question; one of the most common answers is that we should be measuring happiness in the team.
12. Measure team happiness to assess sustainability. Andy Deighton suggests a few tools on the podcast that you can use to measure happiness. Journey Lines is a tool that you can use in the retrospective to evaluate a Sprint or a longer time period (e.g. a project) from the individual or the team’s perspective. Another tool that you can use to measure team happiness is the Happiness Door, a tool that combines a few other tools with the goal of measuring happiness on a regular basis. You can for example use this technique to measure the impact of specific events on the team as they happen (for example after a planning, or after a review, or after a meeting with stakeholders, etc.). The Happiness Door is a more real-time tool, designed to help the team reflect on, and react to what is going on at specific points in time. There are other methods to measure happiness, and there are other aspects that affect the sustainability of the work, the idea implicit in this lesson is that you can measure happiness as a symptom of (lack of) sustainability and direct the methods to specific topics or events that affect the team.
In the end we must produce value to keep playing the game
Alistair Cockburn introduced the idea that software development is an “infinite, cooperative game” in his popular book Agile Software Development, The Cooperative Game. Using Game Theory Alistair asserted that software development does not end with one project, or one delivery, and that the goal of a team is to “prepare the next move”, so that they can continue to play the software development game. In practice, this means that no matter how successful we are today at what we do, we must continue to produce valuable software, that solves real customer and user problems, to be able to continue to play the game.
13. Success is about producing something of value, help the team measure the value produced. It is perfectly possible to produce high-quality software, in an incremental way without producing any value. Antti Tevanlinna alerts us to that fact in the episode where he describes a lesson that he learned from experience: no matter how good you are at producing software, ultimately it is the success of your product in the market that defines your success at software development. As Scrum Masters we must be able to help the team understand if what they are producing is valuable. We can do this by having the Product Owner interact with the team, and the customer to define and validate the value of the software we produce. Asking the customer (or a customer representative) about the value of the software produced is one of the tools we can use, but this is not always possible, so the Scrum Master must work actively with the team and the Product Owner to define methods to measure the value of the software delivered by the team. If you want to know more about how you can do this, then the methods being discussed in the Lean Startup community are a great way to get started.
14. Scrum has a specific location for the definition of Value; use it wisely. Antti Tevanlinna also raises a warning: in Scrum the definition of value is “hidden” in the backlog. If the team is not familiar with the backlog, the Vision for the software they are creating will be hidden. It is not enough for a team to know what Stories they must work on, they must understand the context of those stories. Simple questions like: “what does the user want to achieve with this particular story?” can help the team understand the reason why they are producing a particular functionality. This understanding of “why” a Story is produced will be critical for the team to produce their best work. We as Scrum Masters must make sure that team and the Product Owner regularly converse about the “Why” of the Stories, and agree on a Vision for the software that they are producing. Only then can we make sure that the value is not hidden in the backlog or the Product Owner’s mind, but it is shared and understood by the team.
Agile is simply about managing (and shortening) your feedback cycles
Scrum is an agile method that places special emphasis on the length of the feedback cycles. It asks us to define a timebox (the Sprint) where a complete cycle of development is completed, from requirements discovery to release to production. The reason for this emphasis is that the feedback we get at the end of this cycle is what enables the team to continuously improve. But the Sprint is not the only feedback cycle you should look at. There are plenty of feedback cycles that we need to make clear, and manage as a Scrum Master.
15. The feedback cycles are the most important tool for Scrum Masters; define them and try to make them shorter. Antti Tevanlinna reminds that especially the feedback cycle that involves the customer is extremely important for the team. We as Scrum Masters must understand what type of feedback the team needs to get their job done, and enable that feedback to happen. A basic feedback cycle is that of the review meeting, where the team demonstrates the functionality they have accomplished, and collect feedback from the stakeholders about both the functionality, and the way they work. The successful Scrum Master will ensure that this feedback cycle is quick enough (1 to 2 weeks is a good cycle), and effective. Preparing specific ways to collect and process feedback will ensure that the feedback is received with an open mind, instead of being seen as antagonistic (when negative), or irrelevant. Remember, that feedback is always valuable, but in the end the team chooses how it reacts (or not) to that feedback.
When the team finally “owns” the process, it may seem that the work of the Scrum Master is over, but it never really is. Once the team “owns” the process we need to shift our focus to the team dynamics, to the organizational impediments, to the interaction with stakeholders, etc. What I’ve learned from interviewing 30 people on the Scrum Master Toolbox podcast is that the definition of success for a Scrum Master is very broad, different people will focus on different aspects of that definition. Not only that, but as the team and the organization change we must also focus on different aspects of that definition. However there is an overall trend in the answers we’ve collected in the last 6 months of interviews, we see two major definitions of success for a Scrum Master: helping the team succeed as a team, and helping the organization succeed as a business.
Both sides of this definition of success are valid and crucial for us to fully understand our role as Scrum Masters. We must constantly assess our work in these dimensions, and help the team and stakeholders understand both dimensions. Make sure that you consider both when crafting your own definition of success.
Here’s a challenge for you: create your own definition of success as a Scrum Master and post it below in the comments. Measure your performance over the next 4 weeks, and then come back, post questions and the results of your evolution during those 4 weeks. When you come back, share with the rest of the community what tools, and practices you used to measure your success as a Scrum Master. Let’s continue to build our knowledge of the profession. It is a young profession, but it certainly is important in today’s world where everything runs on software. The community of Scrum Masters is eagerly waiting for your thoughts and insights.
About the Author
Vasco Duarte wants to transform product development organizations into product business organizations. He does that by focusing the work of the product development teams on the end-to-end life-cycle of their products. Vasco is currently a Managing Partner at Oikosofy. Product Manager, Scrum Master, Project Manager, Director, Agile Coach are only some of the roles that he has taken in software development organizations. Vasco has worked in the software industry since 1997, and has been an Agile practitioner since 2004. He has worked in small, medium and large software organizations as an Agile Coach or leader in agile adoption at those organizations. He was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure.
Challenge Accepted: My Def. of SM Success
Since I've been in this agile change agent role for over a decade - I've gotten a handle on the unspoken message of this type of request and directive ...
Success for me with these two teams will be to get them to enjoy using the physical scrum task board to make their work items visible and start to understand the value of transparency. To see that this team has some accountability to each other in their stories and task, and to foster the observable behavior of asking for help and offering help to other team members in the daily activities to deliver value to customers via working tested software. I feel this objective is fairly well being achieved now.
Success will be seeing some courage in team members learning to say that a story is not Ready for a sprint yet, and then taking the lead on refining that story (splitting, investigating etc) that item and seeing the results of how coming together and telling the story over and over until there is shared understanding results in stories getting done and delivered so much easier. We have just invited the team into story grooming sessions with the PO and Architects.
That's a sample - good enough for now... anyone else want to join the dialogue?