When changing project, team, or even organization, there is always an adjustment period. What are the tools you may need during these transitions? To be successful as a Scrum Master, you must develop your own approach, your own way of doing things. Fortunately, in addition to a multitude of interesting literature on the subject, exchanging with your peers can help you benefit from their varied experiences, thus be inspired to find solutions for the many problems that can arise.
A wide range of solutions can help to cope with the different situations that may occur on an almost daily basis. To offer the best chance of success to the organization, it’s important to know how to innovate in the ways you meet these challenges.
In this context, we wish to provide you with tools and approaches that can help you become the best possible Scrum Master. From the relationship with stakehol ders to your posture as a coach or the establishment of a sustainable pace for the team, here’s an overview of what many years of experience have brought to the role of Scrum Master.
First, it’s important to define a way to measure your success and follow your own development as well as that of your team.
Here are examples of questions that can help you define and measure your success:
- Do we have a shared vision as a team?
- Do we have clear goals for our sprints?
- Is the team happy to work on the project?
- Did the team deliver the increment at the end of this sprint?
- Is everybody satisfied and proud of what has been accomplished?
- Did we improve the way we work (delivered more value then previously)?
- Do we have a dashboard to communicate the status of the product?
- Are we using high-quality user stories?
- Would the team want to work with me as Scrum Master again?
The questions are not as important as the simple fact of asking ourselves questions and paying attention to these aspects. It’s essential to develop your skills and measure this development regularly.
Note that it is also particularly important to step back and evaluate whether the team has assumed ownership of the process and ceremonies. In fact, this is the the most frequently used measure of success. But how do you help the team take ownership of the process? Here are some possible answers…
Learning how to coach a team is one of the most important but also one of the most difficult paths. Adopting a coach’s posture is a subtle process that requires facilitating without really taking control and accepting that we cannot force anyone to do anything. You only need to clarify the reasons and make sure that the team takes ownership for them. So here we get to the notion of why.
The how and the why
Helping the team in defining its role so that it can define its own measure of success is a key to motivation and success. Without a common and clearly established goal, the team cannot effectively coordinate its actions based on the achievement of this objective. The why is often what defines success. Always ask why before you start. Many teams fail because they focus on the HOW rather than the WHY. It’s only by being aware of why they perform tasks that teams are able to give the best of themselves, and it is the role of the Scrum Master to remind them.
It’s important to have frequent face-to-face exchanges and to take notes. This may sound simplistic, but conversations are central to the relationship between the Scrum Master and the members of his team. They help in part to assess what affects the team and to measure its satisfaction through each of the individuals who are part of it. We suggest reading ‘‘How to Win Friends and Influence People’’ by Dale Carnegie. He analyzes what you need to keep in mind when you want to have human relationships grow within the workplace. In particular, he suggests starting conversations discussing a topic that is important to the person and showing genuine interest. Taking notes simply helps to memorize what has been learned from these exchanges and act deliberately with the people you work with.
You must be comfortable with fading away and to just play a facilitating role while evolving in the background. Each ceremony is an opportunity to make way for team members so they can themselves discuss their priorities. You only intervene if necessary and if they need support.
The team with which you worked yesterday is not the same with which you will work tomorrow. Adapt your practices to the developmental stage of each team. Developmental stages are not always the same at the same time. The stages identified by Tuckman can then be useful: Forming, Storming, Norming and Performing (Developmental sequence in small groups by Bruce Tuckman, 1965).
Coaching takes place between consenting adults. Get the explicit consent of participants before starting. This may seem obvious, but you cannot force a team to be coached. Sharing a goal and expectations allows you to ask the team to stick to it. Some kind of contract is established or rather a coaching agreement with the team, and you can then adjust the efforts according to what was agreed upon.
Measure and take notes about EVERYTHING. This will allow you to identify trends once you have collected enough data. This can range from the number of tasks completed to the number of conversations with each team member or the number of interventions during a ceremony to the number of interactions with the stakeholders. The important thing is to be able to draw a realistic picture of the situation by taking a step back and examining the facts.
To help the team understand its own context, observe in particular the measures that show you the behavior of the system. The teams are working in specific contexts and are affected by many factors such as corporate policies, technologies, or organizational culture in general.
Measures such as the lead time or cycle time can help you understand how much time is necessary for a requirement or user story to go through the process. The first indicates the time between the request and the delivery. The second rather indicates the time between starting the work and when the feature is actually ready to be delivered. The lead time is what is perceived by the client.
For example, if a team finishes all the stories in the sprint during which they were initiated but the implementation period is longer, you know you need to examine what prevents stories to get to the team (if the delay is before the sprint) or what prevents the features from being deployed (if the delay occurs after the feature is completed).
A sustainable pace
One of the team’s goal is to find a sustainable and steady pace over time. But how does the Scrum Master know if the pace is sustainable? There are several possible answers, one of them suggests measuring the well-being of the team. This is a good indicator of the sustainability of the pace.
Success is measured by the production of value. Help the team measure the value it has produced. It’s quite possible to produce software increments of no real value. No matter how effective you are in producing software, what matters is the success that it gets on the market. As Scrum Master, you have to help the team understand if it produces value. We must have the Product Owner and the client intervene to define and validate the value created.
The Scrum method implicitly indicates the value in the product backlog. If the team is not familiar with it, the vision and therefore the value of the software remain hidden. It’s not enough to know which stories to work on, you must know the context that dictates the need for this feature. What are we trying to accomplish? The Scrum Master must ensure that the conversation takes place regularly and that everyone agrees on the vision of the software that is being produced.
The feedback loop is perhaps the most important tool for Scrum Masters. They need to understand the type of feedback that is most useful to the team so that it can do its job, and allow this feedback to reach it as regularly as possible. Another important point is to provide feedback channels that allow the team to receive this feedback with an open mind, without attaching negativity.
Finally, when the team finally takes ownership of the process, you would think that the task of the Scrum Master is completed, but it never really is. He can then turn to organizational barriers. After all, his role is both to contribute to the team’s success and that of the company as a whole.