How much data a team has and how reliable that data is.

I think as the agile philosophy suggests that the process should be based on people who are following the process, so an imprical constant of 40 hours a week is probably not just right.

Every process must have some decision points. A team may feel (and the value of the feeling is again evaluated by the same team, which may or may not be correct) that their currect capacity is more than 40, so be it.

Also the absolute avoidance of technical debt is again not the right idea. Just as with financial debt, though undesireable, many business could not have grown to what they are without it. So the case might be with techincal debt. The team is the best judge.

A global solution cannot be right always.

I do want to keep a sustainable pace, defined as where no technical debt is added, but I want that pace to be as high as possible (again, without accumulating technical debt). As I write in the post, I define any low-enough pace to be sustainable in said sense, so how do I know we’re working at an as high but still sustainable pace as possible.

However, you might very well be right in that the only way of knowing is asking my people. If they even know themselves.

Regarding your first point, I agree that people have different working styles. That they have different “capacity” (as I call it above). And it is measuring that capacity I’m really looking for. That’s not an easy task, I know. A little bit funny, I got the latest IEEE Software magazine today, and the editor’s column was on that very subject, measuring the output of developers.

Regarding your second point. Sure, power tools are better than simple tools. But John Henry didn’t have power tools available (I assume, I don’t know his story). In fact, I imagine he used the best tools he could. So it is not really interesting to me if someone can work faster tomorrow (as a metaphor ). I’m interested in today.

Regards, Henrik

This is not a new idea. Do a search on overtime and error rates and you will find many more studies in more fields of work than you can read in a month.

You need to consider the following factors. 1. Does your team really need to maintain a higher level of productivity, or are you just trying to keep ahead of the competition?

1. Have you tracked the error rate of each member of your team when working under various conditions? Each person has a different working style. Some may work nonstop for days, then crash. Others may work in short bursts. Either way, everyone has a point at which their error rate will reach a point where they are making no progress (or worse) due to the time needed to correct errors (and correct the corrections.)

2. Working more hours may not be the best solution. In the long run, working smarter always wins over working for longer periods. John Henry was the best rail spike driver in his day, and he died proving it. Power tools today let anyone work faster than John ever did.

Cheers!

Huet