Agile Retrospectives – Using Double Loop Learning

Agile (or Sprint) retrospective is a useful mechanism for the scrum teams to implement continuous improvement in their processes. The scrum master may facilitate the retrospective meeting to help the team identify processes that worked well and those that did not work so well. The team goes on to find ways to improve the processes and try them out in the next sprint. Retrospectives are very important for Agile teams to be successful because it brings in a continuous ‘inspect and adapt’ approach to the processes applied for making the product.

The Process of retrospective

While there are many techniques to conduct the retrospective meeting, the general process followed is to take the individual’s feedback, collate them and identify top priority items to be implemented in the next sprint. It is fundamentally a process to collect feedback and make corrections to the system.

According to the General Systems Theory, a system has inputs, outputs, transformation processes that convert inputs to outputs and a feedback loop, that feeds back information to the system for possible corrections. The feedback loop is a critical component of any system or organization, since it provides information from the active stakeholders of the system which are crucial to improve the performance. If the feedback loop is missing or dysfunctional, systems will lose the ability to learn.

Therefore retrospective fundamentally is a process of learning for the teams. In systems terminology it is called ‘negative feedback’, which is a method for error detection and correction, so that systems can maintain a desired course of action by correcting deviations. This can be compared to a thermostat which helps control the temperature of a room, by starting off or shutting down the cooling system when the desired temperature is reached. The thermostat works on a negative feedback loop to maintain the room temperature at a desired level.

Most often, retrospectives work as a ‘negative feedback’ mechanism where the teams make corrections based on deviations or ‘errors’ and continue to do what worked well in the past. Based on existing norms for operations, they make corrections in their processes.

For example, operating norms for a sprint team are the practices of SCRUM, and/or generic software engineering and project management processes that explain how planning, scheduling, customer communication, prioritizing, reviews, testing, coding, etc have to be done. Operating norms also govern how individuals within a team should communicate with each other, how they have to collaborate, or how they should escalate an issue, how decisions are made, or whether some issues are discussable in a meeting or not, etc. During retrospectives, teams collect feedback and typically make corrections within these operating norms. For example, the team might make a decision about when to write the acceptance test cases based on how it worked last time. Or it could make a decision about who should do the code inspections next time. Or it could change the frequency of meetings with the clients for better communication or decide about a different medium for communication. 

While negative feedback is needed, it falls short in systems which work in complex and dynamic environments. In such environments, the existing operating norms need to be questioned periodically and changed to respond to the environment in an appropriate manner. This includes asking ‘Why’ questions on the existing and proposed processes and going a level deeper into investigating why we do what we do.

Chris Argyris (1923 – 2013), a well known organization scientist, had made a seminal contribution to organizational learning and change. His contribution to organization learning works not just with human behaviour but also the reasoning that humans apply in learning and making decisions. One of his most popular frameworks is called the Double loop learning. Double Loop Learning involves reflecting on the underlying norms, values and frameworks that drive our actions. This leads to questioning the strategy and the goals that we have set for ourselves. 

Imagine in the example discussed above, the thermostat is able to decide the optimum temperature for the room and work accordingly instead of a pre-determined temperature. That would be Double Loop Learning. It includes questioning if our methods are effective.

As against this, single loop learning, works within the given framework of norms, goals and frameworks and tries to improve efficiency whereas Double loop Learning tries to confront the very norms and frameworks within which we operate. For example, the very practices of Agile (SCRUM, XP, etc) evolved because the existing norms of software product development, management, team organization and customer involvement, conditions for project success, etc., were questioned by a group of engineers. Alternative methods were found because the effectiveness of the existing methods was questioned.

Even though retrospectives are meant for continuous improvement, they can be easily upgraded for spaces where collective reflection and dialogue happens for discontinuous improvements.

In the examples of retrospectives quoted above, taking double loop learning approach would involve collective reflecting on whether the current and proposed practices are helpful in achieving the project goals. It would include reflecting not only on the engineering/SCRUM practices but also on the team’s functioning –looking at the group processes of decision making, problem solving, communication, etc. This kind of reflection would help the team to get clarity about effectiveness measures vs efficiency measures, ie., positive feedback vs negative feedback, doing the right things vs doing things right. This in turn will contribute directly to customer satisfaction, increasing business value and employee morale.