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?
dotdotdev.com 