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.

Put on Your Lab Coats!

One of the most effective things I’ve done with my teams so far is urging them to simply try things out. Late last year, we heard many variations on trendy phrases like “celebrate your failures”, and I sent a Happy New Year message to my teams reflecting on the great sanity behind the fashion. I suggested that celebrating failures is not about reveling in the failure itself, but about encouraging learning and daring. The former comes from reflecting on the vast amount of data that a failure generates, but we already knew about that from the inspect-and-adapt loops built in to Agile frameworks. What I find really exciting about the notion of celebrating failure comes one step earlier: if it’s okay to fail, then that means it’s okay to try things. Even crazy things.

There is too much pressure in a business environment to be sure that you’re right. We spend inordinate amounts of time trying to predict the future of proposed initiatives based on supposedly rigorous but frequently inaccurate cost-benefit analyses.  Weighing the pros and cons of a proposal is perfectly rational, but taken too far, it creates an environment hostile to new ideas. This is especially true at a fine-grained level, where the ROI on time spent debating the future success of an idea is minimal.

So, I sent that email. No one responded. Email is a terrible way to spread ideas. But later, usually in retros, I called attention to the idea.  I used the metaphor of a scientific experiment. “You see a problem,” I told the team, “and you have a hypothesis that taking a certain action will at least partially solve that problem.  Taking that action is testing your hypothesis, and to test it, you need some level of control in your environment and some sort of measuring stick.  How will you evaluate whether the hypothesis was correct?  How do you avoid muddying results by, for example, failing to really embrace this approach across the team?”

This metaphor landed well with the teams.  They have shown hints of defining actions and measurements more crisply.  They are more likely to give proposed actions their all, rather than half-trying and thereby undermining the experiments.  They are trying things they are not completely sure will work.  It also undid a strange, surprising knot in which the teams repeatedly tied themselves.  In one example, the team wanted to implement a procedure to solve a near-term problem, but worried that it would become overhead in the long-term. They really got stuck there.  It truly wasn’t occurring to them that the very tool they were using to put the procedure in place (the retro) could be used to remove the procedure once its value was gone.  This idea of intentionally temporary changes was a big insight for me.

I’ve since discussed this with fellow coaches, and we’ve nearly all had the same experience: get your teams to stop worrying and start trying stuff, and magic happens.