Posted by Robert Merrill on October 26, 2009 under Uncategorized | 
Once again, reality fails to conform to plan, even in the case of something seemingly similar to something done every year—the manufacture and distribution of influenza vaccine.
In “Swine Flu Vaccine Shortage: Why?” on NPR.org, we learn that late-in-the-process verification of actual yields, and a bottleneck at the packaging stage, have led to a late-in-the-lifecycle discovery that we don’t have nearly as much vaccine as we expected to have by now.
It will be interesting to watch the story unfold. Here are my predictions of what we will learn: Read more of this article »
Posted by Robert Merrill on February 6, 2009 under Agile Methods, Estimation |
With just a little bit of effort, the uncertainty in a project estimate drops rapidly. But there comes a point where getting even a little bit more accuracy takes a lot more work (yellow line) and there
“Real Agile teams don’t waste time on X.”
“You can’t deliver quality software without getting X right first.”
My favorite quote from fantasy writer and Christian apologist C. S. Lewis is this: “(The Devil) often sends errors into the world in pairs—pairs of opposites…He relies on your extra dislike of one to draw you gradually into the opposite one. But do not let us be fooled. We have to keep our eyes on the goal and go straight through between both errors.”
A key principle of Agile software development (and much else in business besides) is that of “diminishing returns.” At some point, extra effort in the same direction, even on generally worthwhile activity, is no longer worth it.
I most often find myself talking about diminishing returns when it comes to cost and schedule estimation. “Robert,” someone comes to me, “I have an idea for some software that’s going to save us a million bucks. How long would it take to build it?” Read more of this article »
Posted by Robert Merrill on September 30, 2008 under Project Set-Up |
I keep getting a trickle of traffic from this post I made on an InfoQ forum back in July, so I really ought to write more on the topic (I finally did). But for now, here’s the comment that continues to spark interest.
Maybe outsiders see the lack of OUTWARD-FACING metrics, that can be compared across projects or even industry-wide. Agile thought leaders seem metrics-averse, maybe out of reaction to the way metrics have been used (and abused) in the past. As I see it, the basic four, productivity (X/effort), velocity (X/time), quality (defect/X), and value (benefit/X) still apply, and within a project, agile teams track and respond to them, in their own effective ways (measured velocity, continuous integration and automated tests, planning game). But when you need to compare projects, you need a more portable X, or what I call “an ounce of software.”
I used to do project set-up for a contracting shop that used agile methods. We needed a decent estimate before we even got the chance to establish a velocity. That estimate needed to be clearly traceable to the initial requirements, to help the client think “scope-to-budget” from the start. The estimate also needed to be tied to actual results on other projects, so it couldn’t be pressured down. Based on these requirements, I introduced Function Points. Usually dismissed with a sniff by agilists, they did just what we needed, and didn’t interfere with people and interactions at all. They also helped our initial story development by revealing gaps and implied stories
You can read the complete thread, “Agile Measurement – A Missing Practice” on InfoQ.
