Scrum Mastery

by Geoff Watts

The aim here is to learn about how the team feels about the situation.

The aim here is to understand the meaning or significance of the situation.

The aim here is to help the team make some progress, or at least make a plan to make progress.

A powerful question usually requires a paradigm shift for it to be answered. You can usually notice when you have asked a powerful question because it is usually followed by one or more of the following:

Great ScrumMasters help teams probe their own challenges. It’s a little bit like teaching people to fish rather than giving them a fish.

would failure mean making the wrong decision. Now making the wrong decision was a good thing—so long as we made that decision quickly, cheaply and in good faith, we didn’t make the same mistake twice, and we learned from that decision how to get better.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

which was around the truth that having one completed story was more valuable than two partially completed stories.

All the great ScrumMasters I have seen ensure their retrospectives have a hook as well — something that sets the scene for what is about to happen while also pulling people in, grabbing their interest and energising them.

“It is better for the developers to be surfing than writing code that won’t be needed. [...] If they went surfing, they would have fun and I would have a less expensive system and fewer headaches to maintain”

Funnily enough it is not just the developers who are concerned or anxious about blurring this boundary between development and test. There are status concerns, quality concerns, job security concerns, career progression concerns. I have seen many organisations that attach lower status to testers than they do to developers;

The more that developers are not trusted to test, the more they will be unable to test and the more they will shirk the responsibility of writing good code.

that the rates for developers with good testing/quality skills are much higher than those without.

Esther Derby says that the only way to deal effectively with turnover on teams is for each member to be doing one thing, learning another, and be teaching a third

Pairing developers with testers can allow testing to be undertaken during coding, and allows that code to evolve in response to the feedback of the ongoing testing process.

It is much more collaborative and agile at heart than pairing developers to feed testers.

Members of a Scrum team should also be aware that they do not need to be busy 100% of the time—in fact, this can lead to sub-optimal results [38]

Remember the goal is not for each individual to be as productive as possible but rather for the team to be as productive as possible.

The former does not necessarily lead to the latter and, in many cases, individual optimisation leads to a diminishing of team productivity.

The team realised that it would have been better to try to get one feature completely done than to have many features partially done.

Great ScrumMasters will also find out what motivates the people they are serving. I was once asked in a workshop about what reward policies Scrum has built into it.

TIP: Find out what motivates the individuals within your team and what motivates them collectively as a team. These are unlikely to be the same thing. You may also be surprised by what you find out and how simple it may be to meet those needs.

Great ScrumMasters are very protective of the team, ensuring they are not undermined, distracted or sabotaged and, at the same time, ruthlessly encourage the team to self-manage and self-regulate.

all good ScrumMasters will help the team reflect on where they can improve, which is a really valuable — if not critical — thing to do. What I have noticed, however, is that the great ScrumMasters, like Paris in the story that follows, focus much, much more on the team’s strengths than their weaknesses.

One of the Scrum values is respect. Part of respecting people includes holding a generally positive view of human nature. Because we respect our colleagues, we believe that most people want to do a good job. One way of helping ensure people do a good job is by believing in them (See the “BELIEF” chapter for more on this). But beyond that, we must help them believe in themselves if they are to realise their potential and truly become a high-performing team. Your belief in them must be genuine.

Great ScrumMasters help teams first of all become aware of their strengths and then decide how to use them to develop even further.

team that four of those five would be word-for-word the same in everyone’s form and would be focussed on the project goals. The remaining objective would be specific to the individual’s own unique development pathway. This worked for us and was copied by a number of other Scrum teams in the organisation (and another organisation as it happens) but wasn’t institutionalised across the company — it didn’t need to be.

As a ScrumMaster sometimes you need to play by the rules, sometimes you bend the rules and sometimes you need to help write new rules.

Sometimes one or more of the team members is just a not team player. What makes it worse is when the person who just won’t buy into the team mentality is the star player.

“I’d rather have a hole in my team than an asshole in my team.”

Jacobs went on to explain that, no matter how indispensable someone may appear to be, you may be surprised how much the rest of the team steps up when that disruptive influence is removed. I

Will Felps’ study on team effectiveness also found that the presence of just one slacker or jerk can bring down performance by 30-40 percent. While a good ScrumMaster will attempt to cater to every individual within the team, the great ScrumMasters will also identify when it’s appropriate to remove one individual for the good of the team [42]. (See the “Assess Your Way To Maturity” chapter for more on helping the team grow as a team).

The teams that develop the furthest focus on developing both their sense of team and also the strengths of the team as a whole.

Stephen Covey [44] claims that most people do not listen with the intent to understand; they listen with the intent to reply.

Great ScrumMasters help their teams develop a talent for listening and empathy as well. Imagine the daily scrum for example. In a team of seven people, each person will be listening for significantly longer than they will be talking so the more that each team member can develop their abilities to listen and truly understand, the more effective that team will become.

If I were to recommend one skill for ScrumMasters to practice it would be empathic listening.

Cooperation and collaboration are both good things but they are not the same thing. You can’t get collaboration without at least a degree of cooperation. However, just because people are cooperating does not mean that they are collaborating.

improv team have no script and have to respond to unpredictable stimuli ... as a team. When one member of the team speaks, rather than think “why did he say that?” or “what a terrible idea,” another team member immediately builds on the direction the first teammate has taken (choosing to believe that the suggestion was both inevitable and inspired) and

Games such as “one-word storytelling” [46] or “the three-headed expert” [47] or “story spines” [48] are really quick and easy (and fun) games that can help teams get into the mindset of collaboration and practice that skill.

The team will probably need to make use of many more communication channels than they were previously used to and most likely at a much broader frequency, so encouraging people to talk to each other is a noble and worthwhile aim.

A good ScrumMaster encourages people to talk to each other. A great ScrumMaster encourages people to listen to each other

A good ScrumMaster helps teams use “yes, but” effectively. A great ScrumMaster helps teams find more space for “yes, and.”

A “yes, and…” mindset is the basic building block of collaboration and, as we discussed in the previous story, improvisational theatre.

Improv actors don’t know what is going to come up, but whatever does come up, they are determined to accept, respect, and add to it.

Surprising results emerge when we have a yes, and mindset in the team; nothing is impossible, nothing can stop us, and th...

Value principles over rules

I know this sounds like I am encouraging insubordination and, to a degree, I suppose I am. The transition to an agile organisation is bound to see a few conflicts arise when the teams who are trying to be agile come up against the less-than-agile processes of the traditional organisation. Sometimes the only way to push change is to be disobedient. However, as I’ve reminded you a couple of times now, a dead ScrumMaster is a useless ScrumMaster.

Unfortunately having all that functionality is also a bad thing because there is a risk that someone will find a reason for using that functionality.

For example, if there is the possibility of having an extra line on the burndown that calculates estimate accuracy then you can be sure that a manager somewhere will be interested in that data. Pretty soon, the tool starts driving the process and becomes a burden on the team rather than enabling them to be effective.

good ScrumMaster protects the team from distractions. A great ScrumMaster finds the root cause of those distractions and eliminates them.