“If you make a mistake and do not correct it, this is called a mistake.”Confucius
Today more than 30 years from the day the Agile Manifesto was created, there are thousands of successful and unsuccessful application cases for Lean & Agile Methodology, numerous hybrid solutions, and thousands of agile coaches and educational institutions. Some companies become Agile adepts, while others stick to traditional managerial doctrines. But there’s one thing everyone could agree upon – it’s impossible to progress in this world without learning from our mistakes. And that’s what a retrospective is for.
What is a Retrospective Meeting in General?
Making a retrospective means looking back at something. The most common description of the Agile Retrospective comes from Scrum Guide, “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness… The Sprint Retrospective concludes the Sprint.”
So in broad meaning, the retrospective is a repetitive event that takes place after every iteration of the software production cycle and is a means of analyzing the ups and downs of the development process, locating issues, resolving conflicts (if any), finding solutions, and implementing them in practice.
How Can Project Retrospective Meeting Help Boost the Development Process?
Knowing from hard-earned experience, a smooth release is as rare as a Stradivarius. If something can go wrong, it most likely will. We need to minimize the impact of unknown factors and thus keep the team’s stress levels below average. Project Managers (PMs) should constantly upgrade the development process to achieve this.
And that’s where a good retro could come in handy, allowing team members to:
- stop for a short while & look back at the gained experience, encapsulate it, own it, document it
- locate cause and effects, find what could be done better next time
- resolve the potential conflicts before they even get into the “boiling” stage
- appreciate right & well-timed decisions, thank colleagues for all the good things
- become closer and more open with each other
Despite all the above, you might still have an opinion in the developer community that a retrospective is just “bla-bla-bla.” In other words, a part of the routine, like time tracking, etc., that doesn’t bring a lot of value to the project requires an investment of time better spent on development. If that’s the case for your team, it may indicate that the retrospective process could use some improvement.
It depends on the Project Manager or (Scrum-master in SCRUM) to make a retrospective a meaningful activity worth the while for the team.
Spoiler alert: if well-organized, it can be fun!
How to Run a Retrospective Meeting: 5 must-haves
Every retro should have a measurable and achievable goal every team member knows before the event. It should be clear to everybody why this meeting serves our best interest.
Make sure there’s a friendly atmosphere. Remember, it’s not you against each other. It’s always you against the problem.
You must have a plan and all the required metrics and materials at hand. Think how you will bring everybody “on board”, loosen the tension, and help the team to open up and speak freely. Use icebreakers. Decide on the format, and plan activities based on the Goal.
4. Schedule & Rules
Fix a limited timeline and fit your meeting into it. Tell the team about the schedule, format, rules, and limitations. Make sure all team members know the “drill” and the time.
5. Application in Practice
The outcome of a good retro should be converted into action items and tasks with a time frame fixed in Confluence, Jira, Trello, etc. No need to pursue all issues at once. Even 1-2 fixed problems per iteration will do a lot of good to the process. A retro without practical implementation has little value and will discredit the whole concept quickly.
Top 5 Approaches to Retrospective
A generalized approach may be applied in most cases. It focuses on detecting positive/negative scenarios in the production process strong & weak points of the team. Maybe a good starting point:
2. Celebrate learning
A technique based on PMBOK’s lessons-learned approach that focuses on making the most out of mistakes and errors.
3. Wastes & bottlenecks
Here, the focus is on the procedures that either waste time & resources or maintain efficiency.
4. Health checks
This technique focuses mainly on the “vibe” within the team. It helps see whether there are any motivational, personal, or psychological struggles within the team that might affect productivity.
- Moving Motivators / Team Motivation Radar
- 5 Dysfunctions of the Team
- Spotify-Like Health Check
- Engagement Survey
5. Root Cause Analysis
This approach pays attention to the causes and effects. It helps the team get to the core of repetitive issues that are otherwise hard to uncover and remedy.
A well-performed retrospective is a powerful tool that will bring much good by optimizing the process, raising motivation, resolving conflicts, and getting the team together. It’s always worth investing 1,5 hours at the end of the iteration into letting team members tell their part of the story. Remember, it’s always you against the problem, not against one another. And if you keep the balance between having fun and actually learning from mistakes at the end of the day, it might upgrade your development process to a whole new level.
If you are looking for a way to turn retrospective into an efficient way to boost your development process – reach out to the IDAP team. We will advise you on the most suitable technique that will match your business purposes.