Research Time

In recent newsletters, I've focused on foundational ideas. This time I'm going to explore a simple, yet valuable technique that you can start using immediately.

I've introduced this technique a number of times and it's paid off each time. The idea is "research time." Just two weeks after introducing research time, the product manager for a recent client told me that the research time was the most valuable time the team spent, and asked if we could double it!

Like any technique, the success of research time depends on your situation. It's easy to try: give your developers half a day every week to indulge in self-directed technical exploration. Be completely hands-off. If you're concerned about people goofing off, ask that they share what they've learned in a peer discussion. I like to provide lunch the following day for informal discussion.

Research time works because developers are typically motivated by a desire to do good work, particularly when they're self-directed. Most developers' natural desire is to make their lives easier and to impress their colleagues. As a result, the work done in research time often has a surprisingly high return for the product being developed.

I particularly recommend research time for teams using Extreme Programming (XP). XP teams are highly focused on delivering results for near-term deadlines. This focus is great for reducing risk and motivating people to excel. On the downside, such tight focus can lead to tunnel vision. Dedicated research time gives developers a chance to widen their range, often leading to insights about how to develop more effectively.

When introducing research time, you may encounter resistance from developers. "We don't have time to do that," and "we're paid to develop software, not experiment," are reactions I've heard. One way to overcome this resistance is to just try it for a month. Decide on a specific time for research every week. In the beginning, you may need to remind developers that it's time to set aside their regular work. By the end of the month, the negative attitude will have evaporated.

Research time only works if developers are strict avoiding about interruptions. At half a day once a week, research time is scarce. It's hard to accomplish much in just half a day and it's easy for people to think of research time as catch-all for postponed meetings. Help developers take the time seriously and remind them not to work on production code during research time. Remember, the goal is innovation, and that requires blocking out the normal pressures of work.

Finally, encourage developers to create software that demonstrates the ideas they're researching. Writing software will force developers to explore and understand their ideas more deeply. Avoid making software that's usable; that will take too much time away from the core ideas. Instead, just demonstrate concepts in small throw-away prototypes. If an idea is useful, it can be expanded upon during normal work hours.

Research time is a small idea that usually shows benefits within a month. You can start doing it right away.

  • Set aside a specific half-day every week for research time
  • Give developers permission to work on any technical topic of interest
  • Don't direct the developers' research
  • Provide time for discussion afterward, such as lunch the next day
  • Keep research time focused: screen interruptions and avoid production code
  • Use small pieces of software to learn and demonstrate concepts

I've been consistently impressed by the amount of value teams get out of research time. I hope you are too.

(Research time is based on an idea John Brewer suggested on the Extreme Programming mailing list in 2000.)

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.