The Sprint Retrospective is one of the most important events in the Scrum framework, and one which enables empiricism in the Scrum framework.
“Improving daily work is even more important than doing daily work.”
― Gene Kim, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
Empiricism in a nutshell
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
– The Scrum Guide
Let me guide you through how these 3 pillars are critical to each Scrum event, and how they can help guide you through the unknowns.
You can sum up the empiricism into:
- Have access to knowledge and a shared understanding (transparency)
- Trying something out based on that knowledge and view the outcome (inspection)
- Based on the results — which is new knowledge — try something else (adaptation).
With this in mind, how would we apply this to our Sprint Retrospective?
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
– The Scrum Guide
The Sprint Retrospective event is a point where the Scrum Team can look back retrospectively on the Sprint and discuss things which detrimentally affected the Scrum Team and this which also had a positive effect on the Scrum Team so that it can create an improvement plan. It also aligns with one of the principles of the Agile Manifesto:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
– The Agile Manifesto
The Sprint Retrospective is also a time when the team will show at the stage within the 5 stages of team development (Forming, Storming, Norming, Performing, Adorning) they are currently at.
Transparency comes from the Scrum Team being courageously open, whilst remaining respectful with each other, to call out things which have affected them. To enable this, the Sprint Retrospective needs to be a “safe” space.
Having stakeholders present may prevent the Scrum Team from discussing all impediments (especially if they are contentious), any personal attacks need to be dealt with.
Examples of impediments which the team may come across are:
- Were there organisational impediments impacting the team?
Did someone steal a developer mid-sprint? Did stakeholder bypass the Product Owner and ask the Development Team to do something different? Is the Development Team not fully allocated to the Scrum Team? Was the Product Owner absent for the majority of the Sprint? Are stakeholders disruptive in the Scrum events (particularity the Daily Scrum)?
- Were there any backlog related impediments?
Were the User Stories or Acceptance Criteria not clear or detailed enough? Was the Product Owner not available to answer questions? Was there a lack of refined work?
- Were there any delivery related impediments?
Was the work underestimated? Did someone goof up on something (i.e. didn’t follow what the User Story was asking for)? Did the Sprint deliver actual customer value? Are the teams using their tools effectively (like burn-down charts)? Did the Development Team commit to the Sprint Goal? Were the team blocked by another team?
- Were there any skill set impediments?
Were the teams working with new technologies? Did the team have a new Dev who needed to be shown the ropes? Was there someone in the team who picked something up that was way out of their skill set but they gave it a go anyway? Is the Development Team full of inexperience individuals? Is there an underperforming Development Team member?
The above are just some examples I’ve come across as a Scrum Master. The important thing is to call out all issues, and if they happen to point to a person in the team, this must all be done in a non-confrontation/blame game way — an ideal way to do this, is through the 4 part non-violent communication process.
Inspection comes from the team inspecting the impediments (and also any good things which led to timely or faster delivery!) in the Sprint. Discussing the impediments identified by the team, to understand how they impacted the team and also how they manifested or what their root cause, is a way of inspecting what has been identified.
Adaptation comes from the team acting on the improvement plan taken into the next Sprint. After discussing what has been identified by the team, and understanding how these have manifested or what the root cause is, the team can then discuss improvements on how to avoid impediments and how to keep anything good which happened.
Improvements will usually result in changes to practices or processes or even changes to the Definition of Done. Actions which involve someone needing to do something should be taken into the Sprint Backlog as a high priority improvement.
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting
– The Scrum Guide
Why update the DoD in the Sprint Review? Well, you could have added a new environment, or plugged you code repositories into a new code quality analysis tool — these changes should want to make the Development Team update what “done” means when they say a User Story is “done”.
Taking a high priority improvement into the Sprint Backlog will ensure it gets done, without doing this; the Scrum Team could forget — action lists in tools (such as Confluence) usually get missed.
Sprint Retrospectives are also a bit of an experiment in disguise, the Scrum Master must prepare a Sprint Retrospective session which gets the best results. This could manifest itself in; trailing different limits on sticky notes, trailing different styles of Retrospective (e.g. moving away from the usual Sad/Mad/Glad style), and also trailing focused retrospectives (e.g. just focusing on the big issues the Scrum Master has identified).
Hopefully, you can see from the above how transparency of the team’s impediments and making an improvement plan are the keys to success.
That’s it for the third article of Mastering Empirical Process Control, I hope you found it useful. Please stay tuned for Part IV in this series: how empirical process control pillars are keys to success at your Daily Scrum event.