I can provide a little information on this based around how my company has implemented it and how we have struggled.

At my company we implemented it as a recruiting tool and as a way to keep engineers skills sharp. There are also some potentially interesting reasons to keep utilization from getting too high to better facilitate context switching. That answer also has several good guidelines around 20% time and some additional references that further support his point.

We are not basing what we do around the points mentioned there, but I do think it is worth reflecting on if you are trying to implement your own 20% time at a company.

We have a few basic guidelines around what people's 20% time can be used for. It should be something that generally contributes to the company (including to the culture we are trying to build) or to your own professional development. So spending time learning a new programming language is awesome, using the time to learn guitar is not.

We also hold regular presentations, and if you are taking the time then you need to also give a presentation as to what you were working on. This keeps the 20% time productive. Some things we have found 20% time especially good for:

• Prototyping ideas or playing with technologies we aren't yet ready to put into production.
• Keeping skills sharp.
• Recruiting great people.
• Provide an opportunity for engineering to build effective proofs of concept that can get product-level support.

As far as allocation, we've tried several different things.

Time Per Week

The idea here is that 1 day a week is dedicated to side projects. Essentially the "if you're allocating 20% to a Friday every week" approach to the problem. We tried this implementation first, and ran into several immediate problems:

• Many interesting challenges are not conducive to working on for one day. It takes that long just to familiarize yourself with what you are doing.
• If you were running even slightly behind on any given task, you didn't take it… which frequently meant that you never took 20% time. Rolling over was problematic, because frankly, if you are tracking it with a time sheet at that level something has gone wrong.
• Not very predictable from a planning standpoint, because while Fridays were common they weren't universal, and you didn't know who would be taking it or whether they would actually take it.
• It did help more with planning, because it helped prevent people from putting their personal velocity too high if they put in an automatic 20% buffer.
• For the most part, it never got used.

One Iteration Out of Five

We worked for a long time off of two week iterations. So the next implementation of the idea was that you would spend one iteration out of every five working on whatever side projects. This worked reasonably well–substantially better than the previous version. Some considerations:

• This made things very predictable from a product standpoint. You knew exactly what weeks you would lose and could schedule around that accordingly.
• On the other hand, scheduling conflicts were common because a team would be scheduled for a release the week after and need to get mock deployments or last-minute testing done. So they would frequently find their schedule moving around, and they could easily disrupt someone else's 20% time because of the need for their expertise on the deploy or the code.
• It didn't really help with the utilization problem.
• Teams that didn't have perfectly synced iterations (none of us did) couldn't really effectively work together on larger or more interesting projects.

One Week Out of Five

Then we started moving to a kanban system and started thinking in weeks instead of iterations, so we transitioned between 1 iteration out of five to one week out of five.

• Conflicts with deployments were more common (frequency), but generally generated lower impact since it was easier to block off a week than it was to block off two weeks.
• Since everyone was working week-by-week, it made it easier to sync up with other teams.

Other than that it was very similar to one iteration out of five.

Time blocks per quarter

This is the current system that we are trying. The idea here is that you set up tasks for yourself on the kanban boards with the amount of time allocated to them that you get for the quarter. Time does not roll between quarters, but you can take it all up front or all at the end, or in smaller chunks as you see fit. This lets individuals and teams figure out what would work best for them based on their release schedule, and also to take time in more or less than a one week increment depending on their schedule, what they are trying to do, etc.

This solves a lot of the problems we encountered before, but it has the disadvantage that time has to be more closely managed and is harder to precisely predict. On the other hand, it can be had at a lower level of disruption.