In this episode we talk with Diana Larsen about the origins and reasons for the 5 steps framework.


Diana co-authored “Agile Retrospectives - Making good teams great”. Have you ever wondered why you’d need a 5 steps framework? What’s wrong in just adding items to 3 columns and picking action items? Read on or listen to the episode.

Here are a few highlights from Diana:

Back in 1996 Norm couldn’t facilitate cause he was the manager of the team so he asked me to facilitate. He knew I had experience facilitating meetings around team development. That was my first retrospective. He gave me an unpublished manuscript of his book “project retrospectives”, I met Esther Derby trough norm and we got both very involved with the growing community of what was later named agile.

As we worked we realized there needed to be something other the end of project retrospectives in the agile space. We talked with others in the industry like Rachel Davis and Tim McKinnon and realized we needed retrospectives around the iterative cadence of agile. A time not just for the organization to look back at how to improve projects but for the team to look Back at the how to improve how they work together.

We started writing about what we were doing differently then Norm, and we looked at other facilitation sources: one from The institute of cultural affairs in Canada (the Art of focused conversations, one from Human system dynamics (the adaptive action format).

All shared first an assessment of the current situation. Then once you have clarity look in to what insights can we get–an analytical phase versus the initial descriptive phase–and then comes a decision phase. Now what do we want to do about that? Where is the best place to put our energy. That became gather data, generate insights, generate what to do.

We also knew most of the people that pick up our book were not trained facilitators they where software folks and were not expected to have those skills. It’s interesting to see how those facilitation techniques have become more important now then they were back then. We realized we needed to give our audience a way to start the retrospective meeting (set the stage) and then at the end close the retrospective (to shift from this meeting to whatever work is coming after).

Once we determined those 5 steps where the best combination for people we started assigning activities from our experience and from other colleagues and the total quality methods. This is how the 5 steps came to be, so that people would have all the understanding that they needed.

As we were writing the book we would often get questions like: “I don’t understand how you could write a whole book about retrospectives it’s just two questions”. Having the lists don’t make you close to any action.

“You build models, you put them out in to the world and they teach you back.” I look at my coffee cup and I think,”oh it’s only half full” does it mean I want to get more coffee? Maybe I’ll wait till later. That’s gather data, generate insights, decide what to do. With the 5 steps we take a group of people so they can simultaneously go trough the same thinking process that an individual goes trough. That’s the real power in it. That’s why we suggest people not to leave out parts or you’d miss out on some of the thinking process.

Institute of cultural affairs has ORID Observation, Reflection, Interpretation, Decision. We collapsed observation and reflection (on how you reacted to that situation) in to gather data.

Things happened but the real crux is how do we respond to the things? If I go back to the coffee cup example, on some day if I knock it off I might be just go along with my days but other times I might be very hard on myself and let it ruin my whole day. It’s not just about having knocked over my coffee cup… that’s a fact… there is coffee all over my desk… what’s really important is how did I respond to that? How did that influence my subsequent behavior? And when you’re in a group, maybe I am fine having knocked it over but other people around are not. And that’s another dynamic. So being able to pull out those dynamics is an important step.

Generating insights is—after we make sure we’re all on the same page about what happened—can we see some patterns? Notice things that are new? Or happening again? What are the causes that make us trip? We only have our own point of view until we take this broader scan and share with the group. Generating insights is where the learning happens. We learn about the implications of what happened. How did it affect us?

When we wrote the book there wasn’t much information about complexity frameworks like David Snowden’s Cynefin that can help to get some sense what kinda of approach we should take based on where the problem falls: simple, complicated, complex.

Tackling something that the team control first helps to build their muscles around team improvement. As the team improve and start seeing more patterns they can start looking in to influencing actions. But they need to get a clear picture of what they’re doing together first. In some ways it’s a fluency progression. The first way that you become fluent is deal with the problems that are internal to the team. Things that the team has direct control over.

In the agile fluency there are four cumulative zones for the teams. It’s not a maturity model. Not all organization need an optimizing team. The zones are: focusing, delivering, optimizing, strengthening. Retrospectives for the teams in the focusing zone are going to be focused on how well are they working together, is there anything they need to adjust in their work process? In the delivery zone the nature of the retrospective is going to change, questions like are we using all the engineering practice that we are creating the smallest about of bugs in our code so that our integrations can go smoothly. The nature of the kinda of things you’re looking in your retrospectives changes depending on what zone you’re developing fluency in. In optimizing the team would retrospect more on cross functional collaboration.

Rotating facilitators is a great idea. In the book we said if nobody has those facilitation skills we should bring in an external facilitator. That was back then, now some of those permanent skills are more widespread. When everyone is involved in facilitation I noticed in a group of 7 maybe only 2/3 have an affinity for facilitation meeting and are interested in developing more skill. A lot of the times these are the people that rotate. The idea is you don’t need your scrum-master to do it and that people can develop facilitation skills.

One of the things we noticed in the Agile community is every terms get coopted and get used in the way people want to use it. So people leading retrospectives hopping trough the 3 columns, trying to find an immediate action items without digging any deeper for insights… might call what they’re doing facilitating but it’s not. Or they’re facilitating in a very minimal kinda… not even good enough for now level. Just going trough the motions.

True facilitation is really leading people trough steps they need can to go trough to as a group to be able to think together to be able to come to some conclusion. Where the action by Elise Keith is a book about the 16 type of meetings that go on to really understand what kinda of work are we trying to accomplish to help this group to get to the outcome they need right now.

We want to everyone gets good facilitation skills—in all meetings, demo, planning, standup and of course retrospective.

There is a fallacy that we think that because we’re human we’re born with the skill of listening to each other, the skill at communication what we mean, and having a meeting together and it’s just not true. Just like reading and writing and math and computer programming these are skills you need to develop over time to become effective.

We should focus our retrospectives on a topic because a lot of things happen during an iteration. Influenced by a lot of things. We’re not given enough time to dig deeper, someone has to make the judgment call, what are the things that stand out in this iteration? Where does it stand in the complexity spectrum? Is it a complex situation? Obvious? How is our decision making around this. If we look at the lists and spend a couple of minutes and try to come to a conclusion we haven’t really given the depth of analysis to what gives rise to each of those either enablers or constraints things that got in our way. We don’t have enough time to really examine those so we can get away from the whack-a-mole so we can really deal with what has generated those conditions to occur. Until we look in depth we can’t really know how to improve the situation.

You may have things in your team that you need to deal across a number of iterations… a number of retrospectives. Re-opening up the whole list just confuses the issue.

How much time for a retrospective depends on the size of the group. Bigger group requires longer time. For a group to 4-6 people, in my experience most groups would take just about 75 minutes. Teams that know how to think together can conclude in less then 1 hour. I would play around with the length of time. There is almost no people that can come to substantial improvement action in half an hour. All you’ll do is go back to the 3 columns list and that’s not gonna move you forward. That’s why I think it’s a waste of time.

Favourite activity

Circle of questions (only work in groups of 8/10)

Book reading right now

Business models for teams by Tim Clark and Bruce Hazen, looking for connection with agile fluency

Favorite dish

A Vietnamese dish called Bun


A visionary pragmatist, Diana Larsen is co-founder and Chief Connector at the Agile Fluency™ Project, where we hold a vision of an inspiring future: “Every agile software team practices Agile Software Development at a level of fluent proficiency that specifically fits their businesses’ needs.”. Diana co-authored books Agile Retrospectives: Making Good Teams Great;


Diana Larsen

Music used in intro/outro is by Krakatoa