The Guy

So I read the book. Nice book, but I'm sorry, there weren't fireworks or any of that. In fact, I found some of the points in the book to be a little pedantic, some seemed ill-informed, and some seemed naive. I'm sure Paul is a great guy and he's obviously a qualified writer (We "in the know" call him PG) but he's just another schmuck like the rest of us, trying to figure it out as he goes along. That's not meant to be demeaning -- if anything, I enjoyed the book because of the friendly, pedestrian tone of the material. It was great to read about startups and programming. I felt like I was sitting across the table chatting with the guy.

But what was interesting was the way in which some of his readers treated him. It was as if he were some sort of demi-god of startups. During the application process, posters went out of their way to praise him and defend vigorously any sort of perceived attack against him.

I thought it was just sucking up -- hey, people do it all of the time. It's a contest to get into this startup program, and folks are just sucking up for positioning. But lately I've begun to feel that many folks in IT just want somebody to give them a list of instructions to follow. They want a hero -- somebody more than a mentor. They want The Guy.

I am currently consutling with a large company in the midwest. They have about 8 thousand IT people on staff here. I'm supposed to help them form and implement agile and fast programming teams. So I started reading up on where they were and talking to folks. Remember that the problem they were trying to solve was that over time they had created too many checklists, forms, committees, and processes. In response to that, a new bunch of rebellious internal turks had jumped on the XP/Agile bandwagon, and the company has decided to go with Scrum and some kind of Agile, details to be worked out later.

The first thing I notice is that people talking about process have an incredible tendency to quote authors and books. It's something I've probably seen before but never noticed. You won't see an email that says "Hey! Let's do X to fix that!" Instead, you see something like "Famous author X says that you should always do it like this."

It's almost like a fetish for people who are able to write books. Oddly enough, when I go back to the source material (usually agile/XP books), those authors are doing the same thing! It's enough to believe that good ideas are limited only to those that some author had in a book published, not things that teams can and should come up with on their own.

To further illustrate this point, I'm talking to a really smart technical coach yesterday. Another person asks him, "What about critical path? If the software development process has fewer controls and constraints, what about the ability for management to see where the critical path lies?"

His answer, and I paraphrase, was that they had posed this same question to famous author X. Famous author X said that he had thought and thought about this, and finally concluded that it was a function of trust. That is, companies should completely and absolutely trust their teams. If they did this, then the issue of critical path would go away -- you wouldn't need to have one.

This struck me as a pretty big non-answer. First of all, nobody trusts anybody completely. So that's a non-starter. The answer to the question was to pre-suppose a world in which people didn't have to worry about the answer? Building idealistic imaginary worlds is easy. Getting reality to conform to them is another thing entirely. This wasn't an answer, it was a slogan.

So I simply said something like "Playing devil's advocate, if companies trusted teams completely, they'd just give you a check and ask you to come back with working code. That doesn't sound like it's going to happen anytime soon. I mean, it doesn't sound very practical."

But the interesting thing was that, in response to a valid question about how/why to do something, the answer consisted of appealing to authority. Such-and-such has thought about this problem and he says X. No further analysis is needed. It's been thought about by a famous person. We can just take what he says as gospel. We don't have to have ownership over analyzing and figuring out how to work this -- after all, author X knows all and sees all.

What's even funnier is that now the agile implementation team is doing the same thing to the company as the old, waterfall implementation team did. They're looking for a magic guy, a magic list of instructions, a way that things have to work. They've got the idea that processes should be non-prescriptive. They've got it so much that they're telling folks exactly how projects should work! They're being prescriptively non-prescriptive!

If it weren't so sad, it would be funny. Yesterday in one of the team retrospectives they pointed out that nobody updated the burn-down chart. "Well, then why use it?" I asked, "I mean, if nobody is updating it, that means nobody is using it. No point in continuing to do processes that have no value to the team or the organization, right?"

I got sort of a bunch of blank stares, and then the general impression from the group that of course, we have to make burn-up and burn-down charts! Author X says so! Our non-process process says we must do this.

Maybe I'm just jealous because I'm not the guy. Maybe I don't understand the deeper details of what's going on. Maybe people need order and lists and structure, even when they realize that software development can be an emergent activity. Maybe there will always be The Guy.

Perhaps a little hero worship can be a good thing. Or perhaps not.