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 Correlation between high WIP and defects
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 An old metric revisited: Comparing estimates with actuals
Alert: 82% chance of pontification.
Continue reading Four canards that afflict us
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 Measuring continuous improvement
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).
Continue reading Words don’t mean what they don’t mean
This is the third of three posts dealing with aspects of management that I consider significant in choosing management techniques and metrics for software development and support:
Despite the many complexities of software work, we are always working in one of two modes:
- Discrete project
- Continuous support
By discrete project mode I mean a mode of operation in which an organization creates a special initiative that exists for a defined period of time whenever it needs to achieve a set of related objectives, such as creating a new software application or upgrading the routers on the corporate network.
In contrast, with the continuous support mode of operation, the organization maintains a stable team to support each technical asset (such as the corporate network, a business rules engine, a COTS CRM package, or an ETL product) or suite of applications (such as the suite of applications that support consumer lending in a financial institution) throughout its lifetime. The size of the team may grow or shrink depending on the level of work needed to support the asset or applications at any given time, but the organization does not start a new project for every set of objectives pertaining to the asset or applications.
Continue reading Delivery mode