December - 12th agile principle
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
All the other agile principles revolve around change management. They teach you how to embrace change and how to adapt work processes to a constantly changing environment. The 12th principle takes this to a meta-level and tells the team how to change itself. The assumption is of course that things aren’t perfect and that there is potential for improvement. And indeed, there are always better ways of doing business. The evolutionary approach to software development is applied to the team’s way of getting things done. Obviously, this is consistent with the principles of self-organisation (11) and trust-based team spirit (5). In theory, team reflection and action planning occurs at regular intervals. In practice, reflection happens anytime in meetings or in informal communication between team members and is channeled through a specific “ritual”.
This ritual is known as the retrospective meeting in agile project management. Kanban teams typically hold such meetings on demand. With Scrum being a more rigid framework, it is common that retrospective meetings are scheduled at regular times, most commonly towards the end of an iteration. So, if the Sprint iteration is 2 weeks, the retrospective meeting would be scheduled for the end of the 2nd week. Issues and topics would be collected during the entire Sprint to form its agenda, or members would gauge Sprint outcomes in an impromptu fashion. There are different recipes for conducting such a meeting. However, they all revolve around four basic questions of which there are a number of different phrasings. My favourites, because I like simplicity, are the four whats:
- What went well?
- What went wrong?
- What have we learned?
- What didn’t we learn yet?
Obviously, there is a symmetry as questions two and four are the negatives of one and three. This is intended. The idea is to establish a consensus on the positives and a common understanding of the negatives. Experiences of team members do vary throughout iterations, so the retrospective meeting offers the opportunity for calibrating one’s own experience. To accomplish this, it is not uncommon that each member gives a briefing of their subjective experience before other questions are addressed. Of course, the above four questions are targeted at identifying potential for change and improvement. The whole idea of the retrospective is, to find out how the team can perform better and how the added value can be increased. To that end, all members contribute their points of view about negatives and positives. Agreement about these points signals strong potential for improvement.
The prerequisite for instigating progress is, of course, that decisions about relevant measures are being made and carried out. This decision finding process is also part of the retrospective meeting. Let’s assume, the team has established that builds and deployments take too long and are too error-prone. One possible measure could be to revamp the build automation. For example, the team could decide to upgrade the CI system. Another measure could be to revise unit tests for better performance. A third could be to add hardware to alleviate bottlenecks in the build and deployment chain. Whatever the concrete measures are, they need to be supported by the team and then fed back into the backlog. This implies that retrospective meetings should eventually result in a list of concrete actionable tasks.
Not every retrospective meeting is equally productive. Sometimes, the team is still searching for answers. This state of affairs is represented in question number four: “what didn’t we learn yet?” It is useful to articulate the known unknowns in order to establish a baseline understanding. Disagreement, vagueness, platitudes, and hasty solutions all indicate the absence of a true understanding of a problem. But even without actionable measures, retrospective meetings have value, because it gives participants the opportunity to align their perception and generate insights. Even in an unsuccessful iteration, valuable insights could be gained. To cite Thomas A. Edison: “I have not failed. I’ve just found 10,000 ways that won’t work.” On the other hand, retrospective meetings should not be allowed to devolve into bickering and blaming sessions. It’s important to focus on actionable measures as the end result, even if their formulation is not always possible in an instant.
Another common pitfall is letting dreary routine take over. While every ritual can potentially become a mindless formality, this is especially common and especially deplorable for retrospective meetings. Why common? Because a fixed schedule -as in Scrum- sometimes goes hand in hand with repetitive and uninspired moderation. The team might not feel the need for a retrospective meeting at the given point in time. An unskilled scrum master could make things worse. Why deplorable? Because it is not just an opportunity for becoming more effective as a team. It is also an opportunity for personal growth. An ideal retrospective is much like an exploration of uncharted territory. It is stimulating, thought-provoking and potentially leads to new insights. It is a collective learning experience that ideally leads to becoming better at what each team member does. Therefore, it is important to not let this opportunity become a boring formality. The scrum master can facilitate this by using varying moderation techniques and of course by listening and being responsive.
I don’t think retrospective meetings should be time-boxed. It’s actually an anti-pattern. Only certain activities within the meeting, such as personal reporting, can be meaningfully time-boxed. Since it is essentially a problem solving activity, the retrospective meeting can take minutes or hours. Obviously, if there aren’t any problems to solve, it only takes minutes. But if the team is immersed into analysing and solving a complex issue, and if there is agreement that this issue does matter, curtailing this effort by time targets is counterproductive. Another anti-pattern is to turn the retrospective into a performance review. It is OK to establish an understanding of whether business goals have been met or not. But it is not OK to hand out blame and judgement. For the retrospective meeting to work towards its defined goal, self-improvement, a high degree of openness and honesty is required. This would be completely lost if participants harbour fears of being judged.
Finally, there are organisations that drop the retrospective altogether. This is almost never a good idea, unless there is already different established channel for team reflection. These organisations often try to adopt agile methods without having adopted the underlying agile values. For example, they may have decided to do Scrum or Kanban merely in order to reduce development costs and/or risks. Or they have a traditional top-down management that does not value decision making at the grassroots level. Or the team members are so used to receiving orders that they are not willing to question their procedures. Or there is a deep lack of trust that prevents honesty and openness, because people fear that some weakness may be exposed. Whatever the concrete reasons may be, it always indicates that the team and/or stakeholders haven’t really embraced agile values. This could be the case even if the organisation is (seemingly) doing Scrum for years. The best way to resolve such issues is to hire external professionals to coach and guide the team towards a better implementation of their chosen process.