In the previous parts (link to part 1, link to part 2, link to part 3, link to part 4), we focussed on why you are a Scrum Master, what to do when you land into your new work environment, how to set up a framework that creates a healthy routine for the team, how to develop the discipline that will make a team’s performance predictable and how to empower the team and make it as self-organised as possible.
To round off this series of articles, let us reflect on that and find out how to…
Continually improve
The end of each sprint is an opportunity to analyse what works well and what can be improved – the retrospective. During the retrospective, the team will highlight what they think works less well, and suggest how to improve.
As a side-note reminder, the team, here, will expose their weaknesses; that is why the retrospective is best held behind closed doors. It needs to be a safe space for the team members to open up.
Rarely can all those candidates for improvement be actioned in one sitting. Let the team vote for the one they think is the most urgent and important, and focus on that one. Be lean, here too, and know that, realistically, tweaks tend to be more efficient than major changes.
Keep the team engaged
At first, that exercise should seem useful to everyone. In the long run, however, retrospective fatigue may settle in: indeed, it can be repetitive. There are many ways to keep the session engaging:
- If the goal remains the same, you can change the format. Instead of Good/Bad/Ideas, why not go for Glad/Sad/Mad, The Good/The Bad/The Ugly, the hot-air balloon, the sailing boat, or other?
- Delegate the task to someone else, so they appreciate how challenging it can be to keep an audience engaged for an hour. Or ask the team, upon starting, what format they would like to follow. Even improvise a format, based on current world events to pump some lighthearted fun into the session
- Inject short, energy-boosting games into the retro. For example, assign random words to each team member and ask them all to form a sentence using the given word
- Add cathartic moments into the retro. Ask team members to pick an event from the sprint and explain to the rest of the team how that event made them feel. Or arrange them in pairs and have them discuss one specific item for a couple of minutes, before shuffling the pairs. You can even ask them to collectively identify the defining event of each day of the sprint (e.g., Production outage on Tuesday, finished task t on Friday, team lunch on Thursday, …)
- Be creative and open to new ideas
Reflect
The whole purpose of the retrospective is to get the team together to reflect – on the sprint, on their performance. They will not efficiently do that unless they feel comfortable in the company of one another.
In the beginning, a lot of the improvements suggested will affect the mechanics and processes. The team will diagnose that easily, and solutions will be relatively simple to implement. In the longer term, those points are easily addressed, often outside of the retrospective, even: the team members are talking to each other every day and will not necessarily wait until the next retrospective to point out something that can be improved.
On the other hand, a lot of the improvements in a well-established team are around team dynamics. In other words: past a certain point, the best way to improve team collaboration and performance is to ensure team members get on well. To do that, something extra-curricular often works best. Something that creates bonds. It need not be a grand day out doing paintball, or holding the retrospective at a pub. In an increasingly-virtual workplace, that is not always possible. Simply sharing, candidly, how one feels can resonate and help form a bond.
The pub is best kept for after the retrospective (and after working hours), by the way. You need the team lucid, focused and sober to reflect reliably.
Reflect on Agile itself
Your title of Scrum Master has an Agile connotation. You should therefore ask yourself: Are you Agile? If so, why? If not, why not? What makes you Agile? What are you trying to achieve by being Agile?
When the Agile manifesto was written, in 2001, its goal was to cut through red tape to generate value more quickly.
The various frameworks that came on the back of that (DSDM, XP, Scrum, etc.) are mere guidelines to help achieve that goal. They cannot, therefore, be prescriptive, lest they become the very red tape Agile aimed to cut through.
Let us take an example: Grooming. Say your team performs reasonably well, they are in a right groove, and they groom tasks on Mondays and Thursdays.
Why? Does the team enjoy being aware of what is coming next? Good. Is it that the backlog is regularly depleted on those days? Fine. Is it that “the book” says that is what you need to do? If so, you are doing it wrong.
In the beginning, the framework helps everyone find their feet. In the long term, keep what makes sense, get rid of what does not. Invite opinions on that. That is also what the retrospective is about. Tweak the framework and the processes, so you can do the right thing. Let the team do things right. That is their role in this.
Conclusion
In conclusion, the early days of your new role should probably be spent organising the team (scheduling the ceremonies and laying down the ground rules). From there, spin the team into a groove, until it becomes second nature.
Many engineers will complain about having too many meetings. Present your vision. Explain what the ceremonies are for and why the cadence, and tell them the cadence is provisional and to be revised at every retrospective, after an initial acclimatisation period.
When the groove is going, empower the team. Allow them to self-organise.
Never forget to look back and reflect: why are you doing this? How can you make it better?
When the team is fully self-organised and requires little guidance, the Scrum Master can focus on their real work: manage stakeholders outside the team.
Another topic for another time.
