When I’m coaching, I often find myself setting little 10-minute targets to help teams break old habits. Here are some of my ten-minute rules for software teams:
- check-in working, tested code at least every ten minutes;
- when pairing, switch driver after at most ten minutes;
- if a design session lasts more than 10 minutes, it must be attempting to solve a problem that’s too big to be a single chunk.
Because to make these work effectively, a number of other things have to be in place. Such as a fast build and “vertical slice” thinking.
Advertisement
dru
August 11, 2005
I like this ten minute rule stuff. Any chance you could write some more on vertical slice thinking?
kevin
August 15, 2005
Hi Dru,
I hope to get around to writing about vertical slices “real soon now” (I’ve been saying that for over a year, unfortunately). Other folks are asking too, so I ought to get off my backside and do something about it now…
Mal Ross
August 15, 2005
Pardon the pun, but 10 minutes seems a little extreme for some of the above. Given that Kent’s white book has a section on the “Ten Minute Build” (i.e. your builds alone should be allowed to take up to 10 minutes), how are you meant to code, build, run tests, fix, build, run tests and perform a check-in that time?