Translation: Counting Is a Waste of Time
Fred George is a former IBMer who has been programming for nearly 40 years and has been in the field since before IBM created the Waterfall process (which he emphasizes works — and I agree). On his blog Process, People, and Pods he discusses the advantages of Agile methods from the perspective of someone who has genuinely gone through every process and has enough experience to discuss them intelligently. I found his latest post particularly funny. So here it is:
There it is. You see it. You have this uncontrollable urge to count. It’s a moral obligation, a call to arms; your personal mission.
I’m talking about counting and measuring artifacts. I mean project managers and team leads, and sometimes programmers, testers, and analysts.
And if you stop for a moment and think about it, it’s a big waste of time. A better philosophy:
“Never count your money while you’re sitting at the table. There’ll be time enough for counting when the dealing’s done.” — Kenny Rogers, from The Gambler
This thinking is based on Lean, a process borrowed from manufacturing. One of the practices Lean supports is the identification and elimination of waste. Waste is broadly defined as anything that does not add value to the delivered product.
Agile software development produces a mountain of artifacts — stories, tasks, test cases, and code. All of these artifacts have different useful lifespans. Code persists. Tasks are transient development artifacts. There is a time and place to count each one. But when the counting extends beyond those boundaries: waste!
Here’s a real example from an Agile project. It occurred between the client’s project administrator (somewhere between an administrator and a project manager) and me, in my role as technical lead and process coach. The discussion was about task cards. A task is a small unit of development work identified by the programmer for a story; a story itself averages 10 or more tasks, with high variance.
Project Administrator (PA): “I need to track the task cards.”
Me: “There are going to be a lot of them.”
PA: “I still want to track them.”
Me: “Couldn’t you track just the stories? Development only takes a few days.”
PA: “I still want to track them.”
Me (seeing a pattern here): “Well, if you really want to…”
PA: “Great. We need to number them.”
Me (starting to catch on): “So you can track them?”
PA: “Yes.”
Me: “You can put whatever numbers you want on them. They’re all on the wall.” (Note the technique of delegating to the person who appears to have the most free time.)
PA: “And I need the initials of the pair who worked on them.”
Me (unable to see an easier way out of this): “Ok. We’ll mark the completed ones as we go. We’ll put our initials on them.”
PA: “I need an estimate for each task.”
Me: “Two to four hours.”
PA: “No, I need an estimate for each task.”
Me: “Two to four hours. We split the story into 2 to 4 hour tasks. That is an estimate.” [I repeated this several more times.]
PA: “Ok, I’ll mark a range of 2–4 hours. Then I’ll need the actuals.”
Me: “No.” (I really try not to use this word with clients, but sometimes there’s no better word.)
PA: “But how will I track how long things actually took?”
Me (trying to use powerful Vulcan logic): “If I give you a number, it’ll only be an estimate of the actual time. We have to estimate to account for meetings, distractions, bathroom breaks, and so on. Even we don’t know the actual time it took.”
PA (after a long pause to process this): “But I need the actual time.”
Me (feeling a little guilty for suggesting this): “You could track how long it takes to complete a story, and just divide that.”
PA: “Ok, I think that’ll work.”
I was being a little unfair to our project administrator. The whole conversation would have ended sooner once she saw the number of task cards that were created, started, and completed each day (around 20–25 on average, per day). The tracking only cost us one week.
Most consultants would cave (and do cave) to the pressure to count. Some even advocate for it. Frankly, I exploited my gray hairs and used my authority voice to carry the day in this case.
Imagine the extra work if that process had been established? Even a few minutes per task adds up when there are 3,000 tasks in a project. And the killer question for all of this:
_ … And how will you use that information? _