Increasing sustainable pace
Posted 4 months, 3 weeks ago. Has 7 comments so far.
In the last few years, especially in the agile corners of the web, there’s been quite a lot written about the 40 hour workweek, sustainable pace, no overtime, and so on. I agree with most of this stuff and think exhausted developers in the long run do more harm than good.
I can’t help to wonder, however, what’s so magical about 40 the hour workweek? Why not 35, 45, or even 55? Also, it will naturally vary among different people. So I want to know where to draw the line. Just playing safe on 40 seems a waste, if my team can do better.
The capacity model
In the figure above, I’ve created a simple model for how I imagine things work. It’s pretty safe to assume that everyone has a maximum productivity level, over which it is simply not possible to get. I’d say this maximum is defined by the programmers talent. No matter how much experience, practice or training one gets, there’s still some basic inherent talent level which defines one’s maximum. (If nothing else, let it be the number of words per minute the developer can type.)
More interestingly, we’ve got a current capacity which is the highest amount we can currently produce without lowering quality. A sustainable pace is any pace which is below this current capacity. That is, we can keep going at this rate forever, without accumulating any technical debt. We can go above it once in a while too, in a coding crunch, but then we start accumulating technical debt. This forces us to work at a lower rate later to pay back.
How do you go faster?
There are at least two interesting questions in this model. First, how do you find your current capacity? I believe that question can be answered empirically by increasing development speed until developers start getting (too) tired and bugs start to slip in. The second, and more interesting, question is: how do you raise your current capacity? To answer this, we must first answer another question which is: what defines your capacity? (In the figure, this unknown entity is called x.) My best bet is motivation with a tad of discipline thrown in for good measure.
To sum up, my point is that while we want to achieve a sustainable pace in development, we shouldn’t have to limit ourselves to 40 hours per week. If we can hold a sustainable pace of say 45 hours per week, as opposed to 40, we gain more than one month of extra development time during a year! Especially in start-ups, such as where I work, 40 hours a week is a luxury one cannot afford. Large companies such as Microsoft and Google also very much rely on peoples desire for and ability to work (much) more than 40 hours per week. So the question is, how do we increase our development pace while keeping it sustainable? Is it possible? (I sure hope so.) If so, how do you do?
Discussion
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?
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.)
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
Thanks for you comment Huet!
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
Henrik,
I agree with Huet here, but it’s not about error rates, it’s about technical debt, which is much more insidious.
IMHO, the only way you know if you are working at a sustainable pace is to ask your people. Of course, the fact that you are asking it implies that you want them to move faster and this, in itself, provides a force for technical debt.
If you are working in an environment that you must move faster, but can’t afford to get more people, then you must accept technical debt. I call this “buying a risk”, and it may be the right thing to do.
Just don’t lie to yourself about doing it, and have a plan/strategy for resolving the technical debt later.
Dan
Thanks for your comments Dan,
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.
For more comments, see the scrumdevelopment mailing list.
And for even more, see the comment’s on infoq.com’s coverage.
The issue here is finding a the current capacity of a team.
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.