The Agile Practitioner: The “Other” BPM

One of the key principles of the Agile philosophy is “people and interactions over processes and tools.” For this reason, BPM as we know it here at BPTrends often gets underplayed in organizations that are deep into their agile journey. The fear is that too much business process management will stifle change, which is fundamental to being agile. It is not the purpose of this Column to debate the merits of this thinking. The reality is that “Scrum,” a manifestation of the Agile philosophy, has many well-documented processes.

The BPM I am discussing here is only tangentially related. When I use the term “BPM” in my organization, the assumption is that I am talking about a “blameless post mortem.” Before deciding to write about blameless post mortems (BPM from here on out), I was going to write about trust. It turns out, trusting is a very important characteristic of organizations that enjoy successful agile practices.

It so happens that the BPM is one of the ultimate displays of trust as you will soon see. First, some background is in order. ITHAKA Harbors, where I work, recently had a guest speaker, Dr. Richard Cook of SNAFUcatchers. Dr. Cook's organization has been studying system dynamics in the software space for some time. They have drawn some interesting conclusions about the nature of software that proves relevant to the BPM.

Dr. Cook made an interesting point that had not occurred to many of us. That point is illustrated by the diagram below.

Other_BPM_fig1

Simply put, most of what goes on inside of working software is invisible to us. As systems become increasingly complex, the amount of internal activity that we cannot access during normal operations becomes greater. Thus, the only time we get to understand the weaknesses of our systems is when they fail.

Let me restate this, because it is an extremely important point. Only when systems fail do we get the opportunity to gather evidence of what was actually happening inside them. Far too many organizations squander these opportunities in an attempt to avoid future occurrences. Their goal tends to be to find the root cause of the problem and remediate it. This notion is deeply embedded in quality culture and is rarely questioned.

While understanding root cause is valuable, making it the focal point of a system failure often has the effect of papering over the more important opportunity. The blameless post mortem is an attempt to reverse this effect by focusing on the opportunity to learn.

The Learning Organization

Back in 1990, Peter Senge wrote The Fifth Discipline and launched a revolution called the learning organization. What he was really doing was codifying systems thinking for organizational management. These ideas manifested themselves in a variety of ways within organizations, but in my experience they were most often taken up by human resources as a way to foster better communications. Systems thinking principles most definitely found their way into quality management in the form of a structured approach to problem identification and resolution, but much of what the HR folks saw never translated.

Fast forward to 2012 and a well-known online marketplace was taking systems thinking to the next level. Etsy's software teams were understanding the message of Dr. Cook and his team. As a result, they may have been the progenitors of the BPM as documented in this post, now famous amongst Agile practitioners.

What they recognized is that until we can create a safe space to fully explore failures, we cannot squeeze all of the learning opportunity from them. This circles back to trust. When major systems fail and create significant economic impact, those involved will inevitably feel vulnerable. It doesn't take much to cast doubt on a process designed to explore what can be learned. Blame hangs like a spectre in the shadows.

All Failures are Human Failures

This is compounded be the fact that every failure can be traced back to one or more humans doing something suboptimal. Systems thinking requires us to start from this premise. Nothing useful can be learned by assuming that there is some ghost in the machine. It is only through modifying human behavior that we can learn to mitigate risks.

However, to mitigate risks often means adjusting behavior, which itself introduces new risks. This means that if we use the evidence available to change our behavior in hopes of reducing failures, we are really conducting an experiment with the potential to succeed or fail. Both outcomes provide equal opportunity for learning, although if there is excessive negative emotional baggage attached to negative outcomes, the opportunity to learn is curtailed.

Trust

This is why trust is central to the BPM and culture that surrounds it. Building trust means NEVER blaming someone for a failure. That word is bolded and in all capital letters because there are no valid exceptions to this rule. In order to fully understand this, let us take what might seem like an obvious example for laying blame.

Imagine a disgruntled employee who is about to leave the company deliberately sabotages some code to cause a system failure. After this person has left the company, the failure manifests itself and it is quickly learned that they were the cause. Problem solved, right? It was intentional malicious behavior. Nothing to be learned here. No way to avoid this sort of thing from happening.

If you believe that, you will have missed a huge learning opportunity. Furthermore, by blaming even an ex-employee, you are sowing the seeds of distrust that will infect current employees. As soon as it's okay to blame someone, it's okay to blame someone else. And, next time, that someone else might be ME!

The BPM

What might a BPM look like in this situation? First, we try to look back through the timeline of events leading to the failure. Did it start with the disgruntled employee writing malicious code? Not really. Why was the employee disgruntled? A good BPM will have all the people in the room that can help answer that question. If nobody knew the employee was disgruntled, then we have found our first systemic problem. Were there signs that didn't get uncovered? Were we checking in with that employee frequently enough? Did their manager build a trusting relationship with them, so that they felt comfortable expressing their concerns?

A good BPM facilitator asks questions to uncover not only what happened, but more importantly what assumptions people made at the time and what expectations they had about what happened. Did those assumptions and expectations align? If not, there is an opportunity to learn. Action items often result from a BPM, but they are not necessarily the goal. Learning is always the primary goal.

What if there were people who did know that our ex-employee was disgruntled? Knowing this obviously did not avert the failure in this case. What can we learn from this? Were there channels in place to address the source of the dissatisfaction? If so, what assumptions and expectations led those in the know about the situation to either take no action or the wrong action to effectively address the impending human failure.

These sorts of frank reviews of what people thought only work when everyone has complete confidence that there will be zero personal repercussions regardless of what is learned. Processes may need to change. Systems may need to be modified. Knowledge may need to be disseminated. Nobody will be blamed. That is not the same as assigning responsibility. The difference is an emotional one.

During one of our first BPMs at ITHAKA, one of the engineers stood in front of the room full of peers and managers recounting what had happened during a failure. As he described the chain of events, he came to the point at which he had made an incorrect assumption and began to blame himself for the error. Our vice president of engineering interrupted him and reminded him that this was a “blameless” post mortem. Even blaming oneself is inappropriate. By calling this out, our VP was confirming that we would not allow fear to stifle our ability to learn.

We may miss uncovering events or thoughts that would provide a more complete picture of what happened, but it won't be because someone was afraid to expose themselves. This is critical and the most difficult aspect of a BPM.

Fostering a Blameless Culture

I leave you with this challenge. In order to have a successful BPM, you must first have created an environment free from fear. We all seek security and stability in our work situation. Anything that appears to threaten that (whether it actually does or not) will inhibit our willingness to risk exposure. How can leaders remove such fears?

First, it is imperative that behaviors around blamelessness are 100% consistent. Breaches of this trust should be considered one of the most heinous of infractions. Some managers can learn to operate in such an environment and others will be less successful. If an organization is committed to a blameless culture, they will remove people who cannot learn to behave in a purely constructive manner.

When I became a parent, I disregarded the oft cited adage that there is no manual for being a parent. I read many books on the topic and gleaned that there are only two things required of a successful parent:

  1. Love your children unconditionally
  2. Allow them to grow up with their self-esteem intact

It turns out that these two things are highly related. Even if you love your children unconditionally, they won't assume that if your behavior suggests otherwise. When they make a mistake, making them feel like they “are” the mistake lowers their self-esteem. Furthermore, by not reinforcing your love for them during this time brings into question your love for them. We make this mistake by saying things like “how could you be so stupid?” Or, “you were a bad girl!”

So, when I child does something wrong, good parents talk about the behavior being bad and reinforce that the child is good and unworthy of the bad behavior. They create a space for learning and growth without fear. These same rules apply in creating a blameless culture in a business.

We build trust one interaction at a time. We also recognize that like one bad restaurant review, it will take 20 good ones to offset it. Being empathic, transparent and humble can go a long way to exposing yourself and thereby building trust. It is in this fear-free environment that learning is maximized, systemic problems are uncovered, and risks of failure, while never eliminated, are mitigated.

If you are interested in conducting BPM's in your own organization, this handy facilitator’s guide from Etsy may be helpful.

Tom Bellinson

Tom Bellinson

Mr. Bellinson has been working in information technology positions for over 30 years. His diverse background has allowed him to gain intimate working knowledge in technical, marketing, sales and executive roles. Most recently, Mr. Bellinson finds himself serving as a Scrum Master for ITHAKA, a global online research service. From 2008 to 2011 Bellinson worked with at risk businesses in Michigan through a State funded program which was administered by the University of Michigan. Prior to working for the University of Michigan, Mr. Bellinson served as Vice President of an ERP software company, an independent business and IT consultant, as chief information officer of an automotive engineering services company and as founder and President of a systems integration firm that was a pioneer in Internet services marketplace. Bellinson holds a degree in Communications with a Minor in Management from Oakland University in Rochester, MI and has a variety of technical certifications including APICS CPIM and CSCP.
Share

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share
Share