Type Three and Four Errors – Solving the Wrong Problems Flawlessly

covered wagon

For some reason, I find myself attracted to statistics and probability. This is one of the reasons I love the books of Nassim Taleb, anything that Stephen J. Dubner and Steven D. Levitt of Freakonomics fame write, the social economics work of Dan Ariely, etc. Most recently I was doing some research and ran into the work of Ian I. Mitroff and Abraham Silvers and “The Error of the Third Kind (E3)”.

Because I had read so many books that have statistics and probability as themes, I was familiar with Type One and Type Two errors. Type One errors can be defined as incorrectly detecting an effect that is not present. Type Two errors, on the other hand, occur when one fails to detect an effect that was present. However, Type Three and Type Four errors were new to me.

An Error of the Third Kind (E3), as presented by Mitroff (and others), are those where the wrong problem has been not only proposed, but it is solved flawlessly so that it has the perception of being correct. Mitroff states:

The vast majority of books on management contribute to E3 because they imply that managers already know what their important problems are, for example: how to downsize in the most efficient way, how to improve chances for success in the global economy, how to install the correct Total Quality Management program, how to design the right reward system and so on. In each case, the unstated assumptions are that the essential problem the organization is facing is downsizing, global competitiveness or whatever it may be. While the assumptions may be correct, they are so crucial to formulating a problem correctly that they deserve to be challenged in the strongest possible way by asking tough questions.

puzzleThis type of error reminds me of the argument I often hear from clients that “we have always delivered” or “waterfall has worked for us for years.” The real question that needs to be answered is not if one has “always delivered” it is “what has one always delivered?” If, in software development, the code is difficult to maintain, if it has a great deal of technical debt (for example, only concentrating on on-time delivery), can it really be said that one has delivered successfully?

When someone mentions “waterfall has always worked for us”, I believe this is an example of Type Three error. The real question – has waterfall been optimal? The example I always give is that the covered wagon was successful for transportation, but when I look out the window of a plane, I don’t see any crossing the prairie. In the case of those applying the values and principles of agile properly there is little doubt as to which is the airplane and which is the covered wagon.

Type Four errors may be even more insidious. These are sometimes better known as HiPPO errors (Highest Paid Person’s Opinion). These are seen in companies where top down hierarchical control is the norm. In their book, Dirty Rotten Strategies: How We Trick Ourselves and Others Into Solving the Wrong Problems Precisely, Mitroff and Silvers state:

The Type Three Error is the unintentional error of solving the wrong problem precisely. In sharp contrast, the Type Four Error is the intentional error of solving the wrong problems…

The Type Three Error is primarily the result of ignorance, a narrow and faulty education, and unreflective practice. In contrast, the Type Four is the result of deliberate malice, narrow ideology, overzealousness, a sense of self-righteousness, and wrongdoing.

By allowing others to improperly frame the question, a troublesome groupthink is created that allows many people to solve the wrong problems precisely.

As companies go down the road to Agile transformation, it is helpful to understand the Type Three and Four errors so that we don’t fall into the trap of solving the wrong problems flawlessly.

Too Many Bright Shiny Objects (BSOs)

 

As an Agile Coach who has worked at his fair share of large companies, I spend a lot of time researching what can go wrong with an Agile transition. One of the things that I don’t recall being mentioned is the sheer number of projects that some companies try to run concurrently. I have actually worked at more than one company that bragged about how many projects they were able to juggle at one time. These organizations are great at starting work, but very poor at delivering work as if there were some kind of incentive for the number of projects started versus the number delivered. Unfortunately, this is often the case with companies measuring and paying bonuses based on the number of projects they are working on as opposed to how many actually deliver any value.

The problem is huge and is a confluence of some very bad management decisions and assumptions – management deciding there is value in chasing every opportunity (every bright shiny object – BSO), management assuming that people can effectively work multiple projects (for instance, someone on four projects can be 25% effective on each one) and management obsessively making sure that everyone is 100% busy 100% of the time.

The truth of the situation is that most BSOs are not very valuable. Studies have shown that 64% of software features are “rarely or never used”. This would seem to me to open up the opportunity to slim down the number of concurrent projects to just those that would be used and would provide the most “bang for the buck.” This is something that truly Agile organizations understand, but doesn’t get much press. Perhaps if we stop trying to be everything to everybody then we could focus our efforts on those things truly important. What is the point of instituting the discipline necessary for agile software development if we don’t exhibit the same discipline when choosing what to develop? In other words, building the wrong things right is almost as bad as building the right things wrong.

The next problem is that people are treated like widgets. I had one VP once mention in a meeting that “developers are a commodity that I can snap my fingers and replace at a moment’s notice anywhere in the world.” Not true. People are not widgets or commodities, especially in software development where the productivity of a single developer can be as much as 10x higher than another (even when adjusted for education and experience). Try to get that with a factory worker or brick layer. The truth is that when you pull people in too many directions that their productivity decreases due to increased communication overhead and context shifting. It is even more pronounced in an “Agile” transformation. It doesn’t take a rocket scientist to note that a person on three projects (and three project teams) would need to attend three times as many standups, reviews, retrospectives, etc.

Lastly, organizations seem obsessed with making sure that everyone is 100% billable to projects. In order to be 100% billable this means that someone must take on more work and projects than they can concentrate effectively on. The number of people who literally brag about how busy they are is astounding, as if there were some value in not being able to effectively plan one’s time to be effective as opposed to just busy. It is not the individuals fault; they are merely following the lead of the organization that tracks hours. God forbid someone is not 100% busy because they could be next on the chopping block. And mark my words; companies that track such things will always be going through some kind of employment convulsion from time to time if for no other reason than companies that are not effective are more vulnerable to market changes (why they thirst for agile in the first place, but they never make the changes that would allow them to drink). 100% busyness results in queues, in work waiting. We brag about keeping someone 100% busy – why not brag about keeping our computer CPUs at 100%? Because it is ludicrous. As Demarco aptly points out in his book Slack, efficiency is the enemy of effectiveness and it is about availability not busyness.

As I have stated many times before, the problem of chasing BSOs is that the people in charge of making decisions about software development simply have no clue what software development is all about and what works. Running too many projects concurrently is a sure way to never deliver anything. If you want to be effective delivering, instead of just looking busy, cut down the absolute number of projects you are currently implanting. The results will astound.

In “Getting the Most out of Your Product Development Process”, Adler studied a dozen companies over 8 years, including Raychem, Motorola, Harley-Davidson, Hewlett-Packard, General Electric, AT&T, Ford, General Motors and NEC. Their conclusions:

First, projects get done faster if the organization takes on fewer at a time. Second, investments to relieve bottlenecks yield disproportionately large time-to-market benefits. Third, eliminating unnecessary variation in workloads and work processes eliminates distractions and delays, thereby freeing up the organization to focus on the creative parts of the task. The result: Business units that embraced this approach reduced their average development times by 30% to 50%.

 Ever wonder why coaches always harp on small, co-located, dedicated and stable team? Now you know. They do it because it simply works better.

Want to be Agile? Reduce your number of concurrent projects and replace this approach with small, co-located, dedicated team and see a reduction in development times by 30-50%. More importantly, when people are able to focus the quality of the work increases tremendously, allowing for better and faster delivery in the future.