Inasmuch as doing the work is critical to success, in itself it is not a means to an end. After all, if the work keeps being done in ways it has always been done, these ways will soon be outdated. How many companies out there are presently looking at their processes and realizing that a complete revamp needs to be undertook to improve them? Tons.
Same stands for teams, whose primary goal is to deliver value by applying cross-functional skills and utilizing the tools that the organization provides. Teams perform all the work necessary to deliver that value, with the end result being the product or service which the client so desires. The process of delivery ranges from a week to multiple years, depending on the Delivery Framework that the team applies, and the risk that the ways work is done and communications are performed can get skewed over time increases proportionate with the project duration. The impact of this, if unaddressed timely, can be quite negative: from broken down communications, to dysfunctional teams, to poorly designed solutions, to even project failures in some extreme situations.
The importance of a retrospective cannot be under-estimated. Seemingly small and insignificant, retrospectives can (and will, if done correctly) make a huge positive impact to any and all aspects of project and product management. There seem to be logical points when a retrospective is due – which are normally marked by end of a logical phase within a project, such as a Sprint, a Phase, a Milestone, a Gate, and so on – but really, retrospectives can (and should) be held whenever a situation calls for one.
Retrospectives are (normally) short meetings that serve as a forum for the team to reflect on how it has been doing, and how it can improve. Agile Frameworks, such as SCRUM, do a great job in reinforcing the need for retrospective by incorporating them into their standard sets of meetings that have a predictable repetition cycle resulting in a constant feedback loop for the team to learn, reflect and improve.
Though Scrum Masters are free to design and deliver their retrospectives in ways they see fit, sometimes (and quite often) fit with interactive games specifically designed to engage teams in activities aimed at improving, there is a set of commonly accepted Best Practices regarding structure and content of a retrospective that should be kept in mind. The main goal of a retrospective is to help the team determine, based on their latest increment, what it is that they have been doing well and need to continue doing, what it is that they have done poorly and need to stop doing, and what it is they need to start doing to become more efficient, more collaborative, more productive, more transparent, etc. With these goals in mind, it is the Scrum Master’s job to drive the retrospective in the right direction so that it results in a common understanding (and agreement) of ways that the team will undertake to improve.
To be effective, retrospectives should follow a set of certain best practices that I have listed below which are commonly accepted as powerful enough to drive the purpose out of these meetings, have the team engaged and ensure the buy-in.
- Make the retrospectives as engaging as possible by involving the team in the identification of items to keep, trash or improve.
- Use brainstorming techniques to help team open up and suggest ideas.
- Avoid arguing and finger pointing at all costs. All teams make mistakes, and teams need to be educated on acting as one without blaming one another. Trust needs to thrive in teams.
- Use visual tools to help in facilitation and discussions. Sticky notes are great visualization and collaboration tools that can help these meetings flow.
- Give the team time to reflect. After explaining the game, some 5 minutes should be allocated to allow each person on the team to quietly think of the items to present for discussion. The thinking process of each team member should reflect their personal thoughts and not be influenced by other team members. A great idea is to have each team member hold their own sticky notes with ideas to themselves until everyone is ready to put them on the board.
- Provide guidance on the level of participation by taming down the most vocal team members and helping the most timid ones come out and speak up.
- A great set of reflective questions that can (and should) be asked in retrospectives aim at finding out the following aspects of the previous increment:
What went well?
What didn’t go well?
What have I learned?
What I am still puzzled by?
- When all items have been placed on the board, use the Affinity Chart technique to group them into logically connected items and find common ground between the items placed by different people. Many stickies with similar items indicate a potential for improvement that cannot be ignored.
- Have the group decide on the course of action for the improvement opportunities just identified by asking them what can be done to make this better. Team will voice their ideas by placing sticky notes of a different color on the board under the improvement opportunity under discussion, and if there is a disagreement that can be sensed, use voting and negotiation techniques to get to consensus.
- Assign Improvement Owners and create an “Improvement Board” for tracking improvement initiatives during the next increment. This can be as simple as a 3-column Kanban board with “To Do”, “In Progress” and “Done” titles.
- During the next retrospective, review the progress of improvements identified in the previous retrospective. Ask what stood in the way of implementing an improvement that did not realize.
It is only through continuous improvement that teams achieve excellence. Stagnation is an enemy of progress, and as teams we need to be proactive in the ways we work to deliver value. Our ability to look at how we work, identify week spots, eliminate what does not work and institutionalize what will make us better is critical to not only our success as a team, but also to the success of the organization in which we operate.
In my other posts, I will be sharing some great ideas for retrospective games that can be aimed at various situations that may need to be addressed. As Scrum Masters, we always have our eye on where we can do more coaching, educating, helping, and improving, and it is our job to bring improvement opportunities to our team’s attention and help them strive as high performing self-organizing teams.