In today´s post, I want to talk about the Agile Retrospective format. I met several Scrum Masters and Agile Coaches that facilitate Agile Retrospectives without knowing this concept. In my opinion, a successful Agile Retrospective must follow somehow this structure.
This concept was introduced some years ago by Esther Derby and Diana Larsen, in their book “Agile Retrospectives.
They explained to us that there are five different phases of an Agile Retrospective and this is what I want to explain to you in this post.
When holding a retrospective, a direction is essential to a successful session. Ergo, always start with an introductory period that focuses on the retrospective: setting the stage and the atmosphere for the rest of the discussion.
Foremost, if you want people to be engaged and willing to work with you, it's a good idea to take a moment to thank them for investing their time in the retrospective, as doing so will make them feel like valued contributors. Having done so, make the purpose of the retrospective clear, and outline the goal for the session. You should also give a timeframe for the session.
After the basics have been laid out, it's imperative to have everyone in the room speak up; it only needs to be brief (a word or two from each person describing what he or she hopes to get out of the retrospective), but it's important to break the ice in this manner.
It will go a long way toward helping those present to overcome any nerves, and communicate more readily: thereby facilitating group-think and effective learning.
Once everyone has made their verbal contribution, outline the approach for the session— this will maintain momentum and a sense of direction. Most people automatically “tune out” mentally when they feel they are about to be subjected to an aimless, dull meeting- so keeping a sense of pace is integral to a productive group session.
Once the framework for the retrospective is in place, work on making people feel comfortable with the idea of discussing difficult, challenging topics. Set parameters for acceptable behaviour (e.g. team values and working agreements) so that people know how to talk about difficult or emotional issues, and deliver news that may not be welcomed by the team.
If the team already has a set of team values, it's a good idea to keep the values of the retrospective consistent with these, insofar as is possible. Think of how existing team values can be adapted to the retrospective, and be prepared to answer questions from team members regarding how these values can be applied.
Likewise, post the existing working agreement (if there is one) and adjust it as needed so that it effectively applies to the retrospective (for example, if the usual working agreement asks that code be ready by a certain juncture, adapt it to require that every team have their work ready to present to those attending the retrospective).
If there is no working agreement, draw one up before the retrospective goes any further. Generally, these should have fewer than five tenets—any more than this is too complicated to be practical—and should make everyone in the session accountable for his or her behaviour, so as to foster civility and collaboration.
While it's true that doing this mid-session risks losing some of the inertia momentum you have been working to build, think of it as an investment; for the ten or fifteen minutes you spend on the working agreement, you get something you can use not only throughout future retrospectives but in daily working life as well. (Note that this exercise also often reveals what people are worried about, which is valuable information regarding what needs to be addressed).
The introductory session, when done right (and when values and working agreements already exist), may take as little as five minutes to complete. That being said, it remains valuable, and should not be skipped even as retrospective leaders and teams become more experienced. No matter how familiar people are with the proceedings, after all, failing to ensure that everyone speaks up early in the session may allow some team members to stay silent throughout, which impacts the overall quality of the retrospective.
Likewise, without there being a clear group approach, people may insert their own feelings and agendas into the retrospective, in turn derailing the session. If they do so, what will the interactions devolve into in the absence of working agreements and team values being firmly set in place? Prevention, as they say, is worth a pound of cure.
Iterations, while often brief, are packed with important events and interactions; as such, it's highly recommended that data is gathered throughout (the shorter the iteration is, the more important this actually becomes—consider the fact that if a team member misses one day in a week-long iteration, he or she will have missed 20% of it).
Likewise, when so much information is packed into a short period, team members often cannot catch everything that is going on around them, or may leap to hurried conclusions, and thus have conflicting ideas about the same events. Data, in such instances, is needed to create a clear shared picture of what has occurred.
Data should cover events (this can be anything suitably meaningful to the team, such as meetings, decision points, changes in team membership, milestones, celebrations, and implementing new technologies), metrics (burn-down charts, velocity, defect counts, etc.), and any features or stories the team has completed. Calendars, documents, charts, and so on should be used by the team to further enhance this data.
Data should be reported during retrospectives using a mix of verbal reporting and visual aids such as task boards and charts; if you're going far back in time, a timeline will also be useful. Without well-planned visual aids, people often cannot detect relevant patterns and make other connections effectively.
Remember, too, that the content should not be completely “dry” in nature; feelings are also important to stories and reveal to team leaders what the members of the team were most concerned about during the iteration. If one does not allow an emotional component (and structure it properly) during retrospectives, these worries often slowly eat away at team members, undermining morale and productivity.
Close the ‘Data Gathering’ stage with a quick review of all available data, inviting everyone on the team to look through it and comment on any patterns or changes that they see. This allows everyone attending the retrospective to develop a group perspective on the data before proceeding, thus reducing the likelihood of conflict (as people will not be viewing the data from a narrow, individual perspective).
Data is useless without interpretation and insight; as such, every retrospective should contain a stage where people ask candid questions, where they point out what they see going wrong—and going right—and ask, “Why?”
As part of doing so, one should examine the various situations that arose in the prior iteration, breaking down the interactions that occurred within them and looking for patterns of either functionality or dysfunctionality. The team should assess risks and factor in unexpected events and outcomes.
This should take the form of a measured, logical approach; remember that people tend to leap to any and all available solutions once a problem is presented, and the first solution posited is often not the best one. During the insight-generating stage, all possibilities should be considered, along with their ramifications, and the group should be encouraged to do so analytically and to do so together.
Not only will this lead to better solutions, it will help the team learn to work together better, through exercising the overall group dynamic in an environment where free thought is encouraged. (Likewise, this kind of experimentation encourages “big picture” thinking).
The insight-generation stage is crucial as it allows the team to see how both circumstance and their own actions and behaviours affect their ability to develop software. Without this stage, there can be no establishing of cause and effect.
Once the team has agreed on a handful of the best possible solutions, they need to settle on just one or two of them to utilise in the coming iteration and decide on how best to do so. The team leader must once again provide direction, in the form of structure and guidance, while the team plans the coming experiments and actions.
He or she needs to judge the overall mood of the team; are they ready to handle something complex? Or are they recovering from a stressful event and need to step back and work on something simple?
The Decision Stage should involve the use of story cards or backlog items during the planning process, as this will make it easier to implement improvement plans during the actual work that will occur in the next iteration.
Remember that the retrospective should segue naturally into iteration planning, so try to hold retrospectives just prior to that period (having the retrospective in the morning and iteration planning in the afternoon is ideal).
As a final note, while retrospectives revolve greatly around group-think, do ensure that by the Decision Stage, people have committed to the upcoming tasks individually as well. People need a clear sense of their individual duties—otherwise they tend to assume the group as a whole or someone else in the group, is responsible for the tasks at hand.
Try to close retrospectives in a proactive, inspiring, motivating way—the team will need this sense of momentum to take into the coming iteration. People should walk away with a clear idea of what needs to be done, how it will be documented, and what the follow-up will be.
The team should also leave with a host of reminders that will help them remember what they have learned during the retrospective; otherwise, at least some of it will slip away.
Illustrate new practices with posters or with large, visible charts and make sure the team records their progress on these. The whiteboard used during the retrospective should be printed or scanned.
Finally, take a few minutes, to sum up the retrospective itself and request feedback on what went well during it, and what needs to be done better next time. It's not only our iterations that need improvement, after all—the whole teamwork ecosystem benefits from frequent reflection and maintenance.
If you are interested in getting some extra Agile Retrospectives exercises, I created a blog post with dozens of Agile Retrospectives Ideas, check them and see if you find something interesting.
[shortcake_call2action title="ORGANISATIONAL MASTERY SCORECARD" description="We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery." button_text="Take The Test" button_link="https://www.organisationalmastery.com/scorecard?utm_source=web&utm_medium=Blog - From Luis Goncalves&utm_campaign=Agile Retrospective Format" /]
If you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.