Retrospective in an operations team?
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?
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 https://www.agilealliance.org/agile101/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
- 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.