Empirically (or "anecdotally," if you’re academically-inclined), practitioners know that high work-in-process (WIP) levels tend to lead to a variety of problems. Thanks to Rally Software, we have some hard data to help us make that case with clients. Continue reading
Back in the Old Days, project managers seemed to be obsessed with comparing time-based task estimates with the actual completion times of those tasks. When estimated and actual times didn’t align, we were advised to get better at estimating. The goal wasn’t really to learn to create perfect estimates. The goal was to achieve some level of predictability in an inherently unpredictable process for purposes of short-term planning.
Nowadays we know that the fine-grained estimates we might use to inform our short-term planning in the course of a project are not “the product” for which our customer is paying, and therefore are a form of “waste.” We’ve looked for (and found) alternatives to time-based estimation that can provide the information we need to plan our work without the overhead of preparing time-based estimates for individual tasks.
At two different clients this year, I’ve seen people comparing “estimates” (actually, relative story sizes) with the actual completion times of user stories, but not for the purpose of short-term planning. Continue reading
Alert: 82% chance of pontification.
Let’s walk through a couple of process improvement scenarios to explore the differences between measuring activities and measuring outcomes. The starting point is a software development team that has decided to improve software quality. Continue reading
I’ve found it helpful to keep a few fundamentals in mind when choosing and using metrics, and I want to share those in this post. Maybe you will find some of this useful.
A recent tweet of mine in which I whined about the waste of tracking work hours garnered quite a few responses. The reaction surprised me, as I was only venting and didn’t expect any replies. Apparently, I’m not the only one who is frustrated by this. Not only is it useless to track individuals’ hours by task or by project, it is particularly annoying to use poorly-designed time tracking tools. I was complaining because I presently have to enter time in three different tracking systems. I wrote that the first seems to have been designed by a roomful of monkeys; the second, by a roomful of monkeys on crack; and the third, by a roomful of monkeys on heroin laced with rat poison.
The ensuing Twitter thread reminded me of the futility and waste of tracking individuals’ time at all. People shared their own experiences with the problem and how they had dealt with it. Later, I recalled having written a blog post on a related topic. I visited the Wayback Machine and located it. Here’s the post, dating from December 29, 2007. It lacks only the image of the Dalí painting Suburbs of the Paranoiac-Critical City; Afternoon on the Outskirts of European History, which I hesitate to reproduce in view of recent…er, paranoia about intellectual property rights.
Words don’t have firm, unambiguous, unchanging meanings. This is a source of some frustration for me. The same word can have multiple meanings. Sometimes there are context-dependent meanings. Sometimes there are shades of meaning conveyed by tone of voice. People can have multiple interpretations of the same basic meaning of any given word. Clear communication is more challenging than it might appear to be.
In the field of software development, we have an unfortunate habit of re-using old words to represent new concepts. Maybe it’s because we value re-use (whatever that means). The English word, agile already had a meaning before software developers came along and started using it for something else. A ballerina is agile. A faun is agile. That’s easy to understand. Now, software development can be agile, too (whatever that means).