The Value of a Retrospective

As part of using a Scrum Agile project framework, a concept called ceremonies are used to ensure that the Scrum team is working well together to complete their work. These ceremonies include Sprint Planning, a Daily Scrum, Sprint Review and a Sprint Retrospective. All of these sprint ceremonies work together to ensure that the development team are able to plan and understand their work, resolve issues as they arise and work efficiently to complete work in short Sprint work cycles. At AWH, we work in 2-week sprints to allow for changes in direction and Agile adjustments to the product development roadmap. In this blog I will talk about the importance and value of the Sprint Retrospective ceremony.

It may seem strange to address the Sprint Retrospective as one of the first ceremonies that we feel is important to the successful implementation of the Agile process, because it normally comes at the end of the sequence of the Sprint Ceremonies. However, it is the key element that leads to the continuous process improvements that makes the Scrum methodology so useful in Agile software development.    For clients and team members who have not used Scrum before, the retrospective, on the surface, seems like time being taken away from feature planning or development work to simply review what got completed. However, the Scrum Retrospective is much more valuable than a simple review of the work that was completed. It is a time to take a more mindful look at how the team is working together and to get the most productivity and job satisfaction from the team. 

Running a Retrospective

There are several keys to a good Sprint Retrospective:

1. Keep the meeting time boxed and progressing as needed. We timebox a retrospective to 1 hour for a 2 week sprint.
2. Make sure the meeting is “safe” for all members of the team. A retrospective is a time to be critical of process and performance so that issues can be continually improved. It is important that the team members can state their concerns without reprisal. Some conflict resolution may be necessary during retrospective meetings as the team learns to work together.
3. Make sure all the team members are present and participating. We include the Project Manager, Product Owner, Technical Team Lead, Business analyst, Developers, and Quality Assurance Team. 
4. Have team members be prepared with retrospective feedback when they come to the meeting.

What to answer in a Sprint Retrospective

There are three main topics that a Sprint Retrospective should address to create actions that will lead to the continuous improvement outcome we are looking for:

1. What went well in the sprint?    
2. What did not go well in the sprint
3. What can we do to improve next time?

While these may seem like simple and intuitive questions to answer, in practice, something that is viewed as an item that went well in a sprint for one team member may be viewed quite differently by another team member. Therefore, it is important to get as many of the issues and viewpoints aired as possible so the team can discuss them and determine specific actions to move forward.  

There are many ways and methods for conducting Sprint Retrospective meetings. It is common to have the Scrum Master act as recorder and mediator for the discussions. For some projects, the Scrum Master will act as the facilitator of the meeting, while in others the role of facilitator is moved around the team from sprint to sprint so that the meetings remain fresh and each facilitator brings their own flair to the team.    

At AWH, a sprint meeting is started with an overall review of the most recently completed sprint. Were the sprint goals laid out in sprint planning met? If not, why? Issues discussed are then identified and grouped into the “what went well”, “what did not go well” and “what to improve” categories.

Next, the team reviews action items from the previous retrospective. Were the actions defined effective in the current sprint? Are their further refinements we can make to improve?  

From there, we will involve each team member to introduce an issue from the sprint. The team member may have an idea of which category the issue falls into. but that is not necessary. The team can review the issue and determine which category to add it to. We tend to utilize different ways for the team to present their issues. Sometimes this means submitting anonymous issues prior to the meeting that can be read by the facilitator and then categorized by the team. Other teams are perfectly comfortable bringing up and discussing the issues in the open. Changing the format keeps the team thinking about improvements and prevents the meetings from becoming stale. Team members will continue to share issues until there are no more issues brought up or the time limit for the retrospective has been reached. 

Each issue is individually reviewed, discussed, and documented. The team discusses the issue, its impact on the project, and what actions may be necessary to continue improving the process. We also discuss what could be done to change or improve any processes that are not currently working.   

All AWH retrospectives are kept in a shared document repository (in our case, Confluence) so we can share them among other teams and to help with onboarding new development team members.  Actions are created from the discussions and added to the team’s process for the next and future sprints.

The Value

So, what value does the Sprint Retrospective bring for the cost of pulling the team off the development effort for an hour every two weeks? We see several positive outcomes that arise from Sprint Retrospectives:

1. Improved team communication and trust - through the retrospectives, the development team can learn each other’s personalities and capabilities. Communication between team members improves and blockers are resolved more quickly.
2. Sprint velocity improves - the team learns what work load they are capable of supporting during a sprint and therefore sprint planning generally improves as well.
3. Quality improves - the BA, development and QA teams work together to resolve misunderstandings and resolve technical debt before it turns into rework.
4. Company processes are reviewed and updated - new successful processes are realized and can be easily shared for other teams to adopt. AWH looks to continuously improve and we are constantly reviewing our processes to improve our client engagements. 

AWH also applies this process at the end of a project to review the overall success of the project.  The collective improvements and challenges of an engagement are brought together in an overview of the projects outcome and presented to the company’s Principals.  These project reviews, using the documented Sprint Retrospectives as well as team input, financial tracking, and overall client satisfaction, help drive AWH to make every project great.  

If you’re ready to start your project, contact us. We offer over 25 years of experience -from firmware development, to machine learning and artificial intelligence, we have the right developer team for the project.