Counting Wastes Time

It's there. You see it. You have this overwhelming urge to count it. It's a moral obligation, a call-to-arms; your personal mission.

I am referring to counting artifacts and measuring artifacts. I am talking about project managers and team leads, and sometimes programmers, testers, and analysts.

And if you stop to think about it, it is a big time waster. A better core philosophy:

"Never count your money while you're sitting at the table. There'll be time enough for counting when the dealings done." -- Kenny Rogers from The Gambler

This thinking is based in Lean, a process borrowed from manufacturing. One of the practices Lean espouses 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 loads of artifacts, like stories, tasks, test cases, and code. All of these artifacts have different useful lives. Code endures. Tasks are transient artifacts of development. There is a time and place for counting each. But if you count outside of those boundaries: waste!

Here is a real life example from an Agile project. It occurred between the client project administrator (sort of a cross between a administrator and a project manager) and myself in my role as tech lead and process coach. The discussion was around task cards. A task is a small unit of development work identified by the programmer for a story, which itself has an average of 10 or so tasks, with a huge variance.

• PA: "I need to track task cards."
• Me: "There are going to be a lot of them."
• PA: "I still want to track them."
• Me: "Could you just track stories? Development only takes a couple of 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 (I am beginning to catch on): "So that you can track them?"
• PA: "Yes."
• Me: "You are free to put any number on them you want. They're on the wall." (Note the technique of delegating to the person who seems to have all the extra time.)
• PA: "And I need the initials of the pair that worked on them."
• Me (Can't see a quick way around that.) "Okay. We mark the finished as we go. We'll put our initials on it then."
• 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 break the story down into 2-4 hour tasks. That is the estimate."
• [Repeat several more times.]
  
• PA: "Okay, I will mark a range of 2-4 hours. Then I will need the actuals."
• Me: "No." I really try not to use this word with clients, but sometimes there isn't a better word.
  
• PA: "But how can I track how long it actually took?"
• Me (trying to use powerful Vulcan logic): "If we gave you a number, it is only an estimate of the actuals. We have to estimate to accommodate meetings, distractions, bathroom breaks, and the like. Even we don't know how long it actually took."
• PA (after long processing pause): "But I need actuals."
• Me (feeling a little guilty suggesting it): "You can track how long it takes to do the story, and just divide it."
• PA: "Okay, I guess that will work."

I was being a bit unfair to our project administrator. The whole conversation would be rendered moot as soon as she saw the number of tasks that were created, started, and completed each day (about 20-25 on an average day). The counting only lasted a week.

Most consultants would (and do) succumb to the pressure to count. Some may even advocate it. Frankly, I exploited my gray hair and used my authority voice to carry the day in this case.

Imagine the overhead if this process had been established? Even a few minutes per task add up when there are 3000 tasks on a project. And the killer question for this:

...And how will you use that information?