Running as Root

I was reading a short post on Herding Cats about project management being about finding the truth. There are quite a few other good posts on there that follow the one I mentioned. It sounds like the author has a pretty sensible approach to most project management problems.

The reason the "search for truth" post struck me is that on nearly every project I've been on someone (most often either the product manager or upper management) has at some point been in heavy denial about the various risks to the delivery of the software. Anywhere from thinking that although we've been behind on every milestone, we'll somehow make it all up at the end (and keep 100% of the functionality). The "maybe the bad things won't happen" approach to risk management, which is just risk ignoring, has allowed too many projects to spiral out of control and ultimately caused way too much unnecessary "crunch mode" and developer unhappiness in my life.

I hate to always point the finger outside of development, but it's the way I think. My anecdotal experience is that the ball droppers are almost always in management. That's why competent managers that address problems in a realistic way evoke such a sense of loyalty from me.

I just read a nice little post called Making the Date. It's about correctly managing your software development situation to make a date. It's full of nice little analogies that non-IT people should be able to get, but probably won't. I find it funny that so many places have an "IT problem" in terms of getting good software on time and on budget, especially when so many developers are telling them the exact problem and solution. It also has a couple of items on what the manager should be doing in the process. It's a good little read.

I just finished reading a short article named Are Iterations Hazardous to Your Project? by Alistair Cockburn. In the article he points out a few issues about how Agile methodology vocabulary can be used to disguise Waterfall practices as well as some pretty good points arguing for longer iterations within Agile (a subject near and dear to my heart). I definitely "smell what he's cooking" and I like his suggestions. I particularly like his example of test driven development.

Part of the problem I've been experiencing first hand is being part of an organization that is trying to move from a classic Waterfall methodology to Agile. I don't think this is the kind of change that happens overnight. In fact, I think it is necessary to first transition to an iterative, mini-waterfall approach. This is an immediate improvement in my eyes. The danger seems to be that, because there are instant benefits, people get overly comfortable and begin to believe that they're truly doing Agile or XP just because they're using the "right" vocabulary to describe their practices. They lose site of the fact that they need to iteratively improve their process just as they do their software. Sure, they go through the motions, but ultimately they come to rest at a point well short of a goal the would bring much greater benefits. It'll be interesting to see if my place of work can break the inertia of complacency.

I love layoffs as much as the next guy, but maybe you should never lay off 100 percent of any given team if you're ever expecting to do anything with the product for which they were responsible. Sure, all of those other competent people at your company can take over their duties (while they're not looking for a job elsewhere). Oh wait. You cut a bunch of corners and/or planned to do that "later" so there's a bunch of stuff that's not documented? It's just been handed down in tribal stories while the programmers sat around the warming glow of the monitor and smoked peace pipes? Oh yeah. You're boned.

That's one of those little details I've seen overlooked many times. The cost savings of cutting 100 percent of the team (and possibly offshoring their jobs) is less than cutting everyone except one of the guys that knows how shit works. I still prefer valuing working software over documentation, so I don't think the answer is to exhaustively document stuff. It's just to be aware of what is and isn't documented and plan accordingly. Just a little something I was thinking about today for no reason in particular…