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.
Ryan
on 13 Jan 10“Ooh, I’m really close… just 10 more minutes should do it.”
John A Davis
on 13 Jan 10Most improvements are made by people that don’t use the items they are improving.
:)
MI
on 13 Jan 10Ryan: There’s definitely a danger to that, but we had a 30 minute window and people to keep him honest.
Jeff
on 13 Jan 10Nice 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
on 13 Jan 10Mark, check out this app for timeboxing work on a Mac: http://www.macmation.com/TimeBoxed
Anonymous Coward
on 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
on 13 Jan 10Why even spend the 30 minutes if you have a known solution?
jnappi
on 13 Jan 10I’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
on 13 Jan 10Anonymous 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
on 13 Jan 10You 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
on 14 Jan 10Haha 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
on 14 Jan 10I think there are great quotes in this movie, see my post
B
on 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
on 14 Jan 10Could 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
on 14 Jan 10Also, 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
on 15 Jan 10You 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
on 16 Jan 10I’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
This discussion is closed.