Gaining Value From Sprint Retrospectives
Avoid Just Ticking The Box
When you and your team have been sprinting for a while, you need to make sure that your Sprint Retrospectives remain a regular event and don't become just a tick-box activity that fail to deliver any real value.
The Continuous Improvement Ethos
Agile has always embraced the Continuous Improvement ethos and hopefully your team does too.
Remember the Twelve Principles of Agile Software development? Principle 12 states: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." (Strange how the Agile Manifesto itself hasn't been updated in years. Steve McConnell thinks 20 Years is Enough! Itβs Time to Update the Agile Principles and Values.)
The Scrum Guide says that the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness and therefore supports principle 12 as a recurring reminder to drive continuous improvement with each iteration.
Whilst the focus of the sprint is often primarily on the business value of the potentially shippable product increment under construction, teams must not forget to also focus on the delivery of strategic value through the achievement of continuous learning and improvement. (See previous blog articles: Two Customers and Building People, Then Products.)
Plan-Do-Check-Act
The Scrum ceremonies map well onto the "Plan-Do-Check-Act" lifecycle with the Sprint Retrospective being intended as the "Check-Act" part of that lifecycle.
Doing too little or too much checking without taking any actions will make retrospectives feel unproductive and fuel the "why bother to contribute when nothing ever gets done" attitude within your team.
However, taking on too many improvement actions at one time can also introduce too much change too soon, causing disarray within your team if things don't quite work out as anticipated.
Encouraging Full Team Participation
Invite the Product Owner and their colleagues. They may choose not to attend (and that's sometimes helpful π) but it demonstrates the spirit of transparency which helps to build trust and confidence with your customer. After all, any views your customer has about what needs to improve are extremely important so why would you fail to ask them? Sometimes it's the customer that needs to improve too.
You may need to coach some of your "quieter" people outside of retrospectives to remind them to bring up a specific item from a prior conversation during the retrospective and may even need to prompt them on the day. Hopefully it will boost their confidence going forwards as well as start a useful debate.
Recently, someone raised a great point right at the very last minute of the meeting. None-the-less it was greatly appreciated.
Keep It Fresh And Fun
Sprint retrospectives can easily become stale if you don't make an effort to keep them fresh, especially if the continuous improvement ethos is not alive and kicking in your team culture.
Retrospectives can often take the form of a team discussion to answer three questions:
- What went well?
- What didn't go so well?
- What or how can we improve?
Whilst these are helpful questions to drive useful conversations, using the same meeting format in the same location with the same people on each occasion can cause that "same old, same old" feeling to set in and take the edge off your good intentions.
It's helpful to vary the meeting format (and perhaps the person running the event) to keep things fresh and fun. There's nothing to stop you from communicating your intentions in advance so that the team can come prepared.
There are plenty of good books and websites discussing different approaches to retrospectives that you might want to try. (See Try One of These for example.)
Come Prepared
It's not enough for people to just turn up to a retrospective. People need to come prepared.
Many improvement opportunities are lost through lack of preparation. π
Relying on your memory usually isn't enough. I find that keeping notes throughout a sprint helps me remember what I observed and prepares me for the retrospective. Even the Sprint Review that precedes the retrospective can provide numerous feedback items and suggestions for improvements.
Preparation can be as simple as keeping a notepad on your desk (or a text file on your desktop) and simply jotting down notes as matters arise during the current sprint.
Before COVID-19, I sometimes stood at the doorway of the meeting room and wouldn't let people into the meeting until they could prove that they had done some kind of preparation. People soon got the message.
Come prepared to be challenged. Sometimes it can feel like a negative experience when the feedback isn't what you had hoped for or expected. Perhaps some complaints or criticisms were surfaced that will need to be addressed.
Beware Techniques That Discourage Full Team Involvement
Just because you invited everyone and they turned up is no guarantee that everyone will get involved and contribute!
Just like Planning Poker encourages everyone to estimate a story and disclose their estimate at the same time, make sure that you don't use an approach or tooling that allows others to see or agree with someone else's suggestions before submitting their own and that ultimately discourages full team participation.
Before COVID-19 forced remote working on our entire team, we would conduct our retrospectives in a large room with team members writing their comments on sticky notes and all posting on the wall at the same time. This approach encouraged everyone to participate and we were able to group duplicate items.
Switching to remote working and use of software tooling for capturing feedback, we saw the number of comments reducing and so had to re-consider our approach to boost participation.
Having a very large project team also reduced participation and so we opted to revert back to individual retrospectives per scrum team instead of using a combined project-level event with all our scrum teams.
Keep It Safe And Fair
People will contribute to the retrospective when they feel it is safe and when they are given the appropriate opportunity to do so.
Retrospectives should always be a safe place to discuss things with almost no topic off limit and with everyone having equal opportunity to voice their views, suggestions and/or concerns.
A "no names, no blame" culture should exist with the agreement that all feedback must be constructive.
Allow anonymous feedback if necessary but don't encourage this to be the norm.
Many improvement opportunities are also lost because of lack of involvement. π
Don't allow highly-vocal or overly-opinionated individuals to dominate the air time. Try to give everyone equal opportunity and time to contribute. By getting the whole team involved and contributing you'll be giving your team the best chance to surface all potential issues and suggestions.
Remember To Give Yourselves A Pat On The Back
Don't just see the challenges but also recognise your successes.
There are many benefits to positive affirmation so don't miss the opportunity to bolster team morale and point out the great work that's been done despite any challenges that the team faced. People love praise!
It's great to accolade people and highlight clear areas of improvement that have been achieved this sprint or that continue to improve from previous sprints.
Discussion Is Valuable But Time Is Limited
Sprint retrospectives are time-boxed and the duration typically equates to one hour per week of sprint (i.e. a two-week sprint has a two hour retrospective) but this time does not include preparation time.
Sometimes there will be a myriad of discussion points and simply not enough time to discuss everything. Whilst you might run out of time, it doesn't mean you have to drop everything and forget all the good discussion points that were raised. You should also avoid getting sidetracked by "low value" topics.
By taking note of the useful discussion points identified you can organise follow-up meetings to discuss some of them in more detail. (Lean Coffee meetings can be a useful way of achieving and prioritising that.)
Have A Strategic Roadmap
Lack of time is never a valid excuse for failing to improve.
Having a strategic roadmap can drive serious improvements over the longer term that may take several sprints to achieve. Recognise such opportunities and allow people to take ownership of them so that they can turn them into successful achievements.
Actions Speak Louder Than Words
To birth improvements means changing what you do and/or how you do it. (Strange how it takes some people longer than others to figure that out! π)
Sometimes there are so many suggested improvement actions that it's hard to decide exactly which to focus on and for this reason some teams restrict the choices by voting to decide the top three improvements to try out.
Some suggestions may also be more radical than others and really challenge the status quo. This can be innovation at its best or surface vocal confrontation from your resident change resistors! (Some people just don't like change. π)
Trialling different suggestions in different scrum teams can yield interesting results.
Breaking Chains / Killing Sacred Cows
As someone who has coached many Agile teams over the years, I've seen a whole range of reactions to suggested improvements: whether to ways of working, adoption of a new technique or switching tool choices and recognise that it can take a variety of approaches, and sometimes real people skills, to convince some people (or even a whole teams) to embrace change before breakthrough can happen.
Rome wasn't built in a day and I've seen many a change resistor eventually sing the praises of the very changes they once vehemently opposed. Sweet! π
As a result, my deep respect goes to those charismatic winners of hearts and minds knowing that disruption is only half of the battle! π
Record Everything
For an accurate record, don't dismiss anything out of hand but rather record all feedback, suggestions and agreed actions for posterity as well as the list of attendees.
Hold A Retrospective Of Retrospectives
Continuous improvement is an infinite loop. It never ends. It may even be recursive! ππ
Reflecting on your retrospectives over time will help you determine and improve their effectiveness and is therefore a valuable exercise that I would recommend doing from time to time.
I'd also recommend the Spotify technique I saw some years ago called "Definition Of Awesome" where teams agree what "awesome" would look like for them and then work out their next steps to march towards it. (This technique works well alongside a strategic roadmap.)
Both can help you prove (or disprove) that you are really making progress. Good luck with that!
Agile Health Check - Sprint Retrospective
Why not take the opportunity to give your Sprint Retrospectives an Agile health check?
#AgileHealthCheck
Healthy
|
---|
|
Unhealthy
|
|
Tim Simpson
14th January, 2022
#LifeAtCapgemini