Retrospectives - do we really need them?

After over 15 years helping teams and organizations improve with Agile, I'm fascinated how some of the most basic changes are so difficult to implement. For example, one of the questions I keep getting is, "do we really need to do a Sprint Retrospective every Sprint? ??

We know what the "right" answer is (it's "yes", in case you're wondering…), but that's not really the point with these types of questions. The person asking it usually knows the answer already. The resistance is not related to the concept, everybody buys into the idea of continuous improvement and why it matters. The resistance is related to the change in habits and culture. It's like exercise - everybody knows they should exercise regularly. Lack of knowledge is not the reason many of us are unfit. We're unfit because of (bad) habits and other priorities (culture).

This is basically why introducing Agile ways of working to an organization is difficult - habits and culture. The "way of working" is not that difficult to change, as long as people are willing to try. Why? Because it's the same "work" we're used to doing, we're just changing the way we do it. So we create a cross-functional team, and you have to collaborate on an item together, and then we're going to show it to our stakeholders together and capture feedback. These activities are not foreign to people, just the frequency and manner in which we do them in Agile.???

So when we do a Sprint Planning or a Sprint Review, we're getting our typical "work" done. Which is why it's easier to get those events going within a team. If you don't do a Sprint Planning, you don't know what you're working on for the next 2 weeks. If you don't do a Sprint Review, you don't know if the work you just did was good. We are clearly doing "work" in those events and if they are skipped there is a real impact.

Retrospectives however are one of those things that represent a real change in the way a team or organization defines the very concept of "work". Part of your job now is not just delivering value, but finding out ways how you can improve your delivery process. It's an additional responsibility, but one we don't immediately connect in our heads as "work". A good example of this concept in practice is a variant to the question I mentioned earlier - "do we have to do a Sprint retrospective this Sprint? We're behind on our work…". The implication in this line of thinking is clear, retrospecting on how to improve our way of working is not viewed as "work" itself. It's something else. And because it's not work, it's not as important as the other stuff we have to do.

As a Scrum Master, you need to go beyond the practices and processes. Yes, if you choose to do Scrum, you should focus on getting the "process" up and running, and making sure we have good "Agile" practices helping us collaborate internally and engage frequently with stakeholders. However, when there is resistance to a specific process or practice, the answer is usually not going to be enforcing adherence. If I'm not going to the gym at the frequency I agreed with my personal trainer, they can come to my house and take me there, but this is a lot of wasted effort if not accompanied by a conversation . I won't be happy doing it, and as soon as they are not by my side, I will stop going again. The bigger question in this scenario is, "why don't I manage to go regularly to the gym?"

To stretch the gym metaphor a little further, if you were my personal trainer, you might consciously make an effort to come pick me up and take me to the gym to make sure I don't skip trainings in the beginning. You do this to start building a habit. And that's fine. But eventually, you're going to have to change the way I look at "living", and make sure I incorporate health and fitness as an important part of my life. And once I do make that change, you can back off as I no longer need to pushed. I now fully see the value in exercise and enjoy it as part of my new definition for "living".

It's the same kind of thought process a Scrum Master should go through when trying to get a team to the next level of productivity. Sometimes there is a need to focus on the process and practices, but for the change to be sustainable it has to go deeper than that. You have to be able to change the way a team sees their responsibility within the organization. They are no longer only responsible for the ownership, development, and continuous improvement of their product/service (value), they are also responsible for the ownership, development, and continuous improvement of their processes/artifacts (way of working).

A team that understands this is not upset because they have to go to a retrospective. Rather, they get upset when a retrospective is badly facilitated because they understand the importance of that opportunity.

So as a Scrum Master, how do you help to build this habit and change the culture so that there is real continuous improvement? You first make sure the space exists (i.e. that the team is doing retrospectives). However, that will not be enough. You also need to be able to facilitate retrospectives effectively so that the time is well spent when people are there. And you also have to spend some time creating the business case for continuous improvement.

Start measuring the impact of improvement actions you take. Try to quantify the gains in either money or lead time. Celebrate improvements and share knowledge. Use the information to show stakeholders and leadership the benefits of retrospectives and continuous improvement activities. Work to change what is expected from an Agile team so that continuous improvement becomes part of a team's responsibility.

One of the signs of the maturity of an Agile team is their attitude towards retrospectives. And as a Scrum Master, it's one of the most important tools you have available to impact the culture of a team. Be courageous, and don't just use the same template every time while facilitating from the back of the room. Be prepared, change things up, and own the event. It's your responsibility to make sure there is a positive return-on-time-invested (ROTI) for the retrospective. And when there is, the benefits are clear to everybody in the organization.