The Seven Universal Human Emotions

According to one theory, there are seven universal human emotions: anger, contempt, disgust, fear, happiness, sadness, and surprise.

At work and sometimes in everyday life these emotions are filtered because of social conditioning.

In the West, men are not supposed to feel fear or sadness.  Men who express fear or sadness are called wimps.  Women are not supposed to feel anger or contempt and if they express anger or contempt they are called bitches. This oversimplifies, but it is roughly true.

Because certain heart-felt emotions are not considered becoming, not expressible, they are concealed from others.  I call this concealment the distance between  heart and face.  When men feel fear (“I am afraid that I will lose control when transitioning to Scrum”) they may transmogrify this disapproved emotion into contempt (“Scrum will not work in my organization because it does not make logical sense”) since they are not allowed to express fear.

When my face and heart are not in alignment this can cause confusion: the person I am communicating with receives a mixed message.  One thing is said, but a different thing is picked up emotionally. Creating an environment that supports the Scrum values of openness and courage reduces the number of moments when face and heart are mismatched.  This both speeds up communication and enhances the integrity and happiness of all concerned.

Why I Don’t Use the Phrase "Continuous Improvement"

Continuous means “uninterrupted in time, sequence, substance, or extent”. Continues improvement sounds so good, doesn’t it? But that is not the sort of improvement experienced by organizations going over to Scrum.

In my intro to Scrum classes, students create different types of paper airplanes, measure the distance that they fly, and then modify the planes to make them fly further. The students collect data on the distance that each type of plane flies after each throw. A typical chart looks like this:

             Plane #1      Plane #2
Throw #1        5                8
Throw #2        3               13
Throw #3       10               20
Throw #4       11               14
Throw #5       10               25

The planes always fly further in the last throw than they did in the first throw–but the improvement is almost never a straight line. If the team were to quit as soon as they stopped continuously improving, the planes would never reach their full potential.

An organization transitioning to Scrum is likely to have many things changing at once. People are changing roles, the work tempo is changing, interactions with customer are changing. Much is going on. At any given time, the organization will often find that some things will be getting better and some things will be getting worse.

If the organization expects “continuous improvement,” then it is likely to be continuously disappointed.

Is Your Belief in Scrum's Value Testable?

Can any evidence be marshaled or any argument made which would cause you to conclude that Scrum is not valuable?

If you answer yes, then you have a testable belief in the value of Scrum. If no, then you have a non-testable belief in the value of Scrum.

I note that here is nothing inappropriate, incorrect or shameful about holding non-testable beliefs. I have a non-testable belief that my family loves me.

Knowing whether your belief in Scrum is testable or not can be useful. If I have a non-testable belief in Scrum then when a client asks me to provide data about the utility of Scrum I might say, “I am happy to do that. Know, however, that there is no evidence which will cause me to change my belief in the value of Scrum.”

If my belief in Scrum were testable, I might dedicate some time to looking for evidence that would cause me to conclude that Scrum does not work. If I find this evidence, then I might choose to stop being a Scrum consultant.

A second reason to think about the testability of your belief is that it might inform your discussions with other Scrum aficionados. A person with a testable belief in Scrum might say, “I analyzed 23 companies that used 6 approaches and Scrum was 45.3% better than the second best approach.” If you wanted to disagree with this person and argue, say, that Kanban is better, then you might present evidence that Kanban is 4.5% better than Scrum.

In contrast, a person with a non-testable belief in Scrum might say, “I have certain principles and values, and I view Scrum as a way of living these principles and values in the workplace.” Such a person would probably completely decline a Scrum vs. Kanban analysis. If your belief in Scrum’s value is testable, what kind of evidence or argument would cause you to conclude that Scrum is not valuable?

The Danger of Steamrolling Emotional State

A manager who is considering implementing Scrum might say, “I’m concerned about the loss of predictability in Scrum. Right now I can predict what the team is going to be doing six months from now because I have a Gantt chart that tells me what they are going to be doing. But once the team becomes self organizing, I lose this predictability.”

A Scrum coach might respond, “Actually, you can’t predict what the team is going to be doing six months from now. How often have you been surprised in the past? How often do you have to change the Gantt chart? You don’t have predictability; you just have the illusion of predictability. Scrum is more honest about how much you can predict. You should feel more comfortable when you convert to Scrum.”

This is an answer that I have given in the past. I’m rethinking it. I now think it’s wrong.

First, my answer denies the current emotional state of the manager. The manager is telling me that he’s comfortable. But I am telling him that he should not be comfortable.

Second, it also contradicts the manager’s feelings about working with Scrum. The manager says that he is concerned, and I am saying that he should not be concerned.

Third, it fails to really respond to the manager’s implicit request to address his concern. What do men or women want when they describe an emotional state?

In the absence of a specific statement to the contrary, I believe that he or she wants acknowledgment and acceptance. He or she does not want to be corrected or educated or argued with. If I steamroll the manager by telling him that there is no logical reason for concern, his negative emotional state remains. This is akin to telling Joe, who is afraid of flying, that he should not be afraid because planes are safer than cars. His fear of planes does not dissipate, no matter how illogical it might be.

I believe that one of the major reasons why Scrum implementations fail is that, feeling smart and righteous, we often steamroll expressions of emotional state. But these emotions remain. Their persistence creates hard-to-parse impediments to the success of Scrum.

A Structure That Rarely Works

There is a certain pattern of action we humans are almost addicted to. I say “addicted” because we keep acting this way, even though the pattern almost always fails. This pattern of action often shows up in Scrum implementations in large organizations.

This structure has three components: a list of nice things to have, one or more enforcement agencies, and a population whose job it is to produce, willingly or not, the things on the list.
Consider two examples:
– A software development organization develops a list of nice things for its software to have: documentation, unit tests, etc. It creates an enforcement organization, called QA, to ensure that the code produced by the developers has these nice things. In the agile community, we know that this structure rarely works.
– A financial system, likewise, can develop a list of nice things for financial institutions to have such as capital requirements, risk  limits, and so on. This financial system creates various enforcement organizations, including government entities and public/private partnerships, to enforce compliance to the list of nice things. We know that this structure often does not work[1].
When cooking up Scrum in large organizations, the cooks follow a standard recipe quite like the aforementioned pattern. They create several pilot programs, and then capture the lessons learned from these pilots in the form of: a list of nice things to have. An agile advisory board is then created to enforce this list of nice things throughout the entire company. Every new team that implements Scrum is required to satisfy this list.

Given that this command-and-control structure has repeatedly failed throughout the ages at many levels of human society, I wonder why anyone considers it a reasonable way to implement Scrum.