The arc of the coaching conversation

As shown in Figure 5.2, the coaching conversation has a beginning, middle, and end—it’s an arc of activity. The arc of the conversation need not be long. In fact, some of the most productive coaching conversations can happen in the span of ten minutes, once you get good at it.

Conversation Beginning

Whether the coach or the coachee opens the conversation, conversation, the beginning is much the same. In the beginning, venting happens. The coachee needs to get something (or many things) off his chest, and he needs to be heard. During venting, the coach practices listening fully and being totally present.

The venting wears itself out (or the coach offers a timebox to finish it up if it seems that it may go on forever). Then, the real reason the coachee has started talking begins to emerge. The coach checks in with the coachee about the topic (“I think this is about feeling ignored by the team. Did I hear that right?”) as they move into conversation centered on the topic. Reinforcing something about agile may be useful at this point. Perhaps recalling a practice, value, or role characteristic will help address the topic. If so, bring it up. You may also help the coachee call to mind a personal goal or action they have previously expressed as it relates to the topic.

Conversation Middle

 You are getting close to the midpoint and getting over the “hump” of the conversation when the coachee starts to climb out of the dead-endedness of the topic. This happens because the coach asks powerful questions that invite introspection. Perhaps the coach has taken the coachee on an imaginary trip into the future where the topic has already been resolved perfectly.

From this place of possibility, the coachee can see his own solutions. He arrives at the midpoint of the conversation with a resounding “It’s not hopeless after all!”

Perhaps he sees new ways to address the topic, perhaps he sees something within himself that holds him back, or perhaps he feels renewed just having shared something deep and bothersome.

Next, the coachee starts looking for specific solutions. Coach and coachee may brainstorm together while the coach encourages and supports the process.

Oftentimes, supporting the process means giving the coachee room to be big, wild, and unbridled in brainstorming possible actions.

This means the coach may also need to get big, wild, and unbridled. Note something the coach purposefully avoids during the conversation: problem solving.

If you do offer solution options, it’s only to keep the coacher’s juices flowing. You couldn’t care less whether the coachee chooses “your” option because you know that for it to be meaningful the action must be freely chosen by him.

Conversation End

You can feel the conversation ending when the coachee starts narrowing down to a few specific actions to take.

Let it close at this time. Even if a new topic arises, don’t pursue it. Let the coachee move forward on what he has already decided to do.

Rest assured, if important enough, the other topic will come back. The two of you can deal with it then.

Once the coachee has chosen the action to take, the coach supports the coachee by setting up an accountability for that action (Whitworth et al. 2007).

The accountability can be either explicit or soft. An explicit accountability is an agreement the coachee makes about when the action will be done and how he will let the coach know. It’s the coachee’s job to move forward with the action, not the coach’s job to “make” him do it, so the coachee should not be pressured into making an explicit accountability. Put all the responsibility where it belongs, squarely in the coachee’s court.

The accountability can also be soft, such as the coach asking, “May I check in with you in five days to see what has happened?” This is often more comfortable in a business context because people aren’t accustomed to being “pinned down.” (That’s quite a commentary on the weak state of personal accountability in the workplace, isn’t it?)

As you repeatedly coach someone, without forcing, move from soft accountabilities to explicit accountabilities. This ratchets up the coachee’s ability to be accountable, an essential agile skill.

The conversation ends with the coach acknowledging the coachee for who he is being. For example, “I want to let you know that, in this moment, I see courage in you that is palpable.” An acknowledgment is not “Thank you for being courageous in the way you are addressing this issue.” The “thank-you,” although polite, raises the coach above the coachee and saps the coachee’s power. A well-delivered acknowledgment, in contrast, honours who the person had to be for you to feel their courage. Receiving such an acknowledgment magnifies the coachee’s power.

Throughout the conversation, the coach and coachee remain on the same peer level. Certainly, the coach has a few skills, such as all the things you are learning in this book, but that doesn’t make the coach superior. For this to work well, the coachee needs to remain the honoured expert on his life.

Being aware of the arc of an agile coaching conversation can help you keep it positive and forward moving. Reading the signs as you move from the beginning to the middle to the end will help the conversation flow smoothly. Remember, though, that the person is more important than the formula.

So, if the coachee needs something different, give them what they need. You can experiment with this, as with all things, to make it your own.

Subject-Matter Expertise and Coaching

 In the pursuit of a thriving agile team, you will coach all kinds of people one-on-one, such as team members, product owners, managers, and other coaches.

All these people may have far more subject-matter expertise in their specific area than you have. That’s OK. In fact, in many cases, it’s a benefit.

You need not be an expert in any of their domains to coach them well, if you stick to coaching and veer away from solving their problem for them.

Certainly, learn about the latest software refactoring technique or peruse the cool trend data for the product’s target market if that interests you, but don’t let that knowledge move you into solution mode.

Instead, offer insights as their agile mentor, and coach them to come up with their own solutions. If you tend to take on other people’s problems as your own, check your actions to ensure you have not unintentionally burdened yourself with responsibility for the coachee’s situation. The problem and the action rest with them. You cannot make the problem go away by solving it for them. Your solution can be only a temporary fix at best, so don’t solve. Instead, coach.

Coaching from a Distance

 Once the coaching relationship has been established, you can take it to the phone or to a videoconference. When you coach at a distance, though, you will not witness the events as they unfold on the team first-hand. You only get vignettes of what’s going on through the retelling of events as various team members convey snippets of conversations coloured by their individual perspectives. To avoid the “he said/she said” trap, focus solely on the coachee and what the coachee wants next in their agile life.

You can still offer your solid mix of coaching and agile mentorship, but the relationship shifts to be more with team members one-on-one rather than coaching the whole team in the moment.

If you miss the moment, you miss the coaching.

Know Your Limits

 Agile itself blurs the line between work and life because, to do agile well, we ask people to bring their whole selves to the endeavour at hand.

We don’t ask people to check their courage at the door. In fact, coaches create an environment that invites people to be courageous. We don’t tell people to shut up and go along because we need the diversity of ideas that come from every voice being heard.

A set of strong value statements in the agile manifesto and a fundamental belief that, given a simple framework, small groups of people can achieve great things together are what form the core of agile.

The manifesto contains four fundamental values:

? Individuals and their interactions over procedures and tools;

? The operation of the software above comprehensive documentation;

? Collaboration with the client above the negotiation and contract;

? The ability to respond to changes above a pre-established plan;

It is not, as it would seem at first glance, a contempt for the traditional elements and tools of software development, but rather the establishment of a value scale, in which flexibility and collaboration are more relevant than process rigidity and planning.

The 12 principles of agile development are as follows: [1]

 1.      Ensure customer satisfaction by delivering functional software quickly and continuously;

2.      Even late changes in project scope are welcome.

3.      Functional software is delivered frequently (weekly or monthly - as short as possible);

4.      Constant cooperation between the people who understand the 'business' and the developers;

5.      Projects arise through motivated individuals, and there must be a relationship of trust.

6.      The best way to get information across developers is through 'face-to-face'

7.      Functional software is the main measure of project progress;

8.      New software features must be delivered constantly. Customers and developers should keep pace until project completion.

9.      Software design should cherish for technical excellence;

10.  Simplicity;

11.  The best architectures, requirements, and designs emerge from self-organizing teams.

12.  At regular intervals, the team reflects on how to become more effective and then refines and adjusts their behaviour

Human relationships are, very simply, the center of the agile manifesto.

Expect that as you coach people well, they will start to open and tell you about their whole selves—their work and their life.

Professional work/life coaches know when they’re out of their depth, and you should, too.

When the coachee brings up a hurtful event or issue in their home life, you may feel ill-equipped to “go there” with them.

If so, don’t. Suggest they find a professional work/life coach. Refer them to the International Coach Federation website (coachfederation.org).

where they can learn about professional coaches and find one. Or, become one yourself.

You may also catch yourself being the “expert opinion” in the conversation—the person who knows what the coachee should do next, how the coachee should go about doing it, and maybe even how the coachee should feel about it.

When you catch yourself doing this, know that you have violated a coaching rule, specifically, the rule that the coachee is an expert on her own life.

Feel free to offer expertise about agile (after all, you are her agile mentor), but stop short of offering her your expert opinion on what’s right for her in her own life. Only she knows that.

If you cross the line, just as in other situations, transparently recognize the gaffe and apologize for it.

Then, get back to territory you can handle, and give yourself a break.

You have just bumped against an important border.

Having found it, you will not cross it lightly again because you know that it is no exaggeration to say that people’s lives are at stake.

Coaching Product Owners

Working with product owners means teaching them their role and then showing them how to work agile to their best advantage.

This is the mentoring part of the agile coach’s job. The coaching part entails helping them make the transition to be a good product owner.

Their journey toward agile may be like yours if they came from a management role where command-and-control behaviour was prized and maybe even essential for climbing the ladder.

Like you, they will need to recover from command-and-control-ism. Like you, they will need to focus on business value delivery rather than micromanaging the next move of every team member. Like you, they will learn to trust the team. You have a lot to help each other through as you both learn to do agile well together.

As you discover new ways to appreciate the joy and power of agile done well, share your discoveries with the product owners in your life to help them see new ways for it to benefit their company and their careers. To be able to coach product owners, you need a common language. That common language comes from the short list of things a team needs a product owner to be: business value driver, vision keeper, daily decision maker, heat shield, and the one ultimately responsible.

Once the product owner understands their role, you can start coaching. This means giving them feedback in the moment when something they’ve just done either undermined the team or supported the team brilliantly.

Just as we tell our teams they are empowered; we coach must also assume we are empowered to give feedback to the product owner. After all, we’re aimed at improving team performance, and the product owner’s work and behaviour heavily influences the team’s performance. Of course, we need to coach them!

The idea of having such open conversations with a product owner and providing direct and sometimes unpleasant feedback may seem like a daunting task, especially if the product owner sits a few organizational rungs above the coach. This can put the coach in an awkward position.

To alleviate the awkwardness, claim the authority and influence that comes with the agile coach role, and use it to start direct conversations with the product owner regardless of the product owner’s organizational position.

As the bulldozer, shepherd, servant leader, and guardian of quality and performance, you must address anything that affects the team’s ability to deliver and continuously improve.

By fully stepping into the agile coach role, your focus on team improvement makes it clear that the coach/product owner conversation is about team health rather than opinion or politics. Such a clarity of role and intention yields positional authority. Use it.

To coach the product owner, first view the product owner as you view any other team member.

All the things you do to coach team members pertain to coaching the product owner, as well. This includes establishing a coaching relationship from the beginning, getting to know where the product owner is on their agile journey, and partnering with the product owner’s manager. It all applies.

Coaching product owners falls into three broad areas: running their business, being a product owner for the team, and getting good at the product owner role. Coaching in some or all these areas will be needed based on the maturity, business expertise, and agile experience of the product owner.

Coaching Product Owners on Running Their Business

 Agile frameworks teach us to harp on business value delivered; we hold business value delivered as the one and only measure of progress and value. We ask product owners to sort the product backlog based on business value and to let nothing, but business value guide their decision making. So, what is business value?

This critical question must be answered deeper than a return on investment (ROI) or profit number. Yes, one (or both) of those measures form part of the equation that makes up business value, but they are joined by other, non-numeric considerations such as risk and knowledge to be gained (Cohn 2006).

While balancing all those aspects of business value and moving toward the complete end vision, which may be months away, product owners need short-term goals to act as stepping-stones toward total business value. Let’s call these stepping-stones business value micro definitions.

They are the goals at the ground level that determine where the product owner points the team, sprint after sprint.

Business Value Micro definitions

In the throes of building a product, the product owner will make many trade-off decisions, several to dozens a day.

On what basis does the product owner make these decisions? They make trade-off decisions according to the business value micro definition, which conveys the next critical business objective.

Perhaps increasing the volume of users on the current product is a must-do to ramp up profit now while the team also performs the work necessary to ready new channel partners.

If so, those two objectives are the current micro definition. Think of it this way: The micro definition expresses the next critical business objective we must achieve on the way to creating the whole product.

Given this clarity, every decision the product owner makes filters through the micro definition: Does [the thing we’re considering] ramp up users or get channel partners ready?

For example, when prioritizing the product backlog, the items that support the micro definition rise to the top of the list. Even decisions such as whether to accept a meeting request get filtered this way: Will this meeting help us ramp up users or get channel partners ready? If not, the meeting should be delayed.

 Require product owners to know the business value micro definition. If necessary, help them discover the value micro definition through coaching.

Using powerful questions and your insights, help them unearth the next micro definition. Once it’s unearthed, help the product owner walk the fine line between achieving short-term and long-term goals for the product.

Help them recognize when they are about to make a short-term trade-off decision that compromises their ability to get what they want in the long term, and vice versa.

You may run into product owners who very plainly do not possess the business acumen to do the job of steering the product (and the team).

When you encounter such a product owner, get help. Just as we cultivate relationships with each team member’s manager, do so with the product owner’s manager and the sponsor (if not one and the same). Rely on these people to plug the holes in the product owner’s business acumen or replace the product owner if the holes are too big to plug.

This can work only if you use the practices of agile to raise impediments and face them squarely.

This can work only if you use the practices of agile to raise impediments and face them squarely. Remember that you don’t have to do the product owner’s job or sugarcoat their shortcomings; you just need to use your impediment-resolving responsibility to get them the help they need.

 references "Addison Wesley"

"Francisco Henrique Manacorda an Agile passionate"