Scrum retrospectives: what is going on, how to make them work
Scrum is a beautiful thing. We carve out a corner of the business-as-usual world and change the values and working ways. We do this because it is one way we can get a product built in the chaos of modern corporate life without sacrificing people, a ton of money and the quality of the product.
And I’d say the Sprint Retrospective, and what follows from it, is the most beautiful part of all. Enshrined in the process, every two or four weeks, we pause for a moment and look at how the last sprint went. We’re looking at our conditions. Our scrum. Our process. And then we look at how we can improve them, and make a plan to make some improvements over the next Sprint.
This is reflective practice, done as a team, regularly. And this is really important. With a reflective practice, the team and team members are able to learn, grow skills and develop. There are opportunities for people to try something different, design a part of the process, step up to something, and be witnessed doing it by the team.
In this way, the sprint becomes a place for learning and experimentation, for growing skills and virtues in the team members.
So what does this mean for running end-of-sprint retrospectives? Here are some reflection points I use before beginning a retrospective:
1. The retrospective is a way for us to improve our ways of working, contentment and conditions. It is important for team morale and for individual’s growth.
2. As a scrum master, I’m looking to embed a culture of continuous improvement via the sprintly reflective practice and doing work in the Sprint.
3. Key messages for scrum master and team going into a retrospective:
- The team has the power to improve their conditions (improve their processes and work lives, deliver more points, improve quality).
- Team morale comes from delivering points and working on improving conditions. Both are important. Skipping either will lead to trouble.
- Blaming others is not going to work. Striving to understand them is a beginning.
- When evaluating the results of changes made from retrospectives:
4. When working on improving conditions, failure is totally OK. Focus on the learning from what happened. This is a kind of gentle inquiry into what happened. Hold it lightly. We’re looking for this kind of feeling: “[laughs]. Wow I really screwed that up [laughs and smiles]. I wonder why?”.
5. Blame destroys the learning. Work away from “They screwed it up!” to a gentle inquiry into what happened and why. Understanding the context of the world/business we are in helps us work out what to do.
6. Witnessing is important. Team members need to witness each others successes and failures, doubts and concerns. Therefore the importance of showcasing both functional work and retrospective-driven improvements.
7. Sometimes, a team is too burned or shocked or harried to be able to get in a place to run a retrospective. It is important to notice these times. Rather than push it, here is an opportunity for some time out. Ideally use this time to go out for a walk. Nature helps if available. Get out of the office and just walk for a bit. People will chat amongst each other. I don’t feel any need to structure this, it seems like people chit chat, work and team issues come up and are discussed and put away again. A camp fire would probably work even better, but that is harder to organise in the daytime in most urban areas :-)
8. As a leader, show your weakness, acknowledge your screw-ups, and showcase your learning with the team.
OK, that is pretty dense. That is definitely enough to think about. Distilled to one key point:
Cultivate a gentle, inquisitive, reflective learning amongst the team and yourself. Hold it all lightly. Laugh, but with kindness. Keep the rhythm.
Originally published at nodestone.io.