Scrum Mastery

by Geoff Watts

Great ScrumMasters encourage their teams to be ADAPTIVE: Act, Diverge, Account, Probe, Try, Involve, Visualise, and Expose.

Teams often come up with “we should communicate better” in their retrospectives. There’s nothing wrong with that. Who can argue against improved communication? You might even see some improvements just by noting the problem. However, the default reaction of a great ScrumMaster in these situations is to ask the team to be specific. Who needs to communicate better with whom? What do they need to communicate better about? When does this communication need to happen? How will we know communication is good enough?

While it’s great to have an action plan, the team should take on a manageable number (one to three) of improvement actions each retrospective.

Great ScrumMasters get the team comfortable with uncertainty and guide them through the process of divergent thinking: coming up with multiple alternatives before converging on the best solution.

One simple technique that has worked really effectively is called The Rule of Seven, as first explained to me by actor and author Lee Devin, who had witnessed it from a team at Boeing. With this technique, the team agrees that they won’t make any decision until they have thought of at least seven different alternative solutions. I’ve found that the first few solutions or ideas are fairly easy to come up with and, usually, fairly sensible as well. Ideas four and five are a typically a little more off-the-wall and take a little longer to emerge. Ideas six and, especially, seven are sometimes a bit crazy. In ideas six & seven, though, are often the seeds of ground-breaking ideas that can really energise a team and lead to quite astounding solutions.

As we observed in the “Holding to account” chapter, a good ScrumMaster will hold team members accountable when necessary, while a great ScrumMaster will hold teams accountable for not holding their teammates to account.

Great ScrumMasters often take on the role of team coach, asking questions of the team to help them reflect on their situation, establish the root cause of their challenge and find a way forward. Too often, it’s the other way around: the team asks the ScrumMaster questions looking for help and answers.

To help new ScrumMasters get used to asking meaningful and helpful questions, the ORID structure [26] offers a useful way of structuring their inquiry.

The first stage is asking observational or objective questions, such as What happened? Who said what? When did it happen? The aim here is to gather some facts about the situation without interpreting or analysing them. The second stage is asking reflective questions such as How did that affect you? How do you feel about that? How do you think others were affected by that? The aim here is to learn about how the team feels about the situation. The third stage is to ask interpretive questions, such as Why do you think that happened? What do you think that means? How do you think that will affect you/them/the organisation? The aim here is to understand the meaning or significance of the situation. The fourth stage is to ask decisional questions, such as What are you going to do? How could you move this forward? What would you consider a positive outcome? The aim here is to help the team make some progress, or at least make a plan to make progress. After all of these types of questions, we come to the powerful questions. A powerful question is one that causes curiosity, intrigue and often touches a deep meaning. 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: • A shift in body posture, perhaps a tilt of the head or a change in how they are sitting. • A period of silent contemplation, which you must be very careful not to fil...

One example of redefining failure I have seen in teams is to introduce the concept of the failure bow [27], a ceremony where a team member whose experiment led to an unsuccessful outcome literally takes a bow and accepts a round of applause for the effort. It is important to note that we are not glorifying failure here but rather changing the way we perceive and deal with it. We reward the effort, transparency and unexpected learning instead.

Almost without exception, the most successful Scrum teams I have seen have had a ScrumMaster that has created an environment where teams don’t accept limiting beliefs such as “but that will never happen here.”

One great tactic I have seen the great ScrumMasters employ is to ask the team what they want to be held to account on, or what is important to them. This way the ScrumMaster has been granted permission to make note of progress in this area, making it much easier for them to do so.

Great ScrumMasters courageously expose, and encourage teams to explore, the elephants in the room as soon as they notice them. They don’t judge, but neither will they let their team tolerate and get dragged down by these problems. Instead, they offer to lead an exploration. For example, the elephant in the room could be that one of the team members is getting into the office later and later. The team are accommodating him by shifting the daily scrum and, sometimes, writing up their conversations but this is leading to inefficient teamwork and resentment is growing in the team. Before this spirals into outright anger and rebellion, the team should confront and solve the problem. There are two ways to look at the fact that retrospectives were included into the Scrum framework. They can either be a great, built-in opportunity for teams to improve the process every sprint. Or they can be viewed as a responsibility placed upon teams as payoff for the extra autonomy and respect they are granted within Scrum. In reality it is probably healthy to take a balanced view involving both of those perspectives but, either way, retrospectives can be incredibly powerful if teams are ADAPTIVE.

A good ScrumMaster holds a balanced retrospective. A great ScrumMaster holds a focussed retrospective

Kurt was keen to finish the sprint off well so was preparing to facilitate the team’s first sprint retrospective. At the morning’s daily scrum he mentioned that he was going to be spending some time today planning tomorrow’s retrospective. He was surprised to hear a few grumbles from the rest of the team. His teammate Dan even mentioned that he might be too busy to make it to the retrospective tomorrow, which disappointed Kurt. After the daily scrum, Kurt had a quick word with Dan and asked him about his plans for the next day. “Well to be honest,” Dan said. “I’m not that keen on going anyway. I’ve never enjoyed those types of meetings.” “What do you mean?” Kurt asked. “This is the first one.” “Yeah, but it’s just the same old thing by another name, isn’t it?” Dan said. “Just another opportunity for a blame-storming session.” “Well, that’s not how I understand it; and it’s certainly not how I intend to run it either,” replied Kurt. Kurt explained the prime directive to Dan. He told Dan that he was following the premise set forth by Norm Kerth [28]: “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.” Kurt then went on to explain that his plan was to lead the team to objectively look back at what happened with the sole purpose of enabling the team to work out how to make the next sprint even more successful...

During the next retrospective, Kurt asked the team to imagine that, instead of being at this retrospective, they were just about to start the sprint review meeting of the upcoming sprint—to imagine that they were in the future and looking back on the really successful sprint they had just finished. Once everyone indicated that they had a mental image of this situation, he asked them to describe the moral of the sprint: a maxim that explained why they were a healthier, more productive, better team than they were a sprint ago. To help them get started Kurt gave a couple of examples: “Don’t talk to strangers” might reflect that we stopped getting distracted from our sprint goal. “Look both ways before you cross” might reflect that we finally solved our quality issues by instigating tighter peer review and QA controls within the team. Once everyone had a moment to think, they were asked to complete the sentence “and the moral of the sprint is...” on an index card and hand it in. When all the cards were complete, the team clustered the cards and identified a common theme, which was around the truth that having one completed story was more valuable than two partially completed stories. The moral? A bird in the hand is worth two in the bush.

95% of ScrumMasters hold balanced retrospectives as if they were second nature. However, not that many hold focussed retrospectives. Hollywood screenwriters talk about the first ten pages of the film script having to contain “a hook,” something that intrigues the reader/audience and pulls them in. The best movies all have a hook. Think of the iconic scenes from The Godfather, The Shining, Up, Jaws or The King’s Speech and you can imagine what I mean by “the hook.” 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.

There are a few common ways of coming up with a retrospective goal: At The Start Of The Retrospective • Ask the team to help you craft a goal during the first couple of minutes: • Ask every member of the team to describe the sprint in a word or two, or perhaps as an abstract object such as “if the sprint were a chocolate bar, what would it be?” Then cluster the outputs and find a theme before focussing the sprint on that theme. • Use a game like Remember The Future [31], which is similar to the “moral of the sprint” exercise in the story. • Ask the team (or perhaps small groups within the team) to come up with a sprint limerick or song that defines either the past sprint or the one that is about to happen. Use that output as something to either aim for or to investigate.

Working as a servant-leader is an alternative approach for many people and organisations. Servant-leaders flatten the hierarchies of their organisations, tear up old standards and challenge the traditions and institutionalised working processes of their companies. At some point, all ScrumMasters will be faced with the prospect of introducing some radical concepts to the team and the organisation in order to continue the journey to a more responsive, high-performing agile structure. Great ScrumMasters are prepared to stand out and break the mould. They pioneer new techniques and strategies in the pursuit of excellence and performance no matter how counter-culture they may seem. Even after many years of experimenting with Scrum, the path is still not well trodden and there is still no blueprint for how organisations should be structured and organised in order to be successful. Therefore ScrumMasters must be prepared to challenge the status quo and do things differently. This doesn’t mean that ScrumMasters should be contrary merely for the sake of it. It does, however, often mean that great ScrumMasters will have to go against the grain of conventional wisdom and, almost certainly, take the more difficult option available to them if the easier option is likely to not be radical enough to alter long-term behaviour. As teams develop and grow, there will even be opportunities to look for alternatives to some of the Scrum practices, especially when the team reach Ri. Be prepared ...

A good ScrumMaster encourages teams to share skills. A great ScrumMaster encourages teams to share responsibilities.

T-shaped doesn’t just have to refer to skills though. Scrum teams are expected to do whatever is required of them to deliver within a sprint. This often means people need to act outside of their job description and take responsibility for tasks that they are not technically responsible for, or necessarily highly skilled at. The Geckos are a good example of a team that needed a more T-shaped mindset. The Geckos were coming towards the end of the sprint (day 28 of 30) and were holding their daily scrum. The team were standing around the sprint backlog board and were taking it in turns to update the rest of the team on what they had been working on and their plan for the day. An extract from the conversation follows: “Guy & I have finished coding the photo upload feature and have handed it over to Roxie and Eve to test,” Christian said. “We’re now done for this sprint so we are probably going to make a start on the ratings feature from the product backlog to give ourselves a bit of a headstart for the next sprint. Obviously we have no impediments because we’re finished! Hooray!” Christian then threw the speaker’s ball to Roxie to indicate that he wished to hear from her next, so Roxie took her turn: “It’s probably going to take us the last two days of the sprint to test. We were hoping for a handoff yesterday, but we ended up kind of hanging around a little yesterday waiting for Christian and Guy to finish. Now we have the feature ready for testing, we can get cracking on it....

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.

Another option is for the team to implement some form of kanban-type limits on the stages within a sprint. For example, the team would set a limit of a maximum of two items to be “in test” at any one time. Once that limit is reached, the team then “swarm” around the items at the bottleneck stage to clear the blockage.

A good ScrumMaster helps a team meet their definition of done at the end of the sprint. A great ScrumMaster helps a team extend their definition of done

Engineering practices such as TDD [37] or test-first are not explicitly called out in Scrum — Scrum is completely non-committal about such things— but in common practice most, if not all, of the successful Scrum teams I have come across

Scrum teams, especially new ones, often need to slow down to speed up.

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]. The most effective Scrum teams acknowledge that, in order for the team to be successful, each individual needs to have some spare capacity. If the spare capacity for any individual is too high, the team should address this in the retrospective. Is there a need for a full-time member with this skillset? Is there anything else this individual could be contributing to the team? How could the team better organise themselves to be more productive? 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.

Great ScrumMasters, while being practical and pragmatic, will not let the team stay too long in a less-than-optimal definition of done. Instead, they will set a target of helping the team extend their definition of done as much as possible, as quickly as possible. This almost always has the biggest impact on productivity, quality, morale and, in effect, agility. It might involve lobbying for greater training or for the transfer of an individual into a Scrum team or perhaps an investment in automation—whatever is needed to help the team get “done” in this and every subsequent sprint. Until we can do this, the best we can hope for is scrummerfall.

A good ScrumMaster facilitates the sprint review to look back and review the product built in the previous sprint. A great ScrumMaster facilitates the sprint review to look forward and shape the product in future sprints.

Ideally Scrum teams should be in a position where they could release the increment at the end of every sprint if they so decide. This might not always be the case (see the “Getting Stuff Done” chapter) and so we may use this information to guide our release and/or marketing strategy.

“Do not follow where the path may lead. Go instead where there is no path and leave a trail.”

I see ScrumMasters as radical change agents within organisations and people who inspire energy for change in others around them. They act as catalysts, incendiary fire-starters who create a place where people want to be and are able to be their best.

Nobody is ever inspired by a cynic. Great ScrumMasters are infectiously positive and optimistic, embodying the art of the possible and role-modelling the values and principles of greatness. They are courageous in their convictions and ruthless in their belief in the capacity and the potential of their team and the organisation. This positivity is part of what makes great ScrumMasters such motivating people.

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. When I responded with “there are none,” they then asked me what they should do about it. I posed them a hypothetical scenario: Suppose, at the end of the project, your boss comes along and says “Great job! That was a really impressive piece of work and it meant a lot to me, and the rest of the company. I would like to recognise your effort and performance but I don’t know how. How can I reward you? Name it...” I asked the group to think about it and then asked them what they would ask for. The responses I got included: • “It would just be nice if someone actually said something like that!” • Money • Time off • New gadgets • Company-sponsored social events • Time and authority to improve the team’s work environment • More autonomy over the team’s work • An opportunity to experiment with new tools or technologies And then one lady said: “It’s funny you should ask because just recently I got something that I didn’t know I wanted but, now that I’ve had it, I want it all the time.” The rest of the group looked at her and ...

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 fi...