Tackling Retrospective Regression
Taking time to reflect is important. In this chaotic world we need to deliberate more in order to grow. Humans are generally pessimistic creatures. We tend to focus less on our achievements than our failures when recalling past events. Through 20:20 hindsight we can identify our mistakes and the exact set of steps we would enact to undo our wrongs. The Undoing Project by Michael Lewis covers this condition far better than I ever could.
Retrospectives shine a mirror on how we build software. Their aim is to provide an opportunity to dwell upon the collective successes and failures of the team, and use that hindsight to improve. The initial euphoria is great, but over time the shine begins to dull. Here I ponder some emerging bad habits that can develop over time, and how you can polish that retro mirror to return it to its shining former glory.
One of the cardinal sins of agility is not having retrospectives at all. This is a symptom of novice and experienced Agile teams alike. All the reasons I’ve encountered to date are not by any means intentional or malicious. It may be tempting to start with just a stand up and build up to retrospectives. However, you’ll miss the opportunity to routinely assess progress.
Once you are having frequent retrospectives, it is paramount to learn the warning signs to preserve the most important of ceremonies. Where the regular meeting invite lies on the team calendar is vital to preserving the voice of the team. Scheduling at the exact same time as a stand up may seem like a smart solution to address context switching. Regardless, you run the risk of focusing on your stand up, and forgetting the retrospective.
Consider the humble ATM, or Cash Machine if you’re so inclined. I recall an anecdote from my university HCI class on why your card is released before the cash. The lecturer in question gave an amusing tale pertaining to treasure seekers taking their money and leaving their card in the machine. To reduce fraud, the order was altered since the key aim of the transaction is to obtain those crisp notes.
Regardless of whether this fable is an urban legend or not, the moral is clear. With a double booking, you run the risk of confusing the true goal. Once the stand up is complete, you are relying on the team to remember a more infrequent ceremony. Dedicate a reoccurring entry to your retrospective, regardless of your Agile paradigm of choice. Maintaining this slot is critical to ensuring that the meeting always occurs. Not honouring that habitual entry removes your teams voice and breeds discontent. So hold it at a different time, preferably at a time where they can get comfortable with a cup of tea and contemplate recent events before the retrospective starts.
Sometimes people need a change of scene. Routine can be great, but it becomes repetitive after a while. While there are many particular formats a retrospective can take to elicit feedback, over time a routine can render them less effective.
Every team has their preferences. A retrospective format can develop into a familiar security blanket. If your team is using the same questions every few weeks, it will enforce a particular frame of mind when attempting to identify improvements and celebrate successes. Consider evolving your plan to get your team thinking differently. True, some may be more effective than others. Nevertheless, failing fast works for retrospectives too!
Thinking Out Loud
Fostering diversity within teams is imperative for many reasons. Differing experiences, backgrounds, opinions and personalities help us build strong teams that will bring innovations to the software we write. Much research has been performed on software team cohesion and the personalities that are drawn to software engineering.
Be mindful of how contrasting personalities engage in retrospectives to empower team members to speak. Balancing introverts and extroverts is particularly challenging. Care must be taken to avoid louder voices being prioritised. In troublesome times this may breed discontent among quieter individuals.
Colleagues with perception and feeling characteristics, as classified under the Myers-Briggs Type Indicator, make for great cohesive agents. They can prevent extroverts from dominating the session. Asking probing questions to introverts directly can help bring them out of their shell. Picking on the quiet ones may seem unfair initially , but it will make for a more balanced viewpoint. However, this does not mean that open questions should not be asked of all team members, regardless of personality, to extract more detail.
Reaction to Action
Regular reflection on our progress is vital to refine our development practices. Good retrospective facilitators will help extract possible process improvements. They are essential to thwart attempts to turn your retrospective into a rabble. Actions speak louder than words after all.
Once these activities have been identified, they can’t just be forgotten. We need to follow through with such suggestions and measure their effectiveness. Logging these ideas and assigning owners is imperative to ensuring their execution. One possible enhancement for us is assigning these items as part of our normal work. Only then will we be able to see the ripple effect of any pebbles we skim across the water.
Thanks for reading!