At Ephox we introduced the concept of Creative Coding Afternoons (or CCA) back in 2006 based loosely on the Atlassian and Jotspot Hackathons. Occuring Friday afternoon every 2 weeks, the original idea was to develop plugins for our editor based on the public APIs. Essentially do things that our clients could do. The best of these were posted on our LiveWorks! site as freely downloadable components.
Our CCAs are evolving into more advanced research that resemble 20% time, with projects spanning many CCAs. So when Atlassian announced it was going to emulate the Google’s 20% time model I was keen to see how it worked out for them.
It was with interested then that I read the recent followup on the progress over the last 10 weeks. In the post Charles reflected on their progress to date with a series of questions put to the developers.
The one I was most interested in was “How much time have you had to work on it?”. Charles summarised the responses by saying
almost all the responses were in the 2-3 day mark, and none higher.
This is closer to 4-6% for the 10 weeks they’ve been going than 20%. Why is this low?
In theory, saying to developers you can devote 20% of your time to do research/personal projects should result in 20% time being spent. The problem, as I see it, is that most project are on tight deadlines, and developers are committed to completing those project related tasks. A fact that seems to be borne out by the following response
…the biggest problem for developers finding time to work on their projects was fitting it around their scheduled work
So what’s the real problem? Well your projects are planned but no time is set aside in the schedule for 20% time activities. When your developers start working on 20% time, the schedule starts to slip, eating into “buffer” time. If the features then require that buffer time, how does the project manager deal with it? Easy, cancel 20% time.
How do we deal with this? The answer I think lies in a response to the question “if you could improve 20% time in any way, how would you?”
“Mandate that particpants (sic) have to spend 2 days a fortnight on it, otherwise it's difficult to keep the pace up to 20%”
So, when planning a project, not only do we need to put aside time for feature overruns, but also time to accommodate 20% time. Again, all good in theory but at the end of the day, as a product company, we need to deliver product. The trick is to balance the successful delivery of new releases with the obvious benefits that can come from 20% time.
I’ll be very interested in how Atlassian handles this over the remainder of their trial.
Pingback: Bookmarks about Jotspot