Transitioning to Scrum: The Thrill of Victory and the Agony of Defeat from MICHAEL A DE LA MAZ on Vimeo.

Why do agile transformations (almost always) fail? from MICHAEL A DE LA MAZ on Vimeo.

1. “This Is Not Like That” by Lyssa Adkins. Argues that agile concepts should be understood directly instead of by analogy.  http://agileanarchy.wordpress.com/2009/12/18/this-is-not-like-that/

2. “Two Forgotten Agile Values: Discipline and Skill” by Brian Marick.  Notes that team members often lack the skills they need.  http://www.exampler.com/discipline-and-skill.html

3. “The Essence of Scrum” by Tobias Mayer.  A contribution to the principle-centered view of Scrum.  http://agilethinking.net/essence-of-scrum.html

4. “Agile: Is, Is Not, May Be” by Ron Jeffries.  Takes a crystal clear position on the importance of developing software in every iteration.  http://xprogramming.com/articles/jatagileisisnotmaybe/

5. “Flaccid Scrum” by Martin Fowler.  Spurred the creation of Scrum developer certification programs. http://martinfowler.com/bliki/FlaccidScrum.html

6. “Measure UP” by Mary Poppendieck.  Emphasizes the importance of measuring productivity at the team level.  http://www.poppendieck.com/measureup.htm

7. “Escalation is Killing Agile — Can We Please Stop It?” by Jean Tabaka.  A plea to reduce the violence in conversations about different ways to be agile.  http://www.rallydev.com/agileblog/2009/10/escalation-is-killing-agile-can-we-please-stop-it/

In Scrum, we teach the value of collaboration, of building on each other’s work.  Before collaboration comes cooperation (which means working in the same direction), and before cooperation comes communication [2].  Communication, cooperation, and collaboration can be considered ways of being, but they are also acquirable skills. The best approach to communication that I have found is called nonviolent communication (NVC)[3].

Unlike many well-known communication systems, such as Crucial Conversations[1], NVC was not developed by management consultants with the goal of maximizing profit.  It was developed by Marshall Rosenberg who, as a youth, witnessed violent race riots in Detroit and wondered whether there was a way for all people to communicate without evaluation and judgment.  NVC’s uses an observations-feelings-needs-requests framework.  It’s the best way I know to communicate in charged situations.  I have found it rewarding to describe NVC to Scrum teams and suggest that they drop into NVC whenever a conversation becomes challenging.  It has been one of the most life-giving gifts I have provided as a Scrum coach.

[1] Crucial Conversations: Tools for Talking When Stakes are High by Patterson, Grenny, and McMillan.
[2] At a CSM training, I heard Tobias Mayer make an observation similar to this one.
[3] For additional information on NVC see http://www.cnvc.org/.  The standard introductory book is Rosenberg’s Nonviolent Communication: A Language of Life.

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.

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.

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?

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.

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.

References
[1] http://www.nytimes.com/2009/01/04/opinion/04lewiseinhorn.html