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