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.

Fear, Slack and Agile Transformation

leadership headstone

This past week I got the chance to finally check out the Silicon Valley Agile Trends and Leadership meetup at Yahoo in Sunnyvale. I really enjoyed the presentation that was given by Dan Kimble on The Leadership Crisis of the Digital Age.

Dan did a great job of framing the problems endemic in today’s high tech world – working too many hours, allowing too many interruptions, superfluous meetings, incessant checking of emails, the inability to unplug, etc. It was interesting to see that nearly everyone in the audience not only recognized the behavior, but agreed that it was irrational.

Fear ImageAfter presenting the group with the problem, Dan allowed discussion as to the possible root causes for such irrational behavior. There were a number of comments that seemed to dance around the true cause like one gentleman who offered that the problem was “culture”. Since this was my maiden voyage, my goal was to keep a low profile, but to those who know me, this is not always possible when the topic is Agile or software development (though on most other subjects I am likely to remain silent). I was compelled to speak up. The real root cause – FEAR.

Most interesting to me was that once that comment was made, it seemed to me that light bulbs starting going off. Fear. Ah yes. I check my emails at all hours so that my boss and co-workers can see how hard I work, how committed I am to the cause. I stay late so that people can see me and will know that I am not replaceable. If I have anything that looks like slack time, I may get sent back home (in some cases home can be very far away). We all seemed to know it, but it was almost like, even in that room of agile aficionados, we were afraid to give it a name.

Fear is a very good motivator. Like sugar it is great for short-term gain, but one cannot live on junk food alone. The problem is that our so-called leaders these days rely almost exclusively on this motivational junk food. The facts are that working over 40 hours is not productive, that not having down time leads to stress and burn out, that a culture of fear leads to employee disengagement and turnover, but facts be damned with our new breed of leaders.

The fear is so bad that all slack has been driven out of day. We do not have the time to think. We do not have the time to plan. We do not have the time to learn. We do not have the time to create long-term strategy. We do not take the time to train. We do not have time to form personal bonds with our co-workers. We do not have the time to build healthy relationships with our clients, let alone our own families. We do not have time to change. We do not have time to transform.

SlackIt is the lack of slack that is the single biggest factor that will derail your agile transformation (or any other significant workplace initiative), even though everyone will benefit from a proper adoption of agile. We are so busy implementing on the newest bright shiny object that we cannot take the time necessary to allow for a proper agile implementation.

So, if there are any “leaders” out there looking to make significant changes in your organization, like an agile transformation, please pay attention. If you want change, you must first remove fear. In its place, install some slack. Give back some time. Allow people to learn. Allow people to reflect. Allow people to change. Allow people to fail gracefully. You want to lead? Give them a reason to follow, something that aligns with their own intrinsic motivation. Stop using motivational junk food. Stop using fear.

Individuals, Teams, Systems – The Evolution of Agile at Scale

building for scaling agile blog 2

If you have any interest at all in agile, if you read agile blogs, if you follow agile trends, you most certainly have been (over) exposed to one phrase “scaled agile.” I, myself, recently received a certification for one of the new scaled agile programs. While I enjoyed the training I find myself not 100% convinced of its effectiveness.

Perhaps it is because of its very novelty that I remain skeptical.  Perhaps it is because I know front line people in companies referenced as successfully adopting who do not agree to the efficacy.  Perhaps it is because “scaling ” has simply become the latest excuse from management why agile cannot be adopted at their company (as in why should we bother when agile has not been Provence to scale).  In the end though I think the reason that I am lukewarm on the idea is because companies have been latching on to scaling before doing the initial groundwork.  in other words, scaling has become a red herring that induces companies to put the cart before the horse or the system before the team.

Once upon a time I coached one of the most amazing agile scrum teams. They were able to deliver things that their management found quite unbelievable so much so that they conveyed a meeting to find answers to why this particular group of people were able to so greatly outperform others in the organization. As an aside I was not originally invited to the meeting but the team lobbies for me to be there as they considered me one of the team and, as a team member, partially responsible for their success.

I remember very well one manager in particular gushing about the team performance and wondering aloud how such a miraculous feat could be “scaled.” “It is very much like the legends of people working together out of their garages,” the manager said, “but how can such a thing” he paused briefly to allow the group to understand what came next would be important, “be scaled?”

Before I realized that the question was merely a rhetorical one to introduce us to the new management buzzword “scaling”, I opened my mouth to answer. “Why we just create more garages,” I said. The answer, which I still stand by to this day, was roundly ignored by aforementioned manager and his manager reports and was about as welcome as a tart in a crowded elevator.  What I realized too late was that “scaling” was management’s way of avoiding any action, especially action that might involve hard work and opposition.

So, you might say, scaled agile to the rescue. Not so fast my friend. My amusing anecdote above was all about creating good teams (and creating more good teams). Agile at scale is about creating a good overall system. There is no need to scale agile until you have enough teams doing agile.

Here is the way I like to explain the evolution to scaled agile. Waterfall is inefficient because it tries to optimize individuals at the expense of teams. Good teams have a higher productivity, shorter time to market, higher quality, etc than individuals.  Enter Scrum. Scrum, when done correctly, optimizes teams. This is a huge advance and if your agile evolution ended here, you would have come a very long way.  Nevertheless it frequently happens that we cam optimize teams at the expense of the system. Once we reach this point it is appropriate to look at ” scaling” and how we can optimize the entire system.

To recap – waterfall optimizes individuals at the expense of teams. Scrum optimizes teams at the expense of the system. Scaling is the attempt to optimize the system. My experience (and it may be biased because like Freud I work mainly with the “sick”) is that companies abuse scaling because they either use it as a means to avoid agile or they rush to scaling without first making the tremendously difficult transition to creating effective scrum teams. My advice remains “build more garages.”

The Gang of Four – How Optimization Perseveres

room, lights, black and white

room, lights, black and white

It must be the new year that has me waxing nostalgic again. My last post was of rockstars past and while I was working on that on that one I was also reminded of some others I had a great affection for, a group that I was a part of we called the “Gang of Four”. This was a tongue in cheek nod to the Gang of Four who were authors of a book on design patterns.

The impetus for the Gang of Four was the desire of four agilists to try to do the right things with regards to implementing agile and scrum – to do things that were generally acknowledged as good agile practices but things that were not necessarily politically palatable. In other words, we were something of a clandestine organization. In fact, our meetings, while not in a secret location, were held in a location well off the beaten path – so much so that some of us had to literally walk 15 minutes to get to our meeting room. Over time we added another like-minded individual but kept the original name. Hell, we even had a ironic salute we would give to each other when we would pass in the hall. It was in the company of these wonderfully dedicated people that I spent the most enjoyable time I had on this gig.

What is important and pertinent to this blog is not the nostalgia or shout out to my compadres (though it pleases me to think they might read this and reflect with happiness), but that regardless of your office politics, your cronyism, your brown-nosing, your ladder climbing or your sheer incompetence and general ineptness, there will always (or rather you should hope there to always) be those who will have the uncompromising desire to succeed in spite of your inanity.

Like a tree whose roots will break rocks in order to drink of the water that sustains it, there will be individuals and teams in your company that will persevere against the all odds to do what is right, to do what is best for the company. Seek these out and when you find them give them the environment that they need because if they survive on rocky soil just imagine what they can do on a proper plot of earth.

Long live the Gang of Four.

Deming, Agile and SAFe

W Edwards Deming

This week was a big week in my quest for lifelong learning – one in which the learning should prove beneficial to my furtherance of agile values and principles; a week that I think I will think of a the week of Deming since I completed my reading of two of Deming’s books – Out of the Crisis and The Essential Deming – and I also completed my Scaling Agile Framework (SAFe) training in which I saw Deming’s face and quotes about a half a dozen times. SAFe itself can be thought of more of a homage to Deming’s work with systems than a software development framework or, perhaps more accurately, Deming’s systems thinking as it applies to software development.

While I will shortly take the SAFe examination test, I am certain that my recent completion of two of Deming’s books will serve me well when I take the exam. In fact, I am inclined to wonder if a healthy knowledge of Deming and deep knowledge of Agile and Scrum may be, while not enough to pass with flying colors, at least enough to merit a passing score. If for nothing else, there is a big value to SAFe training in that it will expose a huge number of people to Deming than might otherwise not find him, though in all candor I cannot imagine that anyone truly interested in creating high quality software would not find Deming on their on quest for knowledge and improvement. I find it somewhat sad the number of people in management who I have personally had to introduce Deming to over the years. Then again, if the folks I help become agile had prior knowledge of Deming would they have a need for me?

Managers from Hell and Agile Transformation

larry apke, whiteboard, agile

larry apke, whiteboard, agile

“Here’s something they’ll probably never teach you in business school: The single biggest decision you make in your job — bigger than all of the rest — is who you name manager. When you name the wrong person manager, nothing fixes that bad decision. Not compensation, not benefits — nothing.”

Jim Clifton, Chairman and CEO, Gallup – State of the American Workplace

A few months back I stumbled onto some research done by Gallup on employee engagement quoted from above. I would like to say that their findings were shocking, but having been an Agile Coach at many large organizations, I find the statistics (and conclusions based on the statistics) to track quite close to my own experiences.

For example, Gallup found that only 30% of all employees in the United States are “engaged and inspired at work” and about 20% are what have been defined as “actively disengaged” employees who “aren’t just unhappy at work; they’re busy acting out their unhappiness. Every day, these workers undermine what their engaged coworkers accomplish.” The remaining 1 out 2 workers are defined as “not engaged” and “essentially ‘checked out.’ They’re sleepwalking through their workday, putting time — but not energy or passion — into their work.”

And take a wild guess what the number one indicator of employee engagement is. You got it – their manager. In another article, Gallup estimates that “companies fail to choose the candidate with the right talent for the job 82% of the time” (Why Great Managers Are So Rare). In other words, next time you are in a meeting with five managers, it is safe to assume that only one (maybe two) were the result of good hiring decisions. If you are a good manager meeting with other managers chances are good that everyone you are speaking with was the result of a poor hiring decision!

The fact that management hiring decisions are so poor should be of some comfort to you the next time you are passed over for the management job you know you can do well, but is little comfort to active agile coaches like myself who are actively trying to help a company get agile and stay agile. On the other hand, knowing this goes a long way in explaining why most companies have so much trouble with the transformation.

Without the support of managers, lasting agile transformation will not occur. The fact that the bulk of your managers are poor leaders just makes it that much harder. Gallup estimates that only 1 in 5 current managers have the abilities to “naturally engage team members and customers, retain top performers, and sustain a culture of high productivity.” Agile is all about engagement. It demands leaders who can engage developers.

So you say you want to be agile? Why don’t you start with hiring better managers? Stop relying on third-party vendors to find your talent. Grow your talent. Recruit your own talent. Find CIOs, VPs, Directors, Managers, Coaches who understand agile, can truly lead agile teams and engage developers.

Go ahead. I’ll be waiting for your call. Of course, it may be a long wait.