You Can Be Right or You Can Be Successful


I recently had lunch with one of my friends and we spoke about some issues that one of his teams was having. As a new team, they were still in the storming and norming stages and they were having some fairly heated discussions around some philosophical issues of software development. For those not familiar with software development you might think there is not really anything to get all worked up about, in which case you would be surprised at the level of intensity some folks have. The discussions the team was having bordered on “a holy war” and there appeared to be little hope for compromise.

I asked my friend a simple question, “would you rather be right or be successful?” This question is one I like to use and is a variation of the quote “you can be right or you can be happy” which I have, until I did the research for this blog, incorrectly attributed to Dr. Phil McGraw (for those who care, the quote is from Gerald Jampolsky). Basically, there are times when we can be right and we can be happy but often we have to make a choice. The same applies to success at work. There are times when we can have it all, but sometimes we need to choose whether we wish to be right or effective.

Recently there has been an outbreak of measles in the United States due to the fact that some parents have not been vaccinating their children. The reason these parents were not vaccinating was due to false science that has since been refuted. In other words, the truth is unequivocal; vaccines do not cause the reactions that anti-vaccination parents fear. These parents are 100% wrong.

Since these parents are 100% wrong and not vaccinating children can lead to adverse health issues in the community, it makes sense that public health officials would try to change the minds of the “anti-vaxxer” parents. They did try. Their first approach was to try and convince the parents by presenting the scientific facts. They theorized that by knowing the true facts, people would make the correct decisions. That effort failed. It seems that merely presenting facts did not change peoples’ minds.

succes04If presenting facts does not work, public health officials concluded the reason for the resistance was emotional and that emotional arguments would be more effective in convincing parents to vaccinate their children. That effort failed as well. (For a more details analysis see

This was surprising. Furthermore, not only are people not convinced by facts or emotion, but that when presented with factual or emotional arguments, the anti-vaxxer parents in the study were LESS likely to vaccinate their children. Evidence suggests that once someone has a strong belief in something, anything (or anyone) contradictory to that belief is seen as a threat. People who are threatened will cease to listen, much like a child will put a finger in their ears. People will erect walls to keep you out.

Knowing this, should we just give in to despair? Of course not. We need to stop trying to be right, whether presenting factual or emotional arguments, and concentrate more on being successful. The question is – what works in convincing people with strong beliefs to change their position? There is something that has been shown to work, something that lowers peoples’ walls and defenses and that thing is listening.

Instead of telling or implying people are wrong, we need to take the time to ask them about their position. We need to stop threatening them. Given the space to explain their position, people will not only feel less threatened, but also they will have to defend their own position and when tasked with defending their own position, people will slowly be able to see that they might not be the experts they think they are. This is where the walls and defenses are lowered so that other arguments might be entertained and listened too. Furthermore, showing respect to individuals and spending time with them will also make it more difficult to not listen. We listen to our friends not our antagonists.

A study of midwives in India found that arguments did not work with them either. What did work was “the rule of seven touches” which marketers know well. You must have meaningful contact and get to know someone (seven touches) before they are willing to trust and listen to you.

succes03This applies to my work of transforming companies from waterfall to agile approach. While I may be 100% correct and it may make me feel good to be right, by presenting my viewpoint as THE way, I will not meet my objective. If I choose to be successful then I must take a different approach. I need to get to know the people involved, understand their concerns, not threaten their ideas, but allow their defenses to be lowered by listening to their ideas and then, and only then, if my ideas are truly right will I have the chance to convince them of or, better yet, guide them to the truth.

In the end you can be right or you can be successful. You can’t always be both.

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.

Patterns, Anti-Patterns and Pilots – Guidance versus Governance

scientist and microscope

In the past, I have proposed that an agile transformation should follow “three pillars of success – Structure, Practices and Governance.” This was a concept I decided to borrow from something I read in the past. It made sense at the time that to successfully transform we need to change structure (build good teams, etc.) and adopt new practices both at the framework/process level (ie Scrum) and for software development (ie TDD, Continuous Integration). It was the concept of governance that, while it seemed to make sense, gave me some pause.

It didn’t take me long before I began to understand why I was uncomfortable with “governance” – primarily because governance seemed too top-down and heavy-handed. It seemed a holdover from the very school of thinking our transformation was trying to change. Perhaps it bothered more so because governance was something easier to implement via the PMO (and something that people were too comfortable with).

governance imageIt wasn’t that governance isn’t needed – even the games we play need rules. It would be chaos indeed if the length of a football field, number of downs or number of players changed from game to game. However, elevating governance seemed to embolden attempts by people in the organization to dictate even the smallest minutia. It was as if governance gave implicit authority to make every team run a west coast offense instead of concentrating on eleven players on each side.

Once governance lost its cache, the question remained as what to replace it with. It made sense to pick a word with a more appropriate servant-leader feel. “Guidance” became a much more palatable alternative. This was better, but it didn’t provide everything needed because there were some rules that would need to be followed. After a brief flirtation with the concept “Governance and Guidance”, in the end, we settled on “Guidance and Tools” as a replacement to the original concept of “Government.” The reason for this was that most of the “rules” revolved around reporting and the tools support necessary to some basic reporting.

Once we settled on the concept of guidance, a definition of guidance was needed. Over time, a working definition emerged that was referred to as:

Patterns, Anti-Patterns and Pilots

Not only does this option have alliterative qualities, but it also allows for a much greater environment for teams to self-organize and experiment. The process is simple. There are certain things that we know to generally work well for teams. One example is Behavior Driven Development (BDD). This would be considered a pattern. It would be a practice that is not only highly recommended, but would be fully supported by the organization from a training perspective for teams that wanted to try it. The key is that this practice would not be mandated. Each team has the option to choose and would be supported in their decision, but not every team would choose to (or have the maturity to successfully) implement. I often tell my teams, while I think driving is great there is a reason I don’t hand my car keys to my nine year old.

scientific methodThe second category would be anti-patterns, which are defined as those things that teams have tried but there is consensus that these have not worked. In other words, something becomes an anti-pattern when multiple teams have tried something unsuccessfully. In addition, there are things our experience as agile coaches and scrum masters have shown to not be effective which are added to the list. One example would be splitting stories between offshore and onshore for the same team. In practice, the anti-patterns begin to look a lot like a “scrum but” list.

The final category, pilots, is where the power resides. This category that allows teams to freely experiment with different ways of doing business without a great deal of pressure. The approach is empirical like the Agile Manifesto. Try something and see what works. There is no failure – only data.

The team identifies these experiments during retrospectives and is free to experiment on anything that is neither a pattern nor anti-pattern. These experiments follow the scientific method in that they have an identifiable hypothesis. The outcome from this experiment (usually lasting a single iteration) is either that the experiment has proven successful in which case it can be elevated to a pattern, the pilot did not achieve the desired outcome or the experiment needs to gather more data.

In the end, after changing from “Governance” to “Guidance and Tools” and outlining an approach to using Patterns, Anti-Patterns and Pilots, I found myself much more comfortable with the underlying “three pillars” approach of our agile transformation. I believe the new approach was better aligned to the underlying Values and Principles outlined in the Agile Manifesto. And, more importantly, I noticed that organization itself seemed more comfortable with the agile transformation and the teams were much more empowered to self-organize.

The Theory of Change & Why I Get In Trouble

organizational antibodies, agile, stock photo

organizational antibodies, agile, stock photo

As an agile coach that has been fortunate to work at a good number of clients over the years, you get an opportunity to experience some interesting similarities among clients. Some are tragic, some are funny and some are just downright intriguing. I recently spoke with another agile coach and I discovered one particular pattern that I have decided to refer to as organizational antibodies.

The talk in question was about the on boarding of coaches and things a coach tends to experience in the first few days on the ion. As we talked together and related our war stories I noticed that both of us had a something happen to both of us early in our engagements with companies. That common denominator was that both of us found ourselves in trouble with management in the new company within the first week or two of our gigs with our coaching ability or competence questioned or tested.

To hear that others shared my knack for getting into hot water early on was a relief to me. Of course, all of these early issues were resolved in short order, but it brought up a very interesting question of why this happened so frequently. As I look back on my personal experiences and after hearing the same from my colleague, a theory began to form in my mind. The end result is my Organizational Antibody Theory of Change.

The theory is this – there are many in any company who benefit from the status quo. Agile is about organizational change and those who prefer the status quo will find the agent of change as a threat to the corpus organizationus and will do their best to protect their system by attacking the agent of change. In other words, there are people in your company that perform the same role that antibodies provide in the human body.

At this point in my career I fully expect to have at least one of these reactions in every gig I start within the first couple of weeks. In the past it was quite disconcerting for me but now that I have experienced it and expect it, I worry less. The problem is always a tempest in a teapot, a minor annoyance that will fade away as my role is better understood and people realize that I am not a threat. Have you ever experienced organizational antibodies before?

The PMO is Dead. Long Live the PPMO!

letters, typewriter

letters, typewriter

One of the most enjoyable parts of my work and my life is delivering presentations or giving talks to outside groups. During one particular Q&A session I was asked a question along these lines – “If you had unlimited power in an organization, what would be the very first thing you would do to ensure agility?”

My answer, “Oh that is easy. The very first thing I would do is get rid of the Project Management Office.” At which I unfortunately took a pause. The collective gasp from the crowd filled that void and the ensuing murmur drowned out my next statement. You see, I was addressing a PMI group, and my statement proved to be provocative to say the least.

Unfortunately, what the now somewhat irate crowd didn’t hear (or pay attention to) was the statement, “And I would replace the PMO with a PPMO – a Product and Project Management Office.” Contrary to their thoughts that I wished to abolish the PMO, I was actually giving them more – another “P” as it were – a whopping 25 percent increase in letters!

I have railed against project focus other times because it is not a good model when it comes to creating software products.  A project has a definite beginning and end whereas software products do not. Of course, software products are sometimes “sunset ” but such plans are often not realized as quickly as proposed.  For example, I was once put in charge of “sun-setting” a software product with a timetable of three years. Now, seven years later I am no longer with that company, the company is no longer in that business and yet that old legacy software chugs along, making money for its new owner.

The funny thing about Project Management Offices in software development is that the majority of their work is really on software products. Of course, there are always some projects thrown in, like update the servers to a new operating system, but mostly we work on products whose future enhancements and support live far longer and cost far more than the original bright shiny objects our projects spun off.

The problem is that when we incorrectly treat our products like projects we tend to produce a huge amount of technical debt. Those bright shiny objects come with a huge hidden cost that project mentality allows to remain hidden. When we acknowledge that we are creating products we tend to take care of the long term health of the product, we make better decisions.

So let’s all say goodbye to the old PMO. It had a good run but its time has come. In its place let’s great with open arms the new and improved PPMO!

– Larry Apke

Timely Feedback – Why Agile Works

faded clock, larry apke

faded clock, larry apke

Most folks who know me well know I like to talk.

I especially like the times when I get to speak in front of groups, whether a face-to-face presentation, a small user’s group or 160 on a conference call all over the world (If you have a group and want a passionate speaker – feel free to call on me).

Sometimes my passion provokes long stories, explanations or asides. Lately though when I speak to others about why agile works, I eschew my sometimes verbose ways and reply with two words – “timely feedback”.

These two words refer back to my argument that software development is, as described by Snowden in his Cynefin Model, complex as opposed to complicated. And complexity begs for timely feedback.

Take a look at the most popular Agile processes and practices and you can see why they are effective. They all are merely ways to produce timely feedback.

Daily standup = daily feedback.

Review, retrospective, grooming, planning – all are timely feedback.

What is automated testing on code check in or continuous integration and deployment? Feedback. Pair programming is nothing more than continuous immediate feedback.

Conversely, what is waterfall than a dearth of feedback? Compared to the continuous timely feedback of agile, waterfall is a vast wasteland of opacity.

So next time you are asked why agile works, or why a shorter iteration is better, or why we should do pair programming, or why continuous integration, take the quick route and prove that brevity is indeed the soul of wit and simply say, “Timely feedback”.

Larry Apke