Your browser does not support inline frames or is currently configured not to display inline frames.

Rapid Development: Taming Wild Software Schedules. Redmond, Wa.: Microsoft Press, 1996. 660 pages. Retail price: $35. ISBN: 1-55615-900-5. Available from Microsoft Press 1-800-MS-PRESS (1-800-677-7377).

Buy Rapid Development from Amazon.com.

Chapter 43
Voluntary Overtime

Too much overtime and schedule pressure can damage a development schedule, but a little overtime can increase the amount of work accomplished each week and improve motivation. An extra four to eight hours a week increases output by 10 to 20 percent or more. A light-handed request to work a little overtime emphasizes that a project is important. Developers, like other people, want to feel important, and they work harder when they do.

43.1 Using Voluntary Overtime

Overtime is misused more often than it's used effectively, so keep the following guidelines in mind if you want to get more than 40 productive hours per week out of your team members.

Use a developer-pull approach rather than a leader-push approach

Trying to motivate developers can be like trying to push on a rope-you'd be better off pulling on the other end. Gerald Weinberg points out that one of the best known results of motivation research is that increasing the driving force first increases performance to a maximum, and then drives it to zero (Weinberg 1971). He says that the rapid fall-off in performance is especially observable in complex tasks like software development: "Pressing the programmer for rapid elimination of a bug may turn out to be the worst possible strategy-but it is by far the most common."

When motivation is low, it also doesn't matter how much time people spend at the office. You won't get 40 hours of work out of them. They'll put in time just to keep up appearances or to avoid feeling bad about not meeting their deadlines.

As Figure 43-1 suggests, developer motivation with average schedule pressure is already high. A nudge is all you need to achieve maximum performance. Additional pressure causes a fall-off in performance.

Figure 43-1. Optimum zone for schedule pressure. A nudge is all that's needed to achieve the highest possible motivation. Source: Adapted from Applied Software Measurement (Jones 1991).

It's OK to ask for a little overtime; just don't ask very hard.

Developers are naturally self-motivated, so the key to getting them to work overtime is to tap into their naturally high self-motivation. Create conditions that will make them want to work extra instead of forcing them to. Generally speaking, the top five ways to motivate developers are:

Achievement. Give developers an opportunity to achieve something significant.
Possibility for growth. Set up the project so that developers can grow both personally and professionally.
Work itself. Assign tasks in such a way that developers find the work to be meaningful, feel responsible for the outcome, and can see the outcome.
Personal life. Show developers that you respect their outside interests.
Technical-supervision opportunity. Provide each developer with the opportunity to provide technical leadership in some area.

One of the most effective ways to motivate developers is to infuse the entire development team with excitement. Set a clear vision for what the team is supposed to achieve. Help the team develop a sense of team identity. And let the team know that results count more than hard work.

The importance of a results focus is one of the main reasons that leader-push overtime doesn't work. A focus on the number of hours a person spends at the office puts the emphasis on style rather than substance. On a rapid-development project, you need to focus on how much work is getting done. If people are meeting their deadlines and motivation is high, it doesn't matter whether they're in the office 50 hours or 25.

Don't require overtime; it will produce less total output.

Here is one of the possible objections to Figure 43-1:

"Sure, motivation decreases as you crank up the overtime. But the developers will be working more hours, so on balance the extra time will more than make up for the loss in motivation. Their total output will still be greater."

To understand the flaw in this argument, understand the following three points:

Most studies have shown that motivation is a stronger influence on productivity than any other factor (Boehm 1981)
Pushing developers when they are already motivated causes a sharp decline in motivation (Weinberg 1971)
The average developer is already working at close to the maximum level of motivation (Jones 1991)

The problem with pressing for more overtime than developers want to work is that when motivation begins to drop, it doesn't just affect the 10 or 20 overtime hours. It affects the 10 or 20 overtime hours plus the 40 regular hours. When you press for overtime, you lose productivity in motivation faster than you gain it in overtime. Figure 43-2 shows the relationship between schedule pressure/hours worked, total output, and developer motivation.

Figure 43-2. Relationship between schedule pressure/hours worked, total output, and developer motivation. If you apply more than a hint of overtime pressure, motivation will drop sharply. Because you lose output faster in motivation than you gain it in extra hours, total output drops too.

As the figure shows, the total output peaks at the same number of hours per week as developer motivation. Because motivation is the strongest influence on productivity, as motivation drops off, total output drops off too. It doesn't drop off as sharply because the drop in motivation is partially offset by the increased number of hours worked.

The implication of Figure 43-2 is startling: Beyond the number of hours that the average developer will work voluntarily, you will reduce total output if you push for more overtime. It doesn't matter what your reasons are or how good they are unless your developers are as impressed with them as you are. If they don't buy your reasons, their motivation will drop and more overtime will result in less progress.

We all know of circumstances in which managers push so hard for overtime that developers work 60 hours a week or more, and sometimes in those circumstances more hours truly does result in more output. The reason for this is that once motivation hits rock bottom, it becomes possible to improve total output by demanding more overtime. The motivation can't get any worse and the hours go up, so the developers produce more total output. In Figure 43-2, that would be a part of the graph that's not shown, the area to the right of very high schedule pressure. The problem with that practice is that it's penny wise and pound foolish. The overzealous manager who insists on that much overtime would gain far more by backing off a lot than by pushing for a little more.

Don't ask a developer to work more overtime than he or she wants to work. Developers are like cats. If you push them in one direction, you can't predict which way they'll go except that they won't go in the direction they're pushed. If you need to get more done, come up with a different solution.

The specific number of hours per week that's correlated with maximum output varies among projects. Some highly motivated developers work 35 hours. Others work 80. The average in the U.S. is probably somewhere between 44 and 48. Regardless, the key to maximum output is to aim for the highest possible motivation regardless of how much or how little overtime that implies.

Don't use overtime to try to bring a project under control.

When a project is perceived to be out of control, requiring developers to work more overtime is one of the most common things managers and team leads do to bring the project under control. But overtime is, in itself, a sign that a project is out of control. Projects that are under control do not require developers to work overtime. Some developers might work overtime because they are highly interested in their project, but they do not need to work overtime to meet their deadlines.

Ask for an amount of overtime that you can actually get.

Opinions vary about how much time programmers can spend working. John Boddie, author of Crunch Mode, says that once the project gets rolling, you should expect members of the team to be putting in at least sixty hours a week and up to 100 hours per week for a few weeks at a time (Boddie 1987). On the other hand, Microsoft veteran Steve Maguire argues that people who work that many hours tend to sandwich personal tasks into their workdays. They take longer lunches, exercise, run errands, pay bills, read computer magazines-in other words they do a lot of things at work that they would do on their own time if they were working only 8 hours a day. Maguire concludes that people who spend 12 hours a day at the office rarely actually work more than 8 hours, although he acknowledges that a self-motivated person will occasionally work more (Maguire 1994). Other experts have also concluded that you can't expect to average much more than eight hours per day (Metzger 1981, Mills in Metzger 1981, DeMarco and Lister 1987, Brady and DeMarco 1994).

I don't know what effect schedule pressure has on the amount of time people spend working. I have often seen what Maguire describes. I have seen people work 50 hours per week for months at a time. I have occasionally seen people work as much as Boddie describes, although only for a week or two at a time.

If you're asking developers to work voluntary overtime, watch how much time they actually spend working. If lunches start to drag on and people start to arrive late at meetings because they have been running errands, you have asked for more overtime than the developers are giving you. Back off. You're driving developer motivation out of Figure 43-1's optimum zone.

An alternative to simply backing off is allowing the developers to cut back to 40 hours per week while you insist that they actually work each and every one of those 40 hours. That position is inherently fair and reasonable on a rapid-development project, and I think it often produces more real work hours than asking for overtime does.

Beware of too much overtime, regardless of the reason.

By far the greatest problem associated with moderate overtime is its tendency to drift into excessive overtime. That's a systemic problem with any kind of overtime, voluntary or mandatory. It doesn't seem to matter whether the pressure to work massive overtime comes from within or without, excessive overtime and the excessive schedule pressure that accompany it lead to the following schedule problems:

Increased number of defects
Increased incentive to take unwise risks
Reduced creativity
Increased burnout
Increased turnover
Reduced time for self-education and organizational improvement
Reduced productivity

Help developers pace themselves. Even if no one is forcing developers to work too much overtime, they can sometimes force themselves to work too much. When that pressure comes from within, it doesn't have a motivational penalty, but it will likely have an effectiveness penalty.

Have you ever watched sprinters run the 100-meter dash? When they're done, their chests heave, their skin is blotchy, and sometimes they're even sick. If runners were to begin a marathon at that pace, they wouldn't finish.

In track and field events, distance runners pay an average-speed penalty for top performance over longer distances. As Figure 43-3 shows, the world-record holder in the marathon runs only about half as fast as the world-record holder in the 100-meter run.

Figure 43-3. Average speed of world-record holders in running events of various distances. As with running events, software developers should pace themselves differently on long and short projects.

Likewise, sprinting for a few weeks is not an effective way to begin a major software-development project. Developers working on a 100,000 line-of-code project are not as fast as developers working on a 5,000 line-of-code project. There is more interaction with other developers because there are more people on the team, and there is much more integration work. The effect is that per-developer productivity on projects of different sizes varies similarly to runner's speeds at different distances, even when you have world-class developers.

You might be able to plan on six- or seven-day weeks if you can sprint to a deadline a few weeks away. But if the deadline is six months away, you'd better be on the verge of discovering a cure for cancer or preventing a space-alien invasion of the earth to ask for that kind of sacrifice. Otherwise that kind of sprint will just be a prelude to burnout, high turnover, and a longer schedule.

43.2 Managing the Risks of Voluntary Overtime

Most of the risks associated with moderate overtime are the risks associated with excessive overtime and schedule pressure. Those risks have been discussed in the previous section.

Reduced capacity to respond to emergency need for still more hours. The only remaining risk is that scheduling overtime taps into your reserves. If you plan to complete your project by working 40 hours per week, you can ask for overtime when you run into trouble. You can probably ask for it without worrying whether you'll hurt motivation. But on a project in which everyone is already working overtime, you can't ask for more without hurting motivation and reducing productivity, which means that you actually don't have any room to maneuver.

To avoid this problem, use moderate overtime only as a corrective measure. Don't plan from the outset of a project to have developers work more than their nominal schedules. If you do run into trouble, you'll be able to tap into reserves and put the project back on track.

43.3 Side Effects of Voluntary Overtime

Moderate overtime has no side effects on quality, usability, functionality or other product or project characteristics.

43.4 Voluntary Overtime's Interactions with Other Practices

Used poorly, requests to overtime can lead to excessive schedule pressure ("Excessive Schedule Pressure" in Section 9.1) and all its problems.

Because developer-pull overtime is the only way to be successful in using overtime, it's intertwined with motivational practices (Chapter 11) including signing up (Chapter 34) and teamwork (Chapter 12) .

Moderate overtime is usually also needed to support miniature milestones (Chapter 27), timebox development (Chapter 39), evolutionary delivery (Chapter 20), evolutionary prototyping (Chapter 21), and other development practices that make use of frequent deadlines.

43.5 The Bottom Line on Voluntary Overtime

If the average developer spends 40 hours per week at the office, some research indicates that only about 30 of those hours are productive (Jones 1991). When that developer is asked to voluntarily work a moderate amount of overtime, say 10 percent, two things happen. First, the developer spends 4 more hours per week at the office, which by itself increases productive hours from 30 to 33, if the proportion of productive hours to work hours is held constant. Second, the developer attaches a greater sense of urgency to the job at hand and can often find ways to increase the number of hours worked per day from 6 to 6.5 or more. Thus, the productive hours have increased from 30 to 35.5, which is an 18-percent increase in output for a 10-percent increase in hours spent at the office.

The bottom line on moderate overtime is that a slight increase in hours worked per week beyond the nominal, say 10 to 20 percent, will usually result in a disproportionately large increase in productivity.

For projects that start to use moderate overtime during construction or testing, overtime can help a shorten a project's overall schedule by 10 or 15 percent (Jones 1991), but beyond that the motivational penalties come into play and additional schedule reductions through overtime are not possible.

Unfortunately for many organizations, moderate overtime is a best practice that is already in widespread use or is already pre-empted by excessive, mandatory overtime. The average developer in the U.S. already works 48 to 50 hours per week (Jones 1991, Krantz 1995). Similar situations exist in Canada and Japan. This situation raises the interesting possibility that the average organization might actually increase total output by reducing overtime below its current level.

43.6 Keys to Success in Using Voluntary Overtime

Here are the keys to success in using voluntary overtime:

Use a developer-pull approach rather than a leader-push approach.
Tap into developer motivations such as achievement, possibility for growth, work itself, personal life, and technical-supervision opportunity to increase the amount of voluntary overtime that developers want to work.
Ask for an amount of overtime that you can actually get.
Beware of developers working too much overtime, regardless of the reason.