29. July 2014 · 9 comments · Categories: Agile


Like many things in life, Retrospective – as a concept – can have many layers of abstraction.

At the superficial level it can be used to identify symptoms and find ways dealing with them.

At a deeper level it can be used to highlight symptoms and attempt a rudimentary root-cause-analysis and possible experiments to address them.

At a fundamental level it can be used to highlight symptoms, explore their causes and explore the attitudes and motivations that need changing in order to better address such occurrences in the future.

If I understand this correctly, deeper retrospection and reflection require the investment of higher levels of cognitive effort. This investment, though, is likely to result in longer term benefits (compared with lower levels of retrospections).

While I can ‘see’ the benefits individuals can gain from exercising higher levels of retrospection, as they can gain better insights into themselves, their attitudes and their behaviours; I am not clear on the benefits to the organization. Are there clear, tangible, measurable benefits that would make the extra investment – in coaching and guiding teams to achieve this level – justifiable? I am still looking for the evidence.

Think about it.

Print Friendly

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...


  1. Thanks for sharing your thoughts on the value of retrospectives Shim.

    In general there’s little evidence on the value and results of Agile, let alone on agile retrospectives. There are a couple of studies done on agile value creation, recent ones are done by the Software Engineering Institute with Rally and QMS. There is a list of 9 studies that I am aware of in my recent blog post http://www.benlinders.com/2014/agile-value-creation/.

    I’m convinced that agile retrospectives play an important role when it comes to getting value from agile. Only when teams and the surrounding organization truly dare to reflect, learn from what is happening, and take action, then improvement is possible. Having the right stakeholders involved in retrospectives assures that the improvement actions will increase the value.

    It depends on the kind and level of the retrospective who needs to be involved. In team retrospectives it’s primary the team members, but it could be good to involve the product owner when there are issues regarding the product backlog, prioritizing, or the quality of user stories. I often advice projects to do retrospectives at major deliveries/releases with all project stakeholders attending. They can also be used to align teams and share learning. Organizations can do large retrospectives where experiences are shared between different projects or departments. My advice is to do retrospectives in agile transformation/adoption programs, involving everybody from the organisation.

    These are just some thoughts on this, what do you think of them?


    • Ben – good points and thanks for posting – I have now discovered your fascinating site at BenLinders.com.

      I do think Agile retrospectives suffer from the same issues as stage- or project reviews (a.k.a.”lessons learned”)…they are too often undertaken as a “tick the box” activity and the “findings” are expressed in such a context-specific way that their usefulness for subsequent work is limited. I agree that it is important to include more than just the core team in a retrospective. However, there is sometimes the issue of apathy – people’s focus has moved on from the past to the next challenge, so it would be important to ensure that the retrospective is prioritized to occur as soon as the wok is completed.


    • Thanks Ben and Terry for your fantastic comments (and great introduction to your blog Ben, lot’s of value there and will take some time to explore).

      While we all agree that Retrospective are important and valuable I’m having a difficulty putting my head around the level of effort organizations need to apply in order to move up the retrospection ‘value chain’ (as in the chart included in the post). Perhaps it is good enough to remain at the low or medium levels as in both – things get done. True, the individuals concerned might not benefit as much but is the extra personal advancement worth the time and money it might cost to get them there?

      On another note: Great to see you two connecting 🙂


      • Thanks again Shim for a thought provoking blog.

        It’s good to focus on the team level with retrospectives. Many small individual changes can create a big team effect. When the team becomes better, their customers, stakeholders and in the end the company benefits.

        If at any time you want to take it to a higher level, a Retrospective of Retrospectives (RoR) (http://www.benlinders.com/2013/improving-collaboration-in-agile-projects-with-the-retrospective-of-retrospectives/) might be an effective way to do it. You’re doing groundwork by enabling team members to learn how they can improve continuously. An RoR creates the conditions to learn across teams and to increase collaboration in projects.

        Great that I’m now in contact with Terry, thanks for making this possible!


  2. Thanks Terry for your nice words.

    As with any agile practices, it’s the values and mindset that makes them work. Understanding why you would do retrospectives and having facilitators who focus on doing an effective meeting and getting to valuable actions makes a difference, as I described in http://www.benlinders.com/2013/how-to-adopt-agile-retrospectives/.

    I agree that retrospectives should be done close to the work and by the team itself – that way they will get the benefits from doing them. One other way to address apathy in retrospectives is to vary the exercise and to design a retrospective that serves the needs of the team and the conditions under which they are doing their work. Having retrospectives facilitated by capable people with a toolbox of retrospective techniques assures this.


  3. This is interesting Terry! Can ypu please contact me? I’de like to discuss this.


  4. Pingback: New PM Articles for the Week of July 28 – August 3 - The Practicing IT Project Manager

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: