I have faced this problem yet again recently and wanted to share two approaches that I have found useful: swarming and reserves.

Swarming

The basic idea behind swarming is to throw extra people at the outstanding work necessary to meet the milestone. In project management terms this typically involves sacrificing effort (budget) to save time (schedule). Effort is typically sacrificed due to two factors. First, more than the optimal number of people are working on one piece of work and some effort is lost through extra coordination. Second, people get involved doing work outside their normal expertise and thus require more time than normal.

An example of swarming is a scrum team pulling together at the end of an iteration to finish their committed stories. Developers could pair up to more quickly resolve the remaining defects. Once done testing their own functionality testers could jump in to help test other features they are unfamiliar with. Business analysts can delay working on future requirements to help test.

There are a couple of guidelines to swarming effectively. The first is to focus on the critical path - the activities that are predicted to take the longest and drive what the final completion date will be. This is typically accomplished by pulling people off of non-critical-path activities, but you have to be careful that you do not inadvertently slow down something else so much that it then becomes critical path.

The second guideline is similar: focus on work necessary for completing the milestone instead of non-milestone-related work. This may seem obvious, but in practice it is surprising how people will tend to choose the more interesting tasks over more tedious but necessary tasks (for example, updating end-user documentation prior to release). One way of achieving this focus is to clearly define what is part of the milestone versus what is not. One team I know uses a task board with post-it notes colored by release to visualize this.

Swarming only works when you have people on the team who are available to swarm - i.e. not all busy on critical path and/or milestone work. This leads us to the topic of reserves.

Reserves

The basic idea behind reserves is to hold back a portion of some type of resource so that it is available if an unforeseen situation arises - usually a problem, or sometimes an opportunity.

One very common approach is to set aside a period of time in the schedule as contingency. This may be an extra iteration per release, an end-of-release iteration to finalize the software for release, or simply extending the original estimated schedule by a certain percentage.

Another approach is to ensure that the team members are working normal hours - i.e. no overtime. If a time crunch does occur, then a short burst of overtime acts as a reserve. You have to be careful using this approach, as too much overtime is dangerous. You need to allow time for recovery afterwards, once the milestone is met, or risk disengagement, reduction in productivity, burnout, and loss of personnel.

A more advanced version of this approach is to ensure that each person is not normally 100% busy, as espoused by the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco. It is suspected that this is one of the reasons that companies such as Google provides 20% time for each employee to pursue personal projects. The first benefit of slack is that this minimizes time to completion by reducing delays due to work waiting in queues (as per lean theory). This thus reduces the chance of needing to struggle to meet a milestone in the first place. The second benefit is that, like overtime, people have the capacity to increase their efforts if a milestone is threatened

A related approach that has worked well in my own experience is to have some project members normally be assigned part time with flexibility in how they spend their non-project time. During crunch periods they can then easily increase the percentage of time they spend on project work.

I would like to hear your experiences regarding swarming and maintaining reserves - please share by leaving a comment.

I generally do not like operating in crunch mode, and I think it should be avoided whenever possible. The time 'saved' while in crunch mode is spent plus more afterwards reacting to and cleaning up the problems that the crunch has introduced. This is especially true for enterprise business applications, which are typically expected to be used and maintained for years. In this context, forcing a crunch mode to make a release a few weeks earlier is a questionable strategy. I have heard many stories of what I consider artificial crunch mode, where the imposed time constraints causing the crunch are arbitrary, frequently imposed by management for apparently no rational reason. Poor project management sometimes leads to crunches due to problems like overly optimistic estimates. Even with the best managers, however, crunch mode can still happen due to changes or events imposed by third parties like senior management, marketing, or the client.

If we cannot entirely eliminate crunch mode, how then can we lessen its negative impact? In my article on understanding project schedules I described the four factors that determine a project schedule: time, resources, scope, and quality. In crunch mode, the time and resources are typically fixed and insufficient for the amount of work to be done (the scope). I believe the main priority is to avoid taking shortcuts which comprise quality, as that is the most expensive to rectify afterwards. The best strategy is to minimize the scope as much as possible. While it is seldom possible to cut entire features, it is often possible to negotiate on specific aspects of each feature. Often slight simplifications in the requirements for a feature can greatly reduce the effort required. A related approach is to accept a certain number of low-impact defects in the application. This is often much less risky than rushing to fix these defects and possibly introducing new problems.

The number one benefit of working four days a week is a better work-life balance - I have more time to spend with my family. It is easier to do the many household chores that need to be done plus have personal time to spend on my own activities, such as writing this article. When I worked five days a week, the standard two-day weekend sometimes felt rushed to me as I tried to get everything done that had been put off till the weekend. With three-day weekends (since I take Mondays off), there is always at least one day to unwind and relax. This leads into another major benefit of the four-day work week - less stress. Working only four days means one less day of work stresses, and one extra day to relax and unwind. This helps prevent burnout and keeps my motivation level at work higher during stressful times. Having more time for non-work activities also helps reduce the stress of trying to balance the many competing demands for my time. So the four-day work week reduces stress in both the professional and personal aspects of my life.

There is one significant drawback of the four-day work week that you are likely wondering about. What about the drop in pay? Working four instead of five days a week represents 20% less hours worked, which corresponds to a 20% drop in pay. It is quite possible to handle this kind of pay reduction, typically by reducing your discretionary spending. You may think it is not possible, but consider that assuming 3% annual raises, you would have made 20% less than your current income six years ago. Reducing your income will also reduce some of your corresponding expenses, such as taxes and travel costs for the one day a week you stay home. However, this kind of fiscal restraint is not for everyone, and I'm not saying you should do it. I didn't - I chose a different option: keep my full pay and make up the one day a week instead.

Yes, officially I still work five days a week. How do I make up the one day a week when I am not at work? Over one year, that is 52 days. I use a variety of ways to make up this time. I receive 11 statutory holidays and three weeks (15 days) of vacation that I use. I work slightly longer than the standard eight hour work day - putting in an extra 30 to 60 minutes of overtime each day. A simpler option would be to just work ten hours a day, which over four days adds up to the 40 hours needed per week, but that is too much for me. As I wrote in my article Overtime Considered Harmful, my productivity and motivation drop too much when I work that much overtime. I have noticed, however, that I can handle slightly higher levels of overtime working four days a week than I could working five days. Assuming on average an extra 40 minutes a day of overtime works out to about 17 extra days over a year. This gives a total of 11 + 15 + 17 = 43 days, leaving 9 days (52 - 43) to make up. One final option I take advantage of is to go on-call. When I am on-call, I earn 9 hours a week for holding the phone, even if it does not ring. Many people dislike being on-call, but in my current role I am able to respond to calls from home, without traveling to the office, and the phone rarely rings. So by going on call one week a month, I earn approximately 14 more days a year. This is five more days than I need, leaving one week of vacation.

Using the approach outlined above allows me to work four days a week and still pull in my full salary. But I do have to sacrifice most of my annual vacation and be on-call. This approach will not work for everyone. Not all workplaces offer flexible work schedules, and only certain types of jobs have an on-call role. But there are many other options to arrange a four-day work week. One option is to combine a pay cut with making up time. Taking a 10% pay cut will give you one day every two weeks, which leaves only 26 days to make up a year, which is possible just with statutory holidays and vacation. If you don't want to use up your vacation, you can work some five-day work weeks - doing this once a month with a 10% pay cut leaves just 4 days to make up after holidays. Working from home might also be an option worth considering. Even if your workplace does not officially support a flexible work schedule, try talking to your manager. Especially if you are a valued employee, they will be motivated to keep you happy.

Before switching to a four-day work week, you need to decide which day to take off. I believe it is best to consistently take the same day off each week to minimize confusion for your coworkers and boss. I personally like taking Mondays off, mainly because many statutory holidays fall on Mondays. If the majority of your work involves dealing with others and attending lots of meetings, then I suggest taking Fridays off - that seems to be a favorite day for people to take off, especially in the summer, and there seems to be less meetings scheduled on Fridays than any other day of the week. I have also heard people mention taking Wednesdays off, as that would split the work week in two, but then you lose the three-day weekend.

I heard recently that research by psychologists has shown that people working a four-day work week report on average higher levels of overall life satisfaction, particularly concerning their work-life balance. This matches my experience. I recommend you give it a try and find out how well the four-day work week works for you.

Much analysis has been done to determine the correlation between software function points / lines of code and work effort. This analysis has shown that using workdays is more reliable as an indicator/predictor than using workhours. The result is that "overtime is explicitly ignored in projecting effort required to perform new work" (Slack, page 64). This means that on average, working overtime does not mean more is accomplished than working a normal work day. DeMarco identifies four reasons why overtime hurts enough to offset the effect of the added hours:

• Reduced quality
• Personnel burnout
• Increased turnover of staff
• Ineffective use of time during normal hours

(See Slack, pages 65-70 for further elaboration on these four points.)

This analysis matches my personal experience. When doing lots of design & coding, I am often mentally exhausted after 7 or 8 hours - I'm no longer at my 'A' game: I get slower, make more errors, and take longer to figure things out. I can sometimes push myself to go as long as 10 hours, but usually that only works when I've had meetings or other non-mentally-draining activities to break up my day. And I certainly don't try to do that more than one day in a row. Why not? Because I've experimented with working 9-10 hours for multiple days in a row, and I don't find it to be a maintainable speed.

Working regular overtime (more than a week or two) has a significant negative impact on a person. Factors such as increased stress, strains on family and personal relationships, less sleep, and less exercise all add up over time to affect an individual's mental, emotional and physical health. Over time, this can result in increased physical illnesses, lack of motivation, and eventually complete burnout. During my university years at a summer manual labour job, one supervisor who had been working extreme amounts of overtime (70+ hours per week for several months) had a nervous breakdown and had to be hospitalized.

This ties in to DeMarco's discussion on turnover, which I found quite interesting. He makes the point that turnover has a cost in terms of hiring & training, and this 'human capital' cost is seldom explicitly measured and tracked. A manufactoring company makes capital investments in factories and equipment in order to produce goods, and these investments are carefully tracked. Knowledge companies invest time & effort in hiring & training employees, but how often is this tracked? A quick test for managers: what is the annual turnover rate for your company / department, and how does it compare with the average for the industry? How much does this turnover cost your company? Think about this before continuing with the next paragraph. If you don't know, then try making a guess.

DeMarco mentions studies which show that "companies whose turnover places them in the best third of the sample are experiencing less than half the turnover loss of those in the worst third" (Slack, pages 67-68). The annual turnover rate was measured at 35% in the computer field as of 1990. An estimated 20% of the average company's total labor expense is turnover cost. (Steve McConnell. 1996. Rapid Development, page 293). I'm interested in seeing more recent statistics on this - let me know if you come across any.

I feel that overtime is harmful, both to the workers engaged in it, and to the company itself - especially regular overtime. As a call to action, just say no to overtime and make our industry a better place to work.

(The title of this post is adapted from the title of a famous article titled Goto Considered Harmful by Edsger W. Dijkstra.)