We allow all our UK based developers to have some time to explore new technologies, try out prototypes and clean-up things that escape the day-to-day process. Two days out of ten, seems a lot doesn't it?
How we started
We started doing our 20% time when we had two week sprints with a release each sprint. We actually had three days of testing, small bug fixing and signing things off. We didn't like starting our new stories for the next sprint as our QAs got behind and never really caught up. We decided to use this time more for clean-up but also for prototyping or trying something out. We had read of other companies doing something similar so were excited to give it a go.
One of the first times we did this we actually decided we wanted to automate all the testing of one of our systems, so that our QAs weren't bogged down for those three days. In our first 20% time, we got most of the team on board as it was painful watching, let alone doing manual testing and we wanted faster feedback on our changes.
We got a lot of the system in a state we could test it. We basically wrote a lot of a page object model and a few features to talk to it. The next 20% time it needed cleaning up, the next we had a lot under test. With a bit of work the three day test cycle was down to about one day. This would never have happened if we were trying in normal sprint time. Major win number one and something no business owner had had to wrestle against other priorities.
After this instance we have had numerous similar examples, albeit on a smaller scale, where each team has been able to try things out, with no consequence in the event of failure, and achieved great prototypes. Much of our new architecture has been tested out in these sessions, new technologies, new approaches, can people work together?
Failures, not so bad after all
Of course, we have had many failures, but maybe even that helps, we won't waste our proper sprint time. Some people ask me about rules when I talk about this. I think the key for me is that the engineers are truly given freedom to explore. If on the face of things something they are doing is completely away from what you are doing then it might seem a bit strange.
But what if they are looking to try something new and would have left your company to do so? What if they think it might be a solution but don't know how to say? What if they can use it in nine months on an urgent project? All these things can and have happened.
Fear, as always, is detrimental
Another rule, no fear, applies in many situations of course. But unlike hackathons where you feel the need to present at the end, presenting should be through excitement of the creator, not demand of the manager.
Better team as a result
I have seen our whole UK engineering group get a lot stronger through our use of 20% time. We have also been more attractive in interviews and gets very positive responses when discussing our job openings; so many developers just want an opportunity to learn and apply new skills and will leave a job to do so.
I personally now have a child, attempting to try new skills and experiment at home is proving harder and harder. This 20% time becomes more important – as a team we are trying to really get to grips with the latest trends in the development community. I just don't have anywhere near as much time in the evenings now, it is a way to stop a divide coming between your team, the ones with spare time and the ones without.
I recommend giving it some serious thought for your organisation.