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.

Advertisements

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!