Does your Bartender Understand Agile?

For the past three years, my mom could simply tell her friends, “my son Ken works for NASA.” Now that Curiosity is on its way to Mars, mom wants to know what it is that I am doing next…and when I’ll visit again, of course!

What do you say, when someone asks, “so, what is it that you do at work?” Are you prepared to explain it, in simple terms?

“An alleged scientific discovery has no merit unless it can be explained to a barmaid.” –Ernest Rutherford, quoted in Einstein: The Man and His Achievement (1973) by G. J. Whitrow, p. 42.

What’s the big deal about “Agile teamwork?” How do you do what you do? Why?

How do we do what we do?

To an outside observer, patterns and practices will be evident in our behaviors and artifacts. For example, a daily standup, a cumulative flow diagram, a Kanban board. What might you feel compelled to say to a visiting friend or relative, as you give them a quick tour of your workspace? What about a newcomer joining your team, on their first day, if they haven’t yet been indoctrinated through training, experience, or study?

Manifest behaviors and artifacts create a “visible” perspective. How we do what we do is discoverable. Our “why” may be a mystery.

Why do we do what we do? 

So what will you say next, if your visitor asks that simple but profound question, “why?”  That’s a very important question. Because, as practitioners–when we aren’t certain what to do or how to go about it–we can innovate. What drives our innovation? Our motives aren’t so “visible” as our behaviors and artifacts. Hopefully, we do have some goals identified, and we are principled in our doing.

Like a compass, goals and principles guide us as we work, and especially as we explore our frontiers. In unfamiliar situations, we can look for patterns, “make something up” and give it a try. That’s an experiment. That can be observed. Yet why we chose to go a certain way isn’t so obvious. A little reflection goes a long way when we act on what we learn. We can “inspect and adapt” to improve our results. We press ON!

What about those who would do likewise? Will imitation or mimicry be sufficient? Probably not. But with some record keeping and explanation, we can make a map or a journal to show or tell others where we’ve been, what we built or tore down, and capture lessons learned along the way. There is value in the legacies of our journey–our charts and transcribed thoughts–when they serve as “visible” trail markers or field guides for those who would follow. When we take time to explain why we acted, whether by rule or exception, we begin to create a transferable legacy, in addition to whatever else we made. Others can build on that and also press on.

Historical Flashback: “Plan-Do-Check-Act” and iterate in small steps. That was the simple yet profound behavioral guidance from Walter Shewhart at Bell Labs in the 1930’s and promoted by W. Edwards Deming. They went to great lengths to explain how and why “PDCA Cycles” work, for example, and much more in the way of principles. (Consider The Deming System of Profound Knowledge and especially Deming’s “14 Points for Management” therein.)

Back to the Future: How might you work differently today? Could you explain why?

Have you reviewed the Agile Manifesto lately? How about the 12 Principles behind it? Do you understand all that… well enough to explain it simply?

I hope you can. I may need some help. A couple months ago I “choked” in an interview, struggled for words, and realized I needed a refresher to be more articulate… and more concise! (Clearly, I still struggle with the ‘concise’ part. Perhaps I don’t understand well enough yet.)

Soon, I’ll be chatting with my mom again. Wish me luck!

–Ken 😉


15 Replies to “Does your Bartender Understand Agile?”

    1. Phenomenal insights follow… Thanks to yesterday’s tweet from @DavidChilcott
      The Fearless Heart: Vulnerability, Difference, and Belonging #AgileNVC #NVC
      [Spotlighting a blog entry by Miki Kashtan written exactly one month ago].

      Miki’s blog led me to watch these two brilliant gems of insight:
      1. Brené Brown: “The power of vulnerability” (TED Talks, TEDX, 2010),
      2, Brené Brown: “Listening to shame” (TED Talks, 2012),

      Highlighting a few facets:
      “Being vulnerable is essential for whole-hearted living. ~ Vulnerability is not weakness. ~ Vulnerability, defined as emotional risk, exposure, uncertainty … fuels our daily lives. ~ Vulnerability is our most accurate measurement of courage. ~ Vulnerability is the birthplace of innovation, creativity, and change!” –Brené Brown, Social Science “Researcher-Storyteller”

      Thank you, Brené, Miki, David, and Peter!

      –Ken 😉

    1. Karol, thank you! My attempt to explain is both ‘apologetic’ on behalf of all of us who share this experience, and (I hope) both ‘informative’ and ‘affirmative’ to those who would do likewise.

      Share the love, and “Press ON!” indeed!

  1. Pingback: Does your Bartender Understand Agile? | Agile | Syngu
  2. Hey Ken – what wonderful, pragmatic insight.

    This is the power of an agile practice we like to embrace – “metaphor”. It makes real for people not familiar with our IT jargon why we do what we do. Unfortunately, there are many metaphors to choose from based on the diversity of world-views out there (or more cynically, the diversity of business strategies, ideologies, etc.).

    One metaphor I like to leverage (at least to bartenders in Southern Florida) is sailing, and making a crossing of the GulfStream to West End, Grand Bahama or Bimini (shameless plug here – see SDLC 3.0). A software endeavor is like a sailboat and must be steered based on our experience and various “practices” we leverage to safely get across. Some experience was learned on many prior occasions the hard way, and should not be lost due to ignorance. Some is learned as we adapt to conditions on the ground. Neither is sufficient alone. Every crossing is different. One might say that Agile is much like “sailing the rhumb line” – trying to cross with as little fuel (or a constrained amount of fuel), as safely and as possible so as to enjoy a few Kalik’s on the other side as quickly as possible :o)

    For whatever name or tag we give to the tactics that we leverage on software endeavors, what is important is that it is based on contextual experience. Sailing has it’s own tags and is also based on experience. In the example I give above, experience tells us that you need to start off from West Palm Beach in the middle of the night to have enough time to “land” on the other side. Experience tells us that we need to adjust heading and steer (or make adjustments) at various points along the way because of the current that varies from 0-about 2.5kn and back again. But that experience only gets us so far due to the variable nature of weather and waves. For the contextual nature of crossings, we know to use “visual navigation” say on approach to Grand Bahama when within the last mile of a Gulf Stream crossing; using visual navigation of water depth making a passage across the Gulf of St. Lawrence would be a different matter altogether because of the clarity of the water.

    With metaphors like this, we can easily explain things like why Agilists have a problem with things like Earned Value Management (based on a prescriptive Work Breakdown Structure as opposed to a “Scope Breakdown Structure”), why comparitive velocity without being normalized to “percent complete” is a problem waiting to happen, and why Agilists have a problem using big documents to extract the tacit knowledge of where we need to get to (which is largely unknown – we know we need to get to Bimini, but we can’t prescribe exactly where the coral heads are). Mostly, metaphors like this particular one explains why the buzzword we use called “Agile” works.

    Which is very valuable to avoid a huge bar fight!

    1. Love the comments Mark. Love your sailing analogy. I use a surfing analogy for Agile 🙂

      1. Preparing for waves
      2. Knowing you have a short period to jump on it!
      3. Not knowing how big the waves are
      4. Knowing you have more waves to come (inspect/adapt/improve)
      5. Planning only as much as you can feasibly see (swells)


  3. I’ve been waiting for someone to write this article. Am I the only one who’s cast my Martini on the ground and denounced the local watering hole as ‘anti-agile’? Huh. Get with the times TGI Friday’s!!!

Leave a Reply