esther derby's "insights you can use"

Five Reasons to Hire a Coach for Agile Teams

2009-06-30T06:25:00.003-05:00

I run into managers who think that they can coach the team as the team adopts Agile methods. In my experience, this usually doesn't work out very well.

So managers, support the team as they learn Agile methods by hiring a coach! It's a investment in success.

Here are five reasons that coach cannot be you.

1. The team needs someone skilled in XP engineering practices and current on the latest testing tools. If you haven't written code in more than three years, or you've never worked on a team that used all the XP practices you don't have the knowledge to coach the team. Sorry. Doesn't make you a bad person or cancel out your value to the organization. Does mean you are not the right person to coach on XP.

2. You may have a conflict of interest. If you are being measured on delivery dates, its possible that you'll ask the team to cut corners, work extra hours, or drop practices to meet a date. That would be bad. The team needs someone who will hold the process in place and help them hold firm when someone is worried about making a date. That can't be you, if you're the one worried about making the date.

Even if you'd never do that, on some level, the team may not believe that yet, especially if you've ever done so in the past. And if they think you'll cave in the face of a date, they'll cave before you even ask them to. It just works that way.

3. A coach will help the team stick to the process, and guide them away from making adjustments that nibble away at iterative incremental development until they are back in a mini-waterfall.

Agile really does involve a shift in the mental model of software development, and until you have an intuitive grasp of the principles and values, the nibbles will make sense to you, too. You've got to live it for a while before you can coach it.

4. As long as you are there to solve problems and tell people what to do, it will be easy for the team to remain dependent on you. It may feel good to be needed, but in the long run, it doesn't help the team, doesn't help the company, and doesn't help you.

5. You've got a ton of other stuff to do supporting the team, removing obstacles, running organizational interference, and working on the work system. Plus you have to do the budget.

Of course, you don't have to be dependent on outside coaches forever. Once you've established a few Agile teams, you can develop a cadre of coaches made up of your own experienced people.

Pfeffer's Six Dangerous Myths About Pay

2009-06-29T15:40:00.004-05:00

A few days ago, I had a little twitter conversation with Dave Rooney, Ben Simo, and Elisabeth Hendrickson about rate vs. cost.

Which reminded me of Jeffrey Pfeffer's excellent article, Six Dangerous Myths About Pay (originally in HBR May/June 1998).

This article should be required reading for all managers.

The Myths are:

Myth #1: labor rates are the same as labor costs.

Myth #2: cutting labor rates will lower labor costs.

Myth #3: labor costs represent a large portion of a company's total costs.

Myth #4: keeping labor costs low creates a potent and sustainable competitive edge.

Myth #5: individual incentive pay improves performance.

Myth #6: people work primarily for the money.

Ain't none of 'em so.

When managers confuse labor rate with labor cost, they make decisions that usually end up costing lots of money.

Labor is an easy to count cost. It's much harder to count the costs of multi-tasking, poor decision-making, ineffective and demotivating work systems, communication latency and other wastes. But the later factors have a big effect on productivity, and therefore, labor cost.

Upcoming Public Workshops

2009-06-12T16:07:00.003-05:00

I've got two public workshops coming up:

Designing Experiential Exercises and Simulations June 22-26, 2009 in Albuquerque, NM.

If you lead workshops or teach classes, experiential exercises and simulations increase engagement and retention. They also make learning (and teaching) more fun. Join Jerry Weinberg and me for this experiential workshop. Participants should come prepared with an exercise or a concept they wish to turn into an experiential activity.

Email me (derby[at]estherderby[dot]com) if you are interested in the Designing Experiential Exercises and Simulations workshop.

Secrets of Agile Teamwork, July 21-23, 2009 in Redmond, WA.

Beyond technical skills, Agile success depends on productive self-organizing teams. How do you develop, grow, and maintain a functioning self-organizing team? It’s not magic, but it doesn’t just happen either. Effective self-organizing teams rely on personal and interpersonal effectiveness. In this hands-on workshop, we’ll discover the secrets to developing the skills you need to succeed and lead on a self-organizing team. My co-leader for this workshop is Diana Larsen.

Register for Secrets of Agile Teamwork through our hosts, SolutionsIQ.

When to stand back, when to step in

2009-06-11T19:57:00.007-05:00

Part of my definition of a successful team is that the members of the team increase their knowledge and capacity as a result of their work on the team. That means that giving the team the opportunity to learn is part of the job.

One of challenges I see when managers first start working with agile teams is knowing when to step back, and when to step in. Swinging too far in either direction hampers team learning.

Helicopter Managers step in too soon. They swoop in at the first whiff of a problem to "rescue" the team. They deprive the team of the chance to think, solve problems, and decide together. These managers may believe they are doing the team a favor; what they really do is hamper the team's development.

Absentee Managers throw up their hands and say "you figure it out," no matter what the issue, or whether the team has the skill and authority to solve the problem. These mangers let the team flail and churn, wasting time and building frustration. People do learn from mistakes; but when people feel frustrated, hopeless or abandoned by their manager, increased capability is not the likely learning outcome.

Self-organizing teams still need managers. But those manager need to know when to step in, and when to stand back.

Here are three guidelines to help managers gauge their actions with self-organizing teams.

#1. If the team has the skills to solve the problem--or they are on the verge of having the skills--give them space to solve the problem. If they're stuck or don't see how to use the skills they have, ask questions to help them get unstuck. They will learn much more from wrestling with the problem than having the manager fix it. (Assuming it's not a management problem. Then it's managements job to fix it.)

#2. When time is not of the essence give the team time to work the issue. If it takes a day or two to solve the problem, will it bring the company to it's knees? (If the answer is yes, you've got bigger problems than working with a self-organizing teams.) Keep in mind that many companies live in permanent fire-fighting mode and believe that everything is urgent. Or the manager believe that people won't actually apply sufficient effort unless they believe the issue is urgent. Again, that's a bigger problem. OTOH, if there's information that will help the team solve the problem give the information. Withholding the information is just plain wrong. Likewise, if there's a very simple solution that the team is overlooking, ask questions to help them discover it.

#3. If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time. If the solution space isn't bounded, then there's something amiss with the way the problem or decision authority has been delegated. Bound the issue so that the team is involved and there's appropriate fiscal and management oversight.

There's always a trade off between expediency and a learning opportunity. Self-organizing teams can outperform manager-let teams....but only if the managers are willing to navigate the balance.

Shifting from a manager-led team to a self-organizing team is a little tricky. It calls on a different set of skills, and brings up questions about value and identify for many managers.

But there's still plenty of work for managers to do. It just doesn't involve task management and having all the answers.

Tips for Retrospective Facilitators

2009-05-29T14:29:00.004-05:00

When Diana Larsen and I teach a two-day Leading Agile Retrospectives workshop, the second day is stand up facilitation practice. We create the bare bones story of an iteration, then the class works together to design a retrospective. Each participant has a chance to lead an activity. And Diana and I offer feedback and facilitation advice.

Having done this more than a few times, I've noticed that we repeat the same advice in almost every class.

My colleague Mark Kilby asked what that advice was, so here it is (at least some of it).

When you ask the group a question, give people enough time to answer. It can feel a little disconcerting to stand there in silence, but people--especially introverted people--need time to collect their thoughts before they speak.

Count to eight s-l-o-w-l-y. If no one has answered, count to eight again. If there's still no answer, move on.

Do some of the work in pairs or small groups. Not every discussion or activity needs to happen with the entire group. Doing some activities in smaller groups or pairs adds variety, makes it easier for reticent people to state their views, and limits the possibility for voluble or dominant people to own the airwaves.

Let the group do as much of the work as possible. Rather than doing all the capturing, when possible have people write their ideas on stickies (with a marker, not a regular pen) and post them. Ask one of the participants to help hang up flip charts or hand out stuff like markers, stickies, dots.

Give instructions in chunks. If you are using an activity that has multiple parts or requires movement, break up the instructions. Even if the instructions seem simple to you, people are not likely to retain them if they are hearing several steps at once and having conversations between steps.

Start by stating the purpose of the activity: For example, "We're going to do use a use a special type of diagram to help us understand which issues are causing most of our difficulties." Wait for questions.

Then give the first instruction. "Please from groups of three." Wait until people are in groups before you continue...or say "In a minute, I'm going to ask you to get into groups of three. Let me tell you what I want you to do in the small group." Give the instruction.

Once they've done than part, give them the next instruction.

Provide a key when you color code anything as part of an activity. (for example sometimes I'll do a timeline with yellow=technical issues or events, blue=team issues or events, green=organizational issues or events.

If you get lost in an activity or something happens that you don't know quite how to handle, pause and reset. No one can be perfect, so get good at recovering gracefully. It's okay to say, "This isn't going the way I thought it would. Is this useful to you?" Always have a back up activity, just in case.

Use wide chisel tip markers in dark colors for writing on flip charts or white boards. Dark blue, dark green, dark purple, green and black are easy to see. Fun colors like orange, light green, turquoise are hard to see from a distance. Red is okay for younger people, problematic for people over 40. Use those fun colors to accent, but not for text. (You can buy boxes of Mr. Sketch dark colors at www.artsuppliesonline.com.)

Write BIG, and use sentence case when writing on flip charts or white boards. It's still sort of surprising how many people stand in front of a flip chart and write letters 1/2 inch tall. Write BIG. People can read sentence case more quickly than they can read ALL CAPS. Capitals are okay for headings, as they create a visual cue.

While I'm on the subject of flip chart writing, there's something about visual field when you are writing BIG on a flip chart that makes it difficult to spell correctly. It's nothing to do with you (or me). Really. It's because your brain can't take in the entire word as it does when you write on a smaller scale. Declare a General Spelling Amnesty, or put a spell check button on your flip chart when you make a mistake--you'll probably get a laugh.

Put dying markers out of their misery. Really. Throw them away (unless they are refillable.) They are useless, worse than useless, because they make you think you are capturing something the group can see, when you aren't and they can't. Throw them away, now! (I visited a company where people held onto dead markers. When I asked why, they told me they were the only markers they had, and the secretary wouldn't order any more. So wrong, on so many levels.)

Okay, that's enough for now.

Shocking Survey Results about Performance Appraisal

2009-05-21T07:34:00.004-05:00

The landed in my inbox this morning:

In a famous Leadership IQ study, we surveyed 48,012 CEOs, Managers & Employees about their performance appraisals. Here's the shocking results: Only 13% of Managers & Employees thought their performance appraisals were effective. And only 6% of CEOs thought their appraisals were effective. We also discovered that only 14% of employees say their performance appraisal conversation offered meaningful and relevant feedback.

Actually, I'm not shocked by these results. Not even surprised.

What is shocking is that many organization continue to add layers of process, systems, and training, in an effort to make a fundamentally broken concept work.

I'm not saying we don't need feedback. We do need information about results and behavior. That information needs to be relevant, timely, and actionable. For ideas on how to make feedback useful look here.

I'm not saying that we don't need to have conversations about performance.

I'm not saying managers don't need to make decisions about whether a person's performance matches the needs of the job.

But the typical performance appraisal process fails to give useful feedback, fails to promote meaningful conversation, and seldom leads to decisions about fit for job.

FAIL.

When there's disagreement on feedback data

2009-05-18T06:32:00.002-05:00

In my previous post, I described a framework for offering feedback on work results and work relationships.

Step 2 is Describe behavior or results. Use neutral language and examples. If the person doesn't recognize himself in the description or agree with the data, the conversation is over. Labels, comparatives, and absolutes raise defenses.

Karen asks:

.... in the case of, "If the person doesn't recognize himself in the description or agree with the data, the conversation is over", what is the manager's next step?

I don't know the specifics of Karen's situation; here's my general advice

First, check your own language.

Adults almost always reject negative labels. (Unless they've been hearing them since they were tiny children, in which case their self-perception has probably become a self-fulfilling prophecy. But that's another story.) So a label such as, inconsiderate, unassertive, sloppy, is not likely to move the conversation forward and achieve change.

Descriptions that are vague can have the same effect. I met a woman who was told in her annual review, "You are too nice." Her manage didn't provide any examples of behavior or impact. That left the feedback receiver struggling to figure out what her manager was talking about. She was reviewing past events trying to sift out what event could possibly have triggered the comment. When people are left to do this, they often pick an incident completely unconnected to the genesis of the feedback, with predictable consequences.

Absolutes invite people to find the one counter example to your statement. If you tell some one he is always late, he will find the one instance where he was on time.

Labels work against perceptions that the feedback is fair, and that the feedback giver has good intentions. (Point 1 and 2 on conditions for effective feedback) When the feedback receiver questions the label, and the conversations devolves into yes-you-are/no-I'm-not, violating Point 3 on conditions for effective feedback. Which in turn creates the feeling neither the process for developing the feedback, nor the way it was delivered is fair (Point 4).

It's really hard to break the labels habit and eliminated loaded words. Really hard.

Even when your language is clear and neutral, it could be that the person needs time to process what you've said. That not unusual, especially when the new information conflicts with their own self-perception. People are generally more receptive if they've heard something about that area of behavior more before. Pushing some one to acknowledge your point of view during the initial conversation will fuel the defense dynamic.

Some options:

• offer some time to process with an agreement to revisit the feedback in a few days.

• suggest that the person talk to a handful of trusted peers to see if they have noticed the behavior

• ask the person to monitor his own behavior for a period of time and see if he notices himself doing what you've described

All this assumes that the organization can tolerate the behavior for a short time longer as the person works through his process. And it assumes that you have a generally positive relationship with the person. The timeframe you set depends on the impact of the behavior.

In a hierarchy, there’s always “the Big Game” of who get to tell who what to do. Playing that game is a loosing strategy.

You might shift your approach and focus on the desired outcome rather than the current behavior. If the behavior is getting in the way of that person doing his job, you can shift the conversation to “You’ll be more successful when you do ________. Here’s why.”

If it's something like claiming to be unaware that he's pinching another person's arm (or other body parts...believe me, I’ve seen all sorts of astonishing behavior in the workplace), it's time for that person to go. In such a case, or if it's a legal or ethical violation, have your ducks lined up with HR or the company lawyer before you go into the conversation.

There's another sort of case, where other people are reporting behavior that the person denies. It could be a conspiracy, but that's not too likely. In this case, your data is second hand, so you have to avoid the tattle tale trap. Rather than report what other people have said, which puts you squarely in the trap, report your data.

Here's an example from my days as a manager.

My group worked on investment accounting software for a big financial services firm. The system included an overnight cycle. When we put new code into production that affected the overnight cycle, the group rotated on-call responsibility, just in case something went wrong. When something did go wrong, the operations people would phone the person on call to fix the problem.

One of the group members, Joni was more than cranky when she was awakened from her sleep. She yelled, she swore, she told the ops people they were stupid.

Obviously, the ops people weren’t about to put up with Joni's abuse. So they skipped Joni's name when she was first the call list and dialed the person who was second on the list. That's when I heard about the problem.

My first step was to support people to speak directly to Joni. Feedback is almost always most effective when it comes directly from the person who is affected by the behavior. Plus, it avoids the emotional escalation of kicking the problem up the hierarchy.

Sad to say, Joni she yelled at the people who spoke to her directly.

I hand not observed her abusive behavior directly, so I wasn't going to get any where with second hand reports. I had seen enough of Joni in action to know she was sometimes impatient and brusque with her peers even when I was in the room, and I'd coached her on that.

So, I talked about the data I did have related to her abusive manner with the ops folks:

I had one person who was upset that his "first call" rotation was essentially doubled, since he got called when he was first and when Joni was first.

I had three ops people who were feeling abused.

I talked about the impact it was having on our relationship with ops, the team and our ability to get work done.

I acknowledged that I hadn't seen the behavior first hand. I asked her for her perspective.

She denied yelling or swearing, and asserted that the ops people were stupid and incompetent.

My response was, "That may be your perception. Whether you think they are competent or not, it's not acceptable to yell and swear at people."

I talked about consequences. I told Joni that I wasn’t going to get into a he said/she said argument, but that it seemed clear that something was amiss since several people were upset by their interactions with her.

And I let her know what would happen if there were more complaints about her swearing and yelling at people.

I’d reviewed the HR policy, so I knew that the next time someone complained, I could ask for a formal HR inquiry.

I didn't hear about Joni abusing people again, probably because she quit a short time after this conversation.

Consequences do sometimes focus the mind.

If you think my approach seems harsh, consider the No Asshole Rule.

Praise Sandwich Tastes Icky, II

2009-05-08T07:00:00.006-05:00

Art Petty posted Why I Hate the Praise Sandwich.

Praise sandwich, as you recall, involves buttering someone up with a compliment or praise, stating a criticism, and then fluffing them back up with another bit of praise.

Sounds icky, too, doesn't it?

Art offers:

5 Reasons Why the Sandwich Technique is a Truly Bad Practice:

It is a crutch that is solely for the benefit of the giver, not the receiver.

It obfuscates the real message.

It confuses the receiver by watering down the key message.

It destroys the value of positive feedback by linking it with the negative. Don't forget that positive feedback is a powerful tool for reinforcing the right behaviors and the sandwich technique devalues this tool.

It is insulting to the receiver and borderline deceitful. "Bob, you did a great job on XYZ, but… ." It's like a pat on the back followed by a sucker punch followed by another pat on the back.

I agree. Been sayin' so for years.

I commented on Art's post:

I find that many people (including managers) don't know how to offer feedback in a direct and respectful way. I teach people to use this framework:

Create an opening so you are sure it's a good time for the person to hear you… not when he's getting ready for a big meeting or rushing to pick up his kid.

Describe behavior or results. Use neutral language and examples. If the person doesn't recognize himself in the description or agree with the data, the conversation is over. Labels, comparatives, and absolutes raise defenses.

Describe the impact. If there's no impact, why are you having the conversation?

Make a request. You may have a specific behavior in mind, or you may want to engage in problem solving. It depends on the situation.

Finally, don't sell past the close. If the person gets the point after you describe the behavior, zip it. Otherwise, it feels like you are beating a dead horse.

My experience is that people are likely to accept critical feedback when:

1) the giver or source is believed to be reliable

2) the receiver trusts the intentions of the giver

3) the receiver has a chance provide clarifications

4) the process is fair--both the way the feedback was developed and the way the feedback was communicated

Praise sandwich tends to erode trust in the feedback givers intentions, and once that's gone, there's not much chance any useful information will get through.

Year-over-year improvement is what matters

2009-04-30T10:04:00.006-05:00

I just heard that a group of people is working on a CMMi-like framework for Agile Product Management. And of course there's the Agile Maturity Model. And various surveys to assess Agility.

"Maturity" and "agility" are the wrong things to measure.

Level doesn't matter.

Results matter. Year-over-year improvement matters.

I've seen plenty of companies that assessed at some vaunted level, but still produce crappy results and still grind engagement and creativity out of their employees.

"Maturity" and "Agility" are proxy measures have the same risks as all measures: they focus attention on the wrong things and often drive behavior that's counter-productive.

Focus on doing better every day. Practices help you do that. Removing organizational impediments helps you do that. Improving skills does that. Improving the quality of management does that. Improving team capability does that.

What to do with a struggling employee

2009-04-22T09:55:00.002-05:00

Esther Schindler recently put forward a scenario about a struggling employee named Frank, and solicited advice from her network.

Briefly, the scenario is this: Frank was a great maintenance programmer, but the company is retiring the system he worked on. Frank has moved to a new project in a new language and he's not catching on. (Full scenario is here.)

The Other Esther summarized the advice she received in When the Job Changes But the Programmer Doesn't and When the Job Changes But the Programmer Doesn't Part II: Saving Frank's Job.

My full response (excerpted in Esther Schindler's posts):

It sounds like Frank has been a valuable employee. But now he's in a position where his skills and preferences aren't a good match for what the position requires.

So first, I'd think about whether there is a way to make use of his maintenance programmer skills on the new system. Can he fix bugs? Can he contribute domain knowledge in some other way?

It's not unusual for people who are learning a new skill to follow rules rigidly. They haven't internalized the new knowledge to the extent that they can see possibilities and use the skill intuitively.

The scenario doesn't say how Frank has gone about learning the new language. Pair programming can be a great way to learn, and pairing a beginner with an expert can be enlightening for both.

I'd also look at how the work is chunked up. It may be that if Frank broke the work down into more discrete 1-2 day chunks he'd be able to make better progress.

If there's no way to use Frank's skills, then Frank's manager needs to have another forthright conversation with him, explaining his expectation and concerns, and hearing Frank's point of view, as well. Chances are pretty good that Frank is as distressed as his manager is.

But before the meeting, Frank's manager needs to decide if he's willing to give Frank another chance, or give him time to find another job within the company. If not, get the ducks lined up with HR to end Frank's employment.

If Frank wants to try once more to get up to speed, they need to agree on a plan with specific actions. They need to agree how they'll evaluate whether Frank is making the kind of progress the job requires. And the manager has to put a time limit on it--weeks not months.

If Frank recognizes that he's just not in the right job, and he's an employee that can still make a valuable contribution somewhere in the company, set a time frame for Frank to find a job internally--weeks not months. Start looking for Frank's replacement. If Frank hasn't found an internal job by then, end his employment.

If Frank isn't a good candidate to stay at the company, don't let the situation drag on forever. The current state is painful for everyone. And while firing Frank will probably be painful, it won't be as difficult as the alternative.

A couple of things to emphasize:

Allow weeks not months to turn the situation around. That means 2-6 weeks, no more.

Choose based on how big a hit you can take on the project. Look at the trade offs. Some times no body is better than a warm body. If working with Frank is taking significant productive time away from others for little potential return, 0 weeks is the right answer. As Jerry Weinberg asked, "Is this a business or a charity?"

If Frank can be valuable to the company, but not on your project, set a time frame for *Frank* to find a new job. You are not a job placement service, and not your job to find him a new assignment. It's Frank's job to find that next assignment. You can offer to introduce him to people or give a reference, but Frank needs to do the work. And set a time limit 2-6 weeks, no more, depending on your project needs. Do not wait until Frank has found a a new assignment to start looking for his replacement.

The Benefits of Peer Feedback

2009-04-14T07:50:00.003-05:00

Peer feedback is a core skill for collaboration. It's impossible to work closely with out running into some bumps: differences, disappointments, and disagreements. Peer to peer feedback can help keep working relationships on track and improve results (and it keeps the manager out of the transaction so it doesn't be come a *big deal*).

I teach about feedback in both my team collaboration workshop and management workshops. "But does it work in the real world?" some ask. Ola Ellnestam blogs How I Learned about Feedback.

Five Ways that Team Members Build Trust with Each Other

2009-04-02T17:05:00.003-05:00

Building trust may seem mysterious... something that just happens, or grows through some unknowable process. Like many things, there are concrete actions that tend to build trust (and concrete actions that are almost guaranteed to break trust down).

First, a definition of trust in the workplace. We all know that trust is the foundation for teamwork. But to hear some people talk about it, you'd think team members were getting married, not creating software together. What we need in the workplace is professional trust. Professional trust says, I trust that you are competent to do the work, that you'll share relevant information, and that you have good intentions towards the team. Taken broadly, that's trust about communication, commitment, and competence.

1. Address issues directly

It's inevitable that some person on the team will rub another person on the team the wrong way. Maybe it's they way he cracks his gum, or listens to voice mail on speaker phone. Maybe it's using your laptop and changing all the preferences. Maybe it's breaking the build and then leaving for lunch.

These frictions are inevitable. When a team member speaks directly to the person who is bugging him, he builds trust. Raising an issue says, "I value our working relationship, and I'm willing to have an uncomfortable conversation to make it better." It says, "You'll know where you stand with me; I won't be talking behind your back."

These conversations aren't always easy. Sometimes people delay the uncomfortable discussion until the situation becomes intolerable, letting anger and resentment build.

Sometimes people try to avoid the difficult conversation by telling their manger about the problem. And sometimes the manager falls into the trap of carrying the message. Seth had just started a new job and hadn't really made friends with anyone on the team yet, so he spent is lunch hour alone. On his second week on the job, his new manager called him in to inform him that another team member resented the amount of time he was taking for lunch, since 45 minutes was the unspoken rule.

(I do wonder why no one bothered to tell Seth this, and why no one invited him for lunch in his first week on the job, but that's another issue.)

When his coworker talked to the manager instead of talking directly to Seth, he broke
trust. When I talked to Seth, he'd been at that job for over a year, and still didn't fully trust his coworker. No one likes a tattle tale.

When people don't know how to have difficult conversations...or think it's not their job to navigate working relationship, trust erodes. And that's why people need a framework to talk about interpersonal feedback.

2. Share Relevant Information

If you don't support an idea or approach, say so. (Of course, there are more effective and less effective ways to do this.)

When someone on the team withholds and opinion or concern when a topic is under discussion and then comes back later to say "I thought it was a bad idea from the start," other team members feel blindsided. That breaks trust.

Relevant information is about the task, but it's also about you. People tend to trust people they know as individuals and can identify with. Shared experience, shared interests and identification form solid ground that people can land on when there is friction and conflict. You don't have to share your deepest secrets, but letting other people on the team know something about life outside work makes people "real." It's hard to trust a cipher; much easier to trust and be generous with someone who shares some of the same challenges and interests that you do.

In order for teams to function, team members need to believe that their co-workers are reliable. Without the confidence that others are reliable and will carry their share of the load, few will commit to a shared goal.

3. Follow Through on Commitments or Give Early Notice When You Can't

No reasonable person expects that every person can meet every commitment all the time. We know that sometimes a piece of code turns out to be more complex than anticipated or we discover we didn't fully understand the task when we made our estimate. But when you wait until the moment the task was due to let people know it's going to be late, it breaks trust. So let people know as soon as you know, and renegotiate.

4. Say No When You Mean No

Sometimes you just can't take on another task, or do a favor that someone asks for.
But most of us are programmed from an early age to please other people. If we say no, we're called selfish or "not a team player." But if you really can't do what's asked, it's more respectful to say No and let the other person get on with getting his need met elsewhere.

Saying Yes without follow-through leads others to doubt your word. If you can't say No, your Yes won't mean anything.

It may seem paradoxical, but building competence trust sometimes means admitting that you don't have all the answers.

5. Show What You Know and What You Don't Know.

Be generous in sharing your knowledge (without inflicting help). But also be willing to hear other peoples ideas, build on them, and help others shine. Admit when you don't know the answers; there's nothing worse than a know-it-all who is wrong. Ask for help. That helps other see you as a real person, and people generally like to be helpful.

Visibly Valuable

2009-03-31T14:11:00.003-05:00

In these unsettled times, you can spend time worrying about things you can't control, or you can take action on things that are within your control.

Here are 10 things you can do as a developer to make yourself more visibly valuable, which may keep you off the RIF list.

1. Understand what is most important to work on. List those items in rank order. Work on the most important thing until it is done, or until you are stuck. Move to item two. Repeat.

How will you know what is most important? Ask your manager. Do not accept “everything is important” or “they are all number one priorities” as an answer. Those are not answers, they are signs that your manager is pressured, stressed, and isn’t taking time to think clearly.

Ask your boss some questions that will help him think.

• If you were doing this work, which would you work on first?

• Which has to be done soonest?

• Which one will bring in/save the most money?

• Which one will help you most?

2. Get more done by doing fewer things at once. Finish one task or project before you start the next (in priority order, of course). I currently have 4 handcraft projects in progress. I work on the green sweater for awhile, then I switch to the gold quilt, until I want to work on the blue hat, and then I skitter off to the purple quilt. I’m having a great time, I’m busy, and ain’t none of my projects getting done.

It’s quite clear to most people (including me) that I could get one of these project finished faster if I concentrated my effort on that project rather than switching back and forth. Some how, many managers forget this when they go to work and hope that multitasking will actually work. But it doesn't, so don’t even try to do everything at once. It doesn’t work, and actually slows down progress.

3. Understand your own capacity before you commit. Track where your time goes for a couple of weeks. How much time do you spend checking email, answering questions, going to meetings? Look for ways to reduce interruptions and reduce the biggest unproductive use of your time. (Taking breaks is not an unnecessary use of your time. We all know that we do better if we take a little breather from time to time.)

4. Review all the meeting you attend on a regular basis. Notice which meetings have stated goals (that match what actually happens) and which have a published agenda (that’s actually followed). Decline to attend meetings that don’t have a real purpose and a plausible agenda. They will waste your time.

5. Make commitments based on your known capacity, rather than on an ideal 40 hour week. You will become known as some one who meets her commitments, rather than some one who is always late or overly optimistic in her estimates.

6. Work in inch pebbles. Break down projects into tasks that you can complete in a day or two. When you do this, you can report tangible progress at least twice every week. You will become known as someone who gets work done.

7. Test as you go. Check in code at the very least once a day, and run all your tests for that piece of code each time you check in. That way, you will avoid having a false assessment of progress by deferring knowledge of problems until the (false) end of the task.

8. Peer review all fixes. A defect is a clue that the code is difficult to understand or poorly written. So you will avoid breaking something else by having another set of eyes look at the fix.

9. Write tests for the defect fix, and then write a half-dozen tests (at least) in the code around the defect. Defects tend to cluster, so you will be strengthening your code and your feedback system by writing additional tests.

10. Work at a sustainable pace. Tired people make mistakes and write or miss defects. You don’t want to be known as someone who makes mistakes. For most people, a sustainable pace is somewhere between 40-50 hours a week.

I'll write a list for managers, perhaps next week.

Three Myths about Teams

2009-03-30T07:30:00.002-05:00

Myth #1: All a team needs to get them working well together is a clear goal and sufficient pressure to perform. I’ve never seen a team without a clear and compelling goal gel; but I’ve seen plenty of teams who did have a clear goal flail and fail. Until a group of people decides to work as a team and decides to agree, they won’t function well as a team.

Myth #2: A manager can discern individual contributions to team results. While a manager can tell certain things about the way a team is functioning, in most cases, it’s impossible to tease out individual contribution. And when managers try to assess who has made the biggest contributions, they are often wrong. Taking action on an incorrect assessment can have devastating effects on the team, and makes the manager look foolish.

Myth #3: If the team isn’t struggling or working long hours they aren’t working hard. Teams that are working well together make the work look easy. They work at a purposeful, yet relaxed pace. They even look like they are having fun.

Three Pillars of Executive Support

2009-03-11T10:22:00.002-05:00

I hear people talk about getting executive support for Agile adoptions (or other organizational changes). But I seldom hear people talk about what that support looks like. It's more than money and speeches.

Want to know how to really help your organization change? Three Pillars of Executive Support for Agile Adoption on AgileJournal.com.

system blindness

2009-03-07T08:00:00.003-06:00

One of the big problems I see in organizations is that managers who want to improve productivity pull the wrong levers.

For example, one company I know of decided to improve performance by ranking everyone in the company from 1...n, and firing the bottom 10%. Not surprisingly (to me at least), performance didn't get better. But the managers were surprised (when they noticed at all).

Individual performance is important, but it's often not the primary lever to improve organizational performance--it's the work system that needs improvement.

In the company that tried ranking to improve performance, there was no clear product direction, priorities shifted weekly, and teams where broken and reformed every few months. Improving any of those factors would have had a much bigger over all improvement effect than forced ranking and culling.

We like to believe that people succeed or fail by their own efforts. I don't discount individual effort....but focusing only on individual effort blinds us to system effects.

Meeting Madness

2009-03-04T07:30:00.002-06:00

Seth Godin blogs about Three Kinds of Meetings:

There are only three kinds of classic meetings:

Information. This is a meeting where attendees are informed about what is happening (with or without their blessing). While there may be a facade of conversation, it's primarily designed to inform.

Discussion. This is a meeting where the leader actually wants feedback or direction or connections. You can use this meeting to come up with an action plan, or develop a new idea, for example.

Permission. This is a meeting where the other side is supposed to say yes but has the power to say no.

PLEASE don't confuse them. Confused meeting types are the number one source of meeting ennui. One source of confusion is that a meeting starts as one sort of meeting and then magically morphs into another kind. The reason this is frightening is that one side or the other might not realize that's actually occurring.

Indeed.

People waste countless hours in meetings with murky goals. Worse, each person may come out of such a meeting with different conclusions, spreading the confusion further in the organization.

Even when a meeting has a clear purpose, if there's no clear way to achieve that purpose, the meeting will not be as effective (or short) as it could be. Another waste of time.

People, people, people.

Improving the quality of meetings is a small intervention that can bring significant improvements to an organization. So don't overlook it even if improving meetings isn't shiny or sexy. Be a master of the obvious. Get the basics right, and you'll have a stronger foundation for the fancy stuff.

More ideas on how to improve meetings:

How to Improve Meetings When You are Not in Charge

The ROTI Method of Gauging Meeting Effectiveness

Applying "the simplest thing that could possibly work" principle

2009-02-11T07:40:00.003-06:00

What problem are organizations trying to solve with incentive pay?

Is an incentive plan the simplest, most effective way to address the problem?

Most managers believe that incentive pay plans encourage the desired behavior, drive performance improvement, and reward (individual) achievement. That may be the case, with certain kinds of work.

But before looking to incentive pay to improve performance, look at the work system.

What are the organizational impediments that might be preventing desired performance?

What else might be preventing people from achieving the desired results?

Do people have a clear understanding of how their work contributes to the bottom line and the companies mission?

Do people have a clear expectation of what's expected of them day-to-day?

Do people have the tools to perform?

Do they have the skills?

Are they receiving feedback from the system and from their peers and managers?

Will individual incentives actually encourage the behavior the organization says it wants?

Will the side effects of incentive pay help or hinder the organization?

These questions need to precede the decision to use incentive pay to drive behavior and results.

As Ann Bares, writing for Workforce.com says,

Much as our management "customers" might like to believe the contrary, incentives are not a sound substitute for an effective organizational structure, good management practices or clear and regular communication.

So work on improving the system and managing well before looking to incentive pay to improve performance and results. That's the simplest thing to do. Plus, for interdependent work, incentive pay is likely the wrong level to pull.

Read Ann Bares' full article here (requires free registration).

15 Things Bob Sutton Believes

2009-02-10T14:48:00.003-06:00

From Bob Sutton's Work Matters blog:

15 THINGS I (Bob Sutton) BELIEVE

1. Sometimes the best management is no management at all -- first do no harm!

2. Indifference is as important as passion.

3. In organizational life, you can have influence over others or you can have freedom from others, but you can't have both at the same time.

4. Saying smart things and giving smart answers are important. Learning to listen to others and to ask smart questions is more important.

5. Learn how to fight as if you are right and listen as if you are wrong: It helps you develop strong opinions that are weakly held.

6. You get what you expect from people. This is especially true when it comes to selfish behavior; unvarnished self-interest is a learned social norm, not an unwavering feature of human behavior.

7. Getting a little power can turn you into an insensitive self-centered jerk.

8. Avoid pompous jerks whenever possible. They not only can make you feel bad about yourself, chances are that you will eventually start acting like them.

9. The best test of a person's character is how he or she treats those with less power.

10. The best single question for testing an organization’s character is: What happens when people make mistakes?

11. The best people and organizations have the attitude of wisdom: The courage to act on what they know right now and the humility to change course when they find better evidence.

12. The quest for management magic and breakthrough ideas is overrated; being a master of the obvious is underrated.

13. Err on the side of optimism and positive energy in all things.

14. It is good to ask yourself, do I have enough? Do you really need more money, power, prestige, or stuff?

15. Jim Maloney is right: Work is an overrated activity

A fine list. What do you believe?

How much to automate

2009-02-10T13:28:00.003-06:00

In my experience it's *really* difficult to do agile development (or be agile) without the frequent feedback provided by automated tests. But automated tests can be expensive.

An interesting post on the topic from Elisabeth Hendrickson:

In some contexts, particularly where there is a legacy code base that was created without automated tests, the cost to create and maintain each automated test is extraordinarily high.

Further, the value of those tests is often less than it could be.

The value in any test is in the information that it provides. But when many of the test failures are because the tests, and not the code, are wrong, the information provided by the whole suite of tests is deemed unreliable and untrustworthy. Information only has value to the extent that we can trust it.

Thus, the automated tests in that kind of context are both insanely expensive and low in value. Some years ago this was the norm. In many organizations, sadly, this is still the norm.

But it doesn’t have to be that way.

Successful Agile teams typically follow at least a subset of the XP development practices like TDD and Continuous Integration. Oh, sure, you can be Agile without doing TDD.

But teams that do practice TDD and ATDD wind up with large suites of automated tests as a side effect.

Read the full post here.

Problem Solving Leadership, March 22-27 in ABQ

2009-02-09T12:37:00.001-06:00

We're giving the next offering of the famous Problem Solving Leadership (PSL) on March 22-27, 2009 Albuquerque, NM led by Jerry Weinberg, Johanna Rothman, and yours truly.

The workshop's purpose is to learn and practice a consultant's most valuable asset: the ability to think and act creatively. We have designed this workshop to be practical and applicable to the modern workplace. Your problems and concerns provide a frame of reference for all
the workshop activities.

What you will learn
. to be a leader while being a member of a team
. to focus your thinking while in chaos
. to make change a productive, creative event
. to build truly effective teams
. to design projects people really want to work on
. to observe exactly what is happening
. to use tools of effective communication
. to handle conflict in problem solving groups

The workshop provides five and a half days of intensive focus on developing your unique leadership style and abilities.

If you would like more information about in this unique workshop experience, send email to jr@jrothman.com and/or take a look at my PSL page.

Self-organizing Teams Interview

2009-02-04T04:02:00.002-06:00

Bas de Baar and I had a little video chat about self-organizing teams a couple of weeks ago. Video is here. (Thanks to Andres and George for pointing out the empty link.)

The Pay Off in Merit Pay (Not)

2009-01-14T13:12:00.004-06:00

If you've been reading this blog for a while, you know how I feel about compensation systems that claim to motivate better performance with differential pay.

For example,

A Compensation Story in 2006,

It's What We Know That Ain't So and

Pay for Performance and Why it Doesn't Really Work in 2007

So of course, I was interested when I came across Where's the Merit-Pay Payoff? by Fay Hansen on WorkforceWeek.com. (requires free registration).

A few snippets:

The seemingly self-evident premise underlying merit pay and other individual performance-based pay plans is that they produce higher employee and organizational performance. Most companies, however, do not test the actual impact of performance-based rewards on employee behaviors and financial results. The most comprehensive empirical studies flow from the academic world, where evidence is mounting that the assumptions underlying individual performance-based pay programs are wrong.

"The evidence is overwhelming that individual pay for performance does not improve organizational performance except in very limited cases."
—Jeffrey Pfeffer, professor, Stanford University Graduate School of Business

"Effective management is a system, not a pay plan. The mistake is that companies try to solve all their problems with pay."
—Jeffrey Pfeffer. professor, Stanford University Graduate School of Business

Pfeffer notes the existing evidence points to group bonuses, profit sharing and gain sharing, which is a form of profit sharing, as more effective forms of performance-based pay than merit pay or individual incentives. "Group plans are more collective and recognize the interdependent nature of work today," he says. "Most employees look at their total compensation and want to see that they share in the success of the organization."

This is particularly germane to organizations that are asking people to work collaboratively in teams. Yes, we do pay individuals. There are rational ways to do that without so-called merit raises. I'm glad to see that group bonuses and profit sharing are starting to come up in the conversation.

----------------------------------------------------------------------------------
I will address the top concerns that come up when I write/talk about this topic preemptively.

1. I am not suggesting that everyone be paid the same salary. Skills, experience, domain knowledge and the current market are all considerations in setting salary. The key is to pay people equitably (which is very different from "pay equally").

2. I am not suggesting that everyone's skills and performance are equal. Of course people have different skill levels and perform differently. Most companies recognize this with salary bands.

3. I am not saying that teams should have a team salary. Salaries are paid to individuals... though I suppose an independent team could contract jointly, and then decide how to allocate pay within their group. But that's a different topic.

4. I am not saying people don't need feedback on their performance at work. People need feedback--which is information about performance, not evaluation--on a frequent basis. The more we can design systems where the feedback comes from the work, the better (e.g., build lights, green bar/red bar test frames). Peer feedback and feedback from managers are crucial for improving performance.

5. I am not saying that people who aren't actually working should continue on the payroll. But any manager who needs a pay-for-performance system with ratings and rankings to figure this out is in big trouble.

I think these are some of the things people fear when they think about removing merit pay. There are other rational pay systems... but they aren't as wide spread, so few people know about them. More on those, later, perhaps.

A Retrospective Report

2009-01-14T08:06:00.003-06:00

John Wilger has posted his experience leading a release retrospective. It's a nice description of the flow of the retrospectives, and shows how activities help people get beyond superficial and habitual thinking.

In summing up, John writes:

Before we held this retrospective, I think some of the team members felt that we would not gain much from doing a full-day retrospective this time around. We had made good progress on our action items from the previous retrospective, and the general feeling was that things were going basically well. What could we possibly need to change?

People, please don’t hold retrospectives only when your team feels like there’s a problem that needs to be dealt with. If you hold retrospectives on a regular basis, whether you feel like you “need” to or not, you will uncover issues before the become problems. In our case, we managed to uncover a number of issues during our retrospective that could easily have grown into much larger problems if we didn’t bother to think about them until the effect was obvious.

intake->meaning->feeling->response

2009-01-13T09:52:00.003-06:00

Mike Cottmeyer writes about Feelings, Thoughts, and Actions.

When people have a strong response, Mike describes thoughts as the point of leverage to change behavior.

How we think can be influenced more directly... it is somehow less personal. We can learn about our environment and the people that are a part of our lives. We can gather more information about what motivates those around us and learn something about their intentions and circumstances. With new information, we can learn to think differently about what is happening to us.....By guiding thinking, we are able to broaden the perspective of our team and create the opportunity to coach behavior.

This lines up nicely with a model I use, Ingredients of an Interaction, from the work of Virginia Satir.

Intake: We take in data from the environment (filtered by our preferences, education, stress level...)

Meaning: We make an interpretation of the data (influenced by past experiences, education, stress level...)

Significance: We have a feeling, based not on the observed data, but on our interpretation of the data.

Response: We act out of our interpretation and feelings.

(Don Gray describes the Satir interaction model in more detail here.

When Mike coaches about thoughts, he's working on the level of Meaning, expanding the possible interpretations. When he talks about bringing in more information, he's working on the level of Intake.

I find this is a powerful model for untangling communication that's gone awry, and for understanding and shifting my own reactions.

***

On a related note, Mike talks about telling people their behavior is "unacceptable."

Rather than start out by telling some one his behavior is unacceptable, I find it usually works better to get agreement that the behavior happened. That usually requires neutral language...rather than "you were pounding the table in our meeting today" I might say "In our meeting, I saw you raise your fist and bring it down on the table." It's too easy for people to get into a Yes-you-did/No-I-didn't argument when there's any hint of judgment in the description. If people don't agree with the data, they aren't likely to listen to anything else you say.

Once I've got agreement on the data, I talk about the impact of the behavior. "I was startled. I noticed that Jen and Josh both pulled back from the table, and didn't say anything else for the rest of the meeting." Depending on how the other person response, I might go further. "When you hit the table, its hard for me to continue participating in the meeting. What I see is that when you bring your fist down on the table, it gets in the way of people listening to your ideas" (or something like that).

I'd rather let the person conclude that the behavior is ineffective and counter-productive and make a different choice. I find that works better with adults than having me say "That behavior is unacceptable"....especially since it may have been accepted in the person's family, or some previous context (where they learned it, and where it might have worked--on some level).

There are times when I do say "that behavior is unacceptable here," but I usually don't need to do that with reasonably well-adjusted adults.