Agile and PHBs

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 has 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.


Hear hear!

Sadly, in process as well as in politics, often you are stuck with nothing more than the sound bite.

A Case for Pairing: Open Workspaces and Distractions

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.

Function Points Are a Crock

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.


Why function points for an application with a metric that is not a metric but a rating?

Imagine calculating car points trying to establish a single value for a car with points for wheels, chassi, gears, backseat and son on?
Has anyone tried?

Not possible i guess!

Our experts group make function points available at lowest cost in the whole world, I guess. We charge around 50 cents to 1 dollar for each RFP page. It converts to $3 – $5 / hour kind of a rate.

We have also come up with a function point tool that is used primarily by our experts to make function point submissions but it can be used by anyone who wishes to practice Function points.

People are invited to use this free online FP tool

If you register on the site (go to home page to register) then it will let you save your work as you go. There are other tools as well (such as WBS and RCL (a requirements capture language under research) tools), please have a look at the services tab on the home page

Do send your suggestions for improvement.


If You’re Not Pair Programming…

… 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.