Retrospectives in Scrum (called “reflections” in eXtreme Programming) are a key agile practice. The mechanics of a retrospective—a meeting through which the team assesses its performance and sets goals for improvement—are fairly straightforward. There are many ways to tailor and improve a retrospective, but this simple Plus/Delta-inspired format is a good start:
- Arrange for a neutral facilitator to run the retrospective.
- All project team members sit in a large conference room, preferably in a circle.
- All participants follow simple ground rules (cell phones off, no interrupting others, each person gets a time-limited turn, and no judgment on feedback).
- Each team member provides feedback on these questions: What’s working well? What can we improve? What are some obstacles or issues facing the team?
- A brainstorming period follows to address the major issues.
- The meeting ends after the facilitator captures action items.
Unlike the traditional “lessons learned,” reflections are conducted while the project is underway, usually after every sprint, to qualitatively inspect the team’s agile process. Although the concept is simple, we’ve found that teams often struggle with establishing effective retrospectives. One of the reasons for this is that after the initial excitement of getting agile projects up and running, we let certain key practices lapse, and the retrospective is often one of the first to slip. Going through the retrospective over and over again can become tiresome if the team doesn’t understand and value its purpose.
Some time ago, Arlen blogged about steps to achieving more efficient agile retrospectives. This post addresses the purpose behind the practice, instead, answering the question, “Why do retrospectives at all?” It’s an important question, because knowing the answer helps us implement and sustain this critical practice.
From a systems perspective, learning and adaptation requires us to continually make slight adjustments in order to discover the best fit for the environment. An agile team needs continuous feedback to enable learning, just as the feedback we get when driving (the feel of the steering wheel, the road conditions, other traffic, etc.) allows us to make the adjustments necessary to steer the vehicle. Learning is enabled by continuous feedback from the environment, and is accomplished through adaptation of strategies and rules. In the field of organizational development, this is called “double-loop learning.”
As illustrated, double-loop learning involves two learning “loops.” The first loop represents adjustments based on fixed, non-changing goals and operating norms. The operation of a thermostat is a common example of single-loop learning.
When a thermostat at a particular setting learns it is either too hot or too cold, it turns itself off. It performs this corrective action on receiving information about the temperature of the room.
Double-loop learning involves an additional learning loop with steps to reflect and adapt the operating norms themselves. With double-loop learning, one questions the norm represented by the thermostat’s temperature setting. Why is the thermostat at this particular setting? Is it the optimum temperature all day? Should it be changed to accommodate the number of people in the room, for example? This sort of self-reflection and learning results in intelligent, congruent action.
The retrospective represents a simple way to implement deeper double-loop learning beyond the day-to-day adjustments we make to keep things running on our projects. Retrospectives are thus fundamental to continuous improvement. Our teams and organizations cannot improve unless we’re constantly assessing and improving our processes, and the retrospective is an excellent way to implement that continuous improvement.
