Using “Do Not Disturb Hours” In An Agile Environment

thumb

3rd May, 2017

Using “Do Not Disturb Hours” In An Agile Environment

Author: David Archer, Backend Developer at Codeweavers

The concept of Kaizen, the Japanese term for Continuous Improvement, is a generally well known and worthy pursuit for any company to integrate into their workflow for a number of reasons, not least of which is improved efficiency. In our workflow at Codeweavers, we implement a number of Kaizen methods and have a keen focus on improving that workflow every day to eliminate those annoying, time-consuming small jobs to improve not only our efficiency but as developers also increase our satisfaction and enjoyment of the job.

There is a strong sense of privilege that is felt working at a company that gives us one day each fortnight to work on projects that we feel would improve our processes within the company or innovative, new products. Being given this freedom without being micromanaged increases the feeling of ownership of one’s own job, and ultimately increases happiness - surely the desire of any manager, pointy-haired or not.

One of the changes that our internal Proposals Team (locally known as “Propono”) has implemented recently is the use of “Do Not Disturb” time. In general, Product and Account Managers, Customer Support staff and Directors have direct access to developers to ask questions at all times at Codeweavers, and we are generally joined in a morning by at least one member of these other teams during our morning standups.

As an agile environment, there is an argument against implementing any “Do Not Disturb” hours as it could cause bottlenecks and roadblocks in communication. However, as Eric Nehrlich has previously discussed (blog.fogcreek.com/keeping-developers-in-the-zone), there is something to be said for being in “the zone”, or a state of “flow”. In non-programming terms, it’s that incredible spot you sometimes get into while doing work where you can just concentrate and work with no awareness of the passage of time.

Continuous Improvement is a desirable thing, and the idea of improving something by simply putting up a “Do Not Disturb” sign for a couple of hours a day is a wonderful example of Kaizen in action. Before implementing the idea within my own team, I decided to see for myself how the members of the Proposals team have found this new working pattern.

Here are some of the key points from my interview with Tom Horan of the Proposals team:

Where did the idea of DND time come from?

We took the idea of Focus Time or Do Not Disturb Time from Cal Newport’s book, Deep Work. The idea that some work needs focus for long periods seemed like a good one to us, and it seemed useful in being able to deliver a lot of work quickly.

How have you implemented DND in your workflow?

For two hours a day, a period of time is allotted to focus on one to two tasks within our team. This focused period is not just limited to external teams and stakeholders not disturbing us, but also focussing on not looking at our phones, the Internet, or talking off topic. We would communicate within the team, and initially, the whole team worked on one task, but as our team size has increased we have now split into two tasks with two subteams working on each.

Have you noticed any gains in performance (e.g. code output) or job satisfaction through this?

There was lots of both. Almost right away, the number of MMF’s (Minimum Marketable Features) that we could blast through was very high, which in turn led to a very high boost in morale, and that positive feeling cycled to push us to get even more done.

Would you say that your code quality has improved through this innovation?

While I cannot categorically, statistically say that it has definitely improved our code, it does certainly feel that the code we have produced overall, and particularly during focussed time, has improved.

What challenges did you face while implementing this initially?

There was kickback from some of the other teams initially due to some miscommunication of what we were expecting to do and how we were planning to implement it. Getting out of the habit of being hyper-reactive to our environment - such as instantly looking at every error log on Gaffa [our in-house visible Continuous Integration and Monitoring system] or every support ticket as soon as it came in - was even more difficult. We just have to get used to the idea that completing the current task should take precedence.

Do you feel that this works well within the agile environment of the company?

The initial kickback was probably because of the “anti-agile” perceived nature of what we were doing, but it definitely has its place within the environment that we work in.

Are there any agile roadblocks?

Communication of what you’re doing and why to people outside of your team will smooth out a lot of what we found to be problems. We still had people walking in and asking if they could chat about a future project despite the notice on our door for example. The other ones are self-made, such as just checking your phone while running tests or waiting for a commit to go to live [a process that can take no more than 20 minutes from initial commit to going live through Gaffa].

What challenges do you feel that there still are around your implementation of DND time?

Committing to it. There was an initial big push, but some days we don’t commit to it through internal distractions as much as external.

Any advice for other teams or companies that wish to implement DND?

It is a beneficial idea, the key is the communication of that internally and to the rest of the company. This helps everyone to stay informed and can allow you to work out the best ways of working with other teams as well as within your team.



Kaizen is all about continuous improvement. As Tom has pointed out, what amounts to a very simple change has increased productivity, morale and quality, and is worth taking a look at within your own teams and workplaces to see if you can get any productivity gains.

As always with work that requires increased concentration, ensure that there is a set time. You could look at the Pomodoro technique (https://cirillocompany.de/pages/pomodoro-technique) as a first stage, or as our Proposals team have done, block out a two-hour slot. The important thing is to not be disturbed internally or externally and to focus on the work.

arrow pointer