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

Witnessing Craftsmanship

September 23, 2013

GreenPainter

Recently we hired a painter to do the exterior of our house. At the time I thought we had simply purchased the services of a painter, however I soon discovered that we were getting something more. We were getting a tutorial in the fundamentals of craftsmanship.

It all started with the first day of work. We had contractors working on an addition to the house. They would typically show up around 8 in the morning each day and work until 5. Our painter however, was different. He would show up at 7 AM and work until 7 PM in the evening. This guy had the work ethic of a Clydesdale. Now I’m sure he was pushing himself hard, but it wasn’t like he was griping about the long hours. In fact, he seemed completely focused on one thing – making sure he was doing the best possible job. He wasn’t asking “Am I done yet?” rather he seemed focused on “What more can I do to make this job perfect?” It was obvious that he took a lot of pride and satisfaction in his work. Unlike a lot of the other contractors, he did all of his work alone.

patches

He started with prepping the house for the paint. I figured he would give the siding a quick power wash and then get right to it. Maybe take a day. Instead, he power washed the siding, then he got out the filler and proceeded to methodically fill every crack, nail hole and imperfection he could find. Then he took another day to meticulously sand all of the patches and anywhere there was a hint of an imperfection. Three days and he never even opened a paint can.

Now, I don’t know a damn thing about painting houses. Maybe everybody does it this way, but I have to say I was mighty impressed. Every day he would show up before everyone else, and every day he would work longer than anyone else. He was focused to the point of myopia. And he was a pretty nice guy. Weird.

When he finally got around to putting the paint on the house, the results were spectacular! Lines and borders were crisp. Everything was carefully taped off in advance. Ground cover laid to catch spills. Again, the preparation was immaculate.

Now it’s not that he didn’t make mistakes. He did make mistakes. When he made them, he called them out and knew exactly what to do to fix them. He didn’t try to hide them or avoid them in any way.

OLYMPUS DIGITAL CAMERA

Now it was pretty obvious watching this guy, that he was achieving what we might call a state of flow. He was focused, challenged, pushing himself and in the moment. I remember watching him and feeling envious. To be that confident in your work, and able to get into that zone is absolutely amazing.

It’s certainly not where I live. I’m in meetings all day long. When I’m not in meetings I get interrupted every 5 minutes by people who were waiting to get my time – because I was in all those #$%^& meetings. My experience is not one of flow. I never get the time to focus. I seem to be progressively working myself into a raging case of attention deficit disorder.

Watching this guy I started to get an intuitive feeling for what that mysterious “Craftsmanship” thing might be all about. I wasn’t about to micro manage this guy. I guess I could have stepped in and told him to spend less time on prep. You know, “We don’t need any of that puttying and sanding! Just powerwash it and start laying down some paint! That’s what I’m paying you for! Not for farting around with putty and taping every last corner exactly right.”

To go that route would have been crazy.

No, what I was seeing here was some sort of relationship between craftsmanship and flow. This was a guy who was uncompromising in his drive to excellence. He painted our front door, then let us know that he’d probably over done it. It was Friday afternoon. Sure enough, as the paint dried there were drips and runs. So what does he do? He shows up at 7 AM on Saturday morning and proceeds to sand down the entire door by hand. Then he repaints it all again – perfect this time. We didn’t ask him to. He told us that’s what he needed to do. I was happy to pay for that kind of quality. It was amazing.

So the $64,000 question is, what would that kind of craftsmanship look like in software? Pick a role, any role: Developer or QA? Scrum Master, Product Owner, Project Manager, or just plain old Manager.

I used to work with a developer who delivered absolutely amazing work. You would sit down and discuss the requirements with him and then he would look at you and say, “Give me a couple of days to do some research and then I’ll start writing some code.” And that’s exactly what he would do – he’d spend all day for 3-4 days just reading books and researching the topic and examples of the code he had been asked to write. Think of it as the prep work – understanding the problem, looking for issues, asking questions, researching other approaches. It’s really not a whole lot different from prepping the house for paint. Power washing the walls, sanding, patching, taping and generally preparing for the work to come. Setting things up to go smoothly.

And once this developer finished his prep work he would write the code in record time, complete with unit tests! It was tight, concise, and easy to read. You could tell that he had taken the time to understand the problem deeply. Objects and methods were clearly named and made sense. The whole thing was elegant. And he delivered! Nobody messed with him. You don’t look at a guy like that and say, “Geez, I really need this fast, can you just hammer it out without doing any research.”

Well, to my undying shame, I actually did that. And I got the answer that I deserved,

“No.”

Asking him to It was like asking him to not wash his hands after going to the bathroom. He had found a way of working that delivered quality that excited his customers. He wasn’t about to compromise that just because some project manager wanted it faster.

I worked with a scrum master who would spend hours preparing for a sprint planning meeting. His mantra was that you should spend twice as much time preparing for a meeting as you do actually attending the meeting. His meetings were meticulous. Often times he had done enough work with the stakeholders in advance that the entire meeting was really just a chance to recap the decisions already made and seek final sign off. To him, a successful meeting was the culmination of many hours of prep work. I think of this as the craft of facilitating a good meeting. Ask him to slap it together faster and he would look at you and ask, “Why bother wasting time on a meeting at all if you aren’t willing to do the legwork?”

Good question.

I believe that at some level there is an element of craftsmanship that can be found in most work whether it is manual labor or knowledge work. I think we all would benefit from finding that craft in our day to day. It offers us the opportunity to find flow in our work, to take pride in what we do, and ultimately to delight our customers/stakeholders.


How I Discovered “Gordon The Guided Missile”

June 18, 2009
Alastair Cockburn gave the opening keynote speech for the conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:
If you live in Utah, you are very lucky to have a high powered group like this around. You can also find likes to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!
Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here: http://www.contextmag.com/archives/199806/innerGame.asp?process=print
The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.
Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I love creativity. Maybe that’s why I like software development so much. Writing code, what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.
So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:
1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.
2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.
3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.
The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!

Fireworks_Rocket

Alastair Cockburn gave the opening keynote speech for the Agile Roots 2009 conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:

http://alistair.cockburn.us/Salt+lake+city

If you live in Utah, you are very lucky to have a high powered group like this around. You can also find links to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!

Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here:

http://www.contextmag.com/archives/199806/innerGame.asp?process=print

The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.

Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I absolutely love creativity. Maybe that’s why I like software development so much. Writing code – what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.

So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:

1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.

2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.

3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.

The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!


Agile Planning Tools Revisited

May 28, 2008

Since my last post listing Agile planning tools a few more have come to my attention including:

Check ’em out. Thanks to those who helped by pointing me toward these products – I appreciate it!

Happy Planning,
Tom