The Teddy Bear and the Shark

I’ve noticed that how I discuss Agile concepts varies depending on my audience. When I coach teams, I tend to focus on what I’ll call Teddy Bear Agile: wonderful things like trust, teamwork, empowerment, communication, sustainability, humans over the machine, etc.  But when I talk to “the business”–product managers, account managers, executives–, I focus on Shark Agile: competitive advantage, getting ahead, ruthless prioritization, doing just enough to get the job done well, etc.  I truly believe it is both, but I am starting to think there is something wrong about the way I am talking about it.

My stance starts with belief in the Teddy Bear: people shouldn’t be miserable at work, and we as a world can and should commit to people being treated well.  I also believe that the Shark benefits are partly the result of following the Teddy Bear values (think self-determination theory).  I think the mistake I’ve been making lies in failing to acknowledge that this causality is only partial.  You don’t magically get all competitive benefits just by being a fun place to work; you must intentionally strive to be both the Teddy Bear and the Shark.

For example, if I only talk about the Teddy Bear with the team, then there is a risk that we forget that the company’s existence is contingent on successful competition by its products.  We could end up looking down on any talk of profits and competition as mercenary, and we might indulge human tendencies like perfectionism that drive us toward scope creep.  On the other hand, if I tell management that they get Shark benefits as a result of the team living in a Teddy Bear world, I risk pushing management toward a laissez faire attitude: They live in fear of the team, tentatively asking them for work and just hoping that it happens.

When things are good, you can afford to be imbalanced, ignoring the Shark, even if that’s wasteful.  Everyone is happy because of the Teddy Bear, and there is enough money rolling in to allow the Shark to be a little slow.  But when times get tough, you need to get the Shark into shape to ensure that the organization is lean and competitive enough to survive. Worse, if you’ve been leaning too far toward the Teddy Bear, when you hit the rough patch, people might say, “See, Agile doesn’t work”, when in fact you’ve been only half following Agile values/principles all along.  Management might suddenly go Full Shark and dump the Teddy Bear, resulting in an even less sustainable imbalance.

Because of the traditional dominance of the Shark-over-Teddy-Bear model, I believe there is often an over-correction. Running so fast away from the Shark, you can fall into the imbalance I have.  So: be the Teddy Bear and be the Shark.  Find your balance.  Here are some guidelines I plan to follow in an attempt to restore my particular imbalance:

  • Coach teams to keep the Teddy Bear, but add the Shark.  Don’t be afraid to remind them that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  Keep that focus razor-sharp.
  • Coach management to explain why we are doing work and to steer clear of constrictive laundry lists.  This keeps team focus clear while allowing them the latitude to find the leanest alternative.
  • Drive for simplicity.  Stories and acceptance criteria tend to specify the minimum, but little keeps teams from flying right past that.  Don’t cut corners recklessly, but when things are good enough call them done and move on immediately.  Building this habit requires partnered discipline by people building products (“I’ve reached the goal, no need to build that extra little shiny thing”) and customer proxies like Product Owners, who can help by accepting work the instant a goal is reached and moving to the next focus without expending any additional time.
  • Above all: do not pander to audiences by focusing only on the face of Agile that is most attractive to them.

Have you found yourself similarly skewed in your focus?  Has your organization leaned too far one way or the other?  Can you look around you and point out people who are clearly Sharks or Teddy Bears, but not a happy balance of both?  I’d love to hear any approaches you’ve tried to fixing it.

Advertisements

Foster Agile: Not Gonna Happen, Pt. 2

Part of the Foster Agile series.

In the original Not Gonna Happen post, I wrote about how my step-father says “not gonna happen” when I set some unreasonable goal for our work renovating my house.  The post focused on how his statement of hard limitations forced us to adopt realistic goals and why having realistic goals is valuable.  I just had a conversation with some Scrum Masters, though, and I realize there is another value of “not gonna happen” that the original post skated right past.  Long before we get into the benefit of realistic and well-crafted goals, we get the benefit of facing the truth.

Many if not most folks have at least some interest in working with others collaboratively.  We want to find solutions that make us all happy.  We want to help each other out.  So when someone comes at us with an unrealistic request, it is very, very hard for us to bluntly say, “not gonna happen”.  Not only are we afraid of them killing the messenger, but being that blunt feels…uncollaborative.  In fact, I wouldn’t be surprised if saying things that bluntly, even if dressed in slightly more corporate-friendly words, would result in the other person saying, “C’mon.  Why can’t you be reasonable?”

The truth is, steadfast adherence to one’s professional opinion of the impossibility of a given scope/time combination–i.e., sticking to “not gonna happen”–, is about as reasonable as you can be.  The trick is marrying that resolution to the truth with an attitude of cooperative invention, seeking and suggesting alternatives that could possibly work.  But that is one strange marriage: “not gonna happen” just doesn’t seem like it goes with the optimism of “here are a bunch of other options”.  If you let your desire to make things work out influence your sense of truth, “not gonna happen” turns into “won’t likely happen”, and then into “maybe it’s possible after all”.  Now the marriage is a mess, with neither partner true to itself: the truth of limitations is watered down, and the alternative plan probably hasn’t gone far enough to really address those limitations.

I now see the great challenge of keeping the marriage going in my head, between the hard “not gonna happen” and the soft “but, hey, partner, let’s work out some way that will happen”.  I recognize that I have often confused compromise with collaboration, trying in vain to compromise with the hard truth of limitations.  I’ll keep collaborating with others to find possible solutions.  However, going forward, when I really believe that something is simply impossible, regardless of the pressure put on me, I will try to say–and keep saying–, “Not gonna happen.”

Foster Agile: Not Gonna Happen

Part of the Foster Agile series.

A typical scenario: I have planned too much work for a work weekend with my step-dad.  The evening of the first day, we are discussing what we will do the second day.

Step-Dad: What’s the plan for tomorrow?
Me: I’m thinking we finish pouring the concrete, set the stones, finish the other stones in the sand, and then get the screenings in.
Step-Dad: Not gonna happen.
Me: You think getting the screenings in is ambitious?
Step-Dad: I think getting just the concrete poured and the stones set in that is ambitious.

Invariably, my step-dad is right. We get what he expected done, and barely that. I could chalk this up to his great experience, but there’s another element here: the courage to recognize the hard truth of limitations. It is this experience which has underscored for me the lean principle recognizing the waste of wishful thinking. With our newly revised plan, we plod along, a clear and achievable (not necessarily easy!) goal in our sights.

What’s the big deal? Can’t you just take on more and stop when you run out of time? Yes, but you lose all sorts of advantages.

The Finish Line Surge. If I am on step 98 out of 100 with a tiny bit of time left, I am more likely to push to make the deadline than if I am on step 98 out of 150.

Quality of Goals. When you are honest with yourself about what you can achieve in a day, you usually come face-to-face with the reality that you won’t get as much done as you hoped. This gives you a sense of just how precious the time is. Acute awareness of the goal’s cost in turn increases the pressure to make that goal really count: high-value, high-priority. If you aren’t setting realistic goals, all you are really doing is making a wish list, and what’s the point of that?

Every Minute Counts. Imagine you are working on a task. You have two ways to do it. Both ways are good quality, both meet the minimum requirements, both achieve the overall purpose set out. One of them, though, is the “gilding the lily” option: a little fancier design, a little more extensible than needed, a little cooler than necessary. If you are on step 98 out of 100, right before the end of the day, and if doing the extra work means you fall a little bit short, the cost of your decision is very hard to miss. If instead you are on step 98 of 352, it is much easier to spend the extra time on the more expensive option without realizing the impact this will have on your overall goal. In effect, you are revising your goal unconsciously. One caveat: as you walk the line of just good enough, trying not to step into the realm of gilding the lily, make sure you don’t overcompensate and fall into the trap of cutting corners on the other side. Mind those quality standards!

Greater Productivity. I am going to stray into heavy speculation with this one: I’d suggest that you actually work faster if you take on less. When I was in college, I did a work study job in a law library. My job involved two tasks: (1) helping the very few people who came to the desk for help, and (2) filing updates to laws. The amount of the latter task varied. I noticed that on days where there was more than I could possibly do in my six-hour shift, I dragged through, getting almost nothing done. However, on days where there was the right amount or even slightly too much, I flew through it with relish. Was it the promise of getting a little free time if I finished the work earlier? Was it the pleasure I (and I suspect many others) derive from finishing tasks? Either way: a reasonable load of work led to much greater productivity than an impossible load. Maybe this is true for others, too.

Sustainability. This also ties into the sustainable pace aspect of Agile. If you cultivate and listen to the voice in your head saying “not gonna happen”, you avoid setting yourself or your team up to fail.  It’s great to set ambitious goals to push yourself (think stretch goals, OKRs, etc.), but if they are flat out impossible, it’s counterproductive.

Try this: set yourself a goal for the day. At the end of the day, ask yourself if you met the goal.  If you met it, great; if not, ask what made you fall short. Try again the next day. Once you are regularly accomplishing your daily goals, ask yourself what you are doing differently in order to meet them. Then, keep setting daily goals, but set goals for the week as well. Repeat the same pattern at this larger scale.  What does learning to meet these make you change?

One note. As you can guess, I apply this thinking to the goals one sets in Scrum: commitment at daily stand-up and sprint goals. I’ve often heard people complain that Scrum’s sprint deadlines are arbitrary. Well, they are. And that’s a good thing. With every action, you are not only choosing to do one thing but choosing not to do myriad other things. By ignoring these opportunity costs, you are ignoring the full cost of your actions.  Are you rich enough in dollars to walk into a store and buy something without even looking at the price tag? Are you rich enough in time to take action without knowing how much it’s costing you?

It’s Not About Me

Some time ago, I met with each of the folks on a new team to get to know them, and I found myself in a dangerous  trap. Going in, I want very badly to make a good impression. I prepared for these meetings by trying to focus on my goal in having the meeting in the first place, trying to put to use some of the positioning and permissioning ideas I learned from a Esther Derby Q&A (thanks, Esther!) I would try to remember that it is about the person I was meeting with, not me.  But still a little voice would creep in: “Psst! How is the coaching going?” The next thing I know I’m engaged in full-blown internal dialogue:

Me: I think I’m doing okay…she really seems to be opening up.

Also Me: I don’t know. I think I might be leading her a bit with my questions.

Me: True, but she really seemed to stall there. You had to help her get back into the flow.

Also Me: I guess, but why didn’t you even try to just sit silently? Mightn’t she have gotten there on her own?

Me: Whoops! I don’t remember anything she said for the last 27 seconds.

Unfortunately, truly focusing your attention on a point outside of yourself for sustained period of time is extremely difficult.  As soon as you define what you don’t want to think about, you are thinking about it.  Here, the thing you are trying not to think about is yourself, or seemingly relevant things like, “am I doing a good job listening?”  The latter is an especially insidious trap if you make regular practice of the normally useful habit of self-reflection.

I’ve seen parallels to this in other areas.  One is meditation.  I know virtually nothing about meditation, but the very little I have done has shown me what a beast of a struggle it is to keep your focus on something as simple as counting your own breaths for even a few seconds.  More importantly, I have found that even minor successes only show me how much fuller my attention could be, how distracted I still am.

The other comes from acting.  I trained in a Meisner-based program, where you spend lots of time on exercises aimed at keeping your attention on your acting partner.  It’s excruciatingly hard.  The second you achieve something close to true attention trained on the other person, pride rushes in to pat you on the back and your focus crumbles away.

While listening is an especially important challenge for coaches to meet, everyone can benefit from improving here.  If I have any conclusions, I suppose they are these.  First, if you are worried about how your coaching/managing/etc. is going while you are meeting with someone, you are almost certainly going to do a poor job.  Second, if you think you are regularly achieving pure focus in your discussions, try meditating (or even just sitting quietly for 15 minutes looking out a window with no agenda) before your next 1:1.  If you find that you brought your focus deeper, it might mean that your original focus wasn’t as deep as you thought.  Third, it might be useful to adopt a phrase you use to remind yourself of this at the top of 1:1 meetings, for example, “it’s all about the other person” or the like.

The Perils of a Notebook

When I started as an Agile Coach, I bought a notebook, zipped my mouth shut, and brought it with me to every team meeting, jotting down observations of what I saw.  Some of my earlier posts talk about some ups and downs of doing so.  More recently, I’ve stopped bringing the notebook if I can avoid it.  There are two main reasons.

The first is that people get weirded out when you are standing there writing notes while you watch them.  The patient’s reaction to the therapist jotting a note is a comic cliche that you risk living out with each scribble.  You can temper this by talking to the team about what you are writing down, but that only helps so much.

The second, a more recent observation, is that writing even the slightest note really jars me out of connection with the team.  The writing may take only a second, but composing the thought and then running to jump back on the train with everyone else takes much longer.  For daily scrum, especially, I have come to trust that if something is important enough to jot down, I will remember it when I get back to my desk when stand-up ends.  I stumbled upon this by observing the first concern (left my notebook behind to avoid freaking out a team).  The feeling of connection was stronger and required so little effort.

So use that notebook carefully, I say!

Definition of an Impediment…Revisited

A while back, I wrote a post while I was–well, if you read the post, you’ll see I was freaking out about what it means to be someone who removes impediments for a team.  I’ve since calmed down, and I wanted to share conclusions I’d reached through my daily observations and practice.

I knew I was responsible for “removing impediments to the Development Team’s progress“, but I worried about undermining the team’s self-sufficiency if I simply removed all impediments.  I therefore thought that I needed a definition of what truly constituted an impediment justifying my removal services.

The problem is that I had mistakenly thought of “removal” as meaning only “intervening on behalf of the team”. Since such intervention could indeed rob the team of a chance to solve their own problem, I concluded I had to pick and choose.  Since then, I’ve changed my view of “removal to mean “helping the team navigate the impediment”.  By doing so, I’ve freed myself to help every time while simultaneously supporting team autonomy.

Sometimes, helping does mean full-on intervention, where I act as wrecking ball change agent to clear a truly external impediment.  More often, though, I strive to help the team get past the impediment in a way that makes them able to do so without my help the next time.

In trying to follow this guideline, I have found it important to discern the precise nature of the impediment.  For example:

  • “I have an idea for an activity I think would help in backlog grooming, but I don’t know who is supposed to enact those.”  I could just say “Feel free to bring it up”, but if I can help the person understand that they should always feel free to bring up their ideas, that gets closer to the true impediment here, which relates to thinking they need to await permission.
  • There’s no point in escalating the problem with the server: the problem has been around forever.”  There are two impediments here: failure of organization to respond to team needs (external) and learned helplessness (internal).  If I just run off and fix the problem, I may have addressed the former, but I’ve done little toward the latter.
  • “It’s Jack’s job to update the wiki page, and he’s out.”  I could ask, “Is there any reason that you can’t update the wiki page?”  That might get the person past the immediate impediment.  But the greater impediment here is the adherence to over-strict role definitions.  Might it be better if I asked “Why is that just Jack’s job?”

My new conclusion (until it evolves again!): Always help remove impediments.  Just be careful about how you do so.

Poking Holes in Done-Done

A while ago, Sam Laing wrote a post as an exercise in questioning one’s own beliefs.  I liked the idea.  It reminded me of Feynman’s statement that part of the obligation of scientists is “bending over backwards to show how you’re maybe wrong”.  If we don’t regularly question base assumptions, we run great risks.  Today, someone I consider very credible suggested that an idea I value (the importance of getting work “done-done”) is conceptually broken.  Seems like high time for me to do some questioning of my assumptions!!

As far as I understand, “done-done” means that a work item (e.g., a story) is truly done, with all loose ends wrapped up.  In my experience, when you don’t clean those things up, you start to accumulate baggage.  And those loose ends, for some reason, seem really easy to forget.  I do it all the time: I don’t figure in time to clean up my tools and workshop after doing some work, and the next weekend starts with me tripping over the mess, looking everywhere for tools I didn’t put away, etc.  Similarly I see teams call stories done, but with little bits at the end unfinished.  Those bits either trip them up in the very next sprint, or accumulate and get even uglier.  Essentially, I believe following done-done is about honoring the lean principle of limiting work in progress.  Or, per Van Halen: “C’mon, baby, finish what ya started.”

Now that I’ve lost all credibility by quoting Van Halen (post-Roth Van Halen to boot), what might be wrong about “done-done” by this definition?  (Remember, I believe in done-done, so my arguments are likely weak.  I truly welcome any comments adding new arguments or strengthening existing ones.  I want to understand this!)

Argument 1: My definition of done-done is simply not what folks mean by this.

Counter 1: I have no counter argument!  Please steer me right!  [UPDATE: Since I initially wrote this post, I have learned that I do indeed have the definition wrong.  “Done-done” is apparently defined as “done coding and done testing”.  In my circles, it’s simply been used as a colloquial way of saying “really for reals done”.  Some people talk about “done-done-done” and even “done-done-done-done”.  I agree that these other variations seem problematic in segmenting the work, maybe even taking a checklist approach (for dangers of that, see argument 4 below).  So, this means this post was a wild goose chase.  But I learned what folks actually mean by “done-done”.  Also, writing this post helped me see a bunch of dangers surrounding focusing on even my definition of “really done”.  So, big day of learning!]


Argument 2: The concept of finality inherent in “done-done” runs counter to the idea of products as continually evolving entities.  Even by suggesting that bits of the work are done, we are suggesting that once we finish it we need never come back.

Counter 2: I see some validity to this.  If in coaching a team I put great emphasis on done-done, I might inadvertently suggest that we never need to come back.  I think that I can balance this by avoiding undue emphasis and by communicating the idea that we are done with the identified work for now.  Also, I think that the team can handle switching conceptually between the idea of a small piece of something being done for now vs. the idea of the overall product continuing to grow and evolve.  I also think that getting to done-done is one of the easier habits to build.  As a result, one probably doesn’t need to harp on it to a harmful extent.


Argument 3: Saying something is done calls into question what “done” means, which brings up Definition of Done, which some consider a bad idea.  The nuances of this idea come out in the interesting discussion between commenters and the author (Alistair Cockburn).

Counter 3: If you use it properly, I think you can avoid all the problems here.  To me, “properly” means: “distance between what really got done and potentially shippable…is zero” (Cockburn); you don’t let the useful shorthand turn into a substitute for meaningful interactions between team members, stakeholders, customers; teams use it to define quality standards for themselves; and teams use it to keep themselves from gold-plating.


Argument 4: Focusing on wrapping up loose ends pushes teams to think of completing laundry lists, as opposed to achieving holistic goals.  This is a strong argument, in my book.  Instead of looking at the problem a user story solves for a user, you get lost in checking off a bunch of acceptance criteria boxes.  As this fun, surprising, and easily replicated exercise highlights, focusing on laundry lists gets you into trouble quickly (e.g., you do the parts, but don’t actually achieve the whole).  If you tell people to get things done down to the last detail, you might inadvertently push them into focusing on those details instead of the overall goal.  This is indeed a major concern.

Counter 4: You can avoid this problem by building a disciplined balance between keeping an eye on the overall goal and ensuring you wrap up what’s critical before moving on.  I talk to my teams about working to switch between the eagle’s view and the ant’s view to avoid the trap of seeing from only one.


Argument 5: Following on from Counter 4 (above): Once you have met the goal, you are done.  What I am calling “loose ends” are not important.

Counter 5: I just can’t believe this makes sense.  I mean, it’s in the details, and to sort out those details, we should have meaningful face-to-face conversations, but if you just race to meeting a goal by the narrowest definition and move on, it seems you are inviting trouble.  Yes, simplicity is essential, but we are always doing some level of work beyond the barest minimum interpretation of a goal, and skipping those will almost always hurt, in my eyes.


Argument 6: “Done-done” is a bumper sticker that misses all the nuance mentioned in the counterarguments above, and therefore lends itself to misunderstanding.  I have no counter for this.  It’s the best argument I see.  Even if no one shows up to tell me of some other argument I’ve missed, going through this exercise has taught me to be careful about slinging “done-done” around like I did in a tweet this morning.  Thanks to the fellow who questioned what I typed without thinking about it!

Ideal is Closer Than You Think

A few weeks ago, I went to agile NYC‘s Agile Day 2014.  During the Open Space, I suggested a session titled “Sounds great in an ideal world, but…”

When the group convened, I started by noting the great number of times recently where a discussion of Agile ideas was followed by someone saying, “That sounds great in an ideal world, but it would never work for my company/department/team.”  I asked if anyone had thoughts on why that answer was so pervasive, or how one might respond to such statements.

Early on, someone asked how I defined an ideal place.  So, I wrote “the ideal place” in the center of a piece of paper and facilitated the group’s mind mapping of what that was.  When the ideas started to peter out, I asked a question: “How many people feel that their current workplace is not this ideal place?”  Almost everyone raised their hands. I looked at a guy with his hand down, thinking my wording had just been confusing, and asked, “Wait, so you are saying your workplace is ideal?”  His response was so awesome:

“Well, no, but we’re always working to make it better.  I mean, I don’t think you ever get to the ideal place.  But if you are working toward it, that’s the best you can do.”

I’ll be honest: I started the session with soapboxy intentions.  People talk about the ideal workplace like it exists out there, and as though their own problems would go away if they were hired there.  My brilliant plan was to say to people: if you don’t think your world is ideal, it is up to you to make it ideal.  But then this guy’s answer floored me with its beautiful simplicity.  If you are working to make things better, you are already in the ideal place.  I’ve heard variations on this before, but it really sank in for me this time. Suddenly, the ideal seemed a lot closer!

As for the guy who said this: I don’t know your full name.  If you read this, please let me know: I’d love to credit you for saying this wonderful thing.  And thanks!

Query-Go-Round

A few years ago, I attended some training taught by Pete Behrens.   He led us through a number of collaborative exercises.   They had a number of common traits that I really liked:

  • very simple instructions, so we wasted little time figuring out how to execute (and so the facilitator didn’t have to spend hours explaining);
  • very short duration, so people didn’t get burned out, and so people did not deliberate at length over the value of the exercise;
  • small groups (often pairs), so even quiet voices had room to come out; and
  • frequent rotation, so the perspectives involved were constantly reshuffled.

I led a release planning meeting a month or two later, and I wanted to structure it around exercises sharing these characteristics.  I set up 3-5 activities.  Some were failures and some were so-so, but one stood out as valuable.  It is still popping up here and there throughout our organization.  Based on its longevity, I figure it’s worth sharing a little more widely.

To be clear: I honestly can’t remember if I made this up–inspired by Pete Behrens’ training–or simply repeated something he showed us.  I’m not interested in credit!  I just want more folks to know about this useful tool.

Instructions

The exercise creates bursts of engaged discussion, typically about user stories.  Typically, this exercise would be used in backlog grooming, but you can also use it in release planning or sprint planning.

  • Write each story at the top of a blank sheet of paper.
  • Break into pairs.  Have one group of three if necessary.
  • Give each group one of the stories.
  • Give the groups five minutes to write down as many questions as they can about the story they have.
  • After five minutes, each group passes their paper to the next.  Give them 5 minutes to add questions to those written by the previous group.
  • Continue repeating until each group has seen all of the distributed stories.
  • Hand out the next set of stories, and repeat the exercise until you have gone through all stories.  If you can, shuffle the groups before distributing new stories.

Example

Let’s say your team of seven is grooming a set of nine stories.  You would break into three groups (two pairs and one trio).  You would hand out three stories, and over the course of 15 minutes rotate those stories through all three groups.  You would then hand out three new stories and take another 15 minutes.  And a final repetition would finish the last three stories.  Nine stories reviewed by every team member in 45 minutes!

What’s Next?

In the simplest case, the Product Owner can go answer the questions and adjust stories accordingly.  Ideally, there is some later discussion of the answers.  Some groups here have posted all the questions and their answers on a wiki for later review.  Regardless, you have just gotten every team member thinking about every story in a very engaged way.

Facilitator Notes

  • Make sure people don’t try to answer the questions.  This is just about asking the questions.
  • If people do answer the question (say one person in the pair asks and the other happens to know the answer), make sure they write down the question anyway.  Just because they now know the answer, they shouldn’t cheat the rest of the team of that knowledge!
  • Regardless of how many stories/people you have, the math always works out that you need 5 minutes per story.
  • If the number of stories isn’t equal to the number of groups, you will have to adjust.  For example, with 10 stories, the example group could spend one round where one of the groups has two stories instead of one.

Benefits

  • Many questions identified very quickly.
  • Helps make up for the impossibility of a Product Owner anticipating every question.
  • Avoids backlog grooming meetings where only the Product Owner and one or two team members actually talk.
  • Can take a meeting from boring to engaged, fast-paced, and even a little fun.
  • Flashes a light into corners that usually only get illuminated partway through the sprint.

Drawbacks

  • Be careful not to let this be the only way your team discusses stories.  Some open group discussion is great as well!
  • “Query-Go-Round” is an awfully corny name for the exercise.

I’d love to hear about your experience if you give this a try.  Also please post a comment if you come up with a new application/hack for the exercise. Have fun!

They’re Not Done Talking

I just finished by the Agile Coaching Institute’s Coaching Agile Teams class, taught by Lyssa Adkins and Michael Spayd. Among other things, they taught us to use powerful questions.

For coaches—and really anyone working to guide others—who are not familiar with powerful questions, I recommend you dig in. Unfortunately, just reading about them isn’t enough. When I read about them in the Coaching Agile Teams book, I just didn’t get them. The understanding came when Lyssa and Michael led us through exercises in class.

All the participants paired up and took turns being first coach, then client. It was when I played the part of client that the value of powerful questions really stuck. As client, I brought up a very complicated issue for the practice discussion.  My partner was completely new to powerful questions, and had been instructed to read them verbatim off a board behind me.  Despite the clumsy delivery (all of us were clumsy at first!) and the transparency of the mechanism, each question struck me as startlingly incisive. The sort of questions you think only wise old gurus can ask you, that stop you in your tracks and make you reconsider your basic assumptions.  Really an amazing tool.

During the exercise, the person doing the coaching would wait until I stopped talking and then ask another powerful question. The questions continued to be good ones, but I noticed something else. Because the person would change and ask a new question off the board, the conversation would take a turn. The turns were subtle, but they nonetheless had the effect of severing my previous line of thought. This pattern repeated in later similar exercises, and it reminded me of something.

Years ago, I worked as a standardized patient, the actor hired by medical schools to help train students in dealing with patients. The teaching staff would give me the recent medical history of this fictitious patient and some other details of their lives. They also directed me not to simply spill all the beans, but to let the medical student get the information from me. I repeated the same scenarios many times with different students, and I was also present at the evaluations which immediately followed the exercises.

Many of these first-year students made the same mistake: they would ask a question, and—immediately after I answered—ask another question. The effect was that they were on the right track but turned too soon, missing relevant clues to the medical condition.  It’s not that I was trying to hold anything back.  It’s just that I would naturally stop at certain points.   For example, if they asked, “Has anything changed recently?”, I would naturally tell them one thing that changed and pause.  If they then jumped to a different question, the three other things that recently changed would never come up.  The feedback from the teachers was always the same: don’t change the topic, but ask if there is anything else. In cases where the students simply prompted me to go on, the information would continue to flow.

This is what seemed to me to be happening in the coaching practice as well.  I would reach a sort of natural stopping point, but based on the feeling that the new question severed that thought, it seems to me that I wasn’t actually done with the overarching thought. If the coach had instead asked, “What else?” or “Is there anything more to that?”, I think that I would have simply continued.  As a coaching client, one is not simply listing medical woes or recent life changes.  Another important distinction: coaching and powerful questions are not about fact-finding or diagnosis.  Nonetheless, I think the mechanics of exploration are the same.  I think that the same sorts of natural pauses between thoughts would happen in answering questions like “What’s exciting about this?”, “What is standing in your way?”, “What have you tried so far?”, etc.

If you’re reading this, I’m curious to hear your thoughts.  If you try this out, let me know what happens.  Next time someone seems to have finished answering your question, find a way of asking them to go on. I bet you they’re not done talking.