There are three main ways or principles of DevOps. The first way of DevOps looks at the system level, and seeks to improve the efficiency or flow of the development pipeline. The second way prioritizes feedback loops, in order to make the process more responsive. Finally, the third way encourages teams to experiment with different methods and processes, in order to find what works best.

With the third way DevOps, teams spend each day learning. This focus on learning allows teams to operate more efficiently when they discover better methods. What does this look like in practice?

Establishing a Learning Culture

Many organizations refuse to experiment and try new methods because of the risk of failure. While their current methods may not be ideal, they get the job done adequately. In these traditional organizations, the risk of failure and lost productivity outweigh the potential to increase productivity in a development pipeline. Optimizations beyond the current processes are seen as unnecessary.

With the third way DevOps, organizations must encourage a culture of learning. Their belief is that failure will inevitably happen, and when it does, the best course of action is to learn from the failure and make improvements. The third way DevOps looks to removes blame and repercussions from failure as much as possible. When failure happens, the responsible team admits its mistakes, elaborates on why these failures occurred, and implements preventative measures so that the same failure might not happen again in the future.

Scheduling Blameless Retrospective Meetings

A “blameless” retrospective is not the same as the standard retrospective Scrum ceremony that many people are familiar with. Where the retrospective is regularly scheduled after each sprint, the blameless retrospective is reactive, and is only planned after an incident of some sort. All parties involved with the problem come together, and discuss what happened, and what can be done to address that vulnerability.

The best time to schedule a blameless retrospective is within two days of the problem that it is in response to. If teams wait much longer, they may have lost many of the details of what happened. It also gives other teams a window to experience the same failure, which could have been avoided if they knew what to watch for.

Traditionally, the retrospective is very exclusive. Only the individual team attends, and roles such as the product manager are frequently left out. In contrast, the blameless retrospective is inclusive. All team members responsible for the failure attend, as well as anyone who may be able to offer input, or share a different perspective on the issue. Because they are not blamed for their responsibility in the failure, everyone who contributed can give as much information as they have, such that the host of the meeting can gather all of the information and gain a better understanding of why the failure happened.