At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
One of the core values of the Agile Manifesto is responding to change over following a plan. While responding to change clearly identifies changes to the scope of the software, it’s also important for agile teams to respond to changes in process, team composition, and workflow. In an effort to continuously improve your software, processes, and workflow, it’s important to regularly meet to reflect and adjust your behavior. This meeting is often referred to as a retrospective.
Retrospectives typically follow the cadence of your working periods. For example, if you’re working in two week sprints, you should have retrospectives every two weeks at the end of your sprints. At the end of a sprint, teams should look back and reflect on the work they did: what did they accomplish, what did they not accomplish, and how can they improve their methods.
You don’t want to keep making the same mistakes and causing the same issues you have in previous sprints. If you continue to run into issues with communication, documentation, or any number of other things, you’re going to keep running into blockers. By setting aside time to actually reflect on the work you did and how you did the work, retrospectives allow you to fix those issues moving forward.
However, there are some key elements that need to be considered when reflecting in order to get the most of your retrospectives.
1. Actually hold the retrospective
A lot of the time, the reason retrospectives don’t work is because teams aren’t actually meeting regularly to reflect and adjust their behavior. Yes, retrospectives take time, however, the time you spend discussing issues and determining steps to improve those problems will pay for itself in future working periods.
2. Create a safe space
Creating a safe space is integral for team members to feel comfortable sharing the facts and their feelings, yet it’s easier said than done. Team members must feel their team has active listeners and are open to adapting to the needs of the team. If even a single team member feels their voice isn’t being heard, the team chemistry, morale, and workflow will suffer.
3. Have a structure, but don’t have too much structure
An effective retrospective addresses a few key elements: what went well, what went poorly, and how can we improve. There are a lot of different formats for hosting a retrospective and starting these conversations (start-stop-continue, glad-sad-mad, green-yellow-red), but the key here is to leave enough space for the entire team to have an open, honest discussion about the work and workflow.
4. Come away with action items
Unless your team and the entire organization is working together flawlessly (if that’s true, call me), you will need to be making continuous improvements to your process. An effective retrospective should result in action items. You’re not going to be able to solve all your problems in one working period, so consider agreeing on one or two items you want to improve in the next working period. At the next retrospective, discuss those previous action items and if you’ve taken the necessary steps to improve those items. Then agree to your next improvements.
Don’t allow your retrospectives to become fruitless rituals where the team blabbers on about the same thing time and time again. This is the time to open up, great a healthy team dialogue, and set expectations improvement moving forward.
I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.
