InfoQ

News

Opinion: Putting Overtime in Perspective

Posted by Deborah Hartmann on Sep 13, 2006 06:42 AM

Community
Agile
Topics
Agile Techniques ,
Delivering Value ,
Leadership
Tags
XP
Mitch Lacey is a Program Manager at Microsoft in Redmond, with a passion for Agile software development.  When appropriate to the work, he loves to help a team get fully agile - practicing XP and Scrum, absorbing and living the principles.  Lacey recently blogged about the XP core practice of "Sustainable Pace", which has also been adopted by ScrumMasters and other Agile practitioners, because Agile work, when done in a disciplined, creative way, tends to be very intense.

Definitions on how to implement Sustainable Pace vary, though, from the dogmatic 40-hour rule to "whatever the team can sustain".  For those unfamiliar with the concept, Ron Jeffries, an XP originator, has written:

Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software. XP teams are in it to win, not to die.

Lacey goes on to say: "I used to get hung up on this and even today I continue to see others getting hung up on this.  I used to think that I had to work at a sustainable pace and that I would fail if I worked overtime."  He now understands it differently, and makes some suggestions on determining the value of overtime (rather than rushing ahead and doing it for the usual reasons) in his MSDN blog entry called Breaking the Rules of Agile - Working Overtime.

For more on why sustainability is important, read Ron Jeffries' Impact of Overtime on Productivity, which starts out with:
More features will always bring more revenue, more customer satisfaction, other good things. Therefore there is always pressure for people to work harder, longer hours. This is demonstrably a Bad Idea. Here's some evidence, and some ideas about how to know if pressure is too high.
and along the way he covers topics such as these:
  • Industrial Accidents and the Professional Programmer
  • Mental Acuity for Programming
  • Disproportionate Impact of Defects
  • Practices Slide Under Pressure
If you're interested, there's more on Jeffries' site on overtime.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
IMHO working overtime miss the point by Stephane Boisson Posted Sep 14, 2006 3:53 AM
Re: IMHO working overtime miss the point by Deborah Hartmann Posted Sep 15, 2006 8:06 PM
  1. Back to top

    IMHO working overtime miss the point

    Sep 14, 2006 3:53 AM by Stephane Boisson

    Isn't feedback based iteration supposed to expose problems , so the team can find a way to fix a problem or re-adjust estimation?

  2. Back to top

    Re: IMHO working overtime miss the point

    Sep 15, 2006 8:06 PM by Deborah Hartmann

    Yes, Stephane, I agree with you. The inspect-and-adapt cycle is a good place to react to such problems and head them off. There really isn't any excuse for a deathmarch on an Agile team that is doing retrospectives. But I've also seen teams that don't perceive overtime as a problem so it doesn't come up in the retrospective. Or perhaps there is organizational pressure from outside the team, and they can't shake the feeling that they should comply, so it gets swept under the carpet. These teams need some leadership - someone (a team member, a scrum master, a manaer) who encourages them to discuss it, as the author suggests. This can reset expectations and reveal options that can then be dealt with over time in retrospectives. What do you think?

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.