How to conduct an effective retrospective in your Agile Team
In Agile environment, a retrospective is referred to a regular meeting at the end of each software development iteration aiming to review a workflow, identify issues and find solutions.
Why do Agile teams need retrospectives?
As a matter of fact, many business owners, especially those with a non-technical background, don’t understand why retrospectives are critical for effective teamwork on software projects. Why involve the whole team when top management can find a solution on their own? — that’s one of their most common concerns when it comes to a retrospective.
In any project, retrospectives have two key objectives:
1. To eliminate solutions imposed “from the top”
If you come to your team with a ready solution, you may fall prey to a phenomenon called “not invented here” (NIH) when false pride drives organizations to use less-than-perfect solutions instead of incorporating obviously superior and more effective ones. Even when your team members fully agree with this “imposed” solution, they will never feel committed to your project and its results because of sense of abandonment resulting from non-involvement in decision making. Your whole team should be given an opportunity to “chip in” with their ideas and proposed solutions. In this case, they’ll feel bonded and, what is more important, authoritative enough to influence managerial decisions. At the end of the day, you don’t hire software development professionals that cost a fortune to just let them execute, not lead the efforts, do you? Remember — solutions identified as a result of teamwork and brainstorming will always be more valuable for your team in terms of priority and execution than those “imposed from the top”!
2. To find an approach or solution that will work perfectly well in your particular case
Today’s software development is a very complex process and you’ll most likely not find a specialist who’ll be able to tell you how to solve this or that issue in a certain team without knowing its root causes and the development environment in particular. In order to troubleshoot you need to try different approaches, experiment and make assumptions about where these or those changes will lead.
As we know, there are best practices in everything. Now let’s take a look at such a practice as code review. While it can be very useful for some teams, it can be really useless for others no matter how hard they try. Without knowing the development context and DNA of each certain team top management won’t be able to identify methods that will be most effective for your project.
Retrospective goals and results
Any retrospective is based on the Deming Cycle model aka Plan-Do-Check-Act (PDCA). Each retrospective should be ending with a clear Action Plan which is not the plan of all final changes to be made during the next iteration, but rather is an experiment that will show you the most effective solution for your issue. It’s highly recommended that retrospectives follow PDCA.
As such, the major goal of retrospective is to create a plan of anticipated process experiments. However, many teams that call themselves Agile don’t understand it quite well. For instance, in many cases retrospectives are held to come up with a global issues resolution which is always condemned to fail. Teams are stuck behind their problem and can’t move forward. So, holding retrospectives for the sake of a global resolution is a common mistake of many Agile teams! Instead, they should make one step at a time, experiment and compare results. That’s what retrospectives are most needed for.
If your team treats retrospectives as just meetings to discuss the workflow and processes and find ways to improve them, be prepared to come to a standstill with your work progress! Such retrospectives will never help you reach your goal and create a change plan.
A retrospective lead (e.g. a SCRUM Master) should be able to bring a team to a certain plan and get their buy-in for implementing it. In a real world, it means a list of actions to take and agreements within the team everyone has to adhere to going forward. Actions refer to concrete tasks and people responsible for completing them. If a task is assigned to someone who’s absent at a retrospective, the lead should find a team member that’ll be responsible for explaining the task to the absentee and overseeing its progress. As a result, each team member should be responsible for each action.
In its broad meaning a retrospective aims to understand the current team environment and main issues and find ways to overcome challenges. It does contain a lot of psycho-therapeutical elements. It usually starts with a question “So what’re the issues you’re facing right now?”
Besides the general retrospective, there’re other types such as:
- Quality evaluation retrospective
- Problems evaluation retrospective
- Specific issue evaluation retrospective
Quality evaluation retrospective deals with discussion of product quality issues such as defects, bugs and errors. All of the flaws are discussed, analyzed and presented as a root cause diagram.
Problems evaluation retrospective deals with problems arising on a customer or product owner’s side, while specific issue evaluation retrospective delves into the roots of only one specific problem and how it can be resolved.
Each time a team says it works well, doesn’t have any serious issues, has processes and workflows put in place and all team members get along well with each other — be prepared for a dysfunctional retrospective. It’s a very rare case that a software development team can work without issues or force majors.
To shift your team from this viewpoint and drive it forward, it’s recommended to invite someone on stakeholder’s side (a customer or users) that know for sure there’re some issues indeed. No need to say that customers are rarely fully satisfied with provided services and will always find what to nag at. If such a stakeholder comes to your retro and tells your team what could’ve been done better, team members usually feel motivated to move forward and improve things (believe my 10+ years of experience working in IT companies!).
Another type of a dysfunctional retrospective is when you have just one or a few team members participating in discussions. Team lead should never dominate, but moderate and facilitate during retrospectives. It’s important to have every single team member share own opinion about the issue and how it should be resolved! The more people are open to express their ideas, the higher the chance you’ll find a good solution at the end.
If you, as a retrospective lead, feel someone is too self-reserved to express own opinions, have them write them down on stickers put up to the SCRUM board. They can do it anonymously.
While Agile literature describes different retrospective formats including some very sophisticated ones, the company I work for uses a simple yet effective way. Instead of setting rigorous timing and consequence of actions, we split the whiteboard into 4 areas and fill them in as we go with retrospective:
- Pluses: what went well in the previous iteration?
- Minuses: what issues did we face in the previous iteration?
- Ideas: what new ideas have we got during this retrospective?
- Plan: what changes should we make in the next iteration?
Because the main goal of retrospective is to create a change plan, all interim stages should help reach this goal. At first, we let each team member speak about pluses and minuses of the previous iteration. These pluses and minuses don’t come out of the blue; they’re in fact based on the change plan created in the past retrospectives.
As a rule, new ideas appear when discussing minuses of the previous iteration. Retrospective facilitator or SCRUM Master should make sure discussions don’t become blame-shifting. Forget the question “Whose fault is it?” and focus on “What should we do with it now?”
You can discuss as many ideas as possible, but add to your plan only those that all team members agree with.
Having figured out all pluses, minuses and ideas, the team can move to the plan creation stage. The plan includes concrete actions such as Execute, Discuss, Create, Review or concrete rules (e.g. task A should be executed using approach B). Don’t try to embrace everything in one plan — for effective teamwork in the next iteration a 3–5 point plan would suffice. An extended plan has a low fulfillment potential and can discourage your team.
Wrapping up, retrospectives may have different formats, but what is really important is that they’re held regularly at the end of each iteration and result in a shared goal, i.e. action plan for the next iteration. Make it informal and enjoyable for your team and be sure — if held regularly, retrospectives will provide you with a clear roadmap of how to move further in your software development project. The least they can do is to help you set up a truly self-managed team!
And how do you hold retros within your team?