Thanks to Jeremy D. Miller I just discovered a place that is worth a web surf: Process, People, and Pods. Fred George started to blog less than a month ago and, in a few articles, he described the very nature of agile software development.
From agility inner secret to encounters of the third kind (of developers) and path to development wisdom, we go through all what we would like to tell about our jobs if we knew the words for that.

Oh, and did I tell you about the pods? You should really read those ones too!

I love metaphors on project management. I just read a good one by Tom Looy : "How Long is a Piece of String?". You can get an estimate by looking at it but you will get a more accurate value by measuring it with a ruler. Estimating is not an easy job, especially when it comes to predicting when a piece of software is done. In the early stages of a software project, when you can barely estimate and certainly not measure anything, fixing scope, cost and dates is impossible.

Years ago, I was appointed software project manager for the first time. Being a software developer, I intuitively knew that I should be careful with scope, cost and dates issues. I was reluctant to draw a full gannt chart too early in the project because I suspected that people would rely too heavily on it. The projects director I was reporting to told me : "This is not a way to run a project. You must list every task for the project, estimate them and put them in the chart then you will get a release date. From there you will start tracking the team progress". I complied with the order.
Any experienced project manager obviously knows what happened : as the first tasks were not completed on time, the release date started to slip.
The estimates were indeed very bad. Half of the developers had just graduated from university and relying on their estimates was the worst thing to do but the rookie project manager didn't know that.

Now imagine this project is a big black box with 3 levers...

Dave Nicolette raises concerns about organisations moving to agile development while appointing "traditionally-minded" managers. Risk #1 is that these managers turn the agile processes upside down by transforming them into a Staggered Iterative Waterfall as described by Kane Mar.
I deeply agree with the key statement of those articles : agility's main duty is improvement of interactions between individuals with the help of suitable processes. It is not about focusing on a well-polished process aimed at eliminating every possible waste in human activities. However, I do not subcribe to the RUP-bashing movement that seems to result from it.