40 Hour Guideline?

For some the notion of a 40 hour week is too difficult accept, deeming it too short to really achieve anything. But the rationale for this working principle is built on sound thinking. Working long hours at fever pitch will not only stress a team out, but will induce mental fatigue to the point that silly mistakes are made, and the team will actually work slower and do less than if they were energised everyday and doing less. Obviously when a release is coming up or other such important deadline, then the amount of work the team does must be as flexible as possible, and working more should be acceptable.

I think there is something important to consider that supports the 40 hour week “guideline”. In a team that is energized and running at full-steam, the amount of things going on at any time could be quite large, with the whole team busy coding, designing or talking. Even when a team member is working on something, they will be actively engaged in ensuring they are aware of what is going on around them while they go about their business. Many people who truly engage with pair programming say they like it, but it can be draining. When we work alone, it is easy to take a “breather”, to sit back a little and reflect. But when a pair is engaged, theres no real breather to talk of – its a continual every rolling train of design ideas, forward thinking, code-reviewing and programming to carve the features into the system. When this process hums along like a spinning top, the energy required by the participants is greater than when working alone (certainly in my experience). This is all worthwhile because the idea is that the features that are being implemented are moving along at a productive steady pace and the quality of that work is second to none.

Even when pair programming is not used, there are other practices that actually support this steady train of relentless progress throughout the day, such as TDD (test driven development).  TDD as a practice and a design process can with experience become a profound tool to develop a system with, but its impact on the way its followers think and work, alone or in pairs, should be considered when reviewing the 40 hour guideline.  Just like a spinning top, TDD is difficult to get right, difficult to get it humming along.  But when it does, the level of delivery and progress can be just as profound as the practice itself, creating the well known “flow” state quite easily, and generating extended periods of high concentration and focused work – times this by at least two if this is being done with pairs.

Sometimes these periods of high productivity are like streaks of lightening across the sky, and the amount of progress in a working week might feel small and unproductive. Ignoring the human element that causes the daily mental, emotional and phyisical states of your workforce to fluctuate, a well running team should be able to accommodate and self-organize to help maintain its steady momentum, and the troughs should be less acute.  And this steady pace is built on the high focus developed from the XP practices and open working environment.  When things are truly rocking, it is not uncommon for me to arrive home absolutely exhausted.  But its a positive exhaustion, because its the effect of a causation that itself is positive.  I can wake up the following morning bright and early and be 100% ready for a day riding the development train, and this is part of the point behind the 40 hour guideline.  Happy people are more productive.  Being more productive further fuels happiness and well-being of the team, because they are riding on a wave of positive steady delivery.

The 40 hour week guideline is in the end just a guideline, and it should be appropriately changed to suite your environment.  But its a worthwhile principle of XP and other agile practices because if things are going well, progress will be steady and moving and theres no need for fever pitch.  If this isnt the case, if productivity is not as high and you’re thinking of increasing the hours to get more work out, it might be that other parts of the process arent working like they should be.  Increasing pressure to work longer hours might seem like the easiest approach, and in some cases it can be.  But there should be no need when the team has developed the steady pace.

  1. That’s an excellent observation. I think that the Industrial Revolution has a lot of lessons to teach us today, if we bother to revisit it.

  1. June 10th, 2007

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: