The Organisational Psychotherapy Retrospective

Are you bored with mundane retrospectives? I know I am. And so are the teams I work with.

Scrum Retrospectives

By way of example, let’s take a quick look at the Scrum version of retrospectives.

Scrum describes Sprint Retrospectives thusly:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

…

During the Sprint Retrospective, the team discusses:

• • • What went well in the Sprint?
    • What could be improved?
    • What will we commit to improve in the next Sprint?

Even thought the above description mentions assumptions, the bullet list makes no such provision. And I’ve never seen an IRL retrospective that raised the question of assumptions.

A New Hope

So here’s a new kind of retrospective you might like to experiment with – the OP Retrospective.

The OP Retrospective

The concept – and existence – of the Collective Mindset (a.k.a. Organisational Psyche) is foundational to Organisational Psychotherapy. It is the thing with which every OP therapist interacts.

Organisation Psychotherapy asserts that culture is no more, and no less, than a read-only manifestation of an organisation’s collective mindset – of its collective assumptions and beliefs. Read-only because culture cannot be manipulated directed, but only via changes to those underlying collective assumptions and beliefs.

Are development teams affected by the organisation’s culture? By their own team culture? By the organisation’s collective assumptions and beliefs? By their own team-local assumptions and beliefs? Are they in a position to shift either?

I’’d say “Yes”.

Benefits

Given the influence of collective assumptions and beliefs on communication, productivity, teamwork, joy in work, and a host of other individual, team, and organisational concerns, shifting assumptions can lead the team to a more effective place.

Means

But by what means? There’s no specific ceremony in e.g. Scrum to surface and reflect on collective assumptions and beliefs (culture). Maybe our retrospectives can, from time to time, serve this purpose?

If we wanted to use a retrospective (or a part of one) to explore cultural issues, how might we go about that?

I’d suggest my self-help Organisational Psychotherapy book “Memeology” might be one place to start. It’s stuffed full of questions that a team or group can ask themselves to explore cultural assumptions.

Here’s one example meme (meme #15, “Who Matters” – excerpted from the free sample version of the book:

15. Who Matters

Suggested Preamble

Senior managers, stakeholders, team members, the Big Team, customers, users – call them what you will, they’re the people that we’re doing the work for. They’re the people to whom we deliver the fruits of our efforts. They’re the people whose reactions – and emotional responses – decide the success or failure of our endeavours. They’re the people whose needs matter to us.

By way of example, here’s a partial list of the groups and individuals that are candidates for inclusion on a list of who matters:

• Your organisation’s senior managers and executives (“the higher-ups”).
• Your organisation’s Core Group.
• Your immediate manager a.k.a. “boss”.
• Your project manager (for folks working in project teams or on a project).
• Your product owner or manager (for folks working in product teams or on a product).
• Your development team (the team in which you are a member).
• Other development teams.
• Operations people (the folks that keep your organisation’s websites, production servers, etc., up and running).
• The Programme Management Office (PMO – if your organisation has such a thing).
• Testers (when separate from the development teams).
• The Process Group (the folks who stipulate how the work should work, or who support teams in their ownership of the way the work work – when separate from the development teams).
• Quality Assurance (QA) folks (when present).
• Your business sponsor(s) (internal budget holder, etc.)
• Other people across your organisation.
• Your (end) customer(s) (and their purchasing or procurement departments).
• Commercial partners.
• Regulators.
• Wider society.
• The planet (Gaia).

Suggested Opening Question

Who matters?

Suggested Follow-on Questions

How do we presently go about deciding who matters (and who doesn’t)?

How well (or poorly) does our approach to deciding who matters serve us?

How often do we fail to focus on key groups?

Can we safely exclude some people and / or groups from consideration?

Suggested Wrapping Up

What have we learned or come to realise, maybe for the first time, in our conversation here today on “who matters”?

How far apart or together are we now on the subject of who matters? Has airing the subject eased our concerns?

Is it time for action on who matters? And if so, how might we go about setting some action(s) in train?

Further Reading

Kleiner, A. (2003). Who Really Matters. Currency.

– Bob