Benefits of Publishing Retrospective Results
Many teams go so far as to publish the results of their blameless retrospective for other teams in an organisation to see, for good reason. While nobody likes to have their mistakes made public, it can be very beneficial. Making these results available to other groups does not broadcast failure, but rather identifies something that could have happened to anyone, and how one team encountered and overcame the problem.
If retrospective results are not published or shared between teams, every team essentially runs the risk of encountering the same problems. While the ideal situation would be for no team to ever have problems, issues are inevitable. When problems arise, they take time to discover and address. Limiting this wasted time to one team, and informing all other teams afterwards, saves much more time over allowing multiple teams to make the same mistake and come to the same realisation in their own time.
With published retrospective results, teams can individually analyse their own situations, and see if they pose some of the same risks that resulted in a problem for one team. Teams should publish retrospective results to the pipeline or organisational level. Any groups that could share some of the same risks should be informed of the results. Even for teams that work on different products, or under different circumstances, there could be vulnerabilities or risks that teams share. Even if the risks have different preventative measures, the goal is to make teams aware of what could happen. Teams might not all apply the same precautions and guidelines depending on their own processes, but rather they should incorporate measures that fit with their own methods and practices.
Decreasing Incident Tolerances to Find Smaller Failures
For nearly every project in any organisation, the first iteration is almost always full of problems. People inevitably make mistakes. In these new projects, if teams attempt to solve every problem immediately, they will likely be overwhelmed and unable to accomplish much in any decent time frame. Most components of a product will probably have some error or problem. Instead, teams should focus on the largest, most severe problems and gradually work through all of the issues.
An old adage tells that you eat an elephant one bite at a time. A project that is filled with failures can seem daunting, like being tasked with eating an entire elephant. However, when viewed as individual problems, none of these issues are impossible. Even the most severe failures can be overcome when handled on its own. So by taking one bite at a time, taking care of just a few failures at once, teams can work through every problem that they face on a project.
The best way to create this manageable stream of failures is to use an incident tolerance threshold. Initially, the team sets the threshold very high, so that they only work on the most severe issues. Once the team has corrected these large issues, they decrease the incident tolerance. With a reduced incident tolerance, the team addresses problems that they ignored at first while working on bigger problems. As the number of failures decreases, the team continues to drive the incident tolerance lower. Eventually, the team should reach a point where they can handle any new failures that occur, as they have already addressed all of the existing and more severe issues.