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!


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.


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.


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.


  • 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.


  • 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.

Foster Agile: Keep Your Eye on the Ball

Part of the Foster Agile series.

About twenty years ago, I was working for my step-dad’s engineering firm. Deadlines all around, I was paralyzed. I told him that I didn’t know what to do.  He said, “My grandfather always told me: ‘Keep your eye on the ball.'”  I said, “Sure, but what if there is more than one ball?”  Without missing a beat, he responded, “Keep your eye on the one that’s going to hit you first.”

This advice has served me well over the years, but working alongside him renovating my house over the last few years has really made the lesson stick.  At the start of a day, we discuss what we aim to do.  Then, we do that and only that until the end of the day.  I have occasional moments of panic that I am neglecting something important out there, or that I am going the wrong course, but working alongside my hyper-focused step-dad, I stay with the selected task.  There is this strange feeling–perhaps it is Csikszentmihalyi’s flow, I’m not sure–that the rest of the world has been pushed outside a bubble around us.  By the end of the work weekend, we have accomplished an astonishing amount of work.  As for the things calling from the outside world, nothing has burned down as a result of my ignoring them for a while.

I’ve since tried the same thing at work. I noticed that I was letting my focus slide all over the place in the time slots available between meetings. If I could manage to attend a scheduled meeting for an hour, why was I struggling to maintain focus on a task for an hour? So, I set up meetings with myself to focus on those tasks. And I kept my eye on the ball. The same feeling from working with my step-dad came back. The world retreated behind a bubble. The same anxieties came, but I stuck with my tasks (kept my eye on the ball that was going to hit me first), honoring my commitment. When I emerged, nothing had exploded. The only real change was that I was burning through tasks at a much higher rate.

I struggle to exercise the enormous discipline required to give myself this gift of focus. First, I have to plan my time, committing chunks of time to given tasks.  This runs counter to my impulse to just dive in.  Second, I have to make hard decisions when I realize my list is simply too long for the day.  I have to resist impulse #2: rely on wasteful wishful thinking.  Third, even when I have planned my day, yet another impulse presses me to respond when things call, rather than keeping blinders on.  In all cases, I have to fight an ingrained habit in order to avoid distraction.

Focus is a core value of Scrum.  At the daily stand-up, for example, team members have this wonderful opportunity to select a single task, or a set of serial tasks, to take on for the day.  The system explicitly lays out their right to keep the rest of the world off behind a bubble.  Scrum and other Agile frameworks enable this focus through the key structural component of iteration: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”  Breaking a schedule into chunks allows you to break your work into chunks in the same way, leaving everyone the freedom to focus only on the set of work selected for the current chunk.  It keeps you from the much more complicated discussions you have to have when you have a boundless future in which to schedule your boundless list of tasks.  Focus is one reason Agile principles can work. However, it’s not enough for them just to enable focus; one must discipline oneself to apply those principles.

The folly of multitasking is well-known, but I suspect that many people see its danger only at coarser levels. For example, they talk about the problem of having to go to a couple of half-hour meetings a day, or of having to switch product focus from sprint to sprint. While I agree that these switches degrade focus, it is at the grain of minutes and even seconds that I think context-switching does its greatest damage. You click the bookmark for your bug-tracking software and the system is slow. In the moment you wait, you switch to look at an email that just came in reminding you to submit your time sheet. You open the time sheet app. Another delay in loading. You switch back to read the next email. This pattern continues, and all of a sudden you have eight tasks cluttering your mind. The impulses had good intention: “It is a waste of time for me to stare at the screen while the bug-tracking software loads, so I’ll do something else for a minute.”  Unfortunately, it just doesn’t work. It is actually more efficient by a stunning degree to stare at the screen until the system responds. This is the powerful counter-intuitive truth of “keep your eye on the ball”.

Are you as focused as you think?  I offer this challenge. When you are done with this post, figure out your next few highest priority tasks.  Rank them.  Do the first, and focus only on that until it’s done, at which point you move on to the next.  Pay a little attention to yourself as you do.  Are you really focused?  Did you switch over to email for just a second?  Did you make that spreadsheet a little fancier than it needed to be?  Did you remember something “more urgent’ you had to do and switch to get it done because it would just take a second?  If you switched away, try again.  This time, force yourself not to switch.  Once you’ve succeeded in avoiding a switch, look back on how it went.  What was different?

Highfalutin talk aside:  Keep your eye on the ball.  And if there’s more than one, keep your eye on the one that’s going to hit you first.

Foster Agile: S**t My Step-Dad Said

My step-father has been very successful in academia, private business, and–most relevant here, oddly—making buildings. As far as I know, he only knows about Agile because of my yammering on during some visit. Nonetheless, I learned many of the truths underpinning Agile and Lean thinking from him.

Note that I wrote “truths underpinning Agile and Lean”, not “core Agile/Lean principles”.  The folks who wrote the Agile Manifesto didn’t hunker down in some laboratory and invent Agile ground-up as a theoretical framework.  Rather, they extracted certain commonalities from their empirical observations of real work experience.  Indeed, they start: “We are uncovering better ways…” (emphasis mine).  Read the manifesto or any of the principles.   They don’t say why the approach works, but only that they have observed it to work.

This is one reason I believe so strongly in Agile: it stems from broad empirical knowledge, and not just some cool theory that seems like it might work.  For those new to Agile, though, it can smell like the emperor’s new clothes.  “I can’t really tell you why this works, it just works.  Trust me.  It’s magic.”

I am generally trusting, so it’s enough for me to give it a shot and see for myself.  However, I am also obsessively analytical, and—especially when I am asking others to take a leap–I like to have a better theoretical understanding.  I want to connect the empirical observations of others to some less lofty things that I have observed myself.

That’s where my step-dad comes in.  Before working in Agile, I worked in a variety of roles in different organizations.  During those 18 years, I noticed many things that don’t work and a few that do.  Near the beginning of that time, I worked for a consulting firm of my step-father’s, and toward the end of it, starting renovating my house with him.   During work weekends, I and others were repeatedly stunned by how much more work we got done when he was there leading.  The model presented by this productivity and his superlative discipline allowed me to distill my rough observations of work into–yes, I’m going to say it, and with a capital T, no less–Truths.  What a nerd.

When I started working in a Scrum shop, I read Ken Schwaber and Mike Beedle’s Agile Software Development with Scrum.  Here was a way of working that mapped to the Truths I had seen.  Woohoo!  Again: what a nerd.

Why does this matter to me?  It calms my anxiety that this new set of clothes is of the imperial variety.  And it helps me, as a coach, calm similar anxieties in others.  I’m grateful to my step-dad for showing me these things, and I’m planning a bunch of posts about these Truths that I learned from him.  He’s from a small town called Foster, so I’ll call the series Foster Agile.  Let’s see how far I get.

Daring to Teach

What if someone is wonderfully talented, easy to get along with, but just wired in a way that is at odds with the way Agile teams work? What can you do about it? What should you do about it?

Over my working career, I have labored with some success to change my habits (i.e., rewire myself).  So, I fully believe that rewiring is an option, even if it is difficult work. For example, I have always been prone to falling right down a rabbit hole and losing track of my goal. Looking back, I would always curse my lack of focus, that I did things that I didn’t really choose to do. Sure, I chose them in a sense, but it was the choice of not making a choice, of ignoring the fact that I was going off the rails. The various mechanisms in Scrum and other Agile methods that repeatedly refocus one’s attention therefore make sense to me. This is but one aspect of working in an Agile way that has not only increased my value to the company, but more importantly made me a happier person: less stressed, more focused, able to react to change without so much angst.

I did all this voluntarily, because I was continually frustrated by my old working habits. But is pushing folks to rewire a good idea? I’m of two minds on this. The idea of forcing someone else to change puts a bad taste in my mouth. On the other hand, I am thankful to all the role models who taught me how to work better. To the extent that they intentionally chose to teach me–to encourage me to rewire–I am without reservation glad that they did. Now that I am in the position to teach others, is it fair for me to assume that those I influence will in the future be grateful that I encouraged them to rewire now, and therefore to ignore the bad taste in my mouth?

The easy out is to say that I will not be putting a gun to anyone’s head. If someone chooses to adopt things I teach, that is their choice. Indeed, I predicate my coaching on the idea that it is impossible to force someone to learn something. You can only expose people to ideas, to ways of working, and see what comes of it. The problem with this answer is that most of these instances take place in a company that pays people to create products that yield a profit. Benign an approach as I may take, that environment may be the gun.

I believe that the better ways of working that the Snowbird Seventeen and others uncovered are better because they reflect basic truths about humans. In other words, humans become better value (or profit) producers when you align the way you produce profit with the very way that humans are. That brings me to the edge of an ocean of moral and ethical questions that I simply don’t feel capable of swimming. My simplistic view, standing with the waves lapping my knees, is that you can either cynically regard this as mercenary thinking, or you can see Agile as bringing production in line with what is more fulfilling, enjoyable, and sustainable for us all.

Bringing this back to how I will go forward, I’ll cast aside the rationalizations and take a stand that I’ve been squeamish about taking: I have something worthwhile to teach. There.  I said it. I have learned greatly in my twenty-plus years of working in public, private, and academic organizations ranging in size from two people to over 100,000. I have seen basic human principles hold true in fields as disparate as software development, construction, and theater. Most importantly, I have seen with regularity people throwing their hands up in pained frustration, railing at the world, when many of the knots they bemoan are within their own power to untie.

I cringe a bit writing that. It makes me sound like I think myself some guru that has arrived in the promised land. I’m not. I’ll keep making mistakes, and I’ll keep learning more. Nonetheless, I believe that I have learned things that I want to pass on to others. Further, I believe that every one of us can teach each other at every stage. If we go forward in earnest, open to the ideas of others, living the example we want to see in the world, I think we can make our way without wringing our hands too much over the moral implications of it all.

(Inspired by a question on Quora.)