We Need a Map

February 12, 2017

map

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

Advertisements

The Corn Maze Strategy

October 10, 2016

nature-field-sun-agriculture-large

Today was our annual family visit to the pumpkin patch. We go to a local farm that is a sort of pumpkin theme park. In addition to the fields of U-pick pumpkins, they have a petting zoo, pumpkin launchers, halloween themed play structures, hay rides, and a corn maze. It was a beautiful early October afternoon, and the kids roamed through all the usual activities. Finally we got around to the corn maze.

Now you should know that as these things go, this corn maze is pretty decent. I have no idea how large it really is, but my fitbit tells me that it’s at least a few thousand steps or so. I would guess it’s a walk of a mile or two to get through it. You should also understand that it’s relatively robustly built. You really can’t see any nearby landmarks, and the paths are kept far enough apart that you can’t see other adventurers in the maze. So it’s really quite easy to get good and lost.

So I followed the family in and tagged along behind as we made our way through the maze. I was tired, so I was perfectly happy to let the kids make all the decisions and accept the consequences. The pattern usually went something like this: We would come to an intersection and pause. We would look for clues on the ground. Was one path better travelled than another? Did the curve of the path look like it might actually form a loop? Did the path head in a direction that we thought might be the correct destination? We would ponder these questions and consult as a family before moving onward. So some sort of consensus was arrived at as we reached each intersection.

As I stumbled through the maze following my family, lost in my own thoughts, I started to observe how we were making decisions as a team. At each intersection there was usually some sort of debate. Arguments were made for and against different options. The group would informally arrive at a decision. We had the advantage of multiple brains rather than just one, so you would expect some sort of multiplier effect from using those additional noggins. But it really didn’t feel that way.

Instead we were bouncing around the maze, wandering into loops and blind alleys, and as far as I could perceive, we were not much more successful than someone walking the maze and flipping a coin to decide which direction to go. It was quickly becoming apparent that our success rate was hard to discern from a completely random performance. In fact, at some point I joked that we should be using a 20 sided dice to determine our next move. Geek family.

As we came around a bend I saw another family just standing at an intersection expectantly looking down the path like they were waiting for something. The father came running into view from further down the path and I heard him say rather breathlessly, “There’s nothing down that way guys.” We moved on and I couldn’t help but wonder about that approach. That family was using an interesting strategy. They were obviously making an effort to collect some information about the maze before moving on. That seemed to be one level of effectiveness beyond what we were doing. They were trying to look ahead and gather some intelligence that they could use to help make a better decision about the direction to go in the maze.

We continued to ramble about, but it was soon apparent that the kids were starting to get tired. My wife indicated that it was time for us to bring the adventure to a close before we had a riot on our hands. Dad, stop being such a slacker, it’s time for you to make a few decisions! So that’s when I had an idea.

At the next intersection, I sent a child down each avenue with the instruction to continue until they come to another split in the path and then to report back to me. Off they went. I figured I had two children, so I could afford to lose one with this experiment and still call myself a parent.

At the first junction, the kids came back and one reported a dead end, and the other reported yet another junction. Well that made the decision easy, so off we went. At the next junction however, both kids reported the same thing – there was another junction, but no indication beyond that. So it appears that my look ahead strategy had it’s limitations. There was only so far we could see ahead in the maze using my one intersection strategy. So we flipped a coin and moved on.

At the next intersection, we had a choice between an intersection and an obvious milestone, so we continued toward the milestone. A few more choices like that and we found the end of the maze.

As we celebrated and headed back to the car, it occurred to me that wandering through a corn maze is not all that different from the way that we work on projects as teams.
A project has a lot in common with a corn maze. In principle we all know how they work, but the path from start to finish isn’t all that clear when you start (oh you may THINK it is clear, but let’s face it, there are a lot of unknowns). So you kick off your project and get started and before too long you have to make some decisions. All too often when we make decisions as teams, we do it on the spur of the moment, using only the information that is immediately in front of us. Just like me and the family in the corn maze. We are only using the information that is immediately at hand. Decisions are made quickly with a minimum of information. It’s little better than a coin toss. But there is an alternative.

We can be gathering information to help us make better decisions. There are various names for this kind of look ahead strategy, personally I’m thinking of “set based decision making.“ In set based decision making you explore multiple alternatives. You look down multiple paths, but you don’t go too far. You are gathering just enough information to help you make a good decision now before you proceed onward. Just like with the kids running forward reconnaissance in the maze. This is how you improve the information you use for decision making, and this is how you give yourself a chance to make better decisions.

You see, projects have many important decisions to be made. You bump into them daily. Go the right direction and you are increasing your project’s likelihood of success, go the wrong direction and the project is that much closer to failure. These are high stakes decisions with lots of money on the line. So using the corn maze escape strategy is a good one. A small qualification is probably in order here: The look ahead doesn’t give you a crystal ball or a guarantee of success.

The point is that we all might benefit from using a conscious strategy to acquire knowledge that can inform our decisions. It doesn’t have to be very much additional information in order for there to be a substantial benefit. So the next time you find yourself on a complex project where you have to make tough decisions, remember the corn maze. The strategy you choose can make your journey a whole lot easier.


Roles Considered Harmful

December 27, 2014

business-businessman-businessmen-222-825x550

“Man’s role is uncertain, undefined, and perhaps unnecessary.” – Margaret Mead

So there I was talking to a team that was split across two locations. There was the usual set of complaints that you might expect from a scenario where a team is divided across geophysical locations: miscommunication, delay, misunderstandings, etc.

In this case, the QA folks happened to be in one location and the development folks in another. As we talked through some of these issues, I couldn’t help but point out that the root cause – that separation between the two groups, could easily be solved: just split into two teams by location. Of course, that would leave us with a team of developers without any QA. Working with dev only teams doesn’t bother me (been there, done that, got the merit badge), but it was a different question altogether for this team member I was talking to. For them, the entire idea of removing a role from the team was completely untenable.

The first objection was, “If we don’t have QA on the team, who will keep developers under control? ”

Whoa! What? Back up the truck!

Who will keep the developers under control? Seriously?

At this point, I shifted gears and started asking questions about the team roles. I was concerned with this QA role that ‘controls’ cowboy developers. Why do we need to ‘control’ anybody in the first place? How exactly do you exert this control? What would happen if you didn’t control them?

It was quite an eye opening conversation. The more I looked at it, the more I realized that the roles of QA and developer had an astonishing amount of baggage associated with them. The QA role is the only role that can test code. The developer role is the only one that can write code. One can’t possibly be trusted to do the other’s job. It would be a lapse of ethical integrity!

Oh my God! Do people hear themselves when they utter this tripe?

Apparently not. No wonder we avoid creating roles or minimize them in some processes (i.e. Scrum, or better yet, swarming). It’s awfully easy to come to the conclusion that roles carry as much dysfunction as they do benefit for a team. They invite definition and structure, but in doing so they also create walls and barriers to effectiveness and efficiency.

As soon as you create a role that is entirely responsible for quality (or anything else for that matter), you do three things:

  1. You define their job, and by doing so, you make a distinction between “the things that I do” and “the things that you do”. It starts to define what you can and can’t do. That’s useful if you are trying to subdivide work. But not so useful if you are trying to create dynamic, flexible teams that adapt themselves to unanticipated changes. You know…Agile?
  2. You create an in-group and an out-group. In psychological terms, you are creating an “us” vs. “them” distinction which almost inevitably leads to conflict.
  3. With these foundations, our thinking is constrained about how the process of value creation should work. The distinctions that we hold in our heads are what we use in order to create the boundaries of our processes. We find these boundaries between Dev and QA, sales and product, managers and teams, and yes, even Scrum Masters and coaches. They’re everywhere.

Obviously, roles can have profound impacts on how people think about their relationship with the people they work together with. So what can we do about it?

As I asked further questions, it became apparent to me where I might go. Talking to the team would be a complete waste of time. They didn’t define the roles. They were hired for the roles that their managers defined. So step one is talking to the managers.

Of course managers are people too. They are only trying to fit in the hierarchy and culture of the company. Eliminating roles would be a very threatening thing to a manager whose whole career has been based on making and supporting such roles. So we can’t expect a whole lot of help from there either.
Of course you could just show them…

There are some talented developers I know, coaches really, who are very good at working side by side with teams and demonstrating by example how to blur the distinctions between roles. You can even do it yourself with other managers. Build those relationships. Help them out. Show them how it feels to have someone else help out that doesn’t have the same role as they do.

In the end, I think it comes down to people being able to experience what not having hard defined roles is like. You can’t talk them into it. You just need to roll up your sleeves and demonstrate with them.

“I’m not playing a role. I’m being myself, whatever the hell that is.” – Bea Arthur

References
Scrum Masters Considered Harmful, Paul Hodgetts
Us and Them: The Science of Identity, David Berreby


Satisfaction

October 16, 2014

As some of you may know, I’m building a boat in my brother’s garage. We had a big milestone the other day: we finished painting the bottom and rolled the boat over to finish the topsides. From a distance it looks great!

Up close is another story though. Up close you can find ripples in the paint from where the fiberglass wasn’t sufficiently well sanded. There are other places where you can see fine lines in the paint due to underlying patterns in the filler compound. Add to that the fact that the paint has rough areas where the roller left a pattern. And don’t even get me started about that flat spot.

I see all of these imperfections and more. It’s pretty rough.
—–
I’ve worked with teams like that too. From a distance, everything looks great. You are hitting your milestones and everyone is pleased.

But get close and you find all sorts of flaws. They’re not using story points. They won’t keep their burn down chart up to date. They don’t even know what an acceptance test is. They’re pretty rough. Maybe we should just keep them in the garage…
—–
But around this time, along comes my brother. He takes one look at the boat and says, “Damn! That’s beautiful!” So I point out a flaw. He waves it off and says, “The only boat without scrapes and dents is in the showroom. This boat is going to sail!” Not to be dissuaded, I point out another flaw. He looks at me and says, “Will it float?”
My answer, “Yes.”
“OK then. Let’s get this thing in the water.”

And so we go back to work, and somehow it is OK. I stop worrying and focus on what remains to be done.
—–
Sometimes someone visits the office. Someone I really respect and admire. I show them around and they say, “Wow, what a great team!” So I walk them over to the story board and point out that it’s out of date. They look at me and say, “That’s cool. Not many people even use physical dashboards.” I tell them that the team doesn’t use story points. They look at me and say, “Does the team deliver?”
My answer, “Yes.”
“OK then. Let’s sling some code.”
—–
And so I’m reminded not to be such a damn perfectionist.
Love your boat.
Love your team.


Hungarian Notation for Teams

October 12, 2014

SONY DSC

Back in the day when I was writing windows programs there was this thing called hungarian notation. It was a form of shorthand that allowed you to add the type of a variable to the name of the variable. It led to variable names like “lpszUserName” that stood for “long pointer to a zero terminated string named UserName.” It made for some pretty awkward variable names, but the idea was that you could always tell the type of the variable, even if you couldn’t see the declaration. It was kind of handy, at least until somebody changed the variable type and forgot to change the name. In hindsight, it really was always doomed to fail for almost any kind of legacy code. Name the variable wrong and you introduce subtle bugs that will haunt you for years.

So there we are looking at a list of teams the other day. They had a lot of interesting things in common. They all have some specialization in a given domain. Often they had different geographic location. We were wondering if perhaps they should have some sort of naming convention applied to their names. That’s when I perked up and said, “Hungarian notation for teams!” If the team is located in Bellevue, then we will use ‘bv’. If the team is in the mobile domain, we’ll use ‘mb’. So for a team named “Viper” located in Bellevue doing mobile development we would have “bvmbViper!” Maybe you have a team that is located in San Francisco ‘sf’ that works on web apps ‘wa’ called “Cheetah” we would have “sfwaCheetah.” Now you can simply look at the name of your team and know instantly where they work, and what they work on.

Genius! Maybe we should do this for people too? I’m an Agile manager ‘am’ who writes a blog ‘bl’. You can call me “amblTomPerry”


Post Mortem Magazine

October 10, 2014

console-controller-games-498-825x550

Years ago I used to read a magazine called Game Development (at least I think that was it). I’ve never worked in game development myself, but I found it fascinating to take a little peek into the world of the game development teams. They were always working on some cutting edge game engine technology that enabled “the next generation of jaw dropping graphics” and some form of ridiculously enhanced gaming experience. At the time it seemed to me like the game developers were very much the real deal – the applications I wrote were childish by comparison. The level of performance optimization they engaged in was astronomical compared to anything I dealt with. The geometry they used to describe the 3D worlds they created was a language all it’s own. It looked like all the cool kids were in gaming.

There was a regular article in the magazine called something clever like “Post Mortem”. Every month they would publish a post mortem written by a project manager or team that had just released a new game. These were not happy-go-lucky-aren’t-we-cool reports. No, these were unflinching, unsparing critiques of all that happened on the project. There was drama, daunting challenges, and total train wrecks. This stuff was riveting!

I used to think to myself, “Everybody should be doing this!” I was already working on agile projects at the time. I was dutifully doing a team retrospective every 2 weeks, but I never got the nerve to publish one. I probably should have, but I didn’t think at the time that our stuff would be all that interesting (in hindsight I have had my fair share of project train wrecks). Nobody else published post mortems either. This gaming magazine was the only place I’ve seen them widely published.

It would be interesting to have a magazine composed of just project post mortems and retrospectives. In a very real way it would be a collection of experimental results. Some of those experiments would be successes and many would be failures, and each and every one of them would be useful.

Of course who would read such a publication? Project Management geeks? Scrum Masters? And what would we advertise in this little catalog of triumphs and disasters? Anti-depressants? Liquor? Well, all kidding aside, I really do think it would be useful. Of course nobody makes magazines anymore. It would have to be a blog or something. Not a bad idea really. Hmmm…


A Team Named “Sue”

October 8, 2014

Johnny_Cash_(1964)

My daddy left home when I was three
And he didn’t leave much to ma and me
Just this old guitar and an empty bottle of booze.
Now, I don’t blame him cause he run and hid
But the meanest thing that he ever did
Was before he left, he went and named me “Sue.”

-Johnny Cash, A Boy Named Sue

I love this song. It makes me chuckle every time I hear it. Its a story about a man who names his son “Sue” because he knows it will be the source of mockery and make him into a stronger man. It’s a tongue in cheek little rhyme that covers themes of fathers, sons, manhood and what’s in a name.

Today I was looking at a list of team names. Every single team in the list had named themselves after whatever they were working on. For example, there might be names like Printing Team, or UI Team, or Database Team. And check this out: if there was more than one Printing Team, guess what they called the second team? You got it: Printing Team 2.

I shook my head and thought to myself, “Who named you Sue?”

Right off the bat, I have to confess that I’m really a bit mystified by this kind of behavior. I refuse to believe that a normal human being, not coerced by any outside force, would name themselves after whatever they are working on. I’m working on a Mac right now. Maybe I should change my name to Mac too…nope…not gonna do it. It doesn’t make any sense to me (and I’m not really Scottish). I would rather name myself after something fun or aspirational. I’d use things like:

  • Mountains (Team Everest, Denali, or K2)
  • Animals (Team Angus, Viper, or Gerbil)
  • Cartoon Characters (Team Mickey, Goofy, or Donald)
  • Tools (Team Hammer, Bandsaw, or Monkey Wrench)
  • Rock bands (The Police, Metallica, or Tower of Power)

The possibilities are endless…just like my cliches. Often I think that a team is either intentionally or unintentionally given a name by those who are sponsoring or responsible for setting up the team. After all, early in a project, before everyone shows up, you need a name for this new thing. Often this name is used purely for utilities sake, perhaps with the assumption that the team will replace the name with one of their own. The team adopts it by default, because that’s what everyone else calls them, and they never bother to change it again.

I’m sure there are also places that just tell teams what they want them named. Hello, welcome to Acme! We’re going to put you on team “Sue”. I think that’s ridiculous. Here are my rules for team naming (don’t worry, no one will adopt them):

  1. You can’t name yourself after what you are working on
  2. No one individual can name the team. The team must name itself

If you want someone to feel empowered and respected, you really need to let them decide what they are going to be called. If you can’t even do something as trivial as that, then you are probably going to struggle in other areas too.

So what are your rules for naming teams?