 Be adaptive in retrospectives. A good Scrum Master helps the team identify improvements. A great Scrum Master inspires the team to be adaptive. Retrospectives are a crucial part of the agile approach. No iteration can ever be completely perfect, and no iteration can ever be an unmitigated failure. Understanding this is integral to the inspect and adapt process of Scrum and other agile methods. My heart sinks, therefore, when I see teams going through the motions with their retrospectives and never actually improving. If teams are coming to multiple retrospectives with the same problems, I would consider this to be a failure of the Scrum Master. Not because the Scrum Master hasn't removed the impediment, but because the Scrum Master hasn't created an environment where the team can improve their own situation. If you find that your retrospectives are going a little stale, or aren't providing the value that they think they could, or should, then the good news is that there are a number of things you can do to get more out of them. Great Scrum Masters encourage their teams to be adaptive. Act, diverge, account, probe, try, involve, visualize, and expose. Act on improvements. Teams often come up with, we should communicate better in their retrospectives, and 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 Great Scrum Masters in these situations is to ask the team to be more 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? Now, while there is no specific requirement for teams to leave the retrospective with an action plan, where each action is assigned to someone, simply building the resulting actions into the sprint backlog of the next sprint often increases the chances of something happening as a result of the retrospective. One word of warning, however. While it's great to have an action plan, the team should only take on a manageable number of improvement actions each retrospective. I personally recommend in the range of one to three. It's much more important that the team get into the habit of small and regular improvements than try to fix everything straight away. Diverge before you converge. Quite often, teams that are new to the concept of self-organization and participatory decision-making will feel uncomfortable the entire time that the decision is pending. As soon as any semblance of agreement arises, the team jump on it as an opportunity to end the ambiguity and relax. Again, this isn't always a bad thing, but it is usually suboptimal. Great Scrum Masters get the team comfortable with uncertainty and guide them through the process of divergent thinking, that is, coming up with multiple alternatives before converging on the best solution. Account for follow-through. As we observed in the Holding to Account chapter, a good Scrum Master will hold team members accountable when necessary, while a great Scrum Master will hold the team accountable for not holding their teammates to account. This holds true in the retrospective as much as anywhere. It can be incredibly frustrating and demotivating if the same ideas, complaints or observations come up time and again. Once the team have committed to taking action, the team should ensure that they follow through on this commitment. This could be by transferring the actions on to the upcoming Sprint's backlog or simply that during the next retrospective the team go through their previous actions. Probe for understanding. Great Scrum Masters 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 Scrum Master questions, looking for help and answers. Now, if you're anything like me, when you're asked a question, it can take a lot of focused effort to avoid giving an answer. It's natural. It's often what we've been trained to do and it seems rude not to. And why wouldn't you want to give an answer, especially when someone is quite plainly asking for help? Well, part of the theory is that those who answer their own questions and come up with their own solutions are a lot more empowered and therefore more likely to succeed. After all of these types of questions, we come to the powerful questions. A powerful question is one that causes curiosity and 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've asked a powerful question because it's 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're sitting. Or it could be a period of silent contemplation which you must be very careful not to break, no matter how tempting it is. Or a noticeable change in energy. Now it's quite difficult to give examples of generic reusable powerful questions because, well, they're often context specific. But here are a few that can work in many situations. How do you want it to be? What are you assuming that might not be true? If you were to assume that a solution is possible, what might that look like? If you were to go into create an analogy of the situation, what would that analogy be? If your lives depended on taking some form of action, what would you do? Great Scrum Masters help teams probe their own challenges. Try something new. Not only are retrospectives a great time to discuss, learn and come up with actions, they're also a great time to identify and or run experiments. When I was a Scrum Master at BT, I remember one of our senior managers stating that we, as a company, were redefining what failure meant for us. No longer 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, in good faith, and that we didn't make the same mistake twice, we had to learn from that decision how to get better. This public statement helped tremendously when trying to encourage people to deal with the uncertainty and the numerous possibilities around them. One aspect of redefining failure is to restate the value of experiments, so we are not necessarily valuing the outcome, but instead valuing the learning regardless of the result. Involve everyone. This may sound like an obvious thing for a Scrum Master to do, but it's easily overlooked in practice. It's important for a team to know that everyone is contributing, but people will only contribute if they feel safe to do so. This feeling may take time to develop, but a team where everyone feels able and willing to contribute to their maximum is going to be a more productive and happier team. And great Scrum Masters do everything they can to ensure that everyone has equal opportunity to be involved. Perhaps try breaking the retrospective into lots of smaller groups to begin with. Visualize data to help guide progress. Scrum as a process and the Scrum Master role in particular are sometimes analogized as holding a mirror up to the team. Allowing them to see themselves and their behaviors in order that they can inspect and adapt. This mirror could be simply capturing hard data from the sprint, such as the burn down and task board. It could also involve softer data about what the Scrum Master observes with regard to the team dynamics. Again, although the retrospective is an ideal time to examine data, it's valuable to have metrics such as downtime, stories completed or impediments cleared and in progress on display continually. One of the Scrum values is courage. And Scrum Masters need this in spades as they tackle many issues with team dynamics that it would be easier to ignore. It's often difficult to call a team to account on their lack of attention to quality, but making data visible is one way to make sure it's always in focus. One great tactic that I've seen the great Scrum Masters employ is to ask the team what they want to be held to account on or what is important to them. This way, the Scrum Master has been granted permission to make note of progress in this area and makes it much easier for them to do so. Another great tactic here is to work with the team to discover what their values are and create a chart such as a radar or spider diagram to monitor team progress on this over time. For more details on this, check out the assess your way to maturity chapter. Expose the elephants. Most teams have at least one problem that they are currently ignoring, avoiding or skirting around. This is known as the elephant in the room. A big uncomfortable topic that everyone knows should be addressed but might seem insurmountable. As with anything, if the elephant is avoided for long enough the team will develop coping mechanisms and the problem is these coping mechanisms don't actually deal with the issue. Instead, they make the problem even less likely to be removed because now it doesn't seem quite as necessary anymore. Great Scrum Masters 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. Now the team may well accommodate this person by shifting the daily scrum and sometimes write up their conversations but these activities, these coping mechanisms are just leading to inefficient teamwork and perhaps resentment 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. You can choose to view them as a great built-in opportunity for teams to improve the process every sprint or you could view them as a responsibility placed upon teams as payoff for the extra autonomy and respect they're granted within Scrum. In reality though it's probably healthy to take a balanced view involving both of these perspectives but either way retrospectives can be incredibly powerful if teams are adaptive.