Deflecting Attacks With Invertible Failures

fail to learn, instead of failing and falling

Defining “invertible failure”

An invertible failure is a failure that has the potential, with the correct treatment, to be transformed into a success. They are known risks that we accept in order to learn and adapt.

We sometimes refer to invertible failures as “small failures”, and non-invertible failures as “large failures”. Large failures are unanticipated in contrast to invertible failures. When large failures occur, it often requires desperate measures in order to avoid catastrophic consequences.

At Substantial, we attempt to proactively find invertible failures in as many places as possible. Here are a few examples of invertible failures we have found to help our business.

Frequent Delivery

We have learned that waiting to deliver value-adding changes generally complicates their delivery to customers. Excessive down-time, rollbacks, and lost data are some of the possible effects of a complicated delivery.

We have found that the size or magnitude of these complications changes proportionately to the time between deliveries. The longer we wait to deliver the more complicated problems arise.

Delivering frequently allows us to minimize the impact of each delivery. Any one delivery has a much smaller potential of failure. Also, the failures tend to be simpler to solve since the amount of change is smaller.

Furthermore, we can expand the definition of delivery beyond simply “delivering software to active users.” As a client-services company we also often think of delivery as presenting value to our clients.

This “value” could be a prototype of a possible feature, having a collaborative design session on a new feature, or providing results of a recent performance analysis.

We have found that even these “soft deliveries” tend to be more valuable when delivered more frequently. In other words, we keep the value metronome ticking away at a regular interval.

Ad-Hoc User Testing

One of the most disappointing things in software development is to build something beautiful, functional, and valuable to our client’s business only to ultimately find that the target users can’t figure out how to use it.

Significant time, money, and opportunity put toward creating something that just doesn’t work for users is a large failure. The software doesn’t work when we expected it to. Now we have to spend even more time and money revisiting this functionality in order to make it usable.

This is usually the result of assuming that we already know the way to make a feature usable and forget to ask the question of whether our assumptions, or the existing patterns actually result in a usable feature.

Traditional iterative development processes put value in delivering software to users, then using feedback to further refine and improve that software. While we do encourage an iterative product development process, what if there was a way to incorporate a light process to help insure we don’t build the first iteration in a way that is already unusable?

In order to topsy-turvy said large failure into an invertible one, we sometimes perform ad-hoc user testing or “hallway testing”. This testing is informal unlike formal user testing which is a fairly involved process often involving many hours of preparation and execution.

With ad-hoc user testing, we can turn a large failure into an invertible failure. We build a light prototype, test it, and iterate. This way we can apply iterative product development practices and still provide a better user experience the first time.

Pomodoro

Have you ever set your mind to accomplish a task then found yourself hours later wondering how you didn’t finish it? Sometimes, when building software it can be easy to fall into a rabbit hole trying to solve a problem or build a feature only to find yourself at the end of the day wondering if you’ve progressed at all.

Spending a day failing to achieve one complicated task is a large failure. You leave your desk demoralized after failing to achieve your goal. Furthermore, there may have been other more important things to do in the meantime.

We use the Pomodoro Technique on some of our teams to help make this an invertible failure. Pomodoro is a time management method that encourages setting a goal, then working in short shifts. Often these shifts are as short as 25 minutes. In between each shift, or “pomodoro”, you take a break. During these breaks, you are encouraged to disengage from your task at hand.

One great thing about pomodoro is that there is a regular cadence of work. At the beginning of each cadence, we reflect on whether we met our last pomodoro goal and what our next should be. If we didn’t meet the last goal, why? Was it too large a thing to accomplish? Were we interrupted or otherwise distracted?

Frequently reflecting on our own progress encourages us to make adjustments. Sometimes this is an adjustment to a technique. Other times we find a different way to achieve our goal, or a different goal entirely.

Conclusion

We make invertible failures by anticipating failure, reducing it to mitigable risks, and attacking each of those risks separately. That way, instead of failing and falling, you fail and learn.

Photo by Flickr user kesara_rathnayake

Tags: | , , ,

0 Comments

Add Comments

Comment