Our prevailing system of management...

"Our prevailing system of management has destroyed our people. People are born with intrinsic motivation, self-respect, dignity, curiosity to learn, joy in learning. The forces of destruction begin with toddlers--a prize for the best halloween costume, grades in school, gold stars--and on up through the university. On the job, people, teams, and divisions are ranked, rewarded for the top, punished for the bottom. Management by Objectives, quotas, incentive pay, business plans, put together separately, division by division, cause further loss, unknown and unknowable."

Edward Deming quoted on the ScrumDevelopment list by Jeff Sutherland.

It doesn't have to be this way.

The hidden cost of jerks

A while back I was on a roll about Jerks at Work.

I still hear people justifying jerk behavior because "he's a star" or "she's a creative type" or ....

Bottom line is that jerks cost your company.

Bob Sutton was interviewed on NPR this morning (audio on this page) about the hidden costs of jerks. One "brilliant" guy was actually costing the company:

an executive coach

anger management therapy

a new secretary every few months

(and more!)


I've also seen jerks cost the company because of:

lost productivity because people are talking about the latest incident rather than working

absences due to stress related issues and illness

internal turnover--at one company people were required to stay in a job for a year. And that pattern was that on day 366, a high percentage of people posted for a new internal position. For many jobs a year is about the time it take people to become completely productive, so the cost is in hiring + learning curve.

difficulty recruiting internal because the person has a reputation

time spent on complaints and mediation involving HR or the jerks manager

less collaboration because people don't want to work with the jerk

lower results--most of our work requires cooperation from other people, and people don't want to help a jerk

There's an endless nubmer of excuses for bad behavior. The bottom line is that it almost always costs the company money.

It's what we know that ain't so

In response to my post Sorry Jack, Jason Yip mentioned the book Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management.

I bought myself a copy and have been enjoying a good read.

Pfeffer and Sutton don't directly address the forced ranking program at GE; they do tackle the assumptions that underlie ranking, incentive pay, and other compensation system evils of our time.

I'll summarize some points that stood out for me.

Using $ to drive motivation assumes:

If people would only work harder, they'd get better results. (And they won't work hard unless we manipulate them with rewards.)

That ignores the organizational systems, technologies, skills, and information flow as drivers for performance.

Money is the primary motivator for work.

Most studies show that money is not at the top of the list for most people (unless everything else sucks, then it pops up to the top). Oddly enough, many people assume that others are motivated by money, even when they themselves are not. But why should other people be different?

More money/incentive systems will attract the best people.

Maybe. Maybe it will attract the people who most motivatted by $ rather than the work, the culture, the values, the customers, and so forth. People who come for $ may leave for money, driving turnover. And some studies show that people who are mostly motivated by "instrumental reasons" (e.g., making more money) are more likely to cheat.

Pfeffer and Sutton report that a colleague, James Baron, asks his MBA students if they had a serious illness and had to choose between two doctors, which they would choose: "a) a doctor who had entered medicine primarily to make a lot of money, or b) a doctor who had entered medicine because he or she was interested in the subject matter and had a desire to serve people?"

Hmmm. Which would you choose?

On to "pay for performance."

"Pay for performance" relies on ranking or rating people and create stratification between "winners", "nothing specials," and "losers." The result is predictable. People resent each other, and become less trusting, and less collaborative.

In most companies, the differences in pay are actually pretty insignificant. Think about it: Assume that a person makes $100,000 (for the sake of easy arithmetic). A 5% raise is $5,000. A 1% raise is $1,000. That's really not huge difference in actual dollars (considering the salary). But the perceived difference between 1% and 5% is huge, because it communicates how people are valued within the organization.

In most companies, the real differences in raises are likely to be fractions of a percent, and manager spend days and weeks on ranking/rating and then dealing with employee's resentment.

Is the supposed performance gain really worth the fallout?

Pay for performance also assumes independent effort and clear outcomes. That doesn't sound like the software business.

Pfeffer and Sutton refer to a study by Siegel and Hambrick published in Organization Science: "...the negative effect of pay disparity was especially pronounced for high-technology firms, because these firms had the greatest need for collaboration and teamwork to cope with complex and rapidly changing competitive conditions."

Okay, enough challenging assumptions for one day.

A retrospective story

Pete Deemer shared a retrospective story on the Scrum Development list today:

"I was doing a retrospective with a team that's about 2 months / 3 sprints into scrum. Coming into the retrospective the team seemed to be feeling pretty low – they had yet to hit their sprint goals, and were seeing other unpleasant things -- and comments like "IF we keep using scrum" were coming up in their conversation.

Over the first hour or so of the retrospective the team came up with two lists: "what's working" and "what's not working". The "what's not working" list wound up being about 17 items, almost twice the length of the "what's working" list. Most of the discussion centered around the things that were not working; it was an imposing list, made all the more so by the fact that it was a lot longer than the other one, and we spent most of the time talking about it. Once the lists were complete, the group spent a moment or two staring quietly at them.

Then, I tried something I hadn't done before. I suggested the team go through both lists, and mark each item as either "C" (caused by Scrum), "V" (made visible by Scrum, ie would be happening with or without Scrum), or "N" (not related to Scrum, ie the weather, etc).
Then we tallied them up.

Under "what's working", the score was C=7, V=1, N=2.

Under "what's NOT working", the score was C=5, V=12, N=2.

We stared at the results for a minute. Then one of the junior members of the team volunteered, a little tentatively: "so it looks like Scrum is actually CAUSING the good stuff, but the bad stuff is mostly just things it's MAKING VISIBLE. [pause] That's exactly what we want, isn't it?". The rest of the team nodded and murmured in agreement. In an instant, the group's understanding of its situation went through what felt like a polar reversal.

Three things strike me reading this story:

1) This story shows how teams can really gain insights through stepping back to reflect on how they are working. Sometimes its hard for people to believe in this possibility until they see it happen.

2) Even though you lay out the basic agenda for a retrospective ahead of time, when you're leading a retrospective you need to be able to flex to the current situation, and be able to see opportunities to help the group think and learn together. If Pete had stuck to his original plan, they might just have prioritized issues, made some actions plans--and then tried to move forward, weighted down by feeling dispirited. To flex to the current situation and see opportunities, it helps to have a repertoire of activities and strategies that you can use or adapt in the moment.

3) It's really common for people to misattribute the cause of problems, especially after a change. Sorting like this would help people make that distinction and help them focus their efforts to tune the change or address underlying problems--whether they are adopting Scrum or making any other change or experiment.

I'm adding Caused By-Made Visible-Not Related to my toolkit. And thanks to Pete for sharing his story. I'd love to hear more retrospective stories!

My New Glasses -or - Who Defines "Working "

I picked up my new glasses last week--my first pair of progressives. The opticians warned me that it would take time to adjust to the lenses, cautioned me to be patient, extracted a promise to stick with the lenses for at least two weeks.

They prepared me for the worst. I went home anticipating a miserable adjustment. And it was easy. I had no trouble with the lenses. The frames, on the other hand, have been a different matter.

When I first put them on, they seem fine. But over the course of an hour or so, they settle in and shift on my head so that one side is 3/4 of an inch lower on the right side. It's hard to see out of them, plus they look dorky. Really dorky.

So I went back to have the frames adjusted. 3 times. On the fourth visit, I was not happy.

After greeting me, the optician asked me what I needed. "I'm not happy with my glasses," I said. "The lenses are fine, but the frames sit crooked on my head."

I handed him my glasses. He examined them from every angle, placed them on the counter, and made several measurements.

"These frames are not crooked," he pronounced. "They are perfectly straight."

"But when I put them on they're lower on the right side," I responded.

"These frames are straight," he repeated.

Then he launched into a long, technical explaination of how lenses and frames are designed. He repeated all his measurements, asking me at each stage to confirm that the frames were not crooked.

I took my glasses back. "I agree with you. They are perfectly straight when you measure them, hold them in your hand, or put them on the counter. It's my head that's crooked. Look at them on my face," I said.

"The bottom of the frame is parallel with the floor. They aren't crooked," he asserted.

By this time I was annoyed.

I was also fascinated with the conversation on a meta level, because I've heard this conversation about a million times when a customer tells a developer that a feature doesn't work quite the way the customer needs it to work.

I've even seen these conversations devolve into shouting matches as the developer argues that the solution is technically correct (or conforms to spec) and the customer argues that it doesn't work.

So if you ever find yourself in this situation, remember these rules:

Rule # 1 Never argue with your customer. Discussion, exploration of trade-offs and negotiation are fine. But when you argue, you lose if you win and you lose if you lose.

Rule # 2 Consider the context. It's how the product works in the customers context that matters. Don't matter how it works in your lab.

Rule # 3 Consider that you may have different definitions for the same words. If you're going back and forth about something, check out how you are defining terms.

So back to my glasses.

I tried a different tack: "I think we have a different definition of 'crooked,'" I said. "Would you please adjust my glasses so they are even with my face?"

"Oh, I can do that," the optician said. "But they won't be straight."

Why people do the things they do

So I'm thinking about the person who was proud of making people cry when consulting. Let's call her Jackie.

Jackie comes in with an idea of how people should be doing thier jobs. If th people aren't doing their jobs that way, Jackie's assessment is that the people are incompetent.

There are actually lots of reasons a person--or an entire department--may not be doing things way Jackie thinks they should:

Rewards.
People generally do what they are rewarded for. So if they are rewarded for doing A most people will do A. I consulted to an organization once where the production support group was measured on keeping the environment stable and driving down costs. Every change costs thousands of dollars (long story that I won't go into here). It should come as no surprise that they were not highly responsive to changes.

Organizational systems.
The way people are organized may drive the way people do thier jobs. There may be policies, procedures, processes, job descriptions, or service level agreements that drive job-related behavior.

Mental models.
Each of us has a mental model of how the world (our company, our department, etc) works. People act in a way that's consistent with their mental model. People tend to notice data that confirms their mental models and not see data that doesn't fit--and it's all unconscious.

Lack of experience or training.
People generally choose the best option they have avaible -- the problem may be that they don't have a rich enough array of options. That's fixable with training, coaching, and experience.

So rather than assume people are incompetent and make them cry, it's more helpful to find out which of these factors are at play and work on those.

Applying Agile Retrospectives

Jo Cranford (who I had the pleasure of meeting at Agile2006) reports on applying some of what she learned from Agile Retrospectives: Making Good Teams Great in a recent iteration retrospective.

when do people change?

Diana quotes about a story (via Brian Robertson’s blog) about "getting people to change."

“A colleague of mine spoke at a big leadership conference many years back. It was one of these big things where they had ex-presidents, Jack Welch and other big names and leaders. The people attending the conference had an evaluation sheet to determine the speaker with the most impact. The person who won, with by far the most votes, was Mother Theresa. She just happened to be in town that week so the conference organizers asked her to stop by and say a few words at the end of the conference. She listened for a while to all of these leaders of major corporations, talking and talking about how do we change our people? How can we get them to focus on results?

“At the end Mother Teresa went up to the podium and said something like ‘I don’t know much about leadership, but I do know this. You want to change your people? Do you know them? And, do you love them? If you don’t know them and you don’t love them, you are not going to change them.’”


Contrast this with another method of inspiring people to change that I heard recently: "I go into organizations and I tell it like it is. I don't pull any punches. I tell people that its a miracle that they're still employed. I've made people cry!"

(Why making people cry is something to be proud of is a mystery to me. Though this is not the only time I've heard someone say that with a bit of prideful swagger.)

Threats and denigration usually lead to defensiveness--and maybe surface compliance to reduce threats and pressure.

In my experience, people change to save something they value. They change when they feel they can learn the new way--they'll have the time, resources, and training.

And they change more readily when they have a positive relationship with the person asking them to change.

Marco Abis answers the question "Why do retrospectives?"

Marco Abis had a great post on retrospectives back in May. In case you haven't seen it, I'll quote part of the post here:

First of all why do I value retrospectives? Many different reasons but mainly because they let's you:

learn from experience

bridge the gap between theory and practice

cope with ambiguity and change

develop a critical awareness

Reflecting is something that we all do and Piaget found that this is one of the advanced skills adolescents develop as they approach adulthood. In fact I like to think that when professionals/teams/organisations move towards their adulthood they start to develop, value and apply a reflective approach to improve and grow. Or, to put it in another way, if they don't do it they still haven't turn the tipping point of maturity.

Learn from experience

Reflecting on experience provides the basis for forming more abstract ideas which can then be applied and tested in further experience. It enables us recognise new opportunities and learn from them.

Bridge the gap between theory and practice

As everyone has experienced in his life studying something doesn't necessarily means being able to apply it. We need to know how to apply the knowledge to real problems. Reflecting help us to identify how best to apply in practice what we know in theory.

Cope with ambiguity and change

Reflecting is essential in recognising the uncertainty we face in the modern world where the demand for fast and reliable results often increases stress and workload. This is particularly true in an Agile environment in which we tend to work closely with our customers and often have to cope with new and unique problems never met before.

Develop a critical awareness

We usually reflect both on our own behaviour, the behaviour of others and on the social/organisational context. This leads us to develop self-awareness and to become aware of things we need to change. Reflecting is then a key point for improvement and is far from being an innocuous process because it challenges the status quo, the way things are done.

You can read Marco's complete post on Retrospectives IN and ON Action here.

Instead of just asking "What did we do well?" and "What could we do better?"

A reader asked what he could do to inject some life into his iteration retrospectives. He'd been using two questions "What did we do well?" and "What could we do better?" for several iterations, with the general goal of improving performance.

Here's what I suggested:

Choose a more specific goal, such as “improving team work.” (You could use engineering practices, customer relationships...what ever is most relevant to the team right now.)

Rather than starting with the questions start by setting the stage for the retrospectives. Share the goal. Have the team do a quick, one word check-in.

Then gather some data about goal topic, "teamwork".

Have the team identify 5-6 behaviors they feel are critical to productive team work. Draw a radar chart and label each arm with one of the behaviors. The center

Ask each person to mark on the chart how well the team is doing on that behavior.

(There's an example of a radar here. The one pictured shows the team's average. But you can do it with individual tick marks.)

Use the data from the radar chart to start a discussion. Look at areas where perceptions are different (some people indicated we're at "10" on this and others indicate "2"). Look at how behaviors affect the team, or how the absence of some behaviors affect the team.

Based on the discussion, ask the team to identify one or two behaviors they want to increase or be more aware of in the next iteration.

Devise a way to track that behavior in the iteration.

Sample for Free!

Andy's posted some excerpts from Agile Retrospectives: Making Good Teams Great on the Pragmatic Programmers site.

Enjoy.

The ICA Workshop Method

Several people wrote to ask about the details of how I do the card sort thing described here.

The method is explained in detail in The Workshop Book: From Individual Creativity to Group Action (ICA series). I do a few thing differently than described in the book, but the differences are minor and don't change the outcome.

I've used the Workshop method to gain consensus on user classes, features, and risks. I've used it for planning, setting goals, generating options, and identifying benefits.

It's flexible and it works.

Index cards as a collaboration tool

I spent most of my time at Agile2006 (when I wasn’t leading sessions) sitting in the front lobby chatting with people. One of those people was Jim Shore, who showed me his new on-line collaboration tool (developed with Dave Woldrich, cardmeeting.com.

I find that working with cards to generate ideas and solve problems hugely valuable when I work with groups.

Here’s one of the ways I work with cards:

I ask people to write down at least 10 ideas related to the issue at hand. I ask for 10 because the first several ideas people come up with represent habitual thinking. Pushing for 10 ideas sparks creativity. Usually I have them list the ideas on scrap paper, then transfer their X best ideas to cards. X is determined by the total number of ideas cards I want to work with. I’ve found that 35 is a good number. More is overwhelming to work with, fewer doesn’t allow for rich discussion.

Then I help the group cluster the cards and name the clusters. (I usually do this a specific way that I learned from the ICA folks, which they call the Workshop Method. There’s more to it than I’m going to go into here.)

Several interesting happens when I do this.

Because people are looking at the cards “out there” they’re less likely to get into arguments about ideas. They focus on seeing how the different ideas fit together. Seeing different ideas juxtaposed seems to spark different thinking, too.

Because everyone has offered many ideas, people don’t get as attached to a specific idea as they do when they only have one idea.

As the clustering is going on, people have conversations about why they see something in one group rather than another, and begin to understand other peoples ideas.

People generally leave the process with “our” ideas rather than feeling like the ideas of an individual or a few people favored people won out.

And when people believe it’s “our idea” they’re much more likely to commit to it.

I used this process with anywhere from 5 to 50 people. And it works great—when people are in the same room.

So back to cardmeeting.com.

Cardmeeting.com keeps the physical index card metaphor and allows users to move the cards around, cluster them, add new cards, and add title cards. So you can have people in different locations participating joint problem-solving and thinking together in an active, dynamic way. Add in a VOIP connection, and people could have conversations as they move the cards. I think with a judicious use of group rules, you could have a facilitator help with the clustering, too.

I know there are various web meeting tools and shared desk top programs. This feels like a higher level of collaboration for people thinking together than the ones I have seen up until now.

Jim let me test drive –I am excited to try cardmeeting.com on a real problem. I’ll report back when I do.

Agile and the PMBOK

Michele Sliger (rhymes with "tiger") has a paper posted at Rally that outlines the differences between Agile Project Management and the the more traditional project management thinking embodied in the PMBOK (of PMI fame).

Requires a free registration that may result in some email from Rally.

Sorry Jack

Diana Larsen pointed me to a recent issue of Fortune:

There are lots of interesting observations in the article about what have been unchallenged assumptions about business.

I'm particularly interested in the comments on the sort of forced ranking that Jack Welch helped to popularize.

Seems some executives are finally realizing that forced ranking doesn't just cull the low performers....it pits people against each other, dis-incents collaboration, and drives disengagement. And you can't get much done with unengaged people who don't collaborate and work against each other.

[rant]Why the heck to we need a forced ranking system to cull low performers? If someone isn't doing his job or isn't in the right job, his manager should be managing him, encouraging him to find a more appropriate job within the company, or firing him. If forced ranking is the only way a company has to identify and move out people who aren't doing their job, maybe the problem isn't just with the identified "low performers".[/rant]