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.

The very first thing to do to minimize email distractions is to disable in Outlook all the indicators (like the bell, pop-up that fades, and system tray icon) that announce that a new email has arrived. I have always found these annoying and disabled them years ago. (Why are they enabled by default?) Every productivity expert I have read who mentions email also makes the same recommendation, so if you are reading this now and have those indicators set stop and disable them.

Without these indicators I still found myself becoming distracted by email. A typical scenario would see me working in one of my dedicated blocks of time focused on a task when I needed to either send an email or refer to an old one. I would open Outlook, see all the new emails in my inbox, and get distracted with reading and/or responding to them, especially if they were marked high priority. (This is the classic mistake of doing the urgent instead of the important.) So I tried a number of approaches.

First I tried to figure out how to send an email without opening Outlook. I wanted a shortcut in my Windows quick launch bar to do this, but what would have been trivial in an Unix environment turned out to be surprisingly difficult. In fact, I couldn't figure out how to do it using a command-line script, and I wasn't about to spend the time required to write a .Net program to do this. (If you know how to do this or know of such a program please let me know.) The best workaround I found was to invoke the Windows Run command (normally found in the start menu, it can be invoked by the shortcut of the Windows key + R), and type in the command "mailto:". The extra keystrokes were enough to prevent me from adopting this as a regular practice, and this didn't help anyways when I needed to reference an existing email.

Next I tried to figure out how to have Outlook check for incoming emails less often. I found a number of settings that seemed relevant, but they had no effect. New emails were still detected in less than five minutes. I was not sure if I missed the correct setting in Outlook, or if it was taking its email-checking configuration from the Outlook server. (If you know, please pass along the information via a comment.) In either case, I was pretty unhappy with Outlook. I considered simply shutting it down, but I needed it running in order to provide reminders for all the meetings I had scheduled throughout the day – including reminders for my personal design times.

I finally found a workaround through a coworker – switch Outlook to offline mode, and it will no longer check for emails. When offline Outlook does not send emails either, which was mildly annoying but a limitation I could live with. It took me less than a week, however, before I discovered another major limitation: while in offline mode changes to my schedule would not be communicated back to the Outlook server (and become visible to others) after I went back online. I discovered this via a not-so-amusing exchange with a coworker who was trying to book a meeting with me for an afternoon he saw as free that I had booked something while offline. The workaround to this annoying problem was to discipline myself to treat my calendar as read-only while Outlook was offline. Despite all the issues, offline mode worked quite well for me.

Recently, I have become more disciplined about remaining focused during my solo blocks of time and have found myself using offline mode less often. This seems to work best for me when I am crystal clear on my priorities (usually due to an impending deadline), so when I do see an email that would normally distract me I immediately think "not a priority" and file it for actioning later. There is usually a small amount of mental effort / distraction involved in scanning the email and making this decision, so it would be better to not have the emails come in until I want.

What approaches do you use to avoid getting distracted by email? I would love to hear your ideas, so leave a comment below.

Use a "Do-Not-Disturb" Indicator

My first approach involved trying to prevent people from dropping by my cubicle and distracting me. I placed a sign marked "Do Not Disturb" on the back of my second chair. When I did not want to be disturbed, I moved the chair so that the sign on the back was visible to anyone approaching my cubicle. I informed my coworkers of what I was doing and they were generally (but not entirely) supportive. This approach helped, but had a number of limitations. Coworkers having a discussion in an adjacent cubicle were sometimes distracting, especially if they mentioned my name or if they were discussing a topic I found interesting. I had to learn to remember to put out the chair when I needed to concentrate – sometimes I forgot. I had to learn to stay focused and not let myself get distracted by other conversations – this takes discipline and I find is an ongoing battle. Coworkers sitting adjacent to me had to learn to be careful asking questions to me over the cubicle wall, as they could not see whether I was in do-not-disturb mode. The biggest limitation, however, was that it did nothing about all the meetings I was being scheduled in. Some days I was scheduled in meetings for most of the day, with only small gaps of an hour or less between meetings.

Block Personal Time Between Meetings

The multitude of meetings prompted my next approach, which was to block off time – a minimum of 1.5 hours - in my Outlook calendar between meetings for my own solo design tasks. Doing this also helped with my previous approach: when the time for one of these blocks started the Outlook reminder prompted me to deploy the do-not-disturb chair and focus on my design tasks. The downside of this approach to my team members is that I became much less accessible, either for impromptu drop-ins or for scheduled meetings.

Schedule "Please-Disturb" Times

To address this issue of reduced accessibility I adopted a practice that ironically is the opposite of the previous one: I scheduled "please-disturb" times (in Outlook) during the week for team members to ask questions and get feedback on their work, and communicated these times to the entire team. While I wanted to ensure I was still available to the team, I hoped that having a scheduled time to talk to me would reduce the number of unscheduled drop-ins. In practice this saw mixed results for obvious reasons: team members with questions or needing a review sometimes did not want to wait a day or more, potentially impacting their ability to get work done, in order to wait for a scheduled time. But the approach did work in guaranteeing a certain amount of availability to the team.

Block Personal Time First When Most Productive

After a while using the approach of blocking personal time between meetings I started to notice some patterns. I always seemed to be most productive first thing in the morning rather than after one or more meetings. After meetings my mind is less fresh and I am sometimes distracted by issues discussed in the meetings. Plus I personally have a higher energy level in the morning than the afternoon.

So the idea occurred to me to schedule blocks of personal time first thing in the morning when I am most productive and best able to focus. I also aimed to make these blocks longer – at least two hours and preferably three – than the blocks of time I was scheduling between meetings. I found scheduling these blocks in the current week hard due to meetings, so I started scheduling then in advance. First I scheduled them just for the next week out, but I found this insufficient so I switched to scheduling them a month in advance, and in some cases set up reoccurring events in order to permanently block certain mornings. I then sent an email out explaining what I was doing and that I would be unavailable for meetings most mornings before a certain time.

This approach did cause grief for people trying to schedule a meeting with me as it became much harder for them to find time for me. I have had to make compromises – typically by sacrificing part or all of a blocked morning to important meetings. But otherwise I am very pleased with the boost in productivity I have experienced as a result.

A logical extension of this approach is to expand this practice out to the entire team, so that everyone has the same meeting-free and interruption-free blocks of times throughout the day. I have heard of this being done but have never tried it, partly because other team members typically have far fewer meetings and drop-ins than me. If you have been part of a team that has tried this, please leave a comment describing your experience.

1. Say No To Meeting Invites

The best strategy that I find the hardest to use is to turn down meeting invites. Being asked to attend a meeting is often an acknowledgment that your input is valued, especially the more senior the other attendees. Furthermore, meeting with senior technical or management people is often beneficial for your career, while repeatedly turning down such meetings is not. This produces a natural inclination to want to attend meetings. To combat this, I ask two questions to determine if the meeting is worth attending:

• Can I reasonably expect to make a useful contribution at the meeting? In other words, will others benefit from me attending the meeting?
• Can I benefit from attending the meeting?

If the answer to both of these questions is no then it becomes easier to decline the meeting invite. Unfortunately, few meetings meet this criteria.

2. Leave Meetings That Do Not Deliver Value

If you are in a meeting that is not providing any value for you being there, then one option is to get up and leave. Your ability to do this will depend on your role in the meeting and your corporate culture. I have heard that at ThoughtWorks it is considered acceptable and normal for anyone to leave a meeting at any point if they do not feel it is worth their time to be there. The organizations I have dealt with have not had such enlightened cultures, but I have used and have seen others use this strategy at times. This strategy works best when you are an optional attendee.

3. Tentatively Accept, Then Choose When To Go

Regularly scheduled status meetings are a significant percentage of the meetings I am asked to attend. This is especially an issue with being on multiple projects when each has one (or more) regular weekly or biweekly meetings. The biggest problem with regularly scheduled meetings is that they consistently use up your time, week after week, and I find that they deliver limited benefit for the time spent. One strategy I use is to only tentatively accept the invite for such meetings. This gives me the freedom to choose not to attend, whereas accepting the meeting creates the expectation that I will attend every one. This works especially well for formal meetings with published agendas and minutes. If the agenda has items that are worth my time to attend, I will, otherwise I'll just browse the minutes or talk briefly with someone else who attended.

4. Double Book Meetings

Double booking two meetings at the same time is another time-saving strategy. With two meetings scheduled for the same or overlapping times, you can choose which to go to, with an excuse for missing the other that almost every manager will accept. This works especially well when one of them is a regular status meeting that you can afford to skip. Another option is to attend a portion of both meetings. At the start of the first meeting if you point out your need to leave early, you can often get the agenda shuffled to talk about the issues requiring your attendance first. You can then leave for the second meeting having derived most of the value from the first meeting in a shorter period of time.

If your organization uses a shared calendering application that allows you to see the availability of others when scheduling meetings then using the prior strategy of tentatively accepting meetings makes it easier to get double bookings, as others will schedule meetings for when you are tentatively available. This in turn makes it easier to only tentatively accept their meeting, with the excuse that you may have another at the same time.

5. Penalize Projects For Meetings

A different strategy I use is to "penalize" projects for wasting my time in status meetings. I accomplish this by allocating a fixed number of hours per week to each project. If I only allocate four hours a week to a project, and the project manager wants me to attend a one hour status meeting each week, then that uses up 25% of my time for that project. I have at times emphasized this point. When asked in a status meeting how long it will take me to finish a task, I'll point out that I lost an hour due to the meeting, and thus have one less hour left in the following five business days to work on the task.

At this point you may be getting the impression that I think that status meetings are always a waste of time and do everything to avoid them. Not at all. Status meetings are useful for a variety of reasons, and I do attend a fair number of them. Since I am expected to produce work outside of meetings, however, I do need to ensure that I have significant blocks of non-meeting time available.

6. Schedule Meetings With Myself

It seems ironic that one solution to too many meetings is to schedule more, but it works. When I absolutely need to get a piece of work done, I'll schedule a meeting just for myself to work on the task. This strategy works best when your organization uses a shared calendering application such as Microsoft Outlook that allows you to see the availability of others when scheduling meetings. Other people trying to schedule a meeting with you will see that your schedule is busy and change the meeting time to accommodate you. If the topic is urgent, people may decide to meet anyways without you. In order to make progress on significant work tasks, I sometimes schedule full-day meetings one or more days in a row. The downside with doing this is that the next few days afterwards tend to completely fill up with meetings if I am not careful.

There are several variations of this strategy that I use as well. When others want me to review a design or document with them in a few days and ask when I will be available, I tell them to schedule a meeting with me. This ensures I'll have a block of time available that day to meet and go through what they want reviewed, rather than waiting till that day and risk having it fill up with other meetings. When I am waiting for others to do some tasks for me, and not seeing results for a significant period of time, then I will schedule a meeting with them which they will invariably accept. When they come to the "meeting", I review the tasks I am waiting for and then explain that the next hour (or however long the meeting is) is for them to work on these tasks. My logic is hard to turn down: if they had the time to set aside to meet with me, then they have the time to do my tasks.

Too many meetings can sap your productivity and prevent you from achieving the state of flow when working on a design or coding task. So a necessary component of managing your time is to manage your meetings.

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.)

The same concept is discussed in the book First Things First by Stephen Covey, which I highly recommend reading. In First Things First tasks are classified according to two dimensions: importance and urgency. Covey says that we should spend our time on the important tasks before addressing the unimportant. This seems obvious, but he explains that the natural tendency is to address the urgent tasks, whether or not they are important, which leaves one with no time for the non-urgent yet important tasks. Part of the difficulty is determining which tasks are truly important: this is aided by having a clear set of goals.

Of course, thinking about goals and the importance of tasks takes time. And if you are 100% busy with urgent tasks (i.e. always fighting fires), then you probably feel like you can't afford to spend this time. In reality, if you are that busy, then you can't afford to not do this, or else you risk never completing some (all?) of the important tasks. I view the time spent thinking about goals, objectives and task importance as a planning component of time management. Planning is usually considered a management activity, and everyone needs to manage their time. So if you aren't doing any planning at all of how you spend your time, it probably is not well managed.

I think that the points DeMarco and Covey make mesh together quite well. You need to regularly review and update your goals and objectives based on changing circumstances, both internally (i.e. completing some objectives) and externally (i.e. new technology, new competitors, new market). You also need to reflect on your work - the importance of your tasks, how you work, and improvements that can be made. However, I really don't like calling this slack time - I consider it an integral part of professional software development.