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.
Community comments
Just say no to +40 hours
by Eric Weise,
I always thought the goal was to work less, not more
by Bruce Rennie,
Work that cannot be completed without overtime cannot be completed at all
by Gael Fraiteur,
Re: Work that cannot be completed without overtime cannot be completed at a
by iury ribeiro,
Re: Work that cannot be completed without overtime cannot be completed at a
by Philippe Antras,
Re: Work that cannot be completed without overtime cannot be completed at a
by Vikas Hazrati,
Re: Work that cannot be completed without overtime cannot be completed at a
by Paul Oldfield,
Personal workload
by Roland Carlsson,
Re: Personal workload
by Bruce Rennie,
It's about respect
by Paul Oldfield,
Re: It's about respect
by Dave Rooney,
Re: It's about respect
by Eric Weise,
Question is pointless and self-referential
by James Richardson,
Just say no to +40 hours
by Eric Weise,
Your message is awaiting moderation. Thank you for participating in the discussion.
I've been developing software for about 15 years and the only time I let someone get more than 40 hours a week out of me was when they paid by the hour for every hour I worked. Seriously, even if someone could prove that 45-50 hours per week was a sustainable pace, why would you ever want to put in those hours. Every hour you put in for the company is an hour you could be working on your own business, spending time with your family, or pursuing some hobby.
I always thought the goal was to work less, not more
by Bruce Rennie,
Your message is awaiting moderation. Thank you for participating in the discussion.
Interesting article from 37signals: www.37signals.com/svn/posts/893-workplace-exper...
Work that cannot be completed without overtime cannot be completed at all
by Gael Fraiteur,
Your message is awaiting moderation. Thank you for participating in the discussion.
As a developer, I've always found overtime a repulsive idea, mainly in big organizations. Why should developers always pay for bad estimates of their leaders? That's too easy to use our free time as the adjustment variable.
I only do overtime exceptionally, when there is an urgent reason to do it. For instance, when there is an error in production and the company is making important losses per hour because of that, some overtime is justified.
But doing overtime 3 months before project delivery is not justified. I've even seen cases where the middle management knew 6 months in advance that the time budget was 50% underestimate, but were hiding this reality by fear of being "the bad guys".
And actually, one of the biggest most silly features of XP methodologies is to put a deadline every month, which is a nice way to put developers under constant pressures.
Guys, we do a profession where talented people are rare, so if you consider you have some talent, there is no reason for you to accept systematic overtime. Let it to mall cashiers -- they don't have the luck we have.
Put project managers in front of their responsibilities. Don't accept to be the adjustment variable. Neither let XP gurus tell you at what time you have to go home!
Personal workload
by Roland Carlsson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think all here are missing an important factor. There exists inviduals that accutally can work more hours than others. We aren't all made in an "40-hour-form". For some inviduals there might be a better choice to stay at 30 hours to stay at peek performance. Other can probably work 50-60 hours a week before showing signs of degrading.
Another factor is if one works for their own profit or for a company. Personal commitment con make wonders for the productivity (at least in the shorter perspective).
It's about respect
by Paul Oldfield,
Your message is awaiting moderation. Thank you for participating in the discussion.
As I followed the discussion on Scrum Development list, I came away with the impression that the main objections were to the lack of respect the question / suggestion showed towards other members of the team. It is my experience that nearly all people do a good week's work for a good week's pay, and I respect them for that. They are usually prepared to put in an extra effort in exceptional circumstances, and I respect them for that. If I start saying to a team member that he's only putting in 42 hours while other team members are doing 46 to 48, I am in effect suggesting that he is not fully committed to the project, that I believe I know better than him what are his optimum hours for the week. It shows a profound lack of respect, and I'd expect that person's productivity to fall rather than rise in response to such an approach, even though they may choose to put in the extra hours. Treat your fellow team members with respect if you want top productivity. Pointy-haired bosses get the productivity they deserve.
Re: Personal workload
by Bruce Rennie,
Your message is awaiting moderation. Thank you for participating in the discussion.
So if this super-human developer is writing code 60 hours a week and the rest of the team is working 40, who's testing that extra 20 hours of output?
Optimize for team output, not individual output.
Re: Work that cannot be completed without overtime cannot be completed at a
by iury ribeiro,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with you. Lets put the XP guru to do a handon
Re: Work that cannot be completed without overtime cannot be completed at a
by Philippe Antras,
Your message is awaiting moderation. Thank you for participating in the discussion.
No, because the end of an iteration cannot be compared to a project deadline. It's a deadline because an iteration always end on time (with the exception of Scrum sprint abort), but features that are not "done done" will be re-scheduled in the next iteration.
Moreover, in a XP project, estimates are done by the developpers and schedules are made by customers and developpers, based on the Team velocity (the amount of work they could achieve in the previous iterations).
So they have some pressure, that's correct, but not the same pressure one can imagine when a deadline approaches.
Some would say just enough pressure to focus on their work.
Re: Work that cannot be completed without overtime cannot be completed at a
by Vikas Hazrati,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think we might be going a bit tangent here with the main discussion but the idea of iteration end is to ensure that the team has completed the stories that they committed on. If not what were the reasons and how they can be done in the next iteration.
In my experience it does not put pressure on the developers because they tend to work with a sustainable pace and do not have bursts of late sittings and overtime towards the end of a release that we see in traditional projects.
This again goes against the core value of XP which is courage. If you feel that there is something wrong which would benefit if you pointed it out, then it makes sense to do that immediately rather than springing up surprises later.
Re: Work that cannot be completed without overtime cannot be completed at a
by Paul Oldfield,
Your message is awaiting moderation. Thank you for participating in the discussion.
I cannot agree with the "most silly", but perhaps I have different understanding and experience. Have you ever worked on a genuine and successful XP project?
I'm more familiar with 2 week iterations though I can recall doing monthly ones. 2 week iterations allows the team to envisage the amount of work they are committing to much better, so they tend to over- or under-commit on fewer occasions.
The nice things about iterations with regard to workload are that 1) at the start of every iteration you get a time that's sufficiently slack that you can step back, look at the work to be done and envisage good solutions; and 2) at the end of the iteration there's a degree of pressure to deliver what we have committed to.
Since we are choosing how much work we commit to, we have iterations short enough to be good at predicting how much work we can do, and we have experience of past iterations; we ourselves choose how much pressure we want to put ourselves under at the end of the iteration.
It has been my experience that (most) developers like a bit of pressure occasionally, particularly when they have a fair degree of control over how much pressure there is.
Re: It's about respect
by Dave Rooney,
Your message is awaiting moderation. Thank you for participating in the discussion.
...and variability. As Cockburn says, people aren't just different from each other but even within themselves on a day to day basis. One week I'm good for 40-45 hours, and another I'm sucking wind after 30.
The "40-hour" limit was something created by the first XP team because that's what the standard work week was for them. Unfortunately, that term made it into XP Explained and we're still having the debate almost a decade later. Having said that, though, we had to start somewhere so "40 Hours Week" it was.
Dave Rooney
Mayford Technologies
Re: It's about respect
by Eric Weise,
Your message is awaiting moderation. Thank you for participating in the discussion.
variability would be great if companies let you work a 35 hour week after 45 hour week. But companies usually see 40 hours being a minimum, below that is called PTO.
In regards to iterations, as soon as you start working more to meet some estimate because you made a "commitment", you'll never work under 40 hours again because you've raised your velocity and managements expectations. It's much better to just fail at delivering to your estimate, and then make a better estimate the next time.
Question is pointless and self-referential
by James Richardson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Ok - your team is doing f8uk all in a 40 hour week. How much more will they be doing in a 45 hour work week. I can tell you!
12.5% more of f8uk all!
Actually even this is a lie! - Hours can't be spent linearly... so the more likely answer is that you will work those hours bue due to declining productivity you will get only a fraction of that extra - if even that.
You are asking the wrong question, and getting the wrong answer. Basing decisions around those answers will be most likely wrong decisions.
Perhaps if you started asking: "How can I help my team deliver more effectively?" then you might start getting more done.
Good luck with your team. I'm sure they will be happy to know they are being squeezed for every last bit of life!
James
time4tea.net