The long-time readers of my blog may remember this old post: The Elusive 20% Time.  It turned out to be quite popular as people revisited it, tweeted it and struck conversations about it for a long time after I posted it.  Its text will soon appear as my contribution to the upcoming book by Lisa Crispin and Janet Gregory, More Agile Testing: Learning Journeys for the Whole Team.  For the new readers, here is the updated text (that will be included in the book), shortened, cleaned up by copyediting and less software-centric.

The topic of 20% time has become popular in creative industries in recent years.  Many have heard of companies that have 20% time or know someone who works there. One example is Google, where engineers spend 80% of their hours working on what the company requires them to do and 20% on their own projects. Or so we have been told.

A shop across town is doing it and now we want to do it too. Those who have tried to introduce 20% time in their workplaces found it surprisingly difficult. So, how can we do it? What are the dos and don’ts?  Is there some theory behind this practice?

The main reason for 20% time is to keep the average capacity utilization at 80% rather than at 100% to build in slack time. We can think of a knowledge-work organization as a system that turns requests into delivered products and services. We can then model its behaviour using queuing theory.

Theory

If requests arrive faster than the system can service them, they queue up. When arrivals are slower, the queue size decreases. Because the arrival and service processes are random, the queue size changes randomly with time.  But, on average, the queue size looks like this:

The average queue size remains low while utilization is up to 0.8, then rises sharply and goes to infinity. We can understand this intuitively by thinking about our computer’s CPU: when its utilization is low, it responds instantly to our inputs, but when a background task pushes its utilization close to 100%, the computer becomes frustratingly slow to respond to every click.

Practice

The slack – the gap between the utilized and full capacity — keeps the system responsive.  So, for those who want to have it in their organization, several practical conclusions follow immediately – and they are about what not to do:

• Cost accounting (engineers’ time costs X, but the company may not be able to afford it). The economic benefit comes from reducing the cost of delay.
• Setting up a 20% time project proposal submission-review-approval system
• Tracking the 20% time by filling out timesheets
• Using innovation as a motivator for the 20% time. While new products have come out of 20% projects, they were not the point. If your company cannot innovate during its core hours, that’s a problem!
• Relying on the 20% time to encourage creativity. Saying you’ll unleash your creativity with 20% time begs the question why you’re not creative enough already during your core hours.
• Allocating the 20% time to a Friday every week…

Those are All Don’ts, Where Are the Dos?

OK, what about doing it right? Let’s answer with the best question heard while discussing this subject with practitioners: “If 20% of your capacity is mandated to be filled with non-queue items, then you’ve just shrunk your capacity to 80%, and 80% is your new 100%. Right?” Right, “80 is the new 100″ highlights the main problem with the attempts to mandate the 20% time without understanding the theory. You want to escape the utilization trap, not to stay in the trap and allocate time differently. Utilization depends on two processes: the arrival process (demand) and the service process (capability). You can’t really choose your utilization. It is what it is because the processes are what they are. You can, however, work on the processes by improving your organization’s delivery capability and shaping the demand. As you make progress, slack will emerge.