Does Sustainable Pace mean a 40 hour week?
- Share
-
- |
Read later
My Reading List
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.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
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
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
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
Re: Personal workload
by
Bruce Rennie
Optimize for team output, not individual output.
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
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.
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
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.
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.
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".
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
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.
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
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
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
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
Educational Content
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think