How to engage team members in the Scrum Ceremonies

Luke is a Scrum Master. He gets to work in the morning and one of the questions in his mind is: how do I get my team to participate more and be proactive? 

Luke, just like many Scrum Masters out there need to help the team to take action, and in some cases change their approach to a problem so that they can succeed. 

Many teams are passive. They don’t engage fully in the Scrum ceremonies like Backlog Grooming for example. In one case, one of the teams we worked with wouldn’t even attend or hold a Backlog Grooming meeting with the Product Owner unless it was explicitly asked to. They privately confessed that “refinement is just overhead”. Why would anyone think that participating in clarifying the work they must complete is overhead? 

There are many reasons. One reason is that people focus too much on the practice, and forget the principles behind the practice. Backlog Grooming for example, is a practice that can take many shapes and forms (not just a meeting), which is based on the principle that the work (a User Story) should be incrementally refined (not just at the start of the project or even the Sprint), so that when we start working on the User Story, all the team members understand what it is, and why it is there. 

This focus on the Goal of a User Story, to be refined through Backlog Grooming, is a key practice to enable autonomous teams. Without the Backlog Grooming process, the team would need to ask lots of questions during the implementation, making it fully dependent on the availability of the Product Owner, and removing their ability to bring in technical innovation: innovating on how to implement a User Story based on the understanding of the underlying goal for the User Story. 

Scrum Masters are practice coaches, not project managers 

How can we then help the teams feel empowered, accountable and interested in making things better, to improve regularly? 

When we start work with a team it is important to go through the basics. The Scrum framework is not very difficult to understand and execute. However, how we execute it can make a big difference. If we want our teams to adopt the mindset and not only the practice, we must become coaches to our teams. 

And this is where our biggest Scrum Master paradox happens. We need to help our team members and teams change their mindset, but for that all we can use is practices. 

The problem is that we learn in practice, not in theory. A theory is something we develop after having experienced something in practice. You can’t teach someone Kung Fu with theory, they need to practice it by themselves. 

Scrum is the same. You can’t learn Scrum in theory, you can only learn it in practice. 

This, however, presents 3 challenges we must tackle as Scrum Masters: 

• The only changes we can bring to a team are changes that are anchored in daily or frequent practice
• We never know what works until we try it 
• We must develop a set of coaching tools that help us work with teams in a very practical way

The only changes we can bring to a team are changes that are anchored in daily or frequent practice

When we work with a team, it is tempting to start with the big ideas. Why Agile matters, how businesses need to be adaptable, how we need to be a more collaborative organization/team, etc. 

However, that’s not how we learn! We don’t start learning math by analyzing complicated math theorems or operations. No, we start learning math by learning the basics: to add, subtract, multiply and divide. Simple things that will become the basis for all thinking later on. 

Similarly, when we work with Scrum Teams we must start by practicing the basics, and slowly changing the practice, step by step. 

Here’s an example set of steps that can help you massively improve the daily meetings of your team without ever talking about the underlying theory: 

At first, when we start the daily meetings, the team will feel that they are reporting to the Scrum Master. A simple - yet, very effective - technique for Scrum Masters is to stop looking at the team members. Take notes, but keep looking at your notes while you write. This does not feel disrespectful because people understand why you take notes and creates the need for them to make eye contact with other people: the team members.

An even more effective practice for Scrum Masters that want the team to take over their own daily meetings (autonomy), is to arrange the daily meeting as a circle (or semi-circle), and slowly step out of the circle, leaving the team members to be in their own circle. As we step back we are giving a clear signal that the meeting is theirs, not ours. TIP: if people still look at you, practice item 1 above.

Daily meetings can become sometimes boring and stale, especially as the teams are not yet used to breaking down their User Stories into daily increments and may work on the same story for 2, 3 or even more days in a row. If that is the case, instead of asking about the work (what have you done? what are you expecting to complete? etc.), ask questions about the goal for the Sprint. I often use the following questions:

• Are you confident we, as a team, can reach our Sprint Goal? 
• Is it clear for you what you need to complete today to enable the team to reach the Sprint Goal? 
• What kind of help do you need from the team or people outside the team? 

Finally, you can try to hold the daily meetings need the team board, where the User Stories are visible to everyone. As the team members describe the work or progress, ask them to move the User Stories around the board with the aim to keep a visible understanding of where we are. If something is mentioned that is not on the board, ask the team members to write it down and add it to the board. This will help to discover “unplanned work” or “interruptions” that should be actively managed by the team.

All of these practices are concrete, simple to implement, and significantly change the way the daily meeting works and feels for the team. 

When you try one of these practices you are implicitly helping the team understand why the daily meeting is important. And some of these practices have a direct effect on the level of collaboration in the team.

However, none of these practices starts from theory. They start from very simple, easy to try-out changes, that have a clear impact on how the team works together. 

The take away: big changes start with small steps. Experiment every day with the concrete practices that are already in place, so that the team learns how to improve a certain aspect of their team work. In this case, that aspect was: collaboration.

We never know what works until we try it 

It is tempting to go to a book, learn a new idea and implement it right away. When that idea or practice does not result in the expected improvement we blame the team, stakeholders or even ourselves. 

It’s ok to fail at implementing a technique, and sometimes it is nobody’s fault. We can’t know what works until we try it. 

When Kung Fu superstar Bruce Lee started his career he failed. In fact, he failed countless times to be able to develop his own brand of Kung Fu. He became a master through failure, not through success. 

In order for us to be good at something, we must first get comfortable with failure. 

Practice, practice, practice is the recipe for success. Not theory, not books. 

As Scrum Masters, this should have a direct impact on how we work. When we try a new technique (for example a new retrospective format), we must accept that, at first, it may not have the impact we expected. That’s ok. We must try again. 

As we try a technique several times we become aware of its strengths, its weaknesses and how it applies (or not) to the context where we work. 

My approach to new techniques is simple. I will try any technique I find interesting at least once. If I feel I have explored that technique enough I might drop it, or continue to use it as is. However, most of the times I need 3-5 tries at a technique to understand it well enough to make a call on whether it fits my style or not. So I’ve developed a rule-of-thumb: when I try a new technique, I’ll try it for 3 times before deciding to retire it or continue. 

This ensures that I’m giving my self an opportunity to learn how the technique works (or not), and learn how to apply it better to my context. After 3 tries I decide whether I want to continue to use it or not. 

No matter how many times I use the technique though, I never think that I’ve mastered the technique itself. Rather I look at every implementation as a learning opportunity, and a possibility to improve how I use that technique. 

We must develop a set of coaching tools that help us work with teams in a very practical way

Just like Kung Fu or sports coaches, we don’t actually do the fighting or playing that the teams do. We are watching, helping, but ultimately the teams need to learn on their own and improve their own practice (self-organization and autonomy). 

For that, we must develop a set of tools that help us coach the teams to learn and improve on their own. 

Over time I’ve developed 2 approaches that work well for me when I’m trying to help teams be more proactive, feel and hold themselves accountable, and learn how to make things better on their own - even when I’m not present. 

Visualize all the things

Perhaps as a recognition of my own weaknesses, I’ve learned that if we don’t “see” a problem, we are not able to improve on it. So I help my teams visualize all of the things they need to understand before they can improve. 

A simple example of this is the use of Burndown charts. They are simple, easy to create and update, and give the team a visual representation of their progress (see this article on Burndown patterns). 

Another example is to visually represent the work in progress. A team once started to place inflated balloons on the floor of the room for every new task in progress. Soon enough the room was full of balloons, and when the Product Owner or any other stakeholder came in and asked them to work on something, they had a visual way to show the PO that they had way too much work in progress. A simple question was enough to reach a quick agreement on whether to take that new task on: “which of these balloons would you blow up, to add another one to our work in progress?”

I’ve learned that we, humans, are highly visual, and anything that helps visualize a problem makes that problem much easier to solve. 

Reflect, always

The second coaching tool I bring with me to all the teams and organizations I work with is Reflection. 

I try to reflect on my own, with the team, 1-on-1 with stakeholders. Whatever is possible or necessary at that time and in that context. 

When reflecting on what is going on, to discern the problem from the symptoms, we must have a set of questions that we ask that helps clarify our thinking. Here are a set of reflective questions that stimulate thinking beyond the symptoms: 

• What triggered you to [action]?
• With whom have you discussed your idea with?
• What is your intention with [action]?
• Whom do you need help from to achieve that goal? 

Conclusion

When working with teams that feel like they don’t care to improve, or want to be told what to do we have the option to focus on small, continuous improvements, or try big changes. 

My experience tells me that working on small, continuous and directed improvements is the best way to go. 

As Scrum Masters, we can work on simple changes to the practices which will help our teams take initiative, feel accountable, and learn to collaborate without ever mentioning theories (they don’t want to learn) or principles (they don’t feel relate to their work). 

The simple heuristics I use are: 

• Change small things in the daily/frequent practices you and the team already have.
• Practice something, reflect, learn and adjust. We can only know what works when we try it.
• Visualize all the things, and reflect regularly alone, with stakeholders and the team. This guarantees that the team starts to learn how to improve on their own, instead of being told to do it. 

What heuristics have you developed that help you succeed as a Scrum Master? 

If you want to know more about what other Scrum Masters do when trying to improve their practice listen to our Success Thursday episodes on the Scrum Masters Toolbox Podcast. Every week we interview a new Scrum Master, and they share their view on what success means for our profession. 

Vasco Duarte

Scrum Master Toolbox Podcast Host