Golden Hours

I quite often talk about “Golden Hours”. I employ the practice both at work and at the Open Space Coding Days. However, I find that there are relatively few people who have heard of the practice – a fact that I find somewhat surprising given the huge amount of value that I find that it delivers. Although I can’t quite recall where I first heard of Golden Hours, I have been using the practice for about 6 years, on and off.

Background

There has been a great deal of research over the years into human concentration and productivity, much of which indicates that humans tend to concentrate in sprints. Furthermore, deep concentration seems to take time to achieve (typically at least 10 to 15 minutes) and is easily disrupted, especially by multiple stimuli. The optimum concentration period seems to be in the region of 100 minutes and few are able to maintain deep concentration beyond that.

In addition to the general research, there is a body of productivity studies (including a great deal on developer productivity). Much of this indicates that, regardless of the number of hours actually worked, the vast bulk of productive coding time amounts to about 4 hours a day.

When discussing this with developers, I find that this generally fits with their personal experience.

In Practice

Essentially, Golden Hours takes the observations made above and simply embraces them.

What does it look like in practice? I follow a regime as follows:

• Golden Hours run from 10:00 to 12:00 and from 14:00 to 16:00.
• All preparatory work must be carried out prior to the Golden Hours: all investigations and all communications must be complete. Preparation is regarded as ‘done’ when the pair who will work together are satisfied that they have sufficient knowledge to code for 2 hours without interruption.
• During the assigned Golden Hours, the developers should close all communications: shut off IM, close their email application, mute their phones and so on.
• During the assigned Golden Hours, nobody is allowed to interrupt the developers unless there is an emergency. Fire alarms count, the live systems failing catastrophically also count. Not much else counts as an emergency. This includes the CEO, other senior management and any other stakeholders. It isn’t negotiable. In reality, there is very little that can’t wait for a maximum of 2 hours.
• Depending upon your environment, there may need to be a buffer to protect the developers. In some organisations, that may involve having 1st-line tech support. In others, you may need a assign the ‘bouncer’ role to someone.

I have found that 2 hours is an excellent unit of time to work with. You can thoroughly prepare for a 2 hour coding stint in a relatively short time (I find to 30 minutes preparation time is typically sufficient). It is a length of time that external stakeholders are usually happy to live with the developers going incommunicado. Just the need to thoroughly prepare is an excellent practice that minimises wheel-spinning. Once you have bedded-in Golden Hours, I have also found that it is a good unit of time for estimation purposes – along the lines of “Assuming that you know everything that you need to know, how many golden hours do you estimate that this task / feature / story will take?”.

You may find the response to the introduction of Golden Hours surprising. When I brought the practice into MoveMe, the product owner immediately asked “Does this mean that developers can’t interrupt me during this time either?” with a big smile of his face. An excellent reminder that being unprepared and disorganised is a disruption to others.