On Tuesday, June 27, 2006, at 4:33:40 AM, David H. wrote:

>> Tracking hours at all seems more and more of a distraction to me.
>> The key thing is whether features get done. (I don't have the
>> books with me here in Seattle, but I don't remember back when I
>> read them that I had to do all this hour tracking that people seem
>> to be doing lately.)
>>
> How do you cater for organisation needs where they require you to
> track those hours for various reasons (and sadly so this is a huge ass
> company and there is no way they will drop this) ?
> I agree with you whole heartedly though.

I'd always track whatever they said I had to track. And I'd make it
abundantly clear when they were misusing the data.

> Next, how do you explain it to the customer that a task took those 15%
> or so longer? How do you explain the extra amount of cost incurred?

This is exactly the reason why I don't recommend hour tracking. The
estimates are //estimates//. We're designing here, not laying
bricks.

Does anyone ever throw a hissy fit if something comes in under its
task budget? I've never seen it. But go over and some managers think
they have a right and duty to dig into it. Wrong, wrong, wrong.

>> Anyway, I would probably not track at this level at all. I'd track
>> pure burndown on the tasks, done = done, not done = not done. If I
>> did track hours, I'd track hours against the tasks, not hours
>> against the people.

> Very good point indeed. However how does that work out when you need
> to track people against customers on a times and materials basis where
> the customer wishes to verify they get the most for their buck?

That's two questions.

Value is about what you get, not how much work it takes to do it. If
the customer wants to get the most for their expenditure, they
should pay more attention to the value side of the equation, and
look at the overall rate of producing running tested features.
Looking at the detailed cost figures is like counting how many paint
strokes are used in the garage, while ignoring the fact that the
house has no bathrooms.

Time and materials tracking amounts to buying and selling the hours
of the day, at a constant rate no matter what they're used to do.
Both the buyer and the seller concern themselves with cost, not
value, losing value in the process.

Companies can do what they want, and if they want this information,
we have to give it to them. But until they have the value side of
their situation well in hand, they're looking at the wrong end of
the lever when they track and question estimated hours.

So far, in a decade, I've never seen an Agile team that was so good
at the value side that this level of "optimizing" the cost side
really made sense. Not that they don't have time being wasted --
they do. It's good for a team to ask why things take longer than
planned, because it will suggest areas to work on. Kent's recent
value stream example shows what that analysis can provide.

But when we hear questions phrased like yours above, I don't think
we're hearing about value stream analysis. Too often, we're hearing
someone counting pennies going out instead of dollars coming in.

Ron Jeffries
www.XProgramming.com
Comments lie. Code doesn't.