Category Archives: Coaching

Are You Ready to Coach?

Agile coaches are expected to help teams learn agile methods, engineering techniques, and improve the productivity of the teams they work with.  But before they can do they need to be ready to coach.  Being ready to coach means that you have coaching skills, relevant technical and process skills.

But the  foundational skill in coaching is skill in managing yourself.

Your attitude will contribute or detract from your ability to make contact, assess what coaching is needed, and actually help the client.   So,  before you begin, ask yourself a few questions.

Are you aware of your own emotional state? Manage your own emotions before you coach. Coach from a neutral, curious, and encouraging attitude. If you’re feeling angry or impatient, your emotions will leak into the coaching. Anger, frustration, or impatience won’t create a helpful interaction. Look inside to see where your emotions are coming from: Are you expecting an inexperienced person to perform as well as a master? What are your assumptions about what the other person should know or be able to do? Rather than blame the other person, reframe your judgment as “He doesn’t do that as well as I wish he did” or “She doesn’t know as much about this topic as I wish she did.” Shifting your attitude will make you a better coach.

Is coaching the best learning opportunity? When the team struggles and puts the team goal at risk, ask yourself: Where is the biggest opportunity for learning? Will the team learn most from making their own mistakes and learning from the consequences (That’s the beauty of short iterations—if the team misses a goal, the risk is limited by the length of the iteration) or will the team learn most if you coach them in a different direction?

Does the other person want coaching? Coaching always works better when the other person actually wants help. Try to wait for the person or team to come to you for help rather than immediately stepping in the moment you see trouble. Many people learn from solving problems on their own. That doesn’t mean you always have to wait until someone asks you for coaching. Coaching is part of your job, so you can always offer. But remember that it’s an offer—so ask before you inflict help. However, if you see a pattern emerging—a team member repeatedly refuses help when stuck—you have an opportunity to give feedback on how that pattern of behavior affects the team as a whole.

Does the other person want for coaching from you? Sometimes people want help, but they want it from someone else. Don’t take it personally if a team member would prefer to receive help from someone other than you. But again, look for patterns. If a team member is open to coaching from everyone but you, it’s a clue that the relationship may need repair.

Are you clear on the goal? If you aren’t clear on the desired outcome, you risk setting up a frustrating cycle called “bring me a rock.” “Bring me a rock” happens when success criteria are vague (or nonexistent). Here’s how it goes. You say, “Bring me a rock.” The other person goes off and finds a rock, and brings it back to show you. You look at the rock and realize it’s not the rock you had in mind. You hand the rock back and say, “Not that rock.” And the cycle begins again. The result is frustration and de-motivation—guaranteed! Of course, sometimes the goal isn’t known in detail. In that case, make it clear that the goal is to explore options and gain clarity.

Are you open to other approaches? You may have a very clear idea of how to accomplish the work or handle the interaction. But is it the only way? In most situations, there are many reasonable and acceptable paths to success. If you find yourself expecting things to be done a certain way, ask yourself if that way is simply your preference and not the only correct method. Help the person you are coaching think through different options and discuss the pros and cons of each approach. Then let the person choose the one that fits best for him or her. Team members gain capability when they develop based on their own thinking modes, strengths, and talents.

Are you ready to encourage rather than evaluate? Coaching is about helping another person develop skills and capabilities; it’s not a time for evaluation. Evaluation hinders coaching by creating a “one-up, one-down” dynamic. Most people have enough trouble asking for help in our culture without adding this burden. Stay away from comparative words such as good, better, worse, and bad. When you think the other person is headed down a rat hole, ask questions about risks and impacts rather than criticizing. Then help generate new ideas. Offer encouragement to let people know they are moving in the right direction.

When you can answer “Yes” to these questions, you’re ready to make contact.  And then you  can start to coach.

Should a manager know a language? Yes. One that enables communication with people.

When I talk to people about making the transition from technical work into a management role, one of the recurring questions is whether managers need to know a language. There are strong opinions on both side of the argument:

On one side, people say: “You must know a language if you are to understand the work of your staff and have the respect of developers!”

On the other side, people respond: “Knowing a language isn’t necessary. Managers need to understand the work and not pretend to have more technical depth than they really have.”

Of course, the participants in this discussion are talking about a computer language. But what about being an expert in spoken language?

We communicate every day—to our families and friends, co-workers, managers, and teams. Language allows us to go where we want to go, have what we need, and communicate our ideas and feelings to others. Like many daily activities, our use of language is below the radar of conscious examination.

And that can trip us up. Here are some language traps for managers to avoid:

Absolutes

Have you ever heard this conversation?

Fred: You always forget to take out your testing stubs when you turn code over to CM.

Megan: Sure— I forgot a couple of times and you’ll never let me live it down!

Jennifer: You never include enough information in your bug reports.

Tom: Yes I do. Just ask Chase—he was able to recreate that data purge problem right away.

Always and never should never be used; they will always land you in trouble.

Well, I wouldn’t go that far. These words have their place. But be careful of how you use them, especially when you are hoping to influence future behavior. Always and never tend to focus the mind on finding a counter example. Absolutes set up the dynamic we saw with Fred and Megan and Jennifer and Tom.

Missing Details

Have you ever seen something like this happen?

Krista: You need to do better with your defect reports.

Dave: Okay.

Dave goes off and designs a new automated form that captures the memory state at the time of the error. Two weeks later he proudly shows Krista his work.

Krista: That’s not what I meant! I wanted you to describe the clicks that lead up to the error so the developers could recreate it!

Krista might have gotten what she’d wanted if she had filled in the details of the request. (If you are on Dave’s side of such a vague request, don’t guess, ask for clarification!)

Missing Comparisons

Product manager: We need to get this product out the door faster!

Compared to what? Without a comparison, we tend to fill in the blank with our own definition (which is most likely different from the next guy’s definition). Does faster mean one week faster? A day faster? Faster than our competitor? Faster than the speed of light?

We will do much better at meeting improvement goals when we are explicit and specific:

“The goal for 2.0 release of WidgetWonder is to improve mean-time-to-failure by 10%.”

“The Rec_retrieve function needs to complete in 1 second or less.”

“Our goal is to improve our turn-around time on customer identified critical errors by 25% on average.”

Black and White and Gray

Managers need to recognize when they are talking about a continuum (as with the concept fast) or a mutually exclusive category. We have a natural tendency to categorize. And our professional experience may condition us to look for binary conditions: A test passes or fails. A task is done or not. The release criteria has been met or it has not been met. Being clear about discrete conditions can be useful.

But not everything belongs in a mutually exclusive category, especially characteristics and qualities that pertain to people.

Consider this exchange:

Eric: I’m thinking about moving Cyndi into a management position.

Chris: I don’t know about that…I don’t think she could handle management. Cyndi isn’t assertive.

Assertiveness is not a category, it’s a continuum. One end may be doormat and the other end domineering. People can be at any point on that range, and their placement on the range isn’t fixed. In some situations, when Cyndi knows the subject matter and is feeling good about herself, she can be appropriately assertive. On another day, when everything has gone wrong at home, she’s out of her comfort zone, and is dealing with a situation she’s never faced, she may be less assertive.

Before you put someone in a box, check to see if the variable you are describing is continuous or discrete. Look at how the quality plays in different situations and over time.

It may help to know something about Java or C++…But it’s essential to be competent in the use of daily language (whatever your native language) when you are making the transition to management. Communicating clearly and unambiguously with your team will improve relationships, morale, and results.

An earlier version of this column appeared in STQE magazine, May/June 2002

A Tale of a Too-Hands-Off Manager

I recently worked with a team that was struggling. One of the team members, Tad, wasn’t playing by the rules the team had established. When the team formed, members agreed that each day they’d have a fifteen-minute stand-up meeting to report on progress. The team members agreed that they’d chunk their work into tasks that were a day or two long, knowing that would help them stay on track and make progress visible.

But all was not well. When the other team members picked a story off the task wall, they’d break it down into tasks and post them back on the wall. When Tad picked a story, the card disappeared from the wall. At the stand up meeting, his reports were vague. “I’m coding,” he’d say.

After a couple of rounds of such murky reports, two team members, Sally and Will, sat down with Tad.

“What’s up?” Will asked. “Do you need some help?”

“No,” Tad replied. “I’m working on it.”

“But we don’t know what progress you’re making,” Sally said.

“I’m working on it,” Tad replied, staring at the notebook in his lap.

“Tad,” Will implored. “You agreed to report tangible progress every day. We all did.”

Tad closed his notebook. “I’m working on it. Now leave me alone so I can keep working on it.”

The team’s agile coach tried, too. After a vague report in the next stand-up, the coach probed for more information.

“What exactly are you working on, Tad?” he asked.

“The reset feature,” Tad replied.

“When will you finish it?” the coach asked.

“I’ll be done when I’m done,” Tad replied. “I’m working on it.”

“That’s not good enough,” the coach said, laying down the law. “When you don’t report demonstrable progress, it hurts the team. We don’t know if we’re on track or not. We can’t give our customer an accurate read on meeting our iteration goal.”

“I’m working on it,” Tad replied.

The coach tried benching Tad, telling him he couldn’t take any more tasks. Tad took them anyway, working at odd times, checking out code, and keeping a local copy on his machine.

After weeks of Tad’s odd behavior, the coach approached the development manager. “We’ve tried everything we can think of,” the coach said. “We need you to step in and help us get Tad on track.”

“You are self-organizing,” the manager demurred. “You need to figure out how to deal with team members.”

And that was that.

The team tried everything it could think of to induce Tad to report on his work, finish his work, and see his contribution—or lack thereof—to the team’s iteration goals. And as their manager continued with his “hands off” attitude, team members’ morale plummeted. It felt like their manager had abandoned them. He had.

Fortunately for this team, the hands-off manager left the organization. The new manager recognized the team was struggling and handled the performance issue.

Managers of self-organizing teams need to discern when it’s time to step in and when to step back, allowing the team to solve the problem on its own. How do you know when a light touch is called for and when action is needed? Ask:

  • Does the team have the knowledge to solve this problem?
  • Does the team have the experience to solve this problem?
  • Does the team have the will to solve this problem?
  • Does the team have the courage to solve this problem?

If so, give the team some time to work out the issue. If you sense team members are stuck, coach them with open-ended questions to recognize the resources they already have to address the issue.

  • Is this a new area of responsibility for the team?

If the team is taking on a new responsibility—one that’s been yours in the past—offer a process to help the team make the decision or solve the problem. Be wary of stepping in. If it looks like you are trying to take the decision back or influence the team, your credibility is lost.

  • What are the consequences of failure?

It’s been said we learn more from failure than from success. So do you really want to deprive the team of a learning opportunity? Consider the consequences of letting the team learn from its mistakes. Most projects can survive a missed iteration goal. Most projects can survive going a short way down the wrong technical path.

This article originally appeared as a sidebar to an article in Better Software magazine.

A Coaching Toolkit

As a coach, your job is not to solve or do—it’s to support other people as they develop skills and capabilities and as they solve problems on their own. When it comes to coaching, one size does not fit all. You need to have a variety of practices in your toolkit in order to approach each situation and individual differently. Here are some of the approaches I use when coaching other people.

Provide Context

Sometimes all a person needs is some context. Knowing how a specific task or skill fits into the work of the team or supports the product helps people make better decisions. And knowing the importance of an activity can motivate people to do tasks they don’t normally enjoy. For example, a person may not like test-first development when he first tries it, but when he understands how it contributes to clean code and good design, he may be more willing to stick with it.

Frame the Problem

Sometimes people need help framing the problem. When people are learning a new skill or a new way of thinking they don’t always have a clear understanding of the problem they’re trying to solve. Ask them questions to help them consider and verbalize different aspects of the problem—the what, where, when, who, and how. Having a clear problem statement is (at least) half the battle.

Generate More Options

In other cases, a team member may choose a solution that you know will not be effective. How do you help without being directive? Well, it helps to know that people always choose what they perceive to be the best option available. Always. The trouble is, sometimes people don’t have enough good options to choose from—the only options they can think of either won’t work or work only in the short term. To help them come up with a longer list of options, ask questions. These questions might include:

  • What other ways could we accomplish the same goal?
  • What would happen if we did this part differently?

Rather than reject an option (or worse, dismiss the person), walk through the option with him or her. Start by saying, “You could do that—and here are some of the risks I see.” Generate additional options together. You can offer the first option, then move to jointly generating alternatives. Between you, come up with at least three options. Having only two options is a dilemma; and it forces a choice between “your way” and “my way.”

Provide Real-Time Feedback

Many times, when performing a new skill, people need to hear some real-time feedback to get a feel for how what they are doing is affecting the project. Help them by offering course corrections and confirmation. Just remember that feedback is information that enables different choices; it’s not criticism or evaluation. Describe what you see or hear and state the impact.

Ask Questions

Sometimes people just get stuck. A few well-chosen questions can prompt new thinking. Here are some that work well for me:

  • If you did that, what would you gain? / If you did that, what would the collateral consequences be?
  • What are three things that could go wrong with that approach?
  • What else have you tried?
  • What are you hoping to accomplish?
  • Who else is affected by this?
  • Who else / what else will be affected by this solution?

Catch People Doing Something Right

You don’t have to wait until something is going wrong to provide coaching. Notice when people are performing a new skill correctly and comment on it. If the moment seems right, use the opportunity to explore the root causes of the success. When people know more about the steps and circumstances that lead to good results, they can consciously recreate them.

Demonstrate

Some individuals learn best by seeing it done. In those cases, demonstrating a new skill for them might be your best option. For example, you might teach about Test-Driven Design (TDD) by demonstrating with FitNesse. As you demonstrate ask if your pace is too slow, too fast, or just right. If you only ask if you’re going too fast, the other person may be embarrassed to admit he isn’t keeping up.

Review

Other people learn best by trying it themselves first and then reviewing it with the coach. Always start by stating what works and making global comments about the work product. Only then should you talk about the problems or issues. If there are classes of issues, discuss those rather than pointing out each instance of the problem.

Provide Information

Coaches are a source of information—and sometimes that’s all the other person needs. Depending on your own skill level, ask questions to understand the problem the person is trying to solve. After you understand the problem, offer examples of what has worked before or what factors they might want to consider. It’s common for people who are learning a new skill to think they need one thing when they really need another.

Bring In an Expert

No one expects you to have all the answers. So when you don’t have the answer, don’t hesitate to bring in another knowledgeable person. You’ll solve the problem sooner and model that it’s okay to ask for help.

Listen

One of the most powerful (and underutilized) coaching practices is listening. Being a sounding board as someone talks through a problem or proposed course of action lets the other person hear their own logic. And as people talk they often come up with new ideas or see weakness on their own. Listening also conveys that you are interested in them not just in showing off your expertise.

Coaches look for opportunities to help build skills and capabilities. The more coaching approaches you have available to you, the more opportunities you will see—and use.

This article originally appeared on scrumalliance.org.