Once you adopt Flow, the feelings of positivity, energy and productivity are really invigorating. Individuals and teams are energised, especially once the old barriers to delivery are broken down. These include silos, inefficient hand-off’s between teams or communications locked into untimely reports and not shared in the moment. That last issue is one of our big bugbears. Very few people are going to learn positive lessons from a report. Most people’s reaction will be to dread it ever being completed. Time too is of the essence meaning reports are rarely useful in today’s business world.
Nonetheless, “stuff” happens and the Flow of work can be blocked or, even worse, a project or initiative can crash and burn. It’s always imperative to understand what has gone wrong with a project and to learn from the experience in order to make sure that the Flow isn’t derailed in the future.
In our book called Flow Haydn and I explore the topic of Retrospectives and Continuous Learning. Retrospectives are used in Agile but are often a threatening experience for people. This is especially true when large projects or services fail. Have you ever heard one of these sentences:
“Someone is going is to get fired”
“Heads will roll”
“I.T. will be toast”
“Careers will be lost”
“We need a Post Mortem”
And it’s that last statement that really riles me. Using an analogy which is closely related to death is not only negative and intimidating but also it totally drives the wrong behaviour for teams wishing to improve.
In my opinion, the art of positive reflection, one that contributes to continuous learning, is most definitely missing in most companies today. I would attest the opposite. There is always an overriding focus on blame culture.
This fuels the fear of reprisals for individuals and provokes a culture of keeping one’s head below the parapet – an analogy based upon war. It also means that really valuable learning is kept below the surface. Hence the Flow won’t be improved and, ironically, all of that makes another failure inevitable.
In one of my previous blog posts called “Post Mortem or Retrospective” I wrote about how software engineering projects can sometimes go wrong and I shared a simple “Stop, Start, Continue” technique that one can use to tease out items that can help to improve the Flow, or reduce the risk of blockers arising in future.
Can we do more than that? Well, whilst using the “Stop, Start, Continue” technique could help – especially if the facilitator focuses on the good things to Continue – it’s sometimes better to use a visualisation that injects some fun into the process and attempts to deflect negativity within the Retrospective itself. This is particularly true if we need to reflect on a large project/service failure or when there are multiple stakeholders in the mix.
Hence we recommend using the Sail-boat technique. This Retrospective is not only quite simple, it also frames learning within a storytelling technique, which is often a powerful way to elicit the right lessons and make sure people listen to them.
To do Sail-boat you draw one big picture which includes a Sail-boat, an Island, Wind in the Sails, Iceberg, Anchors, Clouds and Sharks!
● The Island represent the team’s goals & vision for the project or where we need to go in order to get back on course for a service issue
● The Wind in the Sails are the things that worked well and drove us forward
● The Iceberg represents the risks and blockers that we encountered that stopped us from achieving the goals and vision
● The Anchors on the Sailboat represent everything that slowed us down
● The Clouds represent everything that worked well and the things that could help us in the future
● And finally the Sharks. These are things that worked against us. Perhaps an executive who kept stealing team members
And feel free to improvise. I attended a retro workshop recently and the facilitator used Pirates to depict the Audit team! A tad unfair, I hear you say….but the Auditors loved it!
Anyway, everyone in the session take it turns to write on post-it notes the items that they believe fit into each category and then stick them on the picture. I must admit that I prefer one big picture but it can get out of hand if there are too many people in the room! And hence if the group of people in the retro is too large, then simply use multiple flip-charts with each of the topics, as outlined above, on individual pages. This does make it easier if there are lots of post-it notes.
The facilitator looks for common points and removes duplicates. Multiple ‘common’ post-it’s are grouped together for a detailed discussion and very soon the key issues, blockers and things that propelled the team, come to the surface.
Some teams prefer to document the retro for wider distribution. It’s quite easy to use PowerPoint or KeyNote to put one topic on each slide in order to pull out the key learnings.
But the reason that I prefer the one picture, is that it can be placed on a wall near the team to serve not only as a reminder for them but also a visual representation for everyone in the Company to see, use and learn.
And finally, do make sure that you re-iterate the Retrospective Prime Directive before any type of reflective process. Which is:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”.
Write it on a flip chart, hang it on the wall, use it as a positive affirmation of the process and you won’t go wrong.
Sail-boat is one of a variety of techniques we advocate for an Academy Wall or Learning Wall. These Walls are a living record of the lessons that a company is learning about the functioning of its processes, the talents of its people, and the information that makes a real difference to efficiency and value. More on that in Flow.