40 Hours Work Week
David Anderson mentions that the 40 hours work week is part of the agile software development practices he used in the past. The concept of a sustainable pace has somehow gotten lost in the software development world.
Here's a little story about the importance of a 40 hour week.
When I received my freshly minted graduate degree in physics and started at a local Southern California aerospace firm writing Kalman filters for radar I was ecstatic be working for "real" money. My first job was to build an adaptive set of digital filters to capture signals that lived well below the noise in a stream of radar data. I worked hard to learn the tools, understand what the customer wanted (Air force Avionics Laboratory), and comply with all the security and operational procedures.
My 6 month review came around and I went to my bosses office. He had been a software developer on the Apollo Lunar Lander and made final updates to a "glitch" in the descent over-rate detection code while the spacecraft was fueled and ready to fly. This fix included verbal instructions to "ignore the warning light stating you are descending too fast, the code has control and you'll be fine - trust me"
When I stated to him all the hours I was putting in, how I had "gone the extra mile" to get my work done on time, and how I was really deserving for a raise because of my over-enthusiasm for the position.
He stated is strong unhappiness with this approach to work:
- Either I'm not as smart as he thought I was when he hired me since I needed 60 hours to accomplish 40 hours worth of work.
- Or, the contract was losing out on 20 hours of billable revenue, since they were only charging 40 hours while I was working another 20 hours "off books."
Either way, stop working those hours, get the planning process to reflect the actual planned durations along with the effort and stay focused on delivering work for those 40 hours.
The message is clear - GOOD PROJECT MANAGEMENT REQUIRES A FORECASTABLE AND SUSTAINABLE PACE. Seems modern software development may have rediscovered this concept. I learned it the hard way in 1976 - through a less than stellar performance review. I haven't forgotten it since. Neither should anyone trying to manage a team of professionals.
