Resistance is in the Eye of the Beholder

Before I start, I have to give credit to Esther Derby for nearly 100% of the value of this post. She does a free (free!!) monthly Q& A conference call.  During one such call a little over a year ago (“Reframing Resistance for Positive Outcomes”), she opened my eyes on a critical point.  Here’s the very first sentence of Esther’s discussion that day (not verbatim, but close): What resistance really means, if you look beyond the frustration, is a person not going along with your suggestion as enthusiastically or quickly as you would like.

Just this sentence sparked a major perspective shift for me.  The last four words put attention on the part the initiator of the change plays in the feeling of resistance.   Think of it like Newton’s third law: if I punch someone in the face, their face pushes back on my hand.  My hand might really hurt, but would it be fair of me to think ill of them for pushing back on my knuckles with their cheek?  I’m obviously heightening my role as aggressor in this situation, but even in this extreme example, I might have good intentions (e.g., it looked to me like they were about to hurt my friend).  Regardless: I took part in creating the pain I felt in my hand.

While this analogy is silly in some ways, I really like that it highlights something huge that I used to overlook when complaining about resistance: how does the other person feel about it?  Just as focusing on the pain in my hand is unfairly ignoring the pain in the other person’s cheek, complaining of resistance is ignoring the position that I have put the other person in.  They very likely don’t like pushing back, but I am forcing them to do so.  (Of course, they have the option of just giving in, but neither of us does well in that outcome.)

Esther went on to cover some very useful techniques for working through how to approach perceived resistance.  These techniques both involved shifting ones perspective: in one case re-framing the perceived resistance to find its potentially positive components, in the other case seeking an understanding of the other person’s perspective.  Doing the exercises really drove home the truth of her opening statement. Every example of resistance I could think of fit that definition.

One might consider this massive self-deception: if I always slide around to the other person’s perspective, am I simply explaining away resistance that actually exists?  Well, if my interest lies with progress that respects people for who they are, and if understanding their view helps me achieve progress, I don’t think I really care.  Regardless, I truly have come to believe that–in all but very rare cases (e.g., deep personal animus)–resistance is just one’s own view of the feelings one creates by pushing on someone else too fast, too hard, or too insensitively.

The tools Esther shared that day are great, but the really cool thing she did was helping me see the futility in fussing over so-called resistance.  Since then, I’ve stopped using the word in this context.  That’s a pretty damned good result for a free Q&A call.  Thank you, Esther!!

Re-Organizational Agility

At the beginning of this year, I had a discussion with some folks at various companies about organizational issues at scale. At one point we touched on our individual experiences with high-level company re-organizations. As we went around the circle talking about frequency of change, we learned that the represented companies re-organized about once every 18 to 36 months. This struck me as interesting because the language typically used to communicate such changes not only fails to communicate predictable fluidity, but on the contrary implies permanence. I don’t recall explicit claims of permanence, but the old ways are usually cast as simply wrong, the new ways as the solution to a problem. Not one of the many re-orgs I’ve been through is billed as what it truly is: an approach aimed at solving current problems, which is therefore likely to cease being useful when the primary problems change.

In the call, I suggested the idea that the architects of such re-orgs might recognize this and take a different approach. I’ve thought about it a lot since then, in part sparking my thoughts on all management as a support function. If you accept that management serves a support function, it follows that management should constantly adjust to the needs of the org it supports. How would this in turn change the periodic re-org?

I imagine that announcements would make clear that re-orgs are explicitly temporary attempts to respond to the current set of support needs. To prepare for future re-orgs, management could establish an ongoing process to assess the fit of management structure to needs. I think of this as a sort of product in development. Just as the Product Owner attempts to fit a product to the needs of their customers, the Re-Org Owner would attempt to fit their product (management) to the needs of their customers (development teams). As with product release, you could then adjust the frequency and breadth of release to get the appropriate level of feedback on your changes. In any event, you would work to move away from the typical pattern: big announcement, months of figuring out what it means, months of learning to do it, months of learning the problems with it, months of attempting to fix those problems, and finally abandonment for the next approach. This would help de-emphasize any sense of permanence in the re-org. In turn, this would hopefully help defuse a typical response to many of these re-org announcements: “Humpph. More management bullshit.”

It’s possible that this thinking just flows from my bias towards typical Agile team structure. What I’ve observed, though, is that the structure of those teams rarely seems to change based on the high-level re-orgs. In short: the small team structure seems to work more or less indefinitely; you just need to modify the support structure around it to adjust to changes over time.

Regardless, there doesn’t seem to be much here that is too controversial: Why not just be honest that things are going to change again? Why not be thinking ahead about the next re-org to avoid waiting too long and starting too jarringly? Why not try out those changes in smaller measure to validate your decisions?

Thanks to Simon Marcus, Anders Ivarsson, Mac Fowler, and Erik Schon for the very interesting conversation that inspired this thinking!

Inverting the Org Chart

“Hierarchies evolve from the lowest level up…The original purpose of
a hierarchy is always to help its originating subsystems do their jobs better.”
—Thinking in Systems: A Primer, Donella Meadows

You and your friend Kelly have an idea for an internet application. You dream it could be the next big thing. You’re a code wizard and Kelly’s good at telling a story. You gather enough money to get started, find a couple of like-minded builders, and dive in.

You decide to use Scrum, because that worked pretty well for you in your old shop. Kelly is the obvious choice for Product Owner, and you act as Scrum Master. Both of you still actively write code.

Things start going pretty well. You have enough users to attract investors, and the app starts to expand. As it does, your team of four grows to six, then seven, and then jumps to 12. You have plenty of work, and great talent to do it, but the team is getting too big, so you split into two development teams. One of the team members has a knack for keeping the team focused and engaged with each other, so she takes on the SM role for the other team.

Kelly does okay for a while as PO for both teams, but as the teams start to grow further, it gets to be too much. The two of you barely touch code any more. There are greater dealings with investors, payroll is getting to be a real burden, and there is less and less time for focusing on vision. You decide to hire an office manager to deal with daily overhead. Under Kelly’s mentorship, two new POs will guide the teams. Kelly officially becomes CEO and shifts primary focus to higher-level, longer-term strategy. You become CTO, mentoring the senior members of the teams.

You can imagine how this continues. As you continue to add members to the development teams, you continually need to add people to handle work that you used to be able to spread through the team. In a small organization, people can handle these functions themselves. As you grow, it becomes inefficient to spread those functions across everyone, requiring consolidation of the functions under specific people in new roles.

You didn’t need a CEO and CTO when there were four of you. You may have worn that badge, but it was just your specialty within the team. You only needed to spin off management as its own role when the company grew.  You spun off other things typically referred to as support functions–HR, facilities, IT, administrative assistance.  Is management any less of a support function?  The vision, strategy, and leadership they provide are sexier than the stickies, coffee, and toilet washing handled by other support roles, but they are nonetheless things that the teams need to get their work done.  I call that support.

Put differently: management exists to support the managed. Shouldn’t org charts then look like this?

Am I just quibbling? A little. But it’s interesting that org chart templates don’t even provide this as an option.  To build the above, I couldn’t use the Visio template, because it assumed that an Executive square had to be above a Director square.  The arrows came out all wrong.  Maybe always looking at the image with the CEO at the top affects our perception?  In the physical world, supporting something is usually associated with holding something up from below.  Looking at the typical org chart, then, who is supporting whom?

One might worry that the inverted pyramid would give management big heads: “I support the whole company!” Well, if they are actually operating from a position of servant leadership and effectively supporting the whole company, then I say they deserve big heads. They also probably deserve the big salaries, because effective servant leadership is a rare skill that takes enormous effort to refine. Regardless, I prefer Atlas-like claims to the image standard org charts promote: monarchy carried on the shoulders of those below.

To be honest, I think the org chart should depart from pyramidal hierarchy altogether to represent the symbiotic organism it is intended to model, but flipping it upside down is a start. If we invert it, what shifts in our mindset?

Note: the later post Re-Organizational Agility discusses one change this might yield.

Update: I completely forgot a very important credit!  The thinking in this post was sparked by the Meadows quote above.  It’s especially embarrassing given that its only correct placement is right at the top of the post.  My apologies for the oversight.

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.

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 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!