For many years, as I had worked in agile/scrum development environments, retrospective was a great tool for the team to come together and discuss.

In the new operations environment I work now for some time, we use agile/kanban.

Team's response to my suggestion to make a retrospective is around these items:

  • in an operational environment we have high pressure
  • discussions which are not very productive are not useful (because actionables are not possible due to item 1)
  • we should find out whether our management would support retrospectives

Are there examples/experiences from a similar situation?

4 Answers 4



Retrospectives work in any environment in any organization. They are not an Agile practice, although Agile has embraced them whole-heartedly as a reflection of the scientific method for improvement and adaptation.

There is almost no situations in which a retrospective will not be beneficial. Seek forgiveness, not permission. Run a retro.

What is a Retrospective?

From the Agile Alliance

The term “retrospective”, popularized by Norm Kerth (see below), has gained favor in the Agile community over better known ones such as “debriefing” or “post-mortem”, for its more positive connotations. This is also known as the “sprint retrospective”, or “iteration retrospective”, often abbreviated, e.g. “sprint retro”.

The term “reflection workshop” from Alistair Cockburn is encountered less often, though it appears to have influenced the Agile Manifesto’s wording of the corresponding principle.

Is there a defined format?

In short, no.

However most retrospectives follow a loose agenda of

  • Open
  • Gather Data about the time period
  • Generate insight about the data
  • Decide actions off the back of the insight
  • Close down

Each of these steps have a near infinite number of activities you can try, everything from speedboats to circle conversations to lean coffee to dot voting etc. You simply find the appropriate practice for novelty and effectiveness.

How do Retrospectives relate to Kanban?

One of the key principles of Kanban is to visualise your workflow.

If you are not conducting the occasional retrospective then I can assume you are not reviewing the workflow on a periodic basis for effectiveness. Furthermore, I would also assume you are not tracking the common metrics for a continuous flow system and are not using those metrics to drive improvements in the Kanban system.

Which, sadly, is a reflection that you are not really doing Kanban.

What your organisation is probably doing is either anti-Scrum or simply using a Kanban board without any of the underlying principles.

You need a retrospective to review these things.


If you are telling me that your environment is so inelastic and rigid that they cannot spare 1 hour to discuss team improvements then I predict that at some point that team will have a critical failing; either a single point of failure (individual) will leave, a security patch will be missed, something will be misconfigured. I cannot explain exactly what but it will happen and the organisation will pay dearly.

As the old mantra goes

Either you schedule time for maintenance or it will be scheduled for you by an outage.

In the Falklands War, a team of British special forces were advancing towards a position when they were engaged by Argentine forces using heavy machine guns. They took cover behind a small wall and considered their options.

Unable to advance and unable to retreat they did what they had been trained to do. They made a cup of tea and drew a plan in the mud. Over the next 10 minutes, drinking tea, they composed themselves, reevaluated their position, aligned themselves, using the wall for cover they returned fire while a small team flanked and won the position.

No casualties lost.

If a team, facing withering machine gun fire can run a retro in the freezing Falklands environment, your team can spare an hour to double check they are working effectively.

How can you convince people of the value of a retrospective?

Again, we can look to Agile Alliance for all of the information you need.

Retrospectives leverage the benefits of iterative development: they offer explicit opportunities to improve the team’s performance over the duration of the project

This is the critical part. Does your organisation want teams and departments that continually improve?

Retrospectives promote ownership and responsibility by the project team with respect to all aspects of the process; participants can understand the rationale behind all process decisions

This is also important but probably less of an easy sell to management. Teams that are empowered to solve their own problems and improve their own environments often yield much greater project success.

  • 1
    This is a great answer. I think it's also good to note that the structure/content of the Retro may depend on how your team is going to measure its success (and if they don't know that, then that's the first thing to cover in the Retro). A good discussion can also reveal cases where there's a different understanding of value - Is it more important to close lots of tickets or to have fewer defects / re-opened tickets? Also, if you're worried management won't like it, then tell them you want to try it for a fixed period - do it in a controlled fashion, and report back on results.
    – ConMan
    Commented Oct 18, 2021 at 6:41
  • Absolutely @ConMan - great point about differing ideas of value. Commented Oct 18, 2021 at 15:47

If your management is truly supporting agility, then management should support retrospectives. Retrospectives are the only practice called out in the Manifesto for Agile Software Development, and they also support some of the lean principles. If you aren't doing retrospectives, I'd consider that something to "just do". If people do push back, you can find out who doesn't understand lean and agile and who does.

If there's a lot of pressure on the team, then retrospectives should help alleviate some of that pressure by finding out the root causes and getting actionable items. Even if the team cannot take direct action, they can find areas for improvement and escalate to management to handle them.

The best way to get to productive retrospectives is to start having them and learning. It very well could be that the first retrospectives aren't productive, because people are still getting comfortable with the idea and figuring out what works. But if you don't try, you won't get good.

The only thing that I'd recommend is determining a good cadence for retrospectives. In my experience, unlike development teams, operations teams don't have a long planning horizon. Fixed-length iterations don't always work well. You may want to define when you apply a retrospective. In the learning phase, more is better, but too much can be overwhelming, so there's a need to strike a good balance.


And it's even a good idea to step back a little bit from the rigorous definitions found in the scrum bibles – which in this case (IMHO) might be a little bit too formal – and simply present it to the team in terms of "we should periodically take a look at what we're doing, and how we might be able to do it better – without pointing fingers at anyone."

Refer to it as brainstorming.

For instance – "when (not if) something goes wrong," what might have been the root causes? Can anyone think of a way that we could have caught it sooner, or prevented it altogether? Is there any way that we could have handled it better? As you were fighting the fire, could you have used some particular kind of support from someone else on the team? Given that we know that things like that are going to happen again, is there anything that we might be able to do now in order to be better prepared? Things like that. Open-ended, inclusive, maybe a bit hypothetical questions, and no finger-pointing allowed.

Operational teams often find themselves in "reactionary mode," and they tend to become used to it. But they neglect to look at that reaction process during the "down time" when they're not reacting. As they say: "When you're up to your (!) in alligators, you tend to forget that your original objective was to drain the swamp."


Retrospectives are an opportunity for a team to change the things within their power to change.

Even in a high pressure environment there is a lot that the team controls. Examples include:

  • When, where and how you talk to each other
  • How you respond to change - for example how the team handles a high priority request
  • The metrics you use to track your work (cycle times, categorising the types of bugs that get raised)
  • How you report - even when the team has little control over the work they are doing, they can still report on the things that cost them time
  • etc.

we should find out whether our management would support retrospectives

Absolutely. When you speak with your management, sell them on the idea of retrospectives. Some things you might say include:

  • If we were to improve our productivity by just 1% every two weeks, then in a year that would represent a massive rise in the effectiveness of the team
  • By talking through our issues we will become a stronger and more integrated team

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.