Context is everything, especially with agile methods

—Andy Hunt

09/01/2010
Published in PragPub Magazine

If you ever had the pleasure of working with the Amiga operating system in the good old days, you may have experienced a whimsically-named “guru meditation” error. These errors were reported as a long chain of inscrutable numbers that only a guru could decipher (hence the name).

In that spirit, this monthly column is going to look at real-world “error messages” (problems) that you might run into at work or at home, and hopefully offer some possible fixes. This month, we’ll start off with one of my favorite topics.

All the Difference in the World

If you follow my books, articles, blog and twitter postings, you might notice I have a certain preoccupation with the idea of context. That is, the importance of the situation and surroundings of an event more so than the event itself.

In the agile world, we often say that every project needs its own methodology; every project is different. There are no “best practices,” merely some practices that work better than others in certain circumstances. But it’s important to realize what makes every project different. It’s not necessarily the team, the features, or the technology that you’re using. Every project is different because the entire context is different.

Think of what might have changed. The expectations of the sponsors. The time of year. The skill level of the team (for better or for worse). Incompatibilities brought on by new versions of software that you’re using. The list goes on and on. Just because something worked well last year, there is no guarantee that it will work well now.

For example, have you ever heard the story of award-winning violinist virtuoso Joshua Bell? In 2007, he participated in an experiment wherein he played incognito in the Washington DC subway for 45 minutes on a $3.5 million Stradivarius violin.

He performed six difficult pieces with world-class finesse, and yet most of the thousands of passersby didn’t even stop to listen. Some 27 folks chipped in a total of $32 to the musician, and only seven people actually stopped to listen. Three days before this experiment, Bell played to a packed house in a highly respected venue at $100 a seat.

The music was the same, the performance was the same, but the context was wildly different. In the concert hall, the audience had paid a substantial amount of money each to see this performer. They were appreciative and knew what they were listening to.

But in the subway, it is a completely different context. It’s an unexpected event, and people aren’t always sure how to react. How do you know if the performer is even any good? Do you throw some change in the hat just to be polite anyway? Is it worth your time to stop and listen? If you’re like 98% of us, you just hurry past and ignore the performance.

Great things aren’t great by themselves. Great things are only great in the proper context.

Educate the audience

Now think of the violin example in the context of introducing an agile technique or methodology. That's something we're often tasked with trying to accomplish, whether it’s a new technique to an experienced group of agilists or introducing the basics to a group of novices.

Just as with the violinist, if you’re playing to an appreciative audience who knows what they’re listening to, knows why they’re there, and has invested in being there, then you will probably find the experience to be ultimately successful.

On the other hand, if that very same agile technique or methodology is playing to an audience who is hurrying on their way in a different direction, isn’t sure whether to trust it or not, and doesn’t know if it’s any good, guess what the outcome will be? They might “throw a few coins,” metaphorically speaking, but mostly they will simply hurry on their way. And ignore it.

The solution in this case is to properly prepare, even educate, the audience: to help set up a similar context to that of the official concert. Imagine the subway scenario a little differently: posters up the week before announcing a rare, free appearance by virtuoso violinist, playing a genuine Stradivarius violin built in 1713. A brief bio of the violinist. History of Stradivari instruments; maybe a little science poster on the centuries-old search to discover their secrets. Now the audience knows what to expect—they might even go out of their way to participate. They’ve got some background to know that it’s considered “good,” that the player is eminently qualified, and that this is probably a good opportunity.

So you want to introduce unit testing, or the stand-up meeting, or continuous builds, or pair-programming? Want to introduce Kanban to folks who’ve only done XP, or vice-versa? You’ve got to set the stage, and establish context, before introducing or demonstrating anything, or you might look like just another crank in the subway.

But that’s just one example. Even discredited waterfall can be a better choice in some constrained environments. It’s probably better than “Half Arsed Agile” (HalfArsedAgileManifesto.org) which manages to secure the worst of several worlds. The right technique in the wrong context may not work at all. But in the right context, it can make all the difference in the world.

Gently introduce the facts, but also casually introduce the excitement, the benefits, the interesting side-effects, the emotional resonance that will get your team and your boss eager to see how this works. That’s the context you need to create first—something close to the context you yourself felt when you discovered this new thing.

Something to think about.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.