heuristics

Heuristics for an Agile Context

Heuristics are useful, especially in the complex world in which we find ourselves.  Unfortunately, they’re often underutilized, and the notion of heuristics is largely misunderstood.  What we frequently find instead are platitudes that, while inspiring, do little to help us determine our next step.  In fact, I have my own set of these platitudes that I’ve dubbed north stars

So why are heuristics useful?  They’re immediately enactable, straight forward, and they can help us determine what to do next in real time.  Consider this heuristic from the Marine Corps:

Capture the high ground. Stay in touch. Keep moving.

Clear, right?  Hell!  Anyone–with or without military experience–can appreciate the advice, I think.  So why aren’t we using these more often and in our own agile contexts?  That changes today, and it starts with my own.  

Let’s begin with a set of heuristics I used as a manager or seen used by other managers:

  • If I have to tell you no, I will provide a compelling reason.  If I don’t provide or you don’t find the reason compelling, hold me to it.
  • I’m only your manager when we’re in our one on one or you’re throwing a punch at someone.  In all other cases, I’m your product owner.  (Caveat: manager as product owner is often a bad idea, but in certain cases, I’ve seen it work.)
  • If my reports have a spouse or kids, know their names and interests.

I use this next set of heuristics as a facilitator in every retro:

  • Be the quietest person in the room.  If I must talk, ask a question.
  • Questions should come from a place of curiosity.  It should never be a game of trivial pursuit so never make someone guess my answer.
  • Offer advice only when it’s asked for.

Here’s a set of heuristics I exercise for influencing or being influenced by others:

  • The opinion that matters most belongs to the person directly affected by the problem.
  • Know my customer.  If I can’t name who I’m working for, pause and determine.
  • Always start with why.
  • Avoid nomenclature with the uninitiated.  It’s only valuable when others possess identical mental models.
  • Never teach something that my student can’t put into action before the week ends.

When it comes to change:

  • If our experiment can’t begin tomorrow, it’s too big.  Make it smaller.
  • Tweak only one thing in a given context at a time.  If multiple contexts exist, run tweaks in parallel.

I started this post explaining that heuristics are often misunderstood.  For example, what’s the difference between a rule and heuristic?  And does such a distinction even matter?  If you’re curious to read my opinions, you’ll see them in the comments below.


Thanks goes to David Snowden for not only reminding me of the power of heuristics but also for helping me refine my own opinions around metrics as I prepare to speak at the Scrum Gathering in Austin in May.  I hope to see some of you there.


Do you want to get notified when new posts are published? Leave your email below.

4 thoughts on “Heuristics for an Agile Context”

  1. Hey Tanner – what’s your definition of heuristics? Heuristics are simplified rules in my book, a one-liner that covers everything that you have above.

    Your list seems like “rules” to me in the prescriptive zone. Perhaps a relook and resimplify?

    1. Source: https://cognitive-edge.com/videos/cynefin-framework-introduction/

      How interesting. When I set out to put my thoughts on paper, I hadn’t considered the difference between a rule and a heuristic, but the more I mull it over the more interesting it becomes. Here’s my simplest distinction between the two:

      A rule is rigid and something imposed on me by others. Those who enforce the rule are responsible for managing the exceptions.
      A heuristic is flexible and is something I choose to adopt. Since I’m the adopter, I can choose when it is and is not appropriate.

      Put in the context of Cynefin:
      1. Rules are vital in the simple domain.
      2. Rules are useful in the complicated domain but multiple, conflicting rules may all be appropriate to the same circumstance.
      3. Rules are less useful in the complex domain where heuristics (and their inherent flexibility and simplicity) become more appropriate.

      So do I believe my heuristics above require change? Are they prescriptive? I don’t think so. I choose to adopt them so I can choose when to make an exception. For example, if I’m working with a new team and helping them with the fundamentals, I may not be the quietest person the room in the retro, and I may not be asking as many questions as I would with a more mature team.

      Thanks for stopping by and for the thought provoking comment, Srikanth.

  2. Thanks for your post. I’ve also been thinking about heuristics as I dig into the spine model and what it means to have principles and how to identify them/separate them from values and practices. If you aren’t familiar with it, give it a look, it might deepen your introspection as your post helped me.
    http://spine model.info

Leave a Comment

Your email address will not be published. Required fields are marked *