I was teaching a Scrum course the other day and we had a really interesting discussion around the Transparency, Inspection, Adaption pillars of empiricism and how the Scrum Events were build around them.
A Daily Scrum is an opportunity to inspect and adapt their plan to hit the Sprint Goal. The Sprint Review is the place to inspect and adapt against the Product Goal. The Retrospective is where we inspect and adapt the team’s processes and tools in order to continue to increase quality and effectiveness.
Many articles and posts have been written about ways to improve the transpancy of work. We use tools like burn ups, burn downs, values like openness, and the three question format to Daily Scrums to drive this transparency at every level but do we stop and consider how we create the transparency needed to inspect and adapt in a retrospective?
Lets start with the obvious stuff. In order to improve the team’s quality and effectiveness we need the team members to be willing to share what makes their lives difficult on a day to day basis. This could be a process, tool, or maybe a knowledge gap. This often requires courage, and requires a supportive team to encourage these issues to be surfaced and worked on. The team also need to feel supported by management, after all people won’t raise issues if they don’t feel they will be looked at or addressed.
We can also use data. Value Stream maps can be extremely helpful to understand where waste exists and how processes can be tweaked to improve.
Customer and stakeholder feedback can be analysed to understand where quality issues arise and what improvements can be made to a team’s testing processes to reduce these issues in production. If there is a support team tickets can be analysed and the time spend resolving these tickets looked at. We want our applications to be as supportable as possible and we want anyone manning a client service desk on our behalf to have all the tools they need to support our customers.
Finally, I’d also recommend opening the retrospective board at the start of the sprint, rather than just before the meeting. This allows team members to add issues as the sprint goes on, maybe even in Daily Scrum. This will prevent us giving undue weighting to issues which arose towards the end of the Sprint which are fresh in everyone’s mind.
If we truly want to inspect and adapt our team’s processes in retrospective events we need to ensure we create enough transparency in our work and product to be able to properly inspect it. What techniques have you found to draw out conversations for retrospectives? How do you ensure you’ve got enough information available to inspect effectively?
The Sprint Retro is a key part of any scrum team which is looking to improve its process and adapt its ways of working to continuously improve. As with any adaption the key is transparency, the the more information the team can gather throughout the sprint around impediments or challenges they’ve faced the better. Personally I like to create a retrospective board at the start of a Sprint so team members can add their thoughts to the board as the sprint evolves rather than looking back (which always favours things which happen in the last few days).
The main challenge with the Retrospective is to avoid it turning into a moaning or helpless session. From The Scrum Guide:
Scrum Masters use a wide variety of techniques to support gathering information about the sprint including anyonmous submissions, “What Went Well vs What Didn’t Go Well”, and often scenarios involving rockets or icebergs. However, it’s important to remember that the Retrospective is a working session to give the team some concrete actions on what they can do to increase either Quality or Effectiveness (or, ideally both). While having a good rant about something which went wrong or something which impeded them can be therapeutic unless an action is taken to lean from that then neither objective should be met.
This kind of adaption is not easy. It requires teams to look honestly at what’s happened and see what they could have done different, this kind of self assessment takes real courage and for the team to have a real growth mindset. It’s the delicate role of a Scrum Master to balance between criticising what the team should have done and coaching them to look for alternative strategies of what could be done in the future.
Its easy to say that a Sprint Goal failed because X in the infrastructure team. It’s much harder to reflect on what the team could have done to prevent that issue arising. It requires taking acountability and to avoid casting other people as villains.
In earlier versions of The Scrum Guide the team were required to add at least one action to the next Sprint Backlog, however it is now recommended to be properly alongside other work.
The Sprint Retrospective requires the three pillars of empirism to be effective however this time they must be focused inward, at what the team could change or could have done differently. It also requires the Scrum Values to be first and foremost in everyone’s mind. Impediments can come from within the team as often as outside it and we rely on our courage and respect to get us through those tough conversations.
Please feel free to post in the comments below of any retropectives which have worked really wel for you in the past, it would be great to read about them.