Retrospectives IN and ON action

Note: this post is longer than expected and is mainly about introducing and summarising the ideas that led me to wonder if there is a way to use the skills developed by using retrospectives (reflection on action) as a way to experiment while an event is still occurring (reflection in action).

Thanks to the work done by Norm Kerth retrospectivesa ritual held at the end of a project to learn from the experience and to plan changes for the next effort – are spreading nowadays in many different contexts and certainly in every Agile project that is really Agile. In time different types of retrospectives have been developed like project, heartbeat, alignment and incident (more info in the article Agile Project Retrospectives by Tim Mackinnon).

The first week of April I've been lucky enough to attend the Retrospective Facilitator Gathering 2006 in Germany and as often happens with events of this type those 5 days have helped me in reorganising some scattered thoughts I have on the subject and after more than a month I'm able to (start) write them down.

First of all why do I value retrospectives? Many different reasons but mainly because they let's you:

  • learn from experience
  • bridge the gap between theory and practice
  • cope with ambiguity and change
  • develop a critical awareness

Reflecting is something that we all do and Piaget found that this is one of the advanced skills adolescents develop as they approach adulthood. In fact I like to think that when professionals/teams/organisations move towards their adulthood they start to develop, value and apply a reflective approach to improve and grow. Or, to put it in another way, if they don't do it they still haven't turn the tipping point of maturity.

Learn from experience

Reflecting on experience provides the basis for forming more abstract ideas which can then be applied and tested in further experience. It enables us recognise new opportunities and learn from them.

Bridge the gap between theory and practice

As everyone has experienced in his life studying something doesn't necessarily means being able to apply it. We need to know how to apply the knowledge to real problems. Reflecting help us to identify how best to apply in practice what we know in theory.

Cope with ambiguity and change

Reflecting is essential in recognising the uncertainty we face in the modern world where the demand for fast and reliable results often increases stress and workload. This is particularly true in an Agile environment in which we tend to work closely with our customers and often have to cope with new and unique problems never met before.

Develop a critical awareness

We usually reflect both on our own behaviour, the behaviour of others and on the social/organisational context. This leads us to develop self-awareness and to become aware of things we need to change. Reflecting is then a key point for improvement and is far from being an innocuous process because it challenges the status quo, the way things are done.

Donald Schön began his research on reflection to challenge the predominant technical rationality which suggests that problems can be solved following a set of rules learnt during education. The result is a huge stress because we are seen as experts only because 'we are presumed to know, and must claim to do so' regardless our own uncertainty.

In reality the problems we face are often composed by a unique set of circumstances and the result is that the uncertainties as well as our knowledge of the other people involved are both relevant to solving the problems. Feelings, intuitions and critical thinking therefore play an active role and cannot be reduced to a set of rules learnt during formal education.

When we critically analyse our work we do it through reflection and this is when, in my experience, the tension between assimilation and accomodation happen.

In fact we may reflect in action (during an activity) or on action (after the event has been completed). In his book The Reflective Practitioner Schön analises how reflection is used by professionals to tackle the problems they face in their work and concludes that when faced with a new problem they become 'researchers in the practice context' conducting real world experiments.

He calls this approach reflection in action because the behaviour is an experiment itself. The general pattern recalls the scientific enquiry in which the professional experiences feelings and maybe anxiety that something is wrong, something is new and unique, never encountered before. A critical reflection then happens and he is ready to challenge his assumptions. At the end he may reframe the situation and come up with a new hypothesis and test it out.

It is also possible to develop the reflection skill after an event and Schön calls this reflection on action. This process is usually facilitated by another person. Retrospectives are then reflection on action and I wonder how we can use them to develop the reflective skill up to the point in which we can move from reflection on action to reflection in action.


  1. DJN said

    “Reflecting on experience provides the basis for forming more abstract ideas which can then be applied and tested in further experience. It enables us recognise new opportunities and learn from them.”

    I agree 110%.

  2. Maksim said

    Absolutely agree that reflection is a very important factor in building teams and continuous learning. However self reflection can sometime be misleading and may re-enforce non-productive behaviors. It’s important to gather high quality 360 degree feedback, ( i.e. Clients, Developers, Sponsors, Stakeholders… ) and look at the whole picture and not the first thing that comes to mind.

  3. David H. said


    I would like to say that this is a wonderful post. Since you wanted some feedback from a Scrum person, I thought I should add one thought. In a retrospective I also enjoy to reinforce the strenghts a Scrum team has shown. This could also mean that individual strenghts are shown to the team, exposed and carefully taking into account for ones own register. That means that I usually pay a lot attention to even make the “bad things” sound good. That is when “What went wrong” beacomes “What should be improved”. I think it is very important to set a positive tone to all of this.

    Apart from that retrospectives should fit in with the work culture of the company and the team. I have also learned, that removing the team from their actual work environment helps to lighten the mood and open them up.

  4. Ronica R. said

    I also am a Scrum person. Because Scrum/agile are at their core empirical processes, learning is built in throughout. So, yes, there is a formal retrospective at the end. But there are also the daily meetings, an emphasis on an open work setting that fosters constant communication, a tendency toward many prototypings/demos/other feedback points with users. Also, each iteration provides a reflection point at the end, but really these are intermediate reflection points to the real end, which is a release.

    My point here is that agile processes already do provide many points of retrospective IN action. Furthermore, and I suspect this is where you are really going with this idea, practicing scrum/agile does put team members into a habit of reflection, retrospective, and learning. Therefore, team members find more opportunities for feedback and adjustment.

    Maybe the next question is: is there such a thing as too much retrospective IN action? Can it cause you to change course too easily, or to fail to give an idea a chance to work? Or does that very question imply an over-thinking of what is really a simple process of collaboration, which is different from real retrospective, which is what we–in scrum–do every two weeks?

  5. […] Recentemente proprio su quest’ultimo punto ho letto un interessante post di Marco. […]

  6. […] Recently I have read an interesting Marco‚Äôs post that get the point. […]

  7. […] are supposed to apply an approach sort of “by the book” before starting to change it (through retrospectives, of course! ;-)). This is also why people talk about Shu Ha Ri as a way to approach […]

  8. naisioxerloro said

    Good design, who make it?

  9. […] are supposed to apply an approach sort of “by the book” before starting to change it (through retrospectives, of course! ;-)). This is also why people talk about Shu Ha Ri as a way to approach […]

  10. […] and Learn with RetrospectivesRefactoring Your Development Process with RetrospectivesMarco Abis' Retrospectives IN and ON actionSample chapters 3 & 5 from Agile Retrospectives: Making Good Teams Great by Esther Derby and […]

RSS feed for comments on this post · TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your 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 )

Google+ photo

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

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: