We Need a Map

February 12, 2017


“I have an existential map. It has ‘You are here’ written all over it.”

-Steven Wright

I happened to be in a cabin one evening after a long day of hunting. The wood stove was blazing and we were all chilling after dinner. The guides were off to one side hanging out together sharing their experiences from the day. It was fun to watch them as they described where they had been and what they had seen. The dialog would go something like this:

“We were down trail X off of the old logging road Y near the fork in the road and we didn’t see anything”
“You mean down past road Z near the bridge, right?”
“No, no, no. We were down logging road Y.”

Around and around they went.

At this point in the conversation they usually resort to hand gestures to further supplement the conversation. This goes on for a while and pretty soon it’s hard to tell whether you are looking at guides trying to tell each other where they were, or perhaps you are looking at a pair of fighter pilots describing their latest dogfight. There are hands waving wildly in the air. It’s Top Gun in the hunting cabin. Voices are raised, and expressions are animated.

And still they can’t seem to simply tell each other where they were. I’m watching all of this and I’m thinking, “These guys need a map.”

I’d laugh, but I see it all the time in software teams. If I’m honest, I catch myself doing it all the time. It seems that even with all the software that we have today, visualizing what we do and sharing it with each other is still a significant problem for us. How often do you find teams working together and trying to describe something – hands waving in the air and all. I guess we’re all future fighter pilots.

Like I said, I think sometimes what we really need is a map. I challenge you to go take a look at the walls in a second grade classroom. You’ll see nothing but maps. Maps of the US. Maps of the parts of a sentence. Maps of numbers. Everywhere there are maps of the knowledge that second graders consider important. What you see on those walls is the cartography of the eight year old mind.

Now go back to your office and look at the walls. What do you see? I’m betting that the walls are completely bare. Maybe you have some of those crappy motivational posters. If you are really lucky there is a map to the fire escape. There are no maps in the office of the typical knowledge worker. Why is that?

All too often we are like the guides in the cabin. We’re struggling to communicate simple concepts with each other – playing Top Gun. Maybe it’s time for a map.

How Does That Feel?

November 7, 2016


“We cannot direct the wind, but we can adjust the sails.”
-Bertha Calloway

I was out racing for the first time in a long time this weekend. I was rusty and sailing on a boat that I was unfamiliar with. Furthermore, I didn’t know anyone on the crew. So I started doing what I like to see others do when racing: I just started talking about what I was seeing happening around me.

“Do you see that boat over there?”

“Hey, look, there’s a puff of wind over there.”

“It looks like the breeze might be filling in from over there.”

I kept that little monologue up, not constantly, but on a fairly regular basis. Just letting others know what I think I’m seeing. At some point during the race, one of the guys looks at me and says, “Tom, I hear you talking about pressure over here, and puffs over there, and I’m not really sure what you are talking about. How do you know there’s really wind over there?”

That’s a great question. And there are a couple of answers. The first answer is that I simply don’t know. I’m really just guessing. It’s the wind that we are talking about after all, and I have no more special insight than the next guy when it comes to divining the nature of the winds. However, I do have a few years of experience, and it turns out that more often than not I tend to get it right. That’s because I’m looking for certain signs on the water that indicate what might be the presence of wind. Something like a telltale pattern of ripples on the surface can indicate a small downdraft…or it could indicate a small school of fish ruffling the water. Now I usually know the difference, but I could be wrong. Trust me, it happens all the time. But I don’t worry about that when I’m racing. I think there is value in sharing all observations about the race course that help to give my team a tactical advantage.

People tend to assume that the person driving the boat, usually a very experienced and capable individual, knows what is best and has a good grip on the situation on the water. Nothing could be further from the truth. It turns out that when you are the skipper, you often have your head stuck in the boat. It’s not the skipper’s fault – it comes with the job. You are trying to steer to the telltales on the sails. You are reacting to pressure on the tiller. You are worried about the next mark rounding. But you can’t look at everything at once. That’s where a crew that can be feeding you that information is very valuable. It also helps if they can be sharing the information with each other. After all, they are no more likely to get it right than anyone else. That’s OK if there are more than one set of eyes looking at the issue. So if I think I see a puff and I call it out, another team member may disagree and point out the school of fish just beneath the surface of the water that I missed. The dialog is self correcting. It’s a constant patter of conversation where we share our impressions, some false, some true, that help us to confirm or deny our race strategy.

The other thing that I frequently do is ask questions like, “how does that feel?” Again, I have lots of experience sailing, but I’ve never sailed on this boat before. So I make changes to the sail trim and then I ask, “Did that help?” Maybe it does, or maybe not.

So not only am I talking about the physical nature of the race course, but I’m also checking in with my crew mates. Now I don’t do this out of any overabundance of concern about their well being. It’s much more practical than that. My actions are impacting their performance. Now maybe they will tell me how they are impacted or maybe they won’t. In fact, it’s often the case that people won’t tell you unless you ask. So I ask a lot. I change the sail trim and I check back with the skipper, “How’s does that feel now? Better? Worse?” I check with the guy trimming the main, “How about you?” Sometimes the answer is just a shrug. That’s fine, that’s good feedback too.

I’ve noticed a curious thing that seems to happen. As you model this behavior, others start to pick it up and do it too. At the start of the race, maybe I’m the only guy who’s talking. Two hours later as we cross the finish line, people are calling out puffs and asking for feedback from each other. People seem to pick up on it pretty quick if it’s useful. And if not, well, then maybe you don’t get invited back. Like I said, I don’t always get it right.

I wonder if the same sort of communication is useful for our development teams? What sort of things should we be talking about? What kind of observations are useful? Where are the ripples on the water for a software development team? I know they are racing – that much is for sure. Is the boss’s door closed? Is Joe late getting into the office? Does that meeting have an agenda? I don’t know, I’m guessing that some of that is water cooler conversation that probably isn’t worth a whole lot. On the other hand, what if I come into the office and mention that one of our biggest competitors just made a key acquisition. That’s going to send a few ripples through the water. What if there is an issue in production? More ripples. Maybe even some waves.

So there may indeed be some utility in sharing your observations about the business, the technology, the current state of the production system. It’s all wind on the water. It’s tactical information that may or may not be useful. But you are definitely better off talking about it.

So What about asking questions? You know like, “How does that feel?” Boy, there’s a question that software guys just absolutely love to get asked. How often are we checking in to get feedback on how our actions have affected those around us. Once a sprint? Of course I can’t wait that long in sailing, because the race is long over by then. The feedback would hardly even be relevant if I waited that long. In order for us to fine tune our performance and work together as a team, we need to be constantly engaging in a dialog that tests our assumptions about the value of the changes we are making. Did that help? How does that feel? It’s a fuzzy sort of qualitative conversation that I’m sure makes some folks uncomfortable. But maybe that’s because we’re using it wrong.

You see, when I ask the helmsman how a change feels, he knows what I’m asking about. He knows I don’t give a damn about his emotional state. I want to know if the boat just got easier to steer. Did the boat speed up? Did it slow down? Perhaps the same should apply to software teams. We need to make sure that we understand how the conversation is intended. When I ask how things feel, it’s not necessarily the touchy feely question you might think. Rather, I might really be interested in how fast you think you are going.

So, how does that feel?

Poor Uses for Transparency

October 13, 2014


In the Agile world we do a lot of things to try and create transparency within our organizations. We put up information radiators like burn down charts, task boards, and cumulative flow diagrams. We put information up on the walls with sticky notes everywhere you turn. We have team synchronization meetings every day. There’s a lot of information flowing around, so is it even possible that transparency can be misused? Is it possible for transparency to go wrong?

In most cases, I think my default answer to this question would be “no” – in general, I’ll take transparency anytime. However I have run across a few situations with transparency that have made me tear my hair out. There are three different cases that I’m thinking of: Frequency of request, Lack of Decisions, and Missing the point: value.

Updating status information on a regular, even frequent, basis can be useful – especially if the work is high priority. However, there is an upper limit beyond which frequent reporting becomes counter productive. It’s one thing to update status once a week, but when it becomes once a day, something has gone wrong. I’m not really sure that there is a discrete boundary beyond which the reporting becomes too much. All I can say is that you know it when you cross it. The problem is, it ends up creating more churn than productive action.

Transparency isn’t all that useful if it doesn’t lead to meaningful action. A lack of decisions is usually an indicator that there is dysfunction that the transparency is not helping to address. In fact, what you are probably finding is that you are only getting superficial transparency. The question is, why aren’t the decisions getting made?

Finally, transparency is only effective if it helps to understand how the organization delivers value. Often times transparency focuses on things that don’t reflect business value. This is missing the point of transparency. It needs to remain focused on the business value.

Broadcast Communication

September 27, 2014


In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.

What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.

Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.

Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.

There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.

A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:

  • The Scrum of Scrums or other program or portfolio meetings
  • Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
  • Attending other forums, other teams status meetings
  • Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.

If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.

Pervasive Language

August 14, 2013


I was watching a movie with my brother the other day and the rating warning came up, “Rated PG-13 for Pervasive Language”. I found myself scratching my head and wondering: what the hell is pervasive language? Maybe the people in the movie are going to talk a lot? Perhaps it’s just two guys talking to each other like in “Dinner at Andre’s”? I couldn’t help thinking, “This is going to be really boring…”

Actually I’m kind of an expert when it comes pervasive language. You see I’ve got kids and they never seem to stop talking. I go to Agile conferences, and brother do those folks ever talk a lot! You just can’t shut those Agile people up. That’s what we mean by pervasive language, right?

As a sailboat racer I’ve heard an awful lot of pervasive language (of the pirate variety). You hear it out on the race course all the time. It  is interesting to see the way the quantity of dialog changes based on the experience of people on the boat.

New/Green crew – There is an awful lot of talking going on:

“Get the sheet!”
“No, the other sheet!”
“It’s right there in front of you!”
“No, not you, damnit!”

The chatter is virtually non-stop and it can easily escalate to screaming when there is a little stress. The language is certainly pervasive. It is all about how to do the work and very little talk about heads up thinking about strategy or weather. Being on a boat with a new crew demands a lot of patience and a huge amount of talking.

Old timers/Experienced crew – There isn’t much talking at all. There is never screaming on these boats. It’s like everyone on the crew is part of a collective Vulcan Mind Meld. Everyone just knows what to do. When something changes, the whole group knows exactly how to react with a minimum of information exchanged. When there is discussion, it is strategic in nature, “The wind looks better over there…” These are the teams that just quietly and efficiently kick your ass on the race course.

It strikes me that there might be similar patterns of communication on software teams.

New teams have a lot of chatter as they go through the usual forming, storming and norming patterns we have all come to know and love. There are lots of questions and debates about the way things are done, who is doing what, how the work is done, etcetera. Cram all these people together in a common room and you have a recipe for some real noise!

Older, more experienced teams are much more likely to be quiet workers. I’ve worked with some teams where you would walk into their room and all you would hear is the ghostly clicking of keyboards. Everybody was deeply engrossed in their work and making progress.

Of course there are exceptions to these rules. There are teams that are just naturally composed of noisy, gregarious people. Others are naturally quiet. But the broad generalization does seem to hold true.

Now there are some times when you will hear the experienced crews/teams become noisy: When they are learning something new. Introduce a new element that they haven’t had to deal with before and listen to the chatter level rise. It might be caused by the introduction of a new team member or perhaps a new tool (like a new asymmetrical spinnaker). Once we are kicked back into learning mode, the need for communication on the team rises dramatically.

The point I’m trying to make here is that the level of communication that teams engage in is heavily dependent on things like experience and context. Don’t make the mistake of judging a team’s communication simply by how pervasive the communication is (it is equally foolhardy to judge a movie for the “pervasive” quality of its language). Experience, culture, context and personality all play important roles influencing the ways teams communicate with each other. Even beyond all that, there is the question of the quality of the team’s communication.

So what kind of noise is your team making? A roar? A whine? Or are they just humming along?


The New Science of Building Great Teams, Harvard Business Review

What I Learned From My Daughter’s First Grade Classroom

September 10, 2009

The new school year is beginning and my daughter is starting first grade. I had an opportunity to go to her elementary school open house the other day. A word to the wise: never let an Agile development geek into a first grade classroom. I thought I had died and gone to information heaven. I took a camera with me and took some pictures of the kinds of information that they put on the walls in a children’s classroom. It was amazing! In the meantime, my wife fervently denied that she was with the dork taking all the pictures of the walls. Here’s what I discovered before I was escorted from the building:


The first grade classroom is the prototype for a learning environment. These folks are the undisputed masters of the information radiator.  Everywhere you look there is information being displayed. The variety of different kinds of information displayed is amazing! The density of information here is incredible! In one corner of the room I see the following information:

  • Monthly calendar
  • Weather graph
  • Password(???)
  • The alphabet
  • A tally of how many days they’ve been in school
  • Numbers from 1-10
  • Days of the week
  • A chart of all numbers from 1-200
  • A list of who has lost a tooth (Try that on your team! If the number is greater than five, you may be working in a biker bar)
  • And a few other things I can’t quite interpret

What else can we see going on here? Well for one thing, there is LOTS of color. It catches the eye, calls attention to certain details, and livens things up quite a bit. It’s like an interior decorator went nuts in the place. Next, you may observe that much of the information is presented using multiple modalities. Multiple modalities? OK, they use pictures AND words AND color AND shapes. A lot of effort is being made to transmit information in a variety of different ways. Now, just for giggles, what if you were going to put together this exact same board for your team at the office? What would it contain? Here’s how I might do it:

  • Monthly calendar – team vacations, releases, events, barbecues
  • Release graph – How many releases per week are we doing?
  • Word of the day (“Spurtle” – yeah, it’s a word)
  • A quick reference containing all of the major Ruby commands (pick your API/Language, etc)
  • A tally of how many days they’ve been working on a project/sprint/release
  • Numbers from 1, 0 (hey, it’s computer science, you only need two numbers!)
  • List of major business holidays (they always sneak up on me)
  • A chart of all error codes used in our project
  • A ladder of World of Warcraft names/rankings

Hmmm. That’s actually not a bad list. Give it a little color, play with the “modalities” and I just might have some pretty compelling information there. I wonder what else the first graders have to teach us? How about this:


I see at least three things here that I could try out with my team back at the office. First, there is information about today: we have the date, and then  below it is the day’s schedule. Now, I don’t know about you, but back at the office, I don’t have anything like a daily schedule posted on the wall with my team. We all have outlook, and perhaps some would say that’s enough, but for me it’s not quite the same. Outlook reflects MY schedule, not the team’s schedule. And there are significant team events that could use some advertising: Planning meetings, releases, retrospectives, reviews, scrum of scrums, and so on. I know that where I work, everyone is left to their own devices to manage these things and show up or not. Nothing wrong with that, but what if we had a daily schedule, a reminder if you will, that sat next to our task board at our standup meeting? Frankly, I think it might be useful. As a scrum master, it might be a way for me to rather subtly remind the team of the big commitments for the day. Or not.

Let’s move on from the schedule stuff. What’s up with the bottles of ketchup, mayo, and mustard? OK, it may be a little cheesy, but if you look at the image closely you will see that these are clever little symbols for “Catch-Up”, “May Do”, and “Must Do’s”. Do you track Catch-Up work on your team? No? Me either…wait a second…we do keep a list of technical debt. Isn’t technical debt a kind of  Catch up work? So keeping that list of catch up items makes a lot of sense to me. Also, the “May Do’s” and “Must Do’s” make a lot of sense to me as well. I think that defining work as “Must Do” will help the team prioritize the work that is most important (assuming you don’t abuse it) and the “May Do’s” gives the team the ability to identify the things that are available to be pulled on their own initiative. Adding may do and must do to a team’s daily activities would certainly be interesting to try out. I can see pros and cons to doing it. Maybe we could even use these criteria to categorize our backlogs? It’s a possibility…

How about the noise level trumpet off in the corner there? In the wonderful Agile Open Space that you work in, do you ever have issues with noise? Here is your answer! I wonder how well that actually works in a room full of first graders? OK, I’m not going to give them grief for this – it’s probably an experiment.

Here’s another gem that I captured before being chased out of the room by a rather menacing looking old battle axe with a broom (where DO they get these people?):


Would you look at that! They use the “Fist of Five” in first grade too! I was wondering where that technique came from! I need a copy of this poster for my team!


Ooh! Look here! They are graphing their moods over time! Cool! I’ve seen other teams do this, but I’ve never tried it myself. It seems like an idea with some real merit. It certainly makes sense to track the teams mood. It would be very interesting to review information like this at team retrospectives. It would certainly provide an interesting metric to compare against recent “improvements” or other team experiments. One other thing I want to point out here: these teachers seem to think that these information radiators are so important that they will try and cram them just about anywhere! Anyplace is game: the backside of a bookshelf, the side of a locker, the face of a cabinet – any place they will fit. Look around your office. Are you using all the space you have available?

Here’s a quick challenge: So what do you think this is?


Well, as my daughter ever-so-patiently explained to me, this is their “Job Wall”. I like the beehive image – after all we Agilista’s like to “swarm” don’t we? It seems that everyone has regular tasks that they are responsible for. These are tracked here. I like the way it makes responsibilities explicit for everyone involved. It makes me wonder where the teachers get all this stuff? Of course if I were to show up with this silly little beehive, I’m pretty sure that the team would laugh me out of the room. Of course that never stopped me in the past…

You know, if they ever  lift the restraining order and let me back on school property again, I’m definitely going to take some more pictures of the classroom walls. How come more offices don’t look like this? Why aren’t the environments we work in as information rich as the ones that children work and play in? I presume that in the office we are learning too, right?