The Myth of the Blameless Retrospective

DZone 's Guide to

The Myth of the Blameless Retrospective

Is the blameless retrospective movement strong enough to prevail? Only time will tell...

· DevOps Zone ·
Free Resource

I love the idea of the blameless retrospective. What's not to like? Getting all the members of a team together to blamelessly review work done at the end of a production cycle or in response to a crisis is a great idea. There's a great benefit in having a fearless, uninhibited, blame-free examination of a problem in order to improve. You get more information and you get better ideas. Every company should do it. The problem is that most don't. Why? Because many, if not most, corporations are, by nature, blame-seeking.

Blame-seeking in corporations is nothing new. It's the low-hanging fruit in cause analysis. Identifying a single point of failure or particular human shortcoming is usually a lot easier than doing the complex work required to really understand why a failure occurred. However, this is not to say that placing blame and taking actions based on that blame assignment is an ineffective way to address an issue. Sometimes it's justified.

For example, let's say you hire a plumber to fix your leaking dishwasher. He comes in and does the job. You pay him. The leak appears to be fixed. The next day there's water all over your kitchen floor. You call the plumber back. He takes a look and figures out the problem. He didn't tighten a valve; he's to blame. So, he makes the fix, no charge. Good for you. The next day your kitchen is flooded again.

Now, if we were doing a blameless retrospective, we'd call the plumber back and have a kumbaya moment to discover what's wrong with your hiring process and his professional behavior. You'd devise ways for you and the plumber to improve. But is that really your job? The logical course of action is to fire the obviously incompetent plumber and call another one with a proven track record of doing the job right. You don't want to examine the historical facts that led up to the flooding. You don't want a deep analysis of your hiring process. You want a dry floor! That's why you spent the money. So, you blamed the cause of the problem (plumber number one) and hired another plumber. You moved on. Your actions were justified.

Few IT Departments Exist in a Vacuum

Putting dramatic effect aside, there's a reason why the idea of a blameless retrospective is mythical for most companies: blame-seeking tends to be commonplace in older corporations. It's a matter of cultural history. Newer companies such as Google, Etsy, and Airbnb are, in many ways, poster children for the Agile and DevOps sensibilities that champion the value of the blameless retrospective. They're the new kids on the block, so they can have the nice, new processes to go with their nice new toys. They have little to no history with which to contend. But, most IT Departments live in old-school business sectors such as insurance, banking, defense, medicine, retail, entertainment (think Boston Red Sox and Landmark Cinemas), and manufacturing (Maytag, Mack Truck, and Pioneer Seed). These companies are sitting on a pile of legacy code and legacy processes, as well as a pretty entrenched legacy business culture. The effort required for them to migrate to a sensibility that makes a blameless retrospective even remotely possible is nearly as great as asking the airline industry to get off fossil fuel within the next two years.

Add in the ill-conceived perception held by many on the business end of corporate management that a blameless retrospective translates to a "no consequences for bad behavior" retrospective and you have a strong, if not intransigent, resistance to adoption. To top it off, there's still that gnawing little fact that blame-seeking can work, as demonstrated in our little dishwasher example at the beginning of this piece.

The problem is when blame-seeking becomes overwhelmingly counter-productive. When this happens, you get a culture of CYA, in which decisions — in some cases, life and death decisions — are made according to perceptions and opinions rather than facts, because the facts are hidden deep in the caverns of some frightened employee's laptop.

So, what's to be done?

Accepting the Dynamics of Blame-Seeking

This may sound strange, but the easiest way to promote a culture in which truly blameless retrospectives can take place is for a company to guarantee that all employees can have a job forever, even if they mess up. They might be "put out to pasture," but they will not run the risk of financial setback due to getting fired. The refrigerator will remain full. As a result, other than losing some organizational status, those who are the subject of blame have no motivation to hide information or hold back from making a contribution.

As much as I wish otherwise, such a solution is far-fetched and impractical. So then, what's to be done? Should a company just go along with the idea of the blameless retrospective, yet treat it as a myth; something that everybody believes, but nobody thinks is really going to happen? Probably not.

The more real-world approach is to start with acceptance. Accept that corporations are, by nature, blame-seeking. Also, accept that blame-seeking is not solely confined to the business end of the corporation. We in IT are not without sin. If you have any doubt, take a look at the illustration to the left from GitHub. Notice the "Blame" Figure: button. It's there, and it works.

In this case, blame is useful. When something goes whacky in the code, we want to know what's causing the problem so we can fix it. And, if truth be told, knowing the culprit — the last person to touch the code — can provide a small sense of entertaining satisfaction when we admonish the transgressor over after-work beers.

But I digress.

The point is that developers live in the same blame-seeking world as everybody else who works in a corporation. At some point, someone is going to get the finger pointed his or her way. So, we might as well be honest about it. Where things get difficult is when those who are the object of blame are unaware of the ramifications of having the finger pointed at them.

Sometimes blame is benign. Other times it's harmful. It's the difference between remediation and consequence.

Remedial blame looks for the cause of the problem in order to make a fix or improvement. Consequential blame goes beyond remediation. Consequential blame looks for a wrongdoer. It has serious ramifications. When consequential blame is cast, a person can lose his or her job or be subject to legal action. And yet, we rarely talk about it until it happens. Maybe we should.

Getting Honest About Blame-Seeking

While I am not sure that a blameless retrospective is really possible, I think honest retrospectives are, once the boundaries and ramifications of consequential blame become apparent. The mistakes that deserve consequential blame — the type of blame where someone gets fired — needs to be common knowledge within the workforce. Sometimes they are; for example, around security policies and overt theft. Many times, they're not. Let's face it, there's a lot of conduct in IT — crazy code, for example — that is a firing offense, yet is known according to nothing more than tribal knowledge. I know of more than a few cases in which consequential blame was only made apparent during that final trip to the HR Department to sign separation papers.

The best way for honesty to prevail is to make all the reasons for justifiable blame well-known.

My thinking is that the best way for honesty to prevail is to make all the reasons for justifiable blame well-known. While the possibility of a blameless retrospective might be the elusive butterfly on the landscape of information technology, honest retrospectives are possible, provided there's the willingness to know and accept the consequences of blame. Yet, in order to avoid the paradox that is inherent when hoping for honest retrospectives in an essentially blame-seeking culture, an added ingredient is required: courage present somewhere in the organization to be honest regardless of the consequences. Admittedly, this is a tall order.

Blameless Retrospectives: Moving From Myth to Reality

Given my description of current retrospective processes in a blame-seeking organization, things might seem pretty bleak. In many cases they are. There is, however, a light at the end of the tunnel. According to the BBC, Professor Richard Foster from Yale University reports that the average lifespan of a corporation listed on the S&P is expected to be 15 years by 2020. This translates into a lot of turnover.

As those older companies acquire newer ones (think IBM acquiring Red Hat) or get replaced by newer ones altogether, the chances increase that a culture that fosters blameless retrospectives can emerge as the norm in corporate governance, if for no other reason than turnover among both managers and contributors. Just as a pickle can never go back to being a cucumber, those who have experienced the benefit of the blameless retrospective are loath to return to the days of review by finger-pointing. The benefits far outweigh the risks. The question is, then, is the blameless retrospective movement strong enough to prevail? Only time will tell.

This article was originally published in our Scaling DevOps Trend Report. To read more articles like this, download the report today!

Read Today  

devops ,retrospective ,scaling devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}