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’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.”

I Didn’t Say I Was a *Good* Plumber

Occasionally, I run into some online screed about the world surrounding Agile development.  Typically, it’s written by someone who has a relatively high level of experience, and decries people/organizations who are less seasoned.  Those posts really bum me out.

Some focus on the Agile-industrial complex: the slew of people selling services or tools that will help you be better at Agile development.  Okay, maybe some of that happens, but is there any part of any industry where this is anything but normal?  Does it add value to the world to scream that some profiteers have descended on Agile development like they descend on everything else?  It is about as constructive as writing that some people who work in Agile are unfriendly.  Maybe true, but not a great addition to the conversation.

Other posts question the right of newcomers to claim that they are Agile Coaches or a company following Agile principles, etc.  The title of this post responds to this one.  When I started working as an Agile Coach a few months ago, I knew I had a lot of learning to do.  Further, I knew (and know) that my only chance at success lies in striving to continue learning for as long as I do this coaching thing.  Absent a standardized ranking/accreditation system, I immediately began referring to myself an Agile Coach, because I was trying to do the job of Agile Coach.  Sure, I might have been ineffective, ignorant, etc., but I as long as I spent my day job touching pipes with a wrench in an attempt to fix the plumbing, I called myself a plumber.  Not a good plumber, maybe a disastrously bad plumber, but in any case: a plumber.  Are there limits to this thinking?  Sure, but again: what value does it add to the conversation to scream about some human being doing something extreme and ridiculous?

So I am yammering on about adding value to the conversation.  What value does this post add?  Well, here’s my shot: I ask that anyone who is frustrated–whether by some huckster saying that he can Agilitate you for $29.95 or an ignorant Agile Coach in your organization spouting sanctimoniously–to simply not post the screed.  Don’t do it.  Channel that energy elsewhere constructive.  Some ideas:

  • Find a good post on someone else’s blog, and post a comment extending the conversation.
  • Have a cup of coffee with a colleague and discuss some particular aspect of Agile and what it means to you.
  • Look around you and find some aspect of your own Agile practice that you can improve.
  • Re-read a chapter of a favorite dog-eared book about Agile.
  • Write a post honoring (anonymously or not) another individual’s positive contribution to the world of Agile.

What draws me to Agile is its simplicity and focus on eternal learning.  As with many ideas that are simple, though, it takes enormous application to even approach mastery.  Rather than making blanket statements shouting down those that are trying at this ideal–nobly or otherwise–wouldn’t we be better off encouraging earnest pursuit of these principles?