Vision based retrospectives – avoiding conflicting improvements

As most of you know, I’m quite fond of continuous improvement.  I guess it’s the whole idea of admitting that you can’t predict the future.  And therefore, if we wish to grow, we must learn and adjust instead of trying to make better predictions.  Not just in projects, but also the way we organize our work.

I’ve seen continuous improvement as a great motivator for people.  In Agile teams, the retrospective meeting can evolve into a catalyst for learning.  It is not uncommon that people, who have lost their enthusiasm for the trade after years of the same old company politics, start to revive.  Suddenly, they get listened to!  The retrospective becomes their tool to contribute improvements to the organization.  It feels fresh, open and in many cases they have plenty of ideas.

Although this all sounds great, there is a danger in this enthusiasm.  Because what happens when people bring up new ideas?  They expect all of them to be implemented!

Since a retrospective is focused on a single iteration, most improvement suggestions are based on the previous x weeks.  That’s why many Agile teams only seem to improve a little over time.  Sure a lot changes between iterations, but that’s often not directly proportional to the effort it takes to implement these improvements.

What is lacking is a long-term view.  What’s our ideal model?  How do we want to work together?  How will we deliver value to our customers?  How do we integrate with the rest of the organization?

This seems like a dreamy exercise, but beware of its value.  Having an ideal model gives you the ability to weigh your options.  Why would we waste our energy on improvements that don’t contribute to getting closer to our ideal model?  It’s not uncommon that an improvement suggestion gets us farther from our ideal state.  Besides that, it’s simply a fun exercise to imagine a perfect world.

This process has been used for a long time in other industries.  Check out Toyota Kata, if you’re interested to learn about it in a manufacturing context.

In the book, you can read about the Improvement Kata, which has 3 actions:

  1. Understand the current condition
  2. Identify the gap with the vision
  3. Set the next target condition

As you can probably feel, this is an iterative model, where you cycle through the process in a quest to get closer to the vision.

Let me show you how I use the vision during Agile retrospectives.

Visualize the ideal state

If we want to understand our ideal way of working, we need to be able to use it easily.  So in one of our team retrospectives, we focused on writing down our ideal future.  This was a highly interactive meeting, where we started by writing down the stuff that mattered to us.

Then we tried to group items by similarity or category.  Doubles or similar topics were combined until the model became small enough to make it easy to understand, without losing too much meaning.

In the end, I consolidated it in a mind map.  This way, we could easily re-use it in future retrospectives.

Use it as an exercise starter

In some retrospectives, we use the mind map as a starting point.  By going over the different categories, we identify the current gap between current reality and our ideal way of working.

This works as a great conversation starter.  You can attach different retrospective exercises to this, for instance root cause analysis, brain writing, …  Whatever exercise helps the team to get insights in why the gap exists for a specific category in our ideal model.

Finally, we would come up with actions to take a next step, closer to our ideal model.

By using this format, you remove the issue of choosing improvement actions that contradict each other over time, because you start the exercise from the vision.

Use it as a cross-check

In other retrospectives, we follow the standard retrospective format.  We gather data about the previous iteration and try to generate insights.

It is however during the ‘define actions’ part of the meeting, that we include the mind map.  We use it to cross check our possible improvement actions and whether they conflict with our ideal model.

In this format you filter out the improvement actions that contradict the vision.

Observe the impact

In the next retrospective(s), we check the results of the implemented improvement actions.  Did they bring us the next target condition?  If so, we can start working on defining a new one.  If not, we try to understand what happened and brainstorm new improvements that can get us to the next step.  And in some cases, it can take a few retrospectives to eventually reach the target condition.

On an abstract level, the vision has become an essential piece in our continuous improvement toolbox.  It is an essential part of the puzzle to make improvements sustainable and to keep growing as a team.

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.


  1. Abhishek S

    Hi Nick,

    Your idea for vision based retrospection is really good. I have seen in most of the retrospective meetings people actually focus on issues of last sprint, what can be improved for next sprint or release. But, they all lack a vision. It’s not structured. This idea of vision based retrospection is very exciting.

    – Abhishek S.

  2. Pingback: Boring retrospectives – part 9 : Vision Poker « SkyCoach

  3. would you be willing to share any tips for the first step — visualize the ideal state? i’m thinking just doing that is plenty to cover in a ‘retro’ — without necessarily deriving any actions.

  4. Pingback: What is an Agile Sprint Retrospective? | Using Agile Approach

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: