When in doubt, timebox it. Jan 13 2010
17 comments Latest by Favori partner Escort
While working on a new project, we came across some compatibility problems in a plugin that we want to use in that project. We have a known solution that works and doesn’t require the plugin, but if we can make the plugin work without too much additional work it’s worth using it. We have a limited amount of time to finish this project due to our new iteration system, so we’re feeling some time pressure, but we don’t really have enough information to make a good decision yet.
Rather than making an immediate decision, Jeff decided to spend another 30 minutes with the plugin to see if he could make it work. If we can solve the compatibility problems in those 30 minutes, it will be a nice win and we can make use of the plugin that we want to. On the flip side, we already have a known solution to the problem. Even if we’re not able to solve the problems we’ll only lose a half an hour, so it’s worth the time to do a very short spike to see if we can fix it.
Got a web design project in mind? Find a web designer on Sortfolio. Browse by visual style, portfolio, budget, and geographic location.
Over 1 million people use 37signals' simple web-based software to collaborate on projects, track contacts, and organize their business with an intranet.
17 comments so far
Ryan 13 Jan 10
“Ooh, I’m really close… just 10 more minutes should do it.”
John A Davis 13 Jan 10
Most improvements are made by people that don’t use the items they are improving.
:)
MI 13 Jan 10
Ryan: There’s definitely a danger to that, but we had a 30 minute window and people to keep him honest.
Jeff 13 Jan 10
Nice Ryan! Or, “It works….if you don’t poke it too hard, throw it any edge cases, and hold your lips just right. If I had another hour, I could nail it.” I understand the purpose of timeboxing in situations like this but it’s often hard to get developers to decouple emotionally from the problem at hand when the time is up.
Andrew Warner 13 Jan 10
Mark, check out this app for timeboxing work on a Mac: http://www.macmation.com/TimeBoxed
Anonymous Coward 13 Jan 10
@37signals
It’s funny how earlier this week you posted about how corporate speak is weasel
Could the word timebox be any better an example of “corporate speak”?
Anonymous Coward 13 Jan 10
Why even spend the 30 minutes if you have a known solution?
jnappi 13 Jan 10
I’ve heard and even used that timebox approach in these kind of instances. 30 minutes sounds like a really short time frame. The problem I find with the timebox approach, especially really short ones, is that its hard to learn new approaches when you’ve only got 30 minutes. Even if you figure something out in that time frame its typically a shallow understanding.
Its the quickest thing you could get to work the new way vs. the quicker old way.
MI 13 Jan 10
Anonymous Coward, the first: Is it corporate speak? To me, it was a shorter way to say “spend a predefined, limited amount of time on it”. YMMV , obviously.
Anonymous Coward, the second: Because we like the other solution better than the known one. It was more maintainable and worth the investment of 30 minutes to get working.
jnappi: In this case, we had a very specific set of problems. We decided that if we could work around/solve them in 30 minutes it was worth the investment of time. We weren’t looking for new approaches, just to fix a specific issue.
Anonymous Coward 13 Jan 10
You should timebox the two week iteration cycle you are planning to use. Any changes not coded, tested, and checked in to source control at the end of 2 weeks are overwritten and lost. Feature scrapped. I heard some good results from teams doing that.
AndyAA 14 Jan 10
Haha I always do this with Wordpress plugins.
I try to mode them to make them exactly do what I want and just cant let go until I have got it working… then I look up at the clock and I just wasted 2 hours and got nowhere.
T 14 Jan 10
I think there are great quotes in this movie, see my post
B 14 Jan 10
@MI
Could it have been worth more than 30 minutes? (What I mean is, if it hadn’t been finished in 30 minutes would that route have been scraped, even if it could have been done in 15-30 minutes more?)
JF 14 Jan 10
Could it have been worth more than 30 minutes? (What I mean is, if it hadn’t been finished in 30 minutes would that route have been scraped, even if it could have been done in 15-30 minutes more?)
Yes it would have been scrapped. That’s the point of the hard deadline. If we can get it working in 30 minutes then it’s worth it, otherwise it’s not. 50% longer than 30 minutes isn’t worth it.
Jagath 14 Jan 10
Also, don’t underestimate what you could learn about the system just by pursuing that different route for 30 minutes. We call it “doing in order to learn”.
What you learn by experimenting will be beneficial in the long run than just giving up and pursuing the alternate route.
Gebze Emlak 15 Jan 10
You should timebox the two week iteration cycle you are planning to use. Any changes not coded, tested, and checked in to source control at the end of 2 weeks are overwritten and lost. Feature scrapped. I heard some good results from teams doing that.
Favori partner Escort 16 Jan 10
I’ve heard and even used that timebox approach in these kind of instances. 30 minutes sounds like a really short time frame. The problem I find with the timebox approach, especially really short ones, is that its hard to learn new approaches when you’ve only got 30 minutes.thnx admın
Comments are closed