the ten-minute rules

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.

4 thoughts on “the ten-minute rules

  1. 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…

  2. 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?

  3. Pingback: lowering the water level « silk and spinach

Leave a Reply to kevin Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s