Retrospectives – Wronger and Righter

Retrospectives – Wronger and Righter

I have yet to see a development team get any real value out of a retrospective. Not that it seems impossible, just that it seems few to none understand how. In my opinion, the relative failure of retrospectives goes a long way towards explaining the superficial nature of so-called continuous improvement in most agile development shops.


The fact that retrospectives are disassociated in time with the problems (and successes) with which they concern themselves is an issue. Andon, which gives workers the opportunity to stop the line as soon as a problem occurs, points the way to reducing or eliminating this temporal dislocation (and thus to tackling the rationale opposing a stop-the-line approach).

And I have seen few teams with any clear approach for converting the output of retrospectives (e.g. improvement suggestions) into actions for the next (or future) iterations, let alone prioritise these against (other) backlog items e.g. pending user stories or new features.


Anything that gives folks an opportunity, to talk, and reflect has got to be a good thing, in my book. So that, at least, is an entry in the “plus” column for retrospectives.

How to turn the ordinary retrospective into something extra-ordinary? Go back to its roots. Specifically, PDCA (the Shewhart Cycle). Many folks see the word “Plan” in the simple context of e.g. Sprint Planning and Release Planning (Scrum). But in PDCA proper, derived as it is from Francis Bacon’s original “Scientific Method”, “Plan” means hypothesise:

  • “hypothesis” – plan
  • “experiment” – do
  • “evaluation” – check
  • (Control – a later addition) – act

In this scheme of things, any retrospective is pointless unless it’s answering the question “did what we expect to happen – our hypothesis – actually happen?”. If so, why so. And if not, why not? Absent an initial hypothesis, we can never ask ourselves this question.

OODA (Observe-Orient-Decide-Act; Boyd) and LAMDA (Look-Ask-Model-Decide-Act) – close cousins of PDCA – both add emphasis on the context for formulating such hypotheses.

So, next time you start a Sprint, Cycle, or such like, get your hypothetical ducks lined up for the benefit of the ensuing retrospective.

And let us know how it goes?

– Bob

  1. I like the way you bring together the planning and the retrospective meetings together, very yin and yang.

    One thing we’ve discussed is how the cadence of the retrospective and planning session bring a rhythm to work that folks feel they would miss with a complete reliance on immediate resolution, a hypothesis only at this stage.

    We’re also hypothesising that an explicit policy to limit WIP will force the Andon moments naturally, be interesting to see if we can validate that thinking!

  2. Strange! For I’ve seen almost every team I’ve coached get some significant benefit from retrospectives, at leaat initially. Mainly because I ensure that they pick two or three items (prioritised hopefully) to act on. Some of these actions fall on the Scrum Master or the engineering manager. I agree that most, if not all teams, don’t get a huge benefit. Yes, also I’ve not seen them put retro items into the product backlog. But this may be a sign of barely sufficient collaboration with the product owner (limitation of Scrum Master/coach!?!).

    • ceezone said:

      I’ve now written about this (a hopefully constructive explication)

  3. Bob,

    Sorry to hear that you have not seen any development teams get value out of retrospectives. Every team I’ve worked with (even when my official role was as a developer instead of Scrum Coach) has gotten much improvement out of them.

    Sounds like the teams you work on need some help or coaching with the technique. I would be happy to put you in touch with someone that can help.

    In the mean time, here are some articles that might help:

  4. warrp said:

    Thank you for this post – it has reduced my fear of failure and encouraged me to keep improving.

  5. Tobias said:

    There are different kinds of impediments a team faces, and different ways of focusing on them. I agree that it is helpful to “stop the line as soon as a problem occurs”, but only in certain cases. Problems that benefit from this solution are more often than not, technical problems—mechanical problems. There are deeper, systemic or relationship issues for which this approach wouldn’t be appropriate, as nothing would get done (!).

    I think of the periodic retrospective more as “reflection time”. This is the time to take a broader look at process, system, and relationships and to identify what is holding a team back. Usually, these kinds of impediments cannot be resolved by the team alone, and require the support and help of other people in other parts of the organization. Creating an Improvement Team to work with development teams on resolving these issues is important, as otherwise, as you mention, they are just left hanging.

    For those issues a team can resolve, some conversation, perhaps some research and other non-development actions are required. This is where it helps a team to have some space between the end of the reflection, and the start of the next timebox of product-focused work. Knowing they are on top of the impediments (or at least one), that it is recognized by their supporting teams as important (perhaps added to the backlog) and that it will be given attention will free up the developers’ minds to focus better on the upcoming work. Rushing straight from retrospective to product planning will cause our focus to always be on product. This is not all there is.

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 )

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: