You may be familiar with Google's policy that each employee is granted 20% free time to pursue their own interests. Some projects become real Google products like GMail, Google News, Google Talk, and AdSense.
Google has nearly infinite resources, and with thousands of talented developers trying so many things, once in a while one of them is going to be a winner and create a major new revenue stream.
Obviously, TrackAbout does not have infinite resources. But we admire the spirit of Google's free time policy and would like to emulate it to the degree we can.
Around February, 2011, we created a Developer Free Time policy. We were attempting to promote creative thinking and innovation by providing developers freedom to explore new ideas and technologies through experimentation. We left it very open ended and set no expectations.
The ground rules were:
- The program is voluntary, not mandatory. You don't have to participate, but it's encouraged.
- Each developer is granted 2 days per quarter to pursue their interests/projects. Why only 2 days per quarter? We’re not Google, we don’t have infinite resources, and 2 > 0.
- No approval is required for the project.
- Feel free to use the CTO or teammates as a sounding board for ideas to pursue.
- When you've got your idea and time picked, let the PM know so they can plan accordingly.
- Teaming up is great
- A very brief write-up is expected explaining what you did, learned, or accomplished.
- If the developer (or team) wants to present their work, it's encouraged but not required.
We ran this experiment for a year and a half. In that time, we had a handful of cool micro-projects undertaken.
- Prototyped a browser-based visual workflow designer, where the workflows can be deployed to mobile devices for field data collection.
- Prototyped a mobile web version of our application web site.
- Rewrote a tiered rental rate edit dialog as a couple of jQuery plugins (which were later converted to Backbone.js).
- Studied and evaluated the ad-hoc report builder that ships with SQL Server Reporting Services to see if we could embed it in our web app.
- Evaluated several VB.NET-to-C# conversion tools to automate the expunging of the last vestiges of VB.NET from our solution (which we successfully completed during our annual Dev Con in January 2012).
Despite these successes, we found that over time, fewer developers were taking advantage of the free time. In August 2012, Jeff Atwood wrote a nice blog post about free time, and it spurred introspection.
We decided the primary reason developers weren’t consistently taking advantage of free time was perceived pressure to complete backlogs and projects as part of our regular two-week sprint cycle. We push code out to production every two weeks like clockwork. Developers said they felt guilty taking themselves out of the mix for those two days while their other teammates carried the load. There never seemed to be a good time to take the 2 days.
Leaving it up to the developers to choose when they took the time wasn’t working. It seemed like without defining a set time span when everyone could take the time off without feeling guilty, it wasn’t going to happen.
We took a step back and studied our work processes.
One criticism of Scrum and other time-boxed iterative agile practices is that they can feel like a never-ending march, one sprint after the next. Some amount of slack between sprints would help us decompress, sharpen the saw, scratch itches, do research, etc.
At the end of each two-week sprint, we observed there is a period of time during which QA is busy with testing the last couple of backlogs, as well as executing the regression test suite.
QA is also responsible for creating a knowledge transfer presentation to be given to the Support staff so Support learns about what’s changed. In some companies, the developers own this responsibility. We just happened to give it to QA, and they take all the necessary screenshots while they’re executing acceptance tests. This does, however, keep them busier at the tail end of the sprint.
Developers whose work was complete were starting breakdown and analysis of the next sprint. With QA tied up, developers were getting ahead of QA, which created problems downstream when they had to sync up. Ideally, developers, QA and BAs would all be working in tandem whenever a new work item is started.
Also ideally, QA and developers would finish at the same time, and the entire regression suite would be automated. That’s a goal of ours, but we’re not there yet.
Given all the above, our new approach is to institutionalize self-directed time by having it at roughly the same time for all developers. So we defined the rule that self-directed time may be taken during any 4 hours on Thursday or Friday, in weeks when a sprint is ending. Why only 4 hours? Because we’re not Google, we don’t have infinite resources, and 4 > 0.
If you do the math, four hours every two weeks is a “5% free time” policy. Is it enough? Time will tell, and we’ll adjust if we’re not happy with it. Four hours per sprint is more time than our “2 days per quarter” policy provided. The old policy came out to around “3.2% free time”. Furthermore, by occurring more frequently, we theorized it’s more likely that the developers will be able to maintain some momentum by stringing together gains from sprint to sprint.
Why not just pick either Thursday or Friday? Sometimes on the Thursday before a release goes out, developers spend a variable amount of time working with QA to finalize testing on the final backlogs to be completed. So developers may or may not have free time available on Thursday, depending on how things are going with final QA.
Pros and Cons
- Provides a respite from the inexorable march of sprints.
- Provides autonomy, and a chance to sharpen the saw or scratch an itch.
- The fact that self-directed time will occur around the same time for everyone should alleviate guilt or pressure that you're increasing the burden on others.
- Reduces developers leapfrogging over QA into the next sprint.
- Occurs more frequently than "once a quarter" which was the previous policy.
- A half day every two weeks might not be enough time to make significant progress on a complex project.
- Projects that require QA involvement could exacerbate the downstream problem, and so should be considered carefully.
- Self-directed time might mean less time completing prioritized work items or paid work, but on the flip side it might mean a more optimized flow of work which could make a better product. Difficult to say definitively.
Results Since August
Since starting the new policy, several developers have teamed up and put quite a bit of work into revamping aspects of our deployment strategy.
Our deployment automation to our various staging, test, and production environments has evolved considerably over the years. Up until recently, even though largely automated, it required two individuals (one lead, and one watching his back and helping out) to execute a series of build scripts on their local workstation that would check out, build, push the code out to our various target servers, and execute the changes. Given our numerous target servers, it could take a couple of hours on a Sunday night to commit a deployment, and we deploy every two weeks. We would rotate the deployment team members to distribute the pain. Nevertheless, the developers were acutely feeling the pain of deployment and decided to do something about it.
Using developer free time, several members of the team created a new deployment service which runs on all our target servers. This service polls our build server waiting for promoted build products and downloads them as soon as they become available. This completely eliminates the time spent checking out code, compiling, packaging and transferring the build products that was previously required during deployment. We’ve shaved the two-hour deployment down to less than 15 minutes. Our ultimate goal is to make the entire process scheduled in advance and completely automated, only alerting an on-call engineer if there’s trouble.
One of our developers used his free time to rethink and rewrite how we manage database schema updates. We previously had a dependency on Subversion revision numbers for creating script file names, and this made setting file names a hassle. The developer rewrote it so that the file names were timestamp-based instead. This eliminated the dependency on Subversion and had the added benefit of moving us significantly closer to migrating all our source code to a newer distributed version control system, Mercurial.
So far, the changes we made to the free time policy have been received positively and have resulted in some great advances that might not otherwise have been given priority. I’m excited to see where this goes, and what kinds of things our developers will come up with next.
Chief Technology Officer