Sustainable pace is a well known XP practice for the teams who are in the game for long run. It suggests that teams should work hard but at a pace which is sustainable and can be maintained indefinitely. It is there to keep people fresh so they can be more creative.
However, is there a relation between Sustainable pace and the number of work hours per week?
Henrik Jernevad on his blog, tries to decipher the correlation, if any, between the number of work hours per week and Sustainable pace. As per Henrik, every programmer has a “Maximum Productivity” which depends on his talent, then there is something called “Current Capacity” which is the highest amount of work which can be done currently without lowering the quality. Below these two we have the “Sustainable Pace”. He suggests that instead of keeping the work week at 40 hours if we could increase the sustainable pace to a higher number then results could be surprising. Just playing safe with 40 hours a week sounds like waste.
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.
So does an extra month deliver business value worth a month's effort?
The discussion continued on the Scrum Development group where members debated the concept. Many members suggested that increasing the number of work hours does not linearly increase the productivity. Others added that number of hours != value. After a certain tipping point, teams tend to be more destructive than productive. Laurent Bossavit added his point to the discussion where he suggested that, as per him, business value creation iteration on iteration would be nearly the same for a wide range of variation in developer hours.
My hunch is that if you took "value creation" numbers from a team that had a sustainable pace and a good process, you would see large variations from one iteration to the next. If you plotted these numbers you'd get a nice power law curve. You would see very little variation in the overall value creation for a shockingly wide range of variation of "developer hours".
A similar article on IGDA, summarized a similar finding
Workers can maintain productivity more or less indefinitely at 40 hours per five-day workweek. When working longer hours, productivity begins to decline. Somewhere between four days and two months, the gains from additional hours of work are negated by the decline in hourly productivity. In extreme cases (within a day or two, as soon as workers stop getting at least 7-8 hours of sleep per night), the degradation can be abrupt.
Henrik tried to defend his argument for working more than 40 hours per week by quoting examples of Google and Microsoft. He added
Google has even been awarded the title "best company to work for" twice in a row, according to Fortune magazine! And they surely don't limit themselves to 40 hours per week.
Dan Rawsthorne suggested that Sustainable pace is not about number of hours at all, it is about commitment and technical debt. If the team can sustain their pace without providing technical debt then they should go with that pace irrespective of the number of hours. George Dinwiddie further added that sustainable pace is something which could be discussed with the teams in a retrospective setting. He quoted Alistair Cockburn to negate the relation between sustained pace and number of hours.
Increasing hours is, in my experience, the least fruitful way to get more done in the software development field. It's a choice that fits H.L. Mencken's description of "simple, obvious, and wrong." As Alistair Cockburn has so delightfully described, people are non-linear systems. Expecting a linear relationship between input (more hours) and output (quicker accomplishment) is misguided.
Joseph Little tried to summarize the discussion by suggesting that the important factor to sustain pace is not the number of hours worked, but to think creatively and accomplish more in less time. He mentioned that sustainable pace revolves around a lot of factors like work culture, technical debt, motivation etc. It might have a small influence from number of hours worked but that is not the best metric to start with.
