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.

The Corn Maze Strategy

October 10, 2016


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.

Open Agile Management 2016

August 12, 2016


This September 16th we are going to hold a brand new conference in Seattle. It’s a conference dedicated to Agile Management. It’s for managers, executives, coaches, consultants and leaders (lots of folks!) who use agile practices and techniques to help organizations find a better way of working. If you read this blog, that’s probably you. This conference is intended to create a place to have conversations with leading agile practitioners, share stories, and explore new ideas.

The Vision

When you arrive, the first thing that strikes you is the sense of history in the building. The next thing that stands out is the circle of chairs. They’re right in the middle of the space and they seem to draw you in.

People start to filter in, some grabbing a cup of coffee and a pastry. Some chatting and exploring the space. Soon, everyone gathers at the chairs and grabs a seat. Things get kicked off with a short keynote from Ray Arell. It’s really just a story. A fireside chat. Sharing an experience – sharing the theme for the day.

Shortly afterward, the open space bulletin board opens and people add their topics. The marketplace opens and the conference starts in earnest.

The marketplace wall is the focal point for a series of conversations. It starts off in the morning being completely blank. They started off with a set of proposed ideas – each idea written on a colored thought bubble. The thought bubbles were taped to the wall. Throughout the day, people connect the bubbles using yarn. Or they add new bubbles. Runners keep the wall up to date, moving back and forth from ongoing conversations.

At the end of the day there is a synthesis. The participants use a single sheet of flip chart paper to summarize their favorite ideas. Working groups form, emails are shared, agendas proposed, and meeting times set.

In the evening, there is a closing, a retrospective, and appetizers and drinks.

That’s not a bad vision, but all of that just captures the superficial stuff. The stuff that we can control. The rest? Well, that’s the “open” part of open space. I don’t know what people will bring. What I do know is it works. I never fail to be surprised.

Event Overview

When is it?

Friday September 16th, 2016 8:30 AM to 7:00 PM

Where is it?

AXIS Pioneer Square, Seattle

Where Can I Find Out More?

The Open Agile Management Website


Roles Considered Harmful

December 27, 2014


“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

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

Keeping It In the Family

October 16, 2014


I was asked the other day, “Do you use Scrum at home?” It’s not the first time that I’ve been asked this question. The honest answer is: no. Oh, I’ve used bits and pieces here and there. I’ve put together a taskboard to track work on the occasional big household project. I’ve even built a backlog from time to time. But that is about the extent of it. I’ve been married for nearly twenty years – I’m not about to screw it up with Scrum or any other method for that matter.

You won’t find me standing around with the kids doing a daily standup. There is no weekly planning meeting on my family calendar. And the only retrospective that I do is after getting caught leaving the toilet seat up (“Doh!”). Nope, I’ve got to be honest, my household isn’t very agile.

You might ask, “Why not?”

Dang, that’s a really good question. I’m not sure that I have a good answer. Maybe I just want to leave all that stuff at work. But if that were the case, then why do I go home and write this blog? No, that’s not it. Maybe there really has been no structure modelled in my family life before. In fact, the very idea of doing that kind of “work” at home makes me cringe a little bit. I guess I feel like we have things under control. Maybe I don’t even want that control. It’s really hard to say.

I think there is value in sharing the practical time management techniques that I use at work with my kids. I didn’t hesitate to introduce them to pomodoros when my daughter was struggling to stay focused on her homework. It felt really good to be able to introduce her to a tool that would help her be successful. She loves pomodoros! The kids like all the fooling around that I do with self-experiments around the house (“Hey! Look at Daddy!”). They always want to know what kind of nutty thing Dad is doing this week.

However, I’ve never felt a compelling need to have any kind of formal family meeting at all. Call me a bit waterfall. I guess when it comes to my family I only want to give them the techniques that they need for the problems they have. I don’t want to burden them with a framework. Got a problem with focus? Use pomodoros. Does the problem seem too large? Break it down into stories. No progress? Try iterating.

When I can provide a helpful technique that solves their problems (agile or not), I feel like Superman. Seriously folks, there is no better feeling in the world. There is no preaching. I don’t lecture them on the perils of waterfall. To my kids a waterfall is something you ride a log down at Disneyland. I aim to keep it that way as long as possible.

I guess, in retrospect it’s not such a bad approach for introducing agile practices for anyone, regardless of whether they are in your family or not. In fact, why would you treat a team any differently than your family? Aren’t they just that – your extended family? Can we use this to inform how we approach introducing Agile Practices to our teams?

Maybe we just introduce them to the tools they need to solve the problem that they have in the moment. Perhaps that’s how we start. That’s how we demonstrate value and earn trust. Not by dumping some framework they must comply with on their heads.

Hmmm….I think I’ve been doing it wrong.

Introduce agile practices to your team like you would to your family. Give them only what they need and let them figure out the rest.


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.

A Team Named “Sue”

October 8, 2014


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?