#88-Retrospectives and Feedback

This week I will discuss two important aspects of the continuous process improvement that agile requires: Retrospectives and Feedback Loops.

Transcript

Retrospectives and Feedback Loops

Part of what makes agile effective is that it is an empirical process rather than a prescriptive one.  Empiricism is the scientific process where experience and evidence are used to make decisions going forward. This, as opposed to making a plan at the beginning of a process and then expecting that plan to be adhered to throughout. 

But how is experience shared, and how is evidence gathered in order for an empirical process to work? It is based on two things: retrospectives, which are conducted on a regular basis, and feedback loops which are constantly happening throughout the iteration of work. 

Retrospectives are done on a defined pulse. For example, in scrum, when a sprint concludes we do a retrospective before we plan the next sprint. In other processes it may happen at a different time, but that time is defined discreetly. One way to look at it is this: anytime there is something that can be validated by a stakeholder, because enough work has been done for them to be exposed to it, that could be a good time to also conduct a retrospective.

This should be a relatively lightweight process where three questions are always asked:

1. What worked? 

2. What didn't work? 

3. What's next? 

Some leaders I've worked with expand this slightly into four questions: what did we like, what did we learn, what was lacking, and what do we long for? This is often referred to as “the 4 L’s”. 

A retrospective is not about producing a massive report or creating a polished presentation, it is a space for honesty and clarity. Everyone on the team should have the opportunity to answer some or all of these questions. The underlying attitude is that we wish to learn from the work we have done, not just complete it. When I talked about agile leadership, I quoted Peter Drucker who said that true leadership is about developing people through the work that they do. The retrospective is an opportunity for that development to take place. 

Everyone is invited to attend a retrospective, but only members of the team should be active participants. There is an old joke about a chicken and a pig negotiating about opening a restaurant, which will serve ham and eggs. The pig points out that although the chicken will be interested, the pig will be committed. The pigs in a retrospective are the team members who are doing the work and are accountable for its results. The chickens are those that sit on the periphery and observe the process, absorbing information and learning from it.

For a retrospective to be maximally effective you have to make sure that the members feel supported and safe, and that there is a defined framework for giving feedback, and that the team is focused on discovering insights that can be made into actions. You don't want the retrospective to simply turn into an opportunity for people to complain about the things that bother them. One particularly effective scrum master I worked with told the members of the team that they could come to her with any problem that impeded them, but only if they had at least one idea about how to solve it. I think that's a good rule for retrospectives as well. 

Feedback loops should happen constantly throughout an agile process. They are part of the lean principle of continuous improvement. The idea is to catch problems early, elevate them to visibility, and to make improvements without delay. When I discussed the Toyota production system which led to lean manufacturing I mentioned the notion of the “andon cord”, which is a physical handle that anyone on the production line can pull to stop the process when they've identified a problem. That's a good example of a feedback loop; that anyone at any time can pause the work to elevate an issue for immediate discussion and resolution.  No one is ever reprimanded for pulling the andon cord, even if it turns out that they were mistaken to do so, so that everyone feels heard and empowered to engage in process improvement. 

The key difference between retrospectives and feedback loops is frequency. Feedback loops are like physical fitness; you don't expect to work out once and suddenly be more healthy. It's something you have to do constantly and consistently to see results. 

Like most recommended elements of an agile process, retrospectives and feedback loops are focused on team activity. But a common question is: how do we scale an agile process to a large enterprise? 

That's what I'll talk about next week.