The Timebox
Recently during one of our project retrospectives, a colleague of mine noted one of the best practices I tried to adhere to was to use a timebox when I tried something out. The issue at hand was that we were writing acceptance tests for our project, and I wanted to write a fixture to generate links that had a specially encoded date time parameter. We both had different ideas, and my partner knew that I have a knack for sometimes going overboard when writing automated tests, which was also coupled with my partner’s inexperience with fixture writing that made him fearful of going along with my idea. So to ease his worries, I simply said “it’s 2:30 now. How about we just try it only for 10 minutes, and if we don’t have something useable by 2:40, we’ll try something else.” Luckily, we wound up with a simple, yet easy on the eyes FIT test without going over the timebox.
Although timeboxes are commonly used in XP when doing a SpikeSolution, I find it also useful when trying to get “buy in” with your partner when pair programming. Additionally, it helps keep you not only focused on the task at hand, but allows you the freedom to tinker without going overboard and wasting time. And once the timebox is up, and you didn’t complete your solution, turn the keyboard over to your partner and let them try their idea out.
Of course, a timebox is good for anything really… it underlies the urgency to do {insert whatever needs to be done here} within x amount of time, forcing you to focus only on the most important details while keeping the cruft to a minimum. This also why we try to limit our morning huddles to 15 minutes, to avoid turning it into a 1 hour meeting where someone goes into great depth and detail on an issue rather than just flat out saying “We were unable to do X because of Y”, in which someone can simply say “I have an idea on what we could do, lets pair up first session!” 
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
