At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. — Agile Principle #12

This is the final Agile principle and, on the surface, it wraps up the principles in a nice package — closing with encouragement for teams to make their own decisions about how to work more effectively.

This seems both simple and obvious yet it’s one of the most challenging tools in the Agile toolbox.

Most development teams that I’ve encountered either never hold a reflection event or “after-action review,” or they do so only at the end of a program, when it’s too late to do anything except capture vague “lessons learned” that get posted to some site that no one ever visits.

Even Agile teams often conclude that one way to become more effective is to stop holding reflection events — at least not as often as the end of every Sprint. The truth is that after a few Sprints, the reflection steps get repetitive as all the easy problems in the development process get fixed. This is because most teams have reflection events too often, and the outcomes of those events are too unfocused and not as actionable as they need to be.

Good Reflection Events Have a Focus

Reflection events provide a place for team members to express their concerns or bring up ideas they have about how to improve the development process itself, but that doesn’t mean they should be unfocused brainstorming or gripe sessions.

A simple structure like the one below can help ensure the team gets value from their reflection experience:

1. Begin with a summary of changes made previously.

What did you change after the last reflection event? What did you expect to happen — what was your hypothesis? What were the results? Do you want to make this a permanent change?

Most guides to Agile Reflection events completely miss this step, but it’s essential if you want the team to feel like it’s making progress instead of spinning its wheels.

2. Provide some open space for expression and new ideas.

I like giving people sticky notes (physical or virtual) and a place to put their responses to four questions:

• What’s working well and should continue? This first question recognizes success and identifies the things that should not be broken as the process changes.
• What needs to be done better? The second question identifies the friction that still remains to be smoothed out in the process.
• What should we stop doing? This question exposes major areas of work that is, perhaps, unnecessary.
• What should we do next? The final question moves the team forward into action.

Sticky notes make all of this more efficient and effective, since individuals can work in parallel, and it’s easier to see patterns emerge.

3. Decide on a small number of informed changes to tackle next.

Next, the team decides what changes they want to try. Here is where a team new to Agile needs a coach. Agile is uncomfortable at first, so teams need an experienced guide to help steer them towards useful changes in their environment and away from making changes that will prevent the team from realizing the benefits of Agile.

For example, in Rapid Learning Cycles it’s important that team members write Key Decision and Knowledge Gap Reports. If team members don’t do that, they lose a lot of knowledge and that gets in the way of their ability to make better decisions and recommendations. A team member normally needs to write 3 – 5 reports before they get comfortable with the structure. In the meantime, it is just going to be a little uncomfortable. We wouldn’t want the team to abandon these reports early due to their initial discomfort.

However, a team can change the report template, put the reports in a different location, reorganize the keywords / tags that they use to classify each report, or even move from PowerPoint to a tool like Confluence. A wise coach can ask good questions about the source of the discomfort to see if it’s something that will be resolved by time and experience, if it’s something that is within the team’s control to fix or if there is a more serious issue.

4. Frame each change as an experiment to test a hypothesis.

In the beginning, the team will come up with a lot of ideas that can just be done: move the title from the right to the left to make it easier to read, etc. Once the team has taken care of “low hanging fruit” they’ll need to work on things that will take more time: better test harnesses or emulators, more automation. Any improvement is more likely to work if the team takes just a few minutes to align on the hypothesis that they’re testing: “If we build a better test harness for connecting to the database, then we’ll be able to start working on database-related user stories sooner.”

Even simple, small changes benefit by making the expected result clear: “If we move the title from right to left, it will be easier to find the report we want in the thumbnail view.” This framing also makes it easier to recognize that these are tasks that need to be integrated into the team’s plans.

5. Assign ownership for actions to implement the experiment.

Someone needs to take responsibility for building the test harnesses, or it will never get done. If the team is using user stories, then the user for this story is the team itself. The value of this work needs to be assessed alongside the need for a new feature or an improved UX. Agile methods have different ways of handling this type of task. In the Rapid Learning Cycles framework, it would be an activity not connected to a Key Decision or Knowledge Gap.

The Agile Coach sometimes gets responsibility for all of these action items so as not to distract the development team, but this is a mistake — the team needs ownership itself. Spreading out responsibility for improvements helps build shared ownership.

6. Set the date for the next event.

This is probably not the end of the next sprint. Except for the simplest changes, one cycle isn’t enough to see results from the change and may not even be long enough to implement the changes. I recommend that my clients’ teams hold a reflection event after an Integration Event about once a quarter — and to wait to hold the first event until it’s been about three months. That’s long enough for the team to climb up the learning curve so that they make better improvements, but not so long that irritations begin to pile up. Before that, the project leader can ask about any concerns that may need a solution sooner but defer the rest of the changes until the team has run a “clean test” of Agile.

Useful Reflection is Focused, Actionable Reflection

When the team sees that the opportunities that arise in a reflection event lead to measurable improvements for the team, they are less likely to see it as an optional step that can be skipped, or an excuse to leave early. Instead, they see that their ideas become experiments with testable hypotheses that help the team make better decisions about how to work together more effectively.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” — Agile Principle #12