Scrum Mastery

by Geoff Watts

But what a ScrumMaster always needs are the qualities that Geoff describes in this book: Resourceful in removing impediments to productivity Enabling, helping others be effective Tactful, diplomacy personified Respected, known for integrity both within the team and in the wider organization Alternative, prepared to promote a counter-culture Inspiring, generating enthusiasm and energy in others Nurturing of both individuals and teams Empathic, sensitive to those around them Disruptive, able to shift the old status quo and help create a new way of working

With Geoff’s experiences and stories as a guide, you will see that a ScrumMaster is not master of the team, but a master at encouraging, enabling, and energizing people to gel as a team and realize their full potential.

“It is far better to be trusted and respected than to be liked.”

Therefore, in order to be effective as a ScrumMaster it is imperative to earn the respect not only of the team but also of influential people within the organisation.

Teams are surprisingly consistent in choosing who will be good at enabling them to be effective; they know who will get the best out of them. It is also often very different from the person that management tends to select for the role! Given that the team is not accountable to the ScrumMaster and, if anything the ScrumMaster is accountable to the team, it makes a certain amount of sense for the ScrumMaster to be chosen by the team.

Respected ScrumMasters all seem to have a humility about them; a certain selflessness and lack of ego that increases their integrity and the respect they are given. Humble ScrumMasters take regular timeouts to reflect on who has helped them improve their talents or be successful. They acknowledge the mistakes they have made and identify where others have been successful without their help or, better still, in spite of their contributions. To mindfully practice humility, try asking for help and admitting where you have gaps in your knowledge.

Respected ScrumMasters have a much greater rate of success in removing impediments and enabling change within the wider organisation as their views have greater weight with the influence-holders.

TIP: During the next retrospective, ask for feedback from the team on how you could become a better ScrumMaster. Not only will you get some great ideas for how to improve but also merely the act of asking for feedback tends to increase respect. Share your values with the team and ask them to help you keep from compromising them.

A huge element of respect comes from having integrity. Integrity involves honesty, consistency, reliability and a strong moral code.

Scientific studies have proven that people are hard-wired against uncertainty.

Scrum introduces (or makes explicit) a lot of uncertainty—around requirements, process, hierarchy, and job descriptions amongst other things—so having someone you can rely on is highly desirable. The ScrumMaster can be the rock in the storm for the team.

TIP: Don’t over-promise but, instead, make many small commitments and keep them. Admit and apologise, without making excuses, when you fail to keep your commitment.

two commandments of a ScrumMaster. 1. First ask the team

2. Make yourself redundant

My second piece of advice is to go into the role of ScrumMaster with the intention of making the role of ScrumMaster for this team unnecessary. Create such a high-performing, self-organising team, with such a good relationship with the product owner, with such a keen understanding of the Scrum framework (and the principles behind the framework) that they don’t need any facilitation (of either process or people) and have no impediments left to remove. In other words, be so great that they don’t need you anymore. I’m not saying this will definitely happen, but the more you aim for it, the more quickly your team will develop and the better your team will perform.

A good ScrumMaster helps a Scrum team survive in an organisation’s culture. A great ScrumMaster helps change the culture so Scrum teams can thrive.

Perhaps your organisation has a culture of micro-management, or a performance management system that encourages individual development and the growth of heroes. Perhaps your organisation is structured in a matrix-style, applying an individualistic approach to resourcing projects, or perhaps there is a historic desire to fix both time and scope on projects.

Sometimes simply making visible the dysfunction or bottleneck will be sufficient (such as highlighting the causes, consequences and cost of technical debt), sometimes change will require influence, persuasion or lobbying, and other times it will require evidence of a valid alternative path before anyone will listen.

great ScrumMasters take a viral approach: slow enough to not get destroyed by the host organisation but quick enough to gather momentum and instigate structural change within the corporate DNA.

All plans are arguably wrong anyway because, as soon as they are made, the information used to make them is immediately out of date. This is magnified when a team is new and the problem is complex.

In practice, it often takes teams about three or four sprints to establish a steady, predictable velocity, before which time they tend to fluctuate between over-promising and over-delivering.

While the team is figuring things out, it might be worth considering shorter sprints to get some empirical data about team velocity earlier.

Attempting to encourage, pressure or bribe the team into reducing the release plan will almost certainly lead to the team either consciously or sub-consciously cutting quality and introducing technical debt.

If the team were to find out that their plan would only count if it met the expectations of the product owner or management, then their buy-in to the process and the project would undoubtedly diminish. They would then have little chance of achieving the productivity and creativity benefits offered by a self-organising Scrum team.

While we must sometimes make short-term compromises for long-term gains, great ScrumMasters know when it is imperative to take a stand on principle for the sake of the long-term agility, performance and integrity of the organisation. They might educate stakeholders and management about the benefits of self-organisation and the general advantages of team buy-in. They might also help calculate and visually represent the costs of the technical debt that will likely result from pressuring the team into meeting a fixed scope by an imposed deadline.

It’s critical that any arguments be presented calmly and factually. Explaining the danger of undermining the team’s autonomy and self-organisation and emphasising the cost of poor quality will go a long way toward helping management understand the importance of trusting the team.

A good ScrumMaster will hold team members to account if needed. A great ScrumMaster will hold the team to account for not holding their teammates to account.

Scrum teams who write down their working agreements are much more likely to abide by and hold themselves accountable to them.

“You are not the only person who has violated the stated rules today, just the most recent. I want to ask the team a question: are these agreements truly reflective of your intended behavior? Because you are not only breaking your own rules, you are also failing to take action or hold each other accountable to them. If I weren’t here, how would you normally proceed?”

again. This time Vince reminded the team to only include behaviours they really wanted to, and felt able to, commit to as a team.

Letting this behaviour go, even just once, would have set a precedent that the team working agreements weren’t that important. Solving the problem or confronting rule breakers would have taught the team that he would function as their rule police. Vince’s decision to place the solution on the team’s shoulders, while remaining non-judgemental, helped minimise defensive behaviour or a confrontation.

Create a feedback culture

Though many organisations say they value feedback—”It’s the breakfast of champions” is a phrase I have heard many times—when it comes to it, people are either unskilled at, unprepared for, or unwilling to take good, proper, helpful feedback.

yet effective models for giving feedback that a great ScrumMaster can introduce into the team to foster this practice. Sometimes, just focussing on the positive aspects of a behaviour, idea or delivery, and the ways it could be made even better is enough.

Another potential feedback tool is The Perfection Game, as described in the Core Protocols

good ScrumMasters will find ways to provide the necessary feedback for all parties to make the decisions they need to make in order to be successful. Great ScrumMasters go one further and create the environment where feedback flows freely in all directions and becomes an accepted, expected and valued part of how we work.

“It is amazing what you can accomplish if you do not care who gets the credit.”

TIP: Try “battle mapping” [13] to map out both the formal and informal structures of your organisation, interactions, power relationships and spheres of influence.

TIP: Find out what the team’s biggest frustrations are in their work. Choose one that you could reduce or remove to increase their effectiveness.

In order to be a great enabler of a team, a ScrumMaster will need to remove impediments at both the team and organisational level. To remove impediments, ScrumMasters need to understand (or learn) how things get done in the organisation. Knowing whose door to knock on when an issue arises or what channels are most effective in gaining traction (and resolution) is often critical to a ScrumMaster’s, and team’s, success.

A good ScrumMaster is wary of influencing the team. A great ScrumMaster can act normally and know the team will still make their own decisions

best Scrum teams keep each other in check, rather than depending on the Scrum- master to do it for them.

One tool I’ve seen teams use to hold each other accountable during a daily scrum is a buzzer. at any time, if a speaker is being too vague, too detailed, using jargon, or generally not giving the team the information it needs, any one of their team-mates will activate the buzzer to bring the speaker back on track.

“Pairing to help each other learn and get new members up to speed is what we do.”

When a new team member joins, it may even be worth revisiting the team norms and practices to see if there are existing customs that might seem odd, be inappropriate, or require explanation. Always remember that what is simple fun and banter with one set of people may not have the same effect when the composition of the team changes.

When assimilating a new team member, you might also focus daily scrum updates on a product backlog item at a time rather than one person at a time, thus reducing the focus on any one member and increasing the focus on the work.

product owner role is an attempt to bring conversation into the sprint rather than rely on written instructions.

ScrumMasters must ensure that the team get the answers they need during the sprint, which typically involves working with the product owner to improve product backlog items, facilitating better relationships, and removing impediments that stand in the way of team access to the product owner.

The underlying problem of product owner access is not going to be resolved by user stories because user stories are quite openly a token (or placeholder) for a conversation. They are not a contract for a feature and can only really work if followed up with a conversation about the need expressed in the story.

product owner is a crucial role in Scrum.