Should we do a PIR?

One thing that defines good agile teams is the habit of “learning from feedback.”

This idea is not something agile teams invented though, even if it is core to being agile. I imagine that cavemen gave each other feedback on their hunting and gathering techniques and continually improved, as measured by not being hungry and not being squashed by a mammoth.

We held PIRs a long time ago

Certainly, as far back as last century, we held a feedback session called a post mortem, or PIR, at the end of every project or major event.

The PIR (Post Implementation Review) was a chance to look at how we got to the point of releasing something (or rolling back the release) and also whether we achieved our original goal.

There was also another PIR, with the same initials and intent, but a slightly different focus – the post incident review, where we also asked “how we got here”, “how we responded once things went wrong” and “how bad was the impact”.

Both these PIR’s were good in that we took lessons away and both only really worked if we got real feedback from both people in the team and those impacted by the incident/implementation/action.

But the PIRs had some shortcomings:

• The PIRs were event based and not an ongoing habit. As a result the feedback cam after the event was over, not during the process of creating or maintaining something;
• The outcome was often a report, to be read at a later date rather than acted on immediately, meaning there was often a lot of wordsmithing about the context rather than discussion about immediate implementation of small wins; and
• The audience was not just the team, but also outside stakeholders, so the “findings” were often adapted to sound more palatable or to demonstrate that something was being taken seriously.

These short-comings meant that a lot of lessons were lost and some were “learned again” by new people making the same mistakes that others had made last time something happened. Worse, they often resulted in increased process and safeguards that focused on the wrong risks or issues, rather than the team looking for improvements in how they worked.

In spite of these short-comings though, PIRs were worth doing, particularly where they resulted in concrete action or better understanding. I have been surprised at times that people think agile teams can only reflect on a sprint, rather than an event or observation. The idea of the PIR has never gone away for me, it is just that agile teams adapted the idea to their way of working.

Continual learning

Agile teams introduced (or made famous) the idea of continual feedback, or regular inspection/reflection. This might be in the form of a sprint review and retro, or a weekly OKR reflection or even a quarterly look back on how things went. Doing things on an ongoing basis obviously means that lessons can be applied as they are learned and small things can be worth improving.

Again though, agile teams did not invent the idea of regular reflection, with regular opportunities for feedback and shared sense making to create ongoing improvements.

Rather, good feedback and regular reflection have been core to all the high performing teams that I have been a part of.

A whole of business approach

In the “Rockefeller Method” there is a weekly, monthly and quarterly cycle where the whole team reflect on how they are going against their goals and what they should amplify or change.

The team goes beyond just sharing good news (celebrating wins and giving out awards) or apportioning blame (asking for an explanation of why a goal was not met).

Rather, the team starts the cycle with a clear goal, usually captured on a canvas, and measures will track to see how they go. The goal and measures are known to everyone, as is the importance or priority of different goals if there are multiple ones.

Then, at the end of each cycle the whole team reflect on their progress against each measure, as well as the views that people in the team are forming, based on what they are seeing beyond those measures. You can read more about the approach in this book.

When I was using this approach, it took a lot of work to get people involved and to really prioritise the few important things we want to focus on (both innovation and ongoing “boring” hygiene of the business. But it worked really well.

The clear goal and the attempt to come up with measures helped a lot. However the most important factor in making it work was that everyone in the team had the ability to participate in a “generative conversation“.

By generative, I mean a conversation where there was a lot of inquiry, permission to say stupid or unpopular things and a desire to get really meaningful outcomes from the conversations. People did not just listen to the leader or share numbers or manage the message – they debated, argued and supported each other at the same time as being curious to learn from each other.

I think that if you did nothing else but read the “Rockefeller Habits” (the book above) and the book Fierce Conversations, then you could apply what is in them to build a really powerful culture, with a real focus on growth and resilience in your organisation. A clear framework to define and pursue value, with a culture of regular reflection and honest, well intended feedback is a powerful thing.

Again though, this is not the only example of what works.

Even before I was in a “Rockefeller team”, I was in a team that used the Balanced Scorecard approach and even though I heard that others applied that approach to build bureaucracy, the team I was in were learning to assess reality and provide each other feedback that led to great alignment and a desire for real improvement.

We were well led, but we also had a culture of generative conversations again. The only gap I found was that we managers would hold the discussions and “feed information down to the teams” rather than everyone giving their own feedback to everyone else. It was consequently easier to implement, but also less full-on.

In both the Rockefeller Method and Balanced Scorecard approaches, the conversations that the team were supported by hard data and first hand opinions based on experience, but the real benefit came from the shared sense making of that data and the comparison of what the alleged findings of the data with the daily observations and opinions of the team, rather from the scoreboard or numbers.

Scrum teams

Coming back to agile teams, regular reflection and ongoing collaboration are obviously core to the way we work.

Scrum teams formalise the use of a “feedback session” at the end of every sprint.

Hopefully they also have longer term cycles that reflect on a whole theme as it is delivered, or on quarterly changes as well as weekly ones. Hopefully they also have a culture of offering and listening to feedback between meetings. Definitely they have a rhythm of reflecting on their progress and the way they work together every sprint.

I know some of these teams have reduced the retrospective to a fortnightly ceremony that lists grievances and congratulations as and end in themselves, but this is falling short of the potential of the whole Scrum approach.

The hope is that they explore differing opinions and build on each others observations as part of the session. Doing this means that they can also talk about what is really working and what can be done to make life better, rather than just turning up because some calendar told people to come and “collaborate.”

It is the role of the agile coach or scrum master to create a habit of generative conversations to make use of the time the team spends together. Ideally the coach can help the team use evidence for their discussions and commit to concrete action, but the core factor in success is the ability of the team to benefit from the shared conversation.

Product teams

One missed opportunity that some Scrum teams experience is that their conversations lack context. They do not have a clear goal or a measure of progress against that goal. If this happens then they will probably discuss superficial improvements rather than core changes and passionate views on how to make the world better.

Being in a product team should alleviate this, if the team has access to data such as HEART metrics, Pirate Metrics or a good UX team sharing the impact of the team’s work.

Of course, even with these advantages, everything still depends on the team having a generative conversation, rather than just a product manager telling them why the numbers are cool. Hence the value of a product coach or agile coach if the team is not sure how to do this. Or, hence the value of a Product Manager that builds the team rather than just defining the product.

Kanban, operations and lean teams

Product teams measure the impact of their work on their customers and that is ideal. But old school PIRs used to focus on the detail of how the team got to impact the customer and what they can do to reduce risk, deliver better outcomes and better anticipate things.

Lean and Kanban approaches bring the PIR approach to their daily work rather than waiting for an incident or major event. By “the PIR approach”, I mean a combination of stepping back to see the big picture and looking more closely at specific things that do not seem right, or at least seem worthy of attention.

Lean and Kanban team track things like WIP and cycle time. These things can create nice graphs but that is not why they are being tracked.

If a team can see where their bottlenecks are and they can see the impact of “outliers”, or unusual outcomes, then they can discuss why one piece of work takes longer than another, or why mistakes happen every time the team tries a certain approach.

For these teams we are almost right back at the starting point of the second type of PIR, the Post Incident Review. The only differences are that:

• Rather than waiting for an incident, the team can look at multiple stories or tickets and learn from them all instead of only from things that blow up badly;
• The feedback cycle is continuous, rather than event drive; and
• The audience for the incident ticket review is the team doing the work rather than some external stakeholders looking for reassurance.

Conclusion

Good PIRs, retros and learning cycles are a core part of a high performing team in any of the contexts that I have worked on. Core to this is the ability to share and consider feedback as well as having a shared goal that the team is focused on.

I think the concept of a PIR for each event is still a good one and does not disappear when we start having a regular feedback cycle, so a team might devote a retro to looking at a single incident or they might focus on the last release. It should never be an either/or decision but rather a combination of ongoing reflection and specific events creating good learning.

So, agreeing on what to reflect on and learning to have really good generative conversations is probably what I see as the key concept of both coaching a team and being in a high performing team.