An Unplanned Experiment


Relieving the three of all other responsibilities was also crucial. For the duration of the project, they didn't have to contribute to the department's status reports. They didn't have to attend meetings. They didn't have to face all the work-related and did-you-hear-the-one-about interruptions that were routine. They were spared all the politics, the repetitions of "just one more change," and the persistent problems and pressures that characterized so many of our other projects. They had a job to do, and that was their singular responsibility.

Sending them offsite was also critical to their success. Remaining in their cubicles with endless distractions would have been a recipe for failure. But even relocating them elsewhere in the same building would have backfired since they'd have been interrupted repeatedly with "I just need a minute of your time." Having them out of sight, if not out of mind, was significant, especially since none of us worker bees knew where they were. Otherwise, despite management's warnings to stay away, we would have been tempted to drop by just to see how they were doing.

Although this strategy wasn't intended as a grand experiment, it served as such. It was as if management had asked, "How might productivity be affected if we carried out a high-priority project under optimal conditions?"

I would have loved for the company to have treated the situation as a genuine experiment, creating a control group that tackled the exact same project under everyday conditions. Comparing results of the two groups at the end of the mandated time period would have been fascinating. Instead we used our ample experience with other development projects as an ad hoc control group; based on that experience, completion in twelve weeks was unthinkable.

Sending a high-performance team offsite to do the impossible may not be a strategy that IT organizations can use on a regular basis. And it's possible that even this team would have faltered with a longer project or a follow-on project under similar circumstances. But it proved to me—and to many others in the company—that sometimes the best productivity improvements are not the result of tools, technologies, or methodologies, but just leaving people alone and letting them do their job.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.