The Milk of Human Kindness

To understand others and to be understood.  To be open to the beam of light that emanates from another’s soul.  To be connected deeply, so that we understand the feelings and needs of others and they understand our feelings and needs.  To sense someone’s “no” even when they’re saying “yes.”  These are some of the goals of deep communication.

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.

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.

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

Financial Worry: An Impediment to Scrum Adoption

Many people in the United States are broke–and the rest of us are tense. One in four mortgages is underwater[1]. 2008 was the worst year on record for household net worth[2]. Over 20% of households under age 35 have a negative net worth [3].

Adopting agile, however, requires not tension, but slack[4]. I mean psychological slack, emotional slack, resource slack, time slack, and financial slack. Under stress, one’s capacity to change shrinks. A person living paycheck to paycheck may find taking career risks difficult. He or she cannot risk the chance that transitioning to agile will bring about job loss.

It’s hard to try things that might fail when so many people are really anxious about their security. Who will announce during a standup meeting that a task is taking longer than expected because they don’t know how to do something? Who will report that the key impediment to successful agile adoption is their boss’s ignorance of agile?

In a recent interview[5], David Chilcott of Outformations noted that there are three topics that are difficult to discuss in the workplace: sex, money, and power. When it comes to money, Chilcott says, the people at Outformations have open discussions about how much each person should be paid. These discussions can be emotionally difficult. (What? I’m not worth $150 an hour?) Yet in the end, people at Outformations know how much everyone else is paid and why. Difficult or not, these discussions eliminate a key impediment people experience when working together on a team.

In a large corporation, talking about pay is usually impossible because it’s often specifically prohibited by the human resources department. As a result, people feeling anxious about finances cannot discuss this impediment openly. On an agile team, this could lead to a loss of transparency and confusion about why velocity is not as high as it might be.

How might this problem be addressed? I do not have a good answer. Maybe a first step is for large organizations to confront the fact that they are not going to transition to agility quickly. Certain parts of the organization and some teams may be agile and the organization as a whole may be said to be agile in a mechanistic, cargo-cult sense, but “full” agility requires a radical change in corporate DNA, and it won’t happen fast. The good news is that even partial agility (getting to done, iterating, etc.) will lead to radical improvements.

The financial fear that people are now experiencing in their daily lives is rarely discussed in the agile community. Recognizing its existence, and the harm that it does, may be first step in neutralizing it.

[1] http://online.wsj.com/article/SB125903489722661849.html
[2] http://www.nowpublic.com/world/household-net-worth-continues-fall
[3] http://6aa7f5c4a9901a3e1a1682793cd11f5a6b732d29.gripelements.com/pdf/vol-710.pdf
[4] Slack by Tom DeMarco
[5] http://www.vimeo.com/9293844
0 Comments Click here to read/write comments
Tags: essay
Make Love, Not Money
Posted by Michael de la Maza on Mon, Feb 08, 2010 @ 09:51 AM
Email This Email Article | Share on Twitter Twitter | Share on Facebook Facebook | Submit to Digg digg it | Add to delicious delicious | Submit to StumbleUpon StumbleUpon | Share on LinkedIn LinkedIn | Share On Technorati Technorati | Submit to Reddit reddit
Some folks in business are pursuing a strategy that is not taught in business school: The best way to maximize profit is to stop thinking about maximizing profit and, instead, to focus on treating people right. That is to say, the best way to make money is to focus on loving people.

Joel Spolsky of Fogbugz fame says it so: “Best Working Conditions -> Best Programmers -> Best Software -> Profit!” [1]

Tony Hsieh of Zappos puts it this way: “Culture is our number one priority…Our whole belief is that if we get the culture right then a whole bunch of other stuff like building a brand…will happen naturally on its own.”[2]

I want to distinguish this view from two similar perspectives: The first is ’60s style hippie collectivism which holds that capitalism is evil because it is inherently coercive and manipulative, that labor and capital should benefit all members of an organization, and that, really, money is a nuisance and what matters is love. The Make Love, Not Money perspective in contrast, says nothing about whether money is a nuisance or how capital should be organized. This is not to say that it is inconsistent with the hippie view.

The second perspective is the standard Scrum mantra: “The goal of a team is to maximize business value by delivering working software.”[3] Under the Make Love, Not Money view this might be re-written to read: “The goal of a team is to optimize its work environment and, as a beneficial side effect, it will radically increase the business value it delivers.” The fact that optimizing the work environment has often led to significant increases in financial success is an empirical finding. It’s consistent with common sense but doesn’t by necessity follow from the “optimize the work environment” premise.

A good question to ask is: Why don’t profit maximizers do this? The typical middle manager, when asked to increase profit, responds by laying off workers or skimping on office furniture-not by creating a great work environment. I do not know why. I suspect, though, that it has to do with human cognitive limitations. It’s hard for us to understand the nth order effects of our actions. Buying cheap office chairs is a simple thing to do-the other, more complicated.

If he adopted it, a profit maximizer might view the Make Love, Not Money perspective as a useful cognitive crutch which helps him make better decisions, just as coaching a chess novice to develop his pieces (instead of telling him to mate the opposing king) is a useful cognitive crutch.

Bottom line: focus on creating extraordinary work environments and get extraordinary profits for free.

[1] See http://www.fogcreek.com/About.html for an eloquent description of the Fogbugz philosophy.
[2] http://blip.tv/file/1696310
[3] See, for example, http://codebetter.com/blogs/darrell.norton/articles/50339.aspx: “Scrum is a process for the empirical control of software
development. It enables teams to deliver working software in an iterative manner in order to maximize business value.”

Make Love, Not Money

Some folks in business are pursuing a strategy that is not taught in business school: The best way to maximize profit is to stop thinking about maximizing profit and, instead, to focus on treating people right. That is to say, the best way to make money is to focus on loving people.Joel Spolsky of Fogbugz fame says it so: “Best Working Conditions -> Best Programmers -> Best Software -> Profit!” [1]

Tony Hsieh of Zappos puts it this way: “Culture is our number one priority…Our whole belief is that if we get the culture right then a whole bunch of other stuff like building a brand…will happen naturally on its own.”[2]

I want to distinguish this view from two similar perspectives: The first is ’60s style hippie collectivism which holds that capitalism is evil because it is inherently coercive and manipulative, that labor and capital should benefit all members of an organization, and that, really, money is a nuisance and what matters is love. The Make Love, Not Money perspective in contrast, says nothing about whether money is a nuisance or how capital should be organized. This is not to say that it is inconsistent with the hippie view.

The second perspective is the standard Scrum mantra: “The goal of a team is to maximize business value by delivering working software.”[3] Under the Make Love, Not Money view this might be re-written to read: “The goal of a team is to optimize its work environment and, as a beneficial side effect, it will radically increase the business value it delivers.” The fact that optimizing the work environment has often led to significant increases in financial success is an empirical finding. It’s consistent with common sense but doesn’t by necessity follow from the “optimize the work environment” premise.

A good question to ask is: Why don’t profit maximizers do this? The typical middle manager, when asked to increase profit, responds by laying off workers or skimping on office furniture-not by creating a great work environment. I do not know why. I suspect, though, that it has to do with human cognitive limitations. It’s hard for us to understand the nth order effects of our actions. Buying cheap office chairs is a simple thing to do-the other, more complicated.

If he adopted it, a profit maximizer might view the Make Love, Not Money perspective as a useful cognitive crutch which helps him make better decisions, just as coaching a chess novice to develop his pieces (instead of telling him to mate the opposing king) is a useful cognitive crutch.

Bottom line: focus on creating extraordinary work environments and get extraordinary profits for free.

[1] See http://www.fogcreek.com/About.html for an eloquent description of the Fogbugz philosophy.
[2] http://blip.tv/file/1696310
[3] See, for example, http://codebetter.com/blogs/darrell.norton/articles/50339.aspx: “Scrum is a process for the empirical control of software development. It enables teams to deliver working software in an iterative manner in order to maximize business value.”

What I Learned From The Tiger Woods Saga

Members on Agile teams must bring their whole selves[1] to work. They do not split themselves into pieces, bringing some to work and leaving others out. Companies that use Agile methods successfully must help team members work as their whole selves.

The recent Tiger Woods “saga” strikes me as a useful example of the problems of splitting the public from the private self. According to the cover story in the February 2010 issue of Vanity Fair, Tiger Woods, guided by an army of advisors, crafted a public image which in significant respects was wholly at odds with his private self.

Unfortunately, managing the multi-facetedness of humans in a standard command and control manner is difficult. So, in order to reduce management burdens, many companies require, either by decree or by culture, that employees pasteurize themselves to remove their cranky individuality and become more uniform. There is both anecdotal and academic evidence[2] that such conformity “shaping” is harmful to individuals and to those around them (and thus to teams and workplaces).

Consider how the typical command-and-control company addresses divorce. Managers encourage the employee to take vacation or a “personal” day (as if every day were not personal) to handle any issues relating to a divorce. When he or she is at work, the employee must function as if the divorce were not happening. That is to say, management requires the employee to maintain the same input/output relationship no matter what the employee’s internal state may be. This is very dehumanizing. Further, this policy does not serve the company’s interests because it forces employees to behave in dysfunctional ways which are harmful to them and to the company.

A while back, I was teaching a two day course on Scrum when the class began to talk about sharing people across teams. The conversation continued for 30 minutes and covered a variety of topics in a meandering manner. After 30 minutes, a guy I’ll call Greg said, “I do not feel as if I am a member of a team.” This feeling was immediately seconded by several other team members and crystallized the discussion. The key problem was not sharing people across teams, but a lack of team feeling and identity. (Hence, little sense of team responsibility, commitment, or progress). If Greg had not felt safe, he would not have been able to share this feeling. The team would have taken much longer to identify the source of its unhappiness. It’s worth remembering that identifying sources of unhappiness or blockage is critical to increasing a Scrum team’s velocity[3].

When an environment is deeply inconsistent with our way of being, we are forced to splinter. Tiger Woods, with his personal and now professional problems, is an example of this. While we on Scrum teams are not athletes, we do have a need for efficient graceful action just like a great golfer does. We should pay attention to maintaining psychologically safe environments that allow team members to be whole.

When we splinter, trust, respect, and transparency suffer. Splitting ourselves has a bad effect. When teams become less trusting, the quality of communication drops, and so does productivity and that pleasurable feeling of productivity that Agile teams require.

[1] I learned the phrase “whole selves” from Lyssa Adkins.
[2] Managing Workplace Stress by Cartwright and Cooper.
[3] www.scrum.org

Touch

Humans love to touch and to be touched.

Parents hold their children to comfort them. We hug people who are in pain.

In prison, one of the greatest punishment that can be meted out is to place a prisoner in solitary confinement. Solitary confinement does not involve any direct physical deprivation. The prisoner receives the same amount of food, sleep, and exercise. But he does not have human contact for almost the entire day. Studies show that this loss of touch has debilitating psychological effects which, in approximately one third of all cases, persist well after solitary confinement has ended and the prisoner has rejoined the general population.

In typical corporate environments, touch is verboten. My sense is that some of the unproductive behavior that people exhibit at work is due to being in solitary confinement for the entire workday.

In this five minute video I expand slightly on the above and show raw footage (!) of a ten minute touch exercise that I did with the Boston Chapter of the International Institute of Business Analysis on November 12, 2009.

Prior to working through the touch exercise, I ask the participants to take a mental snapshot of their emotional state. After going through the ten minute exercise, approximately 80% of the participants report an increase in happiness, energy, and well being. I know of no non- touch exercise which has similar effects. Professor Dacher Keltner of UC Berkeley discusses the biology of touch in this two minute video.

What does a high touch Scrum team do? A high touch Scrum team does many things to incorporate touch into its daily practice. High touch Scrum teams:
1. Hold hands during the Daily Scrum.
2. Give each other standing backrubs at the start of the Sprint
planning meeting.
3. Hug each other at the end of the retrospective.

As agilists one of our goals is to create environments in which trust, respect, communication, care, and love are in abundance. Touch is one of the most powerful ways to create such environments.

Why Don't I Floss My Teeth?

I’ve been going to the dentist for over thirty years. Whenever I visit the dentist, I’m told to floss twice a day. Flossing fights cavities, bad breath, and disease. Flossing is simple: it takes about two minutes and costs just a few cents. And yet I rarely floss my teeth. Why?

The problem is not at the knowledge level. I know why transitioning from not flossing to flossing is a good idea, full of wonderful benefits for me and my teeth. The problem is not at the behavior level. I know how to floss my teeth because my dentist enthusiastically practices on me everytime I visit her.

So if the problem is not at the knowledge level or the behavior level, what is the impediment that causes me not to floss?

Understanding the answer to this question is, I believe, key to understanding why Scrum adoption is so difficult. Understanding what Scrum is (knowledge) and what to do (behavior) is fairly simple. But there is another level, the emotional level, which I have found contains the key impediments to the successful adoption of Scrum.

Many Scrum coaches have transition plans which include garnering the support of senior executives, providing appropriate training and coaching, and creating a transition committee. While these are certainly important considerations, they do not address impediments at the emotional level. A person who has to transition from being in QA to being a member of a Scrum team and is worried, nervous, afraid, and anxious is not directly helped by knowing that the larger organization has a Scrum Transition Committee or has implemented a Scrum Pilot Project.

For ideas on how to address emotional impediments, I have found that studying Weight Watchers is instructive. Weight Watchers was started in 1961 when Jean Nidetch confessed to a group of friends that she was overweight because she could not stop eating cookies. In launching Weight Watchers, Nidetch explicitly said that while she knew how to eat right, she needed emotional support. Today, Weight Watchers provides weight loss information (knowledge) and teaches a point count system (behavior). But, most importantly, it provides emotional support for people who want to lose weight.

A successful Scrum transition effort will do the same. Not only will it bathe people in the knowledge and behavior needed to do Scrum, it will provide individuals, teams, and organizations with support at the emotional level as they transition to Scrum.

This article was originally published at the web site of the Scrum Alliance.