This blog post was originally published on the Scrum Alliance website on 8th March 2016.
The Scrum Guide states, “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.” There are a number of resources available (books and websites) that provide a variety of ideas for different styles of retrospectives that can focus on different areas for improvement.
On joining Sky Betting and Gaming, I had the opportunity to use and adapt a number of different styles of retrospectives with my teams. I have always tried to include an element of fun within the retrospective to ensure that everyone is engaged with the process and that it is not seen as “just another meeting.” This has included, but was not limited to, running the Lego Flow Game (to elicit ideas on how we can improve our processes), playing retrospective Jenga in the pub, and drawing pictures.
One of the key abilities my team had is the autonomy to inspect and adapt its processes in order to strive for continual improvement. However, we held a retrospective only once a month, which imposes a perceived limit on making improvement suggestions. We struggled particularly with goal setting.
My team worked within a Scrumban environment, that is, we continuously deliver work using Kanban but also use some Scrum events, such as daily stand-ups, retrospectives, and demonstrations/showcases. The team previously set weekly goals that aligned with the delivery health/metric reporting cadence, but they were often not achieved or were too focused on a specific card, ticket, or user story reaching a particular state and therefore provided little or no value. As ScrumMaster, my aim was to work with the team to highlight the need for SMART (specific, measurable, achievable, realistic, and time-bound) goals in order to help keep the team focused on delivering value for the next area of the project that was being developed. How could I do this?
After reading an Scrum Alliance member article on “Bowling and Scrum,” a seed was planted in my head as to whether it would be possible to create a 10-pin bowling retrospective. This builds on the idea that there is an overall or long-term aim when bowling — to achieve a score as close to 300 as possible — as well as a short-term goal in each frame — to get a strike, a spare, or knock down as many pins as possible. Throughout the game, the bowler will inspect and adapt different elements of their starting position, approach, and where they are aiming in order to try and achieve the goal. Would it likewise be possible to get my team to apply these principles during a fun exercise, before applying them in our work environment?
Luckily, I had some bowling knowledge in my back pocket, having bowled for my county (Essex) during my youth and as a qualified British Tenpin Bowling Association Phase I instructor. Using these skills, I created a sheet for my team to fill in during a game of bowling.
The overall objective of the retrospective was to accomplish the following:
- Identify where it might be possible to increase the inspect-and-adapt cadence
- Improve goal setting — how setting short-term (closer) goals can help achieve long-term aims.
So how should you run the retrospective to achieve these objectives?
- Split the group into teams (depending up numbers)
- Assign each person a goal of getting the highest score possible out of 300
- In the first game, have each participant record details of the start position, the target that they’re aiming for (which arrow), whether they hit the target, and which pins were knocked down
- In each frame, have everyone inspect and adapt (using the information they have recorded) to try and improve their score or number of pins knocked down, i.e. move left/right/forward/backward or the arrow that is being aimed for
- In the second game, have the team bowl as they wish (no recording of inspection and adaptation is necessary – remember, this should be a fun exercise).
The goal is that by inspecting and adapting, their score in the second game is better than the first (this is an opportunity for prizes for the most improved bowler, highest score, highest aggregate score, and/or wooden spoon).
How is the session validated?
- After bowling, have the team sit together to discuss how to improve the inspect-and-adapt process between retrospectives and how to improve the goal setting
- Over time, review the goals that are being set. Are they becoming SMARTer?
- Is the number of goals achieved increasing?
- Keep a record of the changes implemented for process improvements, and monitor the impact that they have on any metrics that are gathered or monitored.
So, how did my session run? After explaining what people needed to do, providing them with a sheet to complete and ordering drinks, my team got down to bowling and started recording data.
When the team had finished bowling, we retired to the bar to discuss the outcomes from the session and award the prizes. The team recognised and accepted that they had the opportunity to raise ideas for process improvements at any time and that there was no need to wait until the next retrospective or team meeting. Any suggestions could be discussed, which could lead to experimentation of our processes. These experiments could then be validated to ensure that they had the desired effect and did not cause disruption to other parts of the system.
We agreed that any goals set should focus on work in progress, with the time-bound element of the SMART goal being approximately two to four weeks away. Anything shorter could be impacted by urgent or priority business-as-usual work. Anything longer contained uncertainty as to whether it could be achieved.
So, did we improve? The proof has yet to be realised, because we have only just run the session. However, I am extremely hopeful. My team has agreed with the theory behind the activity, and they are always looking for ways to improve.
If you run a 10-pin bowling retrospective, it would be great to hear how you get on.