Steve Yegge is definitely one of my favorite writers, because he makes some really good points, and in interesting ways. But I have to admit it’s usually full of a lot of blind spots. If he were asking me (he’s not) whether he should mellow out, I’d say no because in despite the blind spots, his rants are probably the most effective route from point a to b, for him. I think that’s because he’s not a zealot, and is willing to flip-flop his opinions several times while trying to find the right solution. Either way, when you see of these blind spots, you gotta yell “car!”

So why am I writing all this crap about someone else’s writing? I mean, in all likeliness I’m probably just as bad or worse in some other way, or maybe the same way. Well today, it’s because of his most recent post, Good Agile, Bad Agile. On the good side, he reminds anyone who forgot that there is a bad version of almost everything. He also points out many of the more risky Agile practices, like abuse of iterations as a recurring death march tool, or as an excuse to leave refactoring for time boxed iterations.

XP actually cover both worries, with the principles “Sustainable Pace“, and “Design Improvement”. Of course, those can be ignored, and according to Steve often are. He goes on to compare Agile to Google’s process, which certainly sounds very interesting. But Google’s not your average company, and just like Agile itself, there is no guarantee that if someone tried to export those practices to another company, that company wouldn’t screw it all up. There are several parts of those practices, at least today, are impossible, highly difficult or outrageously risky for any organization not in Google’s class.

Take the work queue he wraps up the description of good Agile with. Sounds cool, but I don’t see it on the market, and until it is, I don’t see any company without lots of “hand-wavy” math types putting a similar internal app into service. And I think that piece is critical to the whole system to provide some balance to the chaos factor of the other freedoms.

It sounds a lot better than index cards, but index cards in many ways area better than the project management software on the market today. I’ve seen a number of these and amazingly, they haven’t even tackled what should have been the first task: making it easy to get data into the system. It takes like a whole hour to enter in a few tasks for the week, and even then, it’s an inaccurate jumbled mess.

Beyond that visibility is generally very low, so that only the managers have a clue what’s going on. Or at least they think they do, because they don’t realize how bad the data is. Beyond being wrong, it leaves out huge gaping holes; and since non-managers never see the data, they never have cause to point out the deficiencies. And so managers make decisions as if that non-measured data didn’t even exist.

The index cards ideas are just a simple way to try to resolve some of these problems, like visibility and ease of data collection. If you resolved them in software then you’d gain the benefit of being able to use all that hand-wavy math, but today the rest of us get the worst of both worlds: no math, bad visibility, and painful data entry.

So, I’ve made a case for “all the bad stuff he described is the fault of the team's execution of the process”, so I might as well totally ignore Steve’s caution and move on to "all the good stuff he described is really Agile". To be truthful, not all of it is, but I have made the case that at least some of it would be very hard for any non Google class company to do alone. And a lot of the rest just might not work without those other pieces, or without the natural enthusiasm Google has from being able to be very selective, very rich, and very famous. It might work, but it’s hardly proven.

A lot of it is Agile, however. And Agile is potentially good. And, yes, if 90% it screws up it’s bad.. unless of course your comparing it to a process that screws up 95% of the time. In that case, it’s the most amazing thing since sliced bread. It does however mean that you need to pay attention to what you’re doing, don’t take things for granted, and always try to improve your process. And as far as bad Agile goes, well I’d say even the most questionable practices, like pair programming have value in moderation.

Even if taken to obsessive extremes they’re better than the other extreme. It might seem wasteful to tell half your staff “thou shalt not code”, but it’s a lot better than telling half your staff, “thou shalt analyze”, and the other half “thou shalt copy badly written documentation into badly written code, with no understanding of the real problem.”

So, for most organizations, it’s not a choice of good Agile vs. bad Agile, but bad waterfall vs. try your best Agile.

I can identify with Steve’s desire to separate out some of the technology aspects, like unit testing, continuous integration, refactoring, out from the process part of Agile. In many cases they are a lot more difficult to screw up so it’s nice to show that distinction, but a lot of the process practices are intended to help adoption of those practices, and to keep them in place, so you can’t really get the Agile people to drop em. At best, you could come up with a new group, like “The Workable Code Movement™”, that’s a subset of practices if that’s what you want.