Change is often hard. But it is also important and much needed. That is why agile software development suggest to frequently inspect and adapt and promotes the usage of retrospectives to continuously improve the things that teams do. Retrospectives help teams to make changes that stick in the organization, leading to sustainable improvement.
This is the third article in the series on the benefits of agile retrospectives. Earlier I explained how retrospectives deliver actions by the team, i.e. that the team can do themselves and that retrospectives give power to the team by supporting them to self-organize and find better ways of working. This article describes the benefits of designing valuable agile retrospectives that deliver effective actions leading to lasting change.
The book Getting Value out of Agile Retrospectives helps you and your teams to do retrospectives effectively and efficiently. It’s a toolbox with many exercises for facilitating retrospectives, supported with the “what” and “why” of retrospectives, the business value and benefits that they bring, and advice for introducing and improving retrospectives. This new agile retrospectives book can be downloaded from InfoQ and Leanpub and you can buy the paperback edition.
Retrospective actions that stick
A retrospective is a short and intensive session where the team decides on the few vital improvement actions that they will do in the next sprint. There are many different exercises that teams can use to define action that lead to lasting change. The trick is to define actions in such a way that they stays in the minds of the people, and keeps popping up during the next iterations. We have to reach tipping points where small actions result into lasting change. They has become a habit of how people do things, a new skill that they develop and apply.
What can you do to make the changes from retrospectives stick:
- Make change practical and personal
- Have concrete actions addressing real problems
- Give actions a catchy name
- Keep actions small
- Make the “why” of the change visible
- Failure is ok, stimulate people to try things
- (what are your suggestions to make actions stick? Let me know!)
The changes that teams define in a retrospective should be practical and personal. Practical in the sense that they can be done in the next sprint. Yes done, similar as a user story is done. The team is its own customer, and defines up front when the change is sufficient. Having the changes done by the team also makes it personal, it’s is by the team and for the team. One for all, all for one!
Retrospective look at things that have happened recently (in the last iteration). These are real things, something the team has experienced. It may be something that went above expectation, and that they would like to reuse in the next itration. Or something that didn’t go that well, and that they do not want to see happening again. Retrospectives help teams to identify, define, and use their experiences from iterations, to learn and improve.
Giving actions a catchy name makes it easier to remind them. Team members can support each other doing by using the name of the action. It’s a lot easier to say “let’s pair up” to remember an action to do more pair programming then to say “hey, didn’t we have an improvement action somewhere written down about that our team should create and use opportunities to work in pairs when they are developing new code or maintaining existing code”.
Smaller actions are easier to do and hence give quicker benefits. Since they are small you don’t need to plan them, just think about how you can do it and start doing it. You can use a Kanban approach do do small changes from where you are now. Babysteps are also steps, you can make a giant journey by taking on step at the time and keep on walking.
Actions that come out of a retrospective make sense. They are based on something that the team has lived through. It is important that the team knows why they want to do the action and why things need to change. What is it that they want to reach? What makes it important? This should be very clear and should be visible together with the action. One way to do this is to write actions as a use case:
“As a <role/stakeholder> I want <to do an action> so that <why we need to change>.
If people are not afraid to try new things it becomes much easier for them to changes. Making mistakes is ok, you can learn from them.
Sustainable improvement
Teams can do sustainable improvement with retrospectives. Agile Retrospectives help teams to continuously change their way of working, giving them benefits now and in the future and creating more value with agile.
Do you want to have agile retrospectives with actions that stick and result in lasting change? Luis Gonçalves and I have published the book Getting Value out of Agile Retrospectives with many exercises and tips to do effective retrospectives.
