Monday, November 12, 2018

An Example Agile Coaching Conversation

Initiating a Coaching Interaction

Imagine that a manager comes to you and asks:

Manager: “could you teach my team how to use planning poker?”

It may be that there is a perfectly good reason for the team to learn and use planning poker. On the other hand, by following the coaching process, you may learn that the real issue is that the manager thinks the estimates that the team is coming up with are too large. In that case, teaching the team planning poker (when they may already know it) is likely to aggravate the team and leave the original issue unresolved.

Start with Relationship Management

One factor that contributes to the quality of interaction is the rapport you build with those you are coaching. In any interaction, make a conscious effort to contribute to that relationship. It can be as simple as doing a quick check-in and/or engaging in small-talk. When somebody approaches you with a coaching request, it can be tempting to dive right in. Not only does pausing to build rapport contribute to the relationship, it also gives both of you a chance to pause, become present, and focus on the coaching conversation. You may even discover some useful context for the problem at hand. Let’s see how the conversation that started with a request to teach a team planning poker might play out:

Coach: “I’ll have to check my schedule. How have things been going?”

Manager: “Things are pretty good in general, but this team has really been a problem. They are consistently behind and I’m starting to lose sleep over it. Anyway, I need to go, can you take it from here?”

Issue Identification

In the example, the coachee is trying to end the conversation before you have had a chance to do any coaching at all. Your goal is to get a coaching conversation started. A good tool here is to use a coaching question.

Coach: “I’d be happy to teach them planning poker, but I feel like I’m missing some context. Can we back up a moment? What precipitated this?

The question “what precipitated this” has started a coaching conversation. While the coachee has presented you with what may actually be the problem and tried to delegate to you what may be the solution, it is better to go through a process of identifying the issue, even if you end up in the same place you started.

From the conversation so far, you have surfaced that the team is “consistently behind,” that the manager is “starting to lose sleep over it” and that he would like you to teach the team planning poker. Planning poker may or may not be connected to his statement that the team is consistently behind, but losing sleep indicates that it is very important to the manager that something changes to make things better.

Manager: “well, I don’t think they are doing planning poker right because their estimates always seem to come out too high and then they don’t get the work done in time.”
From this answer, it seems that the manager may not understand the purpose of planning poker or may not understand the use of story points (or both). Let’s try another coaching question.

Coach: “I hear you saying that this team doesn’t get their work done in time. How would you summarize the high level problem here?”

Manager: “actually, there’s a lot on my mind. The real problem here is that as a company we seem to have lost the ability to make our customers happy. I guess I was just thinking that the deadline issue was low-hanging fruit.”

Aha! Now we are getting somewhere.

Goal Setting

Once the coachee has identified the issue that they would like to work on, the next step is to turn the issue into a goal. In some cases, the difference may only be semantics, but reframing an issue into a goal can shift the perspective from dealing with an energy sapping problem to investing in achieving an exciting goal.

Coach: “How could you reframe the issue ‘we’ve lost the ability to make our customers happy’ into a goal?”

Manager: [after thinking for a moment] “I think the Product Manager is also frustrated, but I don’t think they realize how good this team has been at partnering with product to better understand customer needs and come up with novel features that delight customers. They are just focused on getting what they want by a certain date. I think a good goal would be to help the Product Manager better understand what this team can do.”

We’ve come a long way from the manager’s initial request. And if we had stepped in with suggestions right away or made assumptions about what the problem was, we might not have ever gotten to this point. Of course, not all coaching conversations will end up with the coachee solving their own problem, but if we don’t try, we’ll never know. And regardless of where we end up, by following a process that includes coaching questions and active observation, we will surface lots of useful information that will come in handy if we need to move to another mode such as teaching or mentoring.

Uncovering Options

At this point, we could step away knowing that we’ve already provided a lot of value to the manager, but we’re not done yet. The next step is to uncover options for achieving the goal.

Coach: “what options do you see for achieving your goal?”

Manager: “I could go and talk to the product manager directly, but I don’t think he sees me as business minded. I could mention my idea to the product owner, I think they worked together at another company. I could also suggest that he talk to a customer that was on the verge of abandoning us until this team partnered with them to come up with some really awesome new features that then also led to a whole new market. Now that I’ve laid it out this way, I think the best bet is to talk to the product owner about setting up a meeting between that customer and the product manager. Thanks! This was really helpful."

This is actually just a fragment of a full Agile Coaching conversation. I've kept it short to fit into the format of a blog post. I'll post more on the full arc of an Agile Coaching conversation in future posts. 

Coaching Questions

Coaching Questions are open-ended and non-leading. They should be appropriate to the stage of the coaching process you are in. Here are some that I have found useful.


  • What are you thinking about?
  • What’s on your mind?

Information Gathering

  • Let’s step back for a moment. What precipitated this?
  • What’s the background on this?
  • How would you summarize the issue?
  • What makes this something that needs to be addressed?
  • How does this fit into the big picture?
  • Why is this top of mind for you right now?


  • Tell me more.
  • And?
  • What else?

Identifying Potential Outcomes

  • What will success look like?
  • What would failure look like?
  • And what would you like to have happen?

Exploring and Discovering Options

  • What options do you see?
  • What paths do you see to achieving your goals?
  • Who or what else could you leverage here?
  • What’s the [ bravest / craziest / least likely to work /most fun / most surprising] approach to try here?
  • If you have a hero that you think would be relevant in this situation, what would they do?
  • What could you apply here from similar situations in the past?
  • What would you do if you had a magic wand?

Focusing, Narrowing, and Planning

  • What’s your recap of the options we’ve discussed?
  • How do the various options we’ve discussed stack up?
  • Out of the various options we’ve discussed, what are you leaning towards?
  • Tell me your next step and when you will take it
One way to get used to using open and non-leading questions is to try “question of the day.” Pick one or two of the coaching questions above, or a question that you have used in the past that is open and non-leading. Try it in conversation throughout the day as appropriate. Try a different question every day. After a while, the questions will become a natural part of your coaching conversations.

A quick activity to get your mind started down this path is to play the coaching question game. Here are four potential questions. Guess which are coaching questions and which are leading, closed, or both. Answers follow directly after.


  1. What’s the background on this?
  2. Do you think they need to have more focus?
  3. What’s the best way for me to take this off your hands?
  4. What makes this something that needs to be addressed?


  1. What’s the background on this?
    Good question
  2. Do you think they need to have more focus?
    Closed: has a yes/no answer. Leading: assumes a need for more focus. 
  3. What’s the best way for me to take this off your hands?
    Leading: assumes the issue should be delegated.  
  4. What makes this something that needs to be addressed?
    Good question

Friday, October 26, 2018

What Does an Agile Coach Do All Day Part 2

In my experience, there is no end of things for an Agile Coach to do. At times, the needs and requests will just pour in. And at other times, you’ll need to be more proactive. Let’s talk about what to do when things are slow. It may be that you are new to a team and they aren’t sure what to make of you yet, so they aren’t bringing you any requests. Or it may be that it seems like everything is humming along just fine. There’s no single way to discover the work that needs doing. Everybody has or will develop their own techniques. That said, there are only so many ways to discover the work. Here is a list of ideas to try. And remember, you don’t need to do this on your own. Consider finding co-conspirators that can help you look for potential problems and opportunities.

  • Go to a standup or any other ceremony and try to use “new eyes.” That is, ignore the exact stories or issues being discussed. Look for boredom, agitation, rote patterns. Pretend you are attending the meeting for the first time.
  • Schedule short 1-1s with folks to see what is on their minds. Don’t force the conversation, just see where it leads. Think of it as an informal session. Talk over coffee, perhaps at the local coffee shop.
  • Spend some time with people outside of the team. What are customers saying? What about support, sales, marketing, or folks on other teams? Bring anything you find back to the team and get their thoughts. 
  • Put together a special workshop for a team as a whole. Think of some interesting or unusual activities that will get people thinking out of the box. 
  • Organize an open space event
  • Think of a topic that may get people excited and put together a lunch and learn or book club. You don’t have to be the speaker. Perhaps there is somebody in the company that you could invite, or perhaps somebody from another company. Get people thinking in new directions. Hopefully, it will spark comments like “perhaps we could do something like that!”
  • Spend some time going to meetups, reading blogs, or joining an Agile Coaching Circle
  • Offer office hours 
  • Create some mechanism for people to send you requests. For instance, set up a Trello board that people can add requests to at any time.  
  • When you see somebody in need, offer to help. As a coach, you should be focused on helping people get to the point where they don’t need your Agile skills. But you may find opportunities to mentor people. For instance, if a Product Owner is feeling swamped and you offer to help write some stories, that may give you the opening you were looking for to introduce them to some new story splitting techniques. 
  • Assess where your teams are on their Agile Journey. Doing it with them is the most effective approach. But if they are too busy or uninterested, you can always do it on your own as you look for new paths to take.
Do you have other ideas? Please share in the comments!

Wednesday, October 17, 2018

What Does an Agile Coach Do All Day? Part 1

Understanding active listening, emotional intelligence, facilitation and a host of other coaching skills is great, but what does an Agile Coach actually do on a day to day basis? How do they create value? One can imagine a coach wandering around, making observations, dropping pearls of wisdom here and there, and being approached for advice. Or perhaps they are like a lucky charm; just great to have around, imparting greater levels of Agility through proximity.

Part of the difficulty of being an Agile Coach is that you are only successful when others are successful. You work is "indirect." Compounding this is the fact that if everybody were already experienced Agilists, you wouldn’t need to explain the value of Agile or how to become Agile. Agile is very different from traditional ways of working. As a result, it can easily end up in people’s “blindspot.” That is, when you explain parts of Agile, they can sound like exactly the wrong thing to do. For example, phrases like “consider working on fewer projects at the same time” and “produce new end-to-end functionality from scratch every two weeks” make many people shake their heads, even in supposedly Agile environments.

As a result, there are many different views of what “Agile” really is. When you show up at a client or a new team, it is likely that the true value that you can provide is not fully understood and that people will have certain pre-conceived notions of who you are, what you believe in, and how you will provide value to the organization, teams, and individuals. To counteract these difficulties, one thing you can do is create and publicize a catalog of service offerings. This gives people a tangible list of things that you can do for them that they may not have even thought of asking for.

Here is my catalog. It is in word format and I invite you to use any and all of the text that will help you create your own service offering catalog.

This idea came from Gillian Lee as she was looking to provide new ways to make Agile Coaching even more approachable and self-serve for her teams.

In Part 2 of this series I discuss ways to discover the potential needs of your teams.

Agile Games!

Over the past couple of years, and even more so lately, Gillian and I have been creating lots of Agile games, including user story games and games that teach Agile Coaching. You can download the full trove here.

Upcoming Events

I've got a number of events coming up! Tonight I'll be at the Kendal Square Agilists doing a talk/large game on "Scaling Agile Organically." You can learn more and register at their meetup page.

This Thursday, and every Thursday, I'll be doing an Agile Coaching webinar. Sign up for this week's webinar here.

And if you are interested in getting your ICAgile Agile Coaching certification (ICP-ACC), I've got three opportunities coming up in Boston and Dallas. Dates and details are on my eventbrite page. Use coupon code ICPACC1 to get $300 off!

Hope to meet you in person soon. What can we learn from each other?

Friday, October 12, 2018

Switching Focus to Agile Coaching

After a long hiatus on this blog, I'll be switching the focus from DIY to Agile Coaching. That said, the essence of providing information for the Agile DIY'er will remain, it is just a change of focus. So, what do I mean by "Agile Coaching?" Topics related to coaching within an Agile environment. Topics like powerful questions, presence, listening, and remaining neutral. These are all things that come from coaching and are independent of any particular domain area. But as an Agilist, you are often working to catalyze change which requires good coaching skills. So, I'll be talking about coaching, but within an Agile context.

One awesome thing about the Agile community is that we have so many tools that are great coaching tools. For instance, part of coaching is identifying what the issue is that needs coaching. Powerful questions are great for that. And what are speedboat and open space if not powerful non-leading open-ended questions? So I'll be talking about great tools like that within a coaching context. Let me know what topics you'd like me to cover and ask me whatever you'd like. I look forward to your participation!

Saturday, March 24, 2018

The Best Product Owners Write Small Valuable User Stories

Are you a product owner, or aspiring to be one? Is your organization struggling with producing user stories that can be implemented start to finish in a few days or less that real users will recognize as valuable and say "thank you" for? Too often, the "user stories" that get implemented in a short period of time are really tasks. In extreme cases, providing end user consumable value takes multiple sprints.

On April 4th, Nexxle and Banner Solutions are partnering to bring you a webinar that will introduce you to a number of story writing and story splitting techniques that can help you and your organization create small valuable stories. We'll do a quick refresher on INVEST using examples of stories that meet or don't meet the INVEST criteria and then cover story splitting techniques including split by test scenario, split by generated list, cake slicing, and many more

Register now for our April 4th webinar.

Sunday, March 11, 2012

11 Self-organizing Teams Teaching Themselves Agile at the Same Time

In a previous post I talked about how I came to learn that I could teach Agile to lots of people at the same time. In writing that post I realized that it was a great illustration of self-organization. That realization was in the forefront of my mind as I ran the session "Hands On Agile Immersion" on March 10th at Agile and Beyond 2012 .

Although I've trained large groups of people on Agile many times over the last few years, it never occurred to me to create a video of the experience. This time, I decided to do it to illustrate large-scale self-organization in action. There were eleven separate teams with no appointed leader.

All I did was set up the learning environment, provide the materials, and give just a few instructions for each activity. The participants did all of the learning/teaching as a self-organized team on their own.

In the span of only an hour and a half, all 11 teams taught themselves the basics of 9 Agile practices as follows:

  • Form cross functional, collocated teams
  • Pick a software product to "build"
  • Write 12 User Stories for that product
  • Put the stories into a backlog ordered by business value with the help of a Product Owner
  • Estimate the stories in story points using Planning Poker
  • Plan a release using 2 iterations worth of stories
  • Do all of the above as independent self-organized teams

The teams did self-organization so well, I was able to do capture lots of video clips of the session and only had to answer 4 or 5 questions about the mechanics during the whole 90 minutes of the session.

As always, one of the favorite things that people learned was "Planning Poker," an Agile estimation technique involving special playing cards. I told people I didn't need them back and I also gave away all of my extras. I brought 48 decks and they were all gone at the end of the session. Not even a single card was left behind!

A short video (4:10) of the session is available on YouTube .

Some folks from Macomb Community College made their own video (3:58). The "Hands on Agile Immersion" part goes from 1:25 until the end.

Friday, March 02, 2012

Agile is a Game

While attending a presentation at Agile New England last night on “Gamestorming” by Todd Lombardo I was reminded that Agile is a game. That may seem a bit uncomfortable for something that is done as a professional activity, but it is actually a very good thing from a business perspective. After all, what is a game? A game is an activity that is governed by a set of rules, has a goal, has a scorekeeping system, and is fun to do.

The Rules of the Game
Nobody really likes rules, but what is the first thing you ask when you are about to play a new game? You ask “what are the rules?” You want to make sure you understand all of the rules and that people are “playing fair.” When these two conditions are met it is a lot easier to learn how to get good at the game and have fun.

The rules in Agile are deceptively simple. They are things like "iterations should be no more than 4 weeks" and "all iterations should be shippable." Following the rules mostly involves unlearning years of what you will later realize were bad habits.

The best part of the rules in Agile is that they are so clear. Don't ask me what the rules are in traditional development. I have no idea and I played that game professionally for more than twenty years!

Winning the Game
The next question you ask when learning a game is “how do I win?” This is the goal of the game. It is important to know what the goal is so that you can work within the rules to achieve the goal.
In all of this, it is important to know how to keep score because it is usually how you know how close you are to your goal.

There are aspects of software development that make it difficult to know the actual score, which is the amount of value produced. Value is a lagging indicator which you don’t really know until after somebody has used what you have provided and given you back something in return. Most of the ways of “keeping score” within Agile, such as burn up and velocity, are really only a proxy for the real score (value produced), but they are still important to know and monitor.

The Fun of Playing
You may wonder what “fun” has to do with a professional activity. Well, I don’t know about you but if I have my choice between working in a “fun” environment or a not-fun environment, I’ll pick the fun environment every time. Another way to look at fun is “doing something that is satisfying.” I believe that most people want to gain satisfaction from their work and that usually comes from feeling that you have provided something of value that benefits others in some way. In my experience, high job satisfaction corresponds directly to personal productivity.

The game of Agile development is simple to learn and to play, at least in comparison to traditional development. As a result, it is much easier to reach the goal and provide a high degree of job satisfaction. In my book, that’s a win-win.

Cooperative Play vs Competitive Play
One last point on this subject is that Agile development is both a team game and a competitive game. It is a team game within your organization and it is a competitive game that your organization plays in the marketplace. Now, get out there and win, win, win!

Learn the rules of the game: Boston, March 20th, Agile Whole Team Training .