This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
Have you ever reflected on past memories, analyzing key events and asking yourself: if I had the chance to go back in time, would I have done something differently? Would I have achieved a different outcome had I done so? Can I use what happened in the past to shape my future and grow from my experience? I am sure most people have at some point in their lives, with varying degrees of frequency. This ritual of examining the past in order to change the future is a retrospective. Yet, a retrospective is not something that we want to be simply an internal exercise of the mind; rather, we can formally apply this concept to our working lives to benefit our teams and to grow incrementally over time as an Agile retrospective.
In business, a retrospective is a key element of Agile delivery and Agile project management. It is a formal meeting held at the conclusion of each iteration of Agile development. The purpose of the Agile retrospective is to reflect on what occurred during the previous iteration, or sprint, and to propose and implement corrective and preventative actions for the betterment of the team over time.
Improve Productivity
Use root cause analysis to isolate problems and to avoid them, taking short terms steps for long-term improvements. For example, a team could have an issue with legacy code causing a large number of defects and rework during the testing of a particular sprint. As a result of the retrospective, the team can plan on adjusting, improving, or implementing different unit tests in order to eliminate this roadblock. Short-term investment would yield great improvements in the long run.
Skill Development
Retrospectives are the perfect opportunity to identify gaps in skills, address them, and to reduce single points of failure with a team or organization. Many teams have a resource with expertise in a specific domain. When that person is unavailable, we acknowledge the blocker but spin cycles trying to fix it on the spot or simply avoid the issue. Building on the example above, by identifying an individual with knowledge over legacy code, you can dedicate part of the next sprint for knowledge transfer, thereby building the skills of the team collectively.
Improve Morale
Retrospectives give a voice to the development teams, empowering them to share their experiences, as a collective, owning not only the content of the agenda but also the actions taken as a result of the meeting. The meeting serves as a purpose to voice frustrations (often leading to positive root cause analysis-based outcomes) and also to celebrate achievements and recognize the efforts of others, thereby bringing the team closer as a unit.
Improve Quality
By looking back through the sprint, development teams can examine and improve the quality of work. I have seen retrospectives be used to plan how user stories are structured as to avoid missing subtle requirements and doing rework. Retrospectives can also lead to formal changes to processes as well. After a bad commit, for example, a team may look at how they are conducting peer reviews or structuring unit or performance testing.
Increased Value
At the end of the day, the team is only as valuable as perceived by the client. By improving gradually over time, the client will reap the benefits in the form of improved feature sets delivered faster and of the highest quality. Agile retrospectives can help ensure that the client is engaged at the appropriate time to ensure their expectations are being met.
Below is a high-level process flow I put together to walk through the retrospective process, capturing key activities conducted by the four major resource types, Release Manager/SCRUM Master, The Development Team, Product Owner/Functional Manager, and, of course, the client.
The retrospective process begins immediately upon the completion of the current sprint, which typically culminates in the deployment of a release. As the individual conducting the retrospective, I would want to gather feedback from the team according to our team ground rules. This information is confidential and voluntary. It helps me to facilitate the formal retrospective discussion. I also try and solicit feedback from the client as well in parallel. Their insight is useful for future improvements but also direct positive feedback. Finally, I make sure to put together all reports agreed upon by the team. Such reports may include velocity charts, burn down charts, defect reports, and other KPIs. These artifacts again may help to guide the discussion with the team. Although the meeting is for the development team, as the facilitator I also gain an inherent value by listening. In the future understanding the lessons learned will help with sprint planning and developing more accurate analogous estimates.
Setting the retrospective meeting requires full participation as it is a required event. The length of the retrospective will vary depending on the iteration length, frequency of releases, and size and composition of the team. In the past, depending on the need, they have averaged about 1-2 hours. Every meeting also must have a clearly defined agenda. Esther Derby and Diana Larsen in Agile Retrospective provide a solid structure for the retrospectives(1):
The above is simply a basic guide on how to conduct a sprint retrospective, not a gospel. The facilitator has the very difficult responsibility of driving the meeting. By planning the retrospective, time boxing the activities, and establishing sound, agreed upon rules, they increase the likelihood of having realistic and tangible outcomes upon which to improve. The reason why I prefer to gather information up front really comes into play here. In addition to guiding the conversation, I am able to learn who has the most to say in any particular sprint and am able to ensure that all voices are heard. Every team member has something to add to the forum.
Gathering the information is perhaps the most difficult aspect of the retrospective. There are a number of methods for information gathering, ranging from the 4Ls model to value stream mapping. Luis Goncalves and Ben Linders put together a fairly comprehensive list of methods in their toolbox, Getting Value out of Agile Retrospectives for further reading on this subject(2). Personally, I like to start with selective questions or the 4Ls model to get the conversation started, supplementing the conversation with reports and metrics along the way. Once we have developed several key themes, I like to have the team prioritize focus areas, ultimately getting to the point where we can associate whys with actual outcomes, both positively and negatively.
By driving each topic down to a why, the team is able to work together to conduct a root cause analysis. I find this to be the most effective method of taking ideas and turning them into tangible action items. While not always essential, I like to have the manager or product owner at these sessions to listen in on the team. If the manager owns the product direction and interactions with the client, they are able to prioritize future sprint accordingly. The worst thing that can happen is for the product owner to consistently push new features and have the same issues occur sprint after sprint. It is their responsibility to work and communicate with the client as to why certain changes are needed and how they will benefit from them.
Investments to improvements in each sprint will benefit the client much more than a short-sighted view. Failure to do so will result in the alienation of the team and stagnant maturity growth. By properly planning for and conducting Agile retrospectives, your organization will be set up for long-term, sustainable improvement over time.
1.) Derby, Esther, and Deena Larsen. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2012.
2.) Gonçalves Luís, and Ben Linders. Getting Value Out of Agile Retrospectives: A Toolbox of Retrospective Exercises. Lulu.com, 2014.