The Team Retrospective may be the most critical activity of an Agile or Scrum team. Building the habit of learning from retrospectives is an important skill. Especially as a strong influencer (whether as a manager, team lead or simply through force of personality), there is a delicate balance between directing the outcome and allowing the outcome to emerge from the team. Ideally the team will take ownership of the learning, drive identification and collation of issues and their root causes, and brainstorm, discuss and decide on best possible actions. However, many times we see the impact of strong personalities on a team leading the retrospective in a particular direction, looking to prove a point, get the next obvious bottleneck dealt with, or otherwise guide the team’s behavior through assumptions rather than building up the mental muscles of self-awareness and self-directed learning.
Retrospectives are a delicate time for a team, in which we ask them to trust one another, follow the prime directive of retrospectives (“Regardless of what we discover, we understand and accept that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”) and challenge the status quo. In order for the team to feel safe to do this we need to manage the environment with care.
Here, we touch a little on attributes of effective retrospectives. If your retrospectives are timely, targeted and without undue influence, the tendency to skip retrospectives, or direct the outcome of the retrospective is diminished.
Respect People’s Time
Respecting people’s time is a critical aspect of this – this has less to do with preparation, though preparation is important, and more to do with respectful use of the time the team takes out of their daily work. First, the retrospective (like any meeting) should start on time, be timeboxed, and reach a real, actionable conclusion on one or perhaps two key issues. Second, the decisions made during the retrospective should be acted on in the next sprint and when impediments extend beyond what the team can own themselves, impediments should be visible and given management attention. The highest priority should be given to following through with the changes suggested by the team and quickly addressing impediments raised.
Without this commitment to resolution, the team will soon see that the retrospective is not given the priority outside the team, and stop challenging the status quo and looking for genuine improvements. Recommendations become perfunctory – simple changes that have little impact on the real barriers to high performance – rather than challenging the current product delivery paradigm and stepping into the realm of true innovation and ownership of delivery outcomes.
Retrospectives on general improvement of the iteration soon reach an impasse. The team has made all the obvious changes they can and probably avoided the few critical changes they could make, assuming some things simply cannot change. At this point, the retrospective may lose impact without a change to the format of the retrospective process.
To revitalize the retrospectives, we can use different retrospective patterns, such as timeline retrospectives or sailboat retrospectives, for example (see How to Hold a Sailboat Retrospective). However, the simplest way to inject another level of energy into the retrospective is simply to provide intent by setting a clear question at the beginning around which to retrospect.
Most retrospectives revolve around an implicit (or sometimes explicit) question about how the most recent sprint can be improved. Framing an alternative question for the retrospective is a powerful way of guiding the team to discuss points of interest on the periphery of the sprint itself.
To be valuable, the intent should be clear to all, relevant and definitely not self-serving. These could be focussed on uncovering specific issues tangential to the success of the sprint itself (e.g. what would have to change for the team to deliver twice as many stories in the same amount of time?) or targeted on organizational issues being ignored by the team (e.g. how can we reduce or eliminate the wait for regulatory compliance sign-offs for new features?)
Beware of Implicit Influence
In many teams, key individuals may carry implicit authority and influence, whether through experience (e.g. the senior architect), longevity (e.g. employee #4) or previous or current position (e.g. the project manager turned scrum master). This means that one statement made by the team carries a different weight to the same statement made by a key influencer.
For example, if the team comes up with a statement like “the team should critically review the suitability of the existing software design for any new stories” this will be discussed in the context of the root cause being addressed, and whether or not this solution will cause the required behavior or outcomes. The same suggestion made by a key influencer, even in their role as a Scrum Master, Product Owner or Team Member, may be interpreted as prolonging the status quo, or defending a strongly held personal opinion by the team. This can cause the team to immediately abdicate responsibility both for the outcome (e.g. by not following through and committing to make the required changes in a timely fashion) and the resolution of the original impediment. The team as a whole loses.
In almost all cases, the most valuable behavior of any influential role model is to listen and perhaps ask clarifying questions. Any other observations or inputs can be made through the brainstorming and collation process, or through providing intent, as described above.
What other hints and tips do you recommend for maximizing the learning opportunity of a retrospective? Let us know…