We all think Scott Adams has worked in our offices, given how often conversations between Dilbert, his co-workers, and his PHB (pointy-haired boss) seem like conversations we've just had. I remember some discussions with management about metrics; the very next Dilbert strip read like someone had recorded our conversation.

Today, Dilbert's PHB paraphrases agile programming to mean "no more planning and no more documentation." The PHB directs the team to "just start writing code and complaining."

That's precisely what many people think agile to be. It's why I often curse the notion of big-A "Agile." Buzzwords almost always end up suggesting equally succinct negative connotations. I spoke recently at a BA conference, and my audience quickly confirmed their perception of agile met these the big myths: no planning and no documentation.

I won't belabor an argument. Basically, to do agile well, you must plan all the time. And with respect to documentation, agile generally says that documentation is a cost that must be recognized. It doesn't say don't do it; it says prioritize documentation with respect to its business value.

In the final panel of today's strip, the PHB says to Dilbert, "That was your training." In fact, that's often all training is nowadays. A concept is distilled into an article, or even two sentences, and the corporation feels that it's done its adequately trained its people. I've actually heard management suggest that its people should be smart enough to seek out and understand new concepts completely on their own.

Yes, agile is a fairly simple concept. Yes, training courses only provide so much value. But there's enough in agile to get wrong and misinterpret that you'd be a PHB were you to ignore the need to properly train your teams.

I currently work as part of an agile mentoring team in a large organization. Up until recently, we shared a project room. At any given point in time, there might have been one of four to six or seven team members (including a manager), plus one to three people that we were working with. On average there were four people in the room at any given time.

Up until this experience, I had always had positive sentiments about open workspaces and team rooms. In this current setting, I did benefit significantly from getting to converse frequently with all of the other people in the room. I learned things I probably would never have learned otherwise. And, I had a grand old social time.

But I also found that I wasn't getting much work done when I had things I need to concentrate on. It seemed like I could be guaranteed a distraction at least every five minutes. Either someone was asking a question, or I was overhearing something that I felt compelled to respond to. It got to the point where if I had to find a couple hours to work on something (such as preparing training material), I ended up leaving the open workspace to find somewhere quiet.

The problem wasn't the open workspace, it was the fact that none of us were really working on the same thing. The other mentors were usually working on a different project than I was. And my manager, well, you know how managers are, there's always something they want you to pay attention to right away.

Escaping the room on occasion was an adequate solution, but the better solution ended up being pairing. I noted that as soon as I found a partner to help build a solution, or someone that I was mentoring, the distractions disappeared. I surmise two reasons: first, as a pair we were focusing on a problem. That meant I was no longer listening to any external conversations. Second, people are more reluctant to interrupt two people that they see obviously engaged in a conversation or task.

As I've paired more and have worked with teams employing pairing, I've grown a long list of benefits that I've seen accrue from the practice. My experience here adds a new bullet item: pairing minimizes distractions.

... what do you call it? "Solo programming," I've heard. My preferred term is "isolation-based programming." So, sure, pairing up seems like a dumb idea. So does programming in isolation. Yeah yeah, it's not really isolation. May as well be.

Every once in a while, someone will ask about the value of incorporating function points. For those under, say, the age of 40, function points were something that were devised in the late 1970s in order to come up with a consistent metric for estimating the size of a software system.

Sure, function points can end up being fairly accurate from time to time. They may help in terms of comparing efforts on two software projects.

The problem is the investment required to derive function points. Function point analysis is expensive (albeit there have been several initiatives to try and simplify the effort). In order to be useful across projects, a metric has to be consistently calculated. In the case of function points, consistently calculating them is a meticulous effort. Generally, you need an "expert" in order to do well with function points.

Fortunately, to save the day, we have high-priced consultants that can come in and explain why (a) agile sucks and (b) why they are the one who can do these ridiculous calculations.

Horse hockey. I've seen as good or better results from agile estimating and planning techniques. Or, agile aside, from notions that are much simpler to calculate ("how many screens are there?"). These techniques, which come more cheaply, are far less onerous, and anybody can quickly learn how to do them without hiring an overpriced consultant (or "software economist").

Should you trust me, a "high-priced consultant" myself to tell you function points are dead? Look around. There's a good reason why most organizations have moved off of such heavyweight nonsense. All of these wondrous efforts and calculations make managers and executives feel good. Function points look like a lot of effort went into them, and fancy looking calculations back this effort up. But that's about it. They don't really add value to a project. What adds value is getting quality product in front of a customer on a consistent basis, giving them what they ask for and expect.

A good consultant will teach you how to start solving your own problems. A questionable one will sell you complexity you don't need.

I just did a google search, looking for something on the agile catchphrase of "Done Done." The first hit was James Shore's site. I clicked on the link, expecting useful information, but received propaganda instead:

In the United States, power flows from the people. We grant our power to representives [sic] on the first Tuesday of November.

In the last six years, that trust has been betrayed.

• Torture
• Extraordinary Rendition
• Engaging in War Under Deceptive Pretences
• Suspension of Habeus Corpus
• Imprisonment Without Trial at Guantanemo [sic] Bay
• Warrantless Wiretapping

These are not American values.

I am on strike today in protest of these actions.

Next year on the first Tuesday of November please join me in removing those responsible.

I applaud Mr Shore for being courageous enough to mix his politics with his business. I choose to minimize my commentary to places like this blog, where my personal beliefs shouldn't be enough to dissuade someone from doing business with me. Of course, that still may happen, but it's far less likely to happen than if I choose to shut down access to information and commerce on my site in order to push my personal belief system.

Perhaps if more people were to take a stand, like Mr Shore, we'd be better off. I'll take my small stand: most of what Mr Shore says is correct, with the exception of the part about the "last six years." The unfortunate part is that these activities aren't just part of the current administration, they've existed in virtually every administration since Abraham Lincoln (who used just about all of these tactics), up to Clinton and of course Bush II. It's just that sometimes the American people have been gullible enough to swallow the rationales and excuses, or worse, have been willing to be complicit because their party happens to be the offender.

I recommend that the American voters remove everyone responsible next year. That includes those in Congress who swallowed the lies as well as those who made the lies--the threat of WMDs, even if real, was not an excuse to invade another country. That's pretty much everyone in Congress. If only we had the courage.

I am neither Republican, Democrat, socialist, or Libertarian. I no longer believe that voting contributes to solving any problem (in fact, I believe that voting is implicitly an act of force). But if I were to vote, I'd say that the only hope for the future of the U.S. lies in someone who actually believes in the U.S. Constitution, and not someone who believes in only parts of it (Republicans or Democrats). That one person is Ron Paul. Do your research.