Last weekend I spoke at the Great Lakes Software Symposium in Chicago and an audience member verbalized a great tip about driving the team towards small code commits.
When you want a team a to add one feature or fix one bug, you use tools like continuous integration to train yourself (and your team) to check in a single feature. But how big are those features? If you've got features lasting weeks or months, then adding a single feature is a huge amount of code.
The key to small code commits is small estimates.
My definition of small is between half a day and a week's worth of work. Anything longer than a week probably has a surprise or two hiding in it. You haven't decomposed that feature down far enough and when you encounter this hidden surprise it might blow up in your face. Anything shorter than half a day is too small. And you can't do anything in half a day anyway... try it sometime and see the interruptions appear from out of thin air.
It's simply easier to estimate smaller chunks of work. It also minimizes the code collisions between you and other developers. It makes your integration tests more effective as well. If your integration test covers 150 classes, you need to use small code commits and continuous integration to isolate what code was broken.
So where are you? Still working on figuring out how to estimate? Start with small units of work and be sure to look back and see how you're performing over time. Fast feedback leads to fast fixes. Be sure to work in smaller amounts of work, commit often, and look back over what you've done as often as possible, whether it's your continuous integration system providing the feedback or the estimate errors.
But remember....
Smaller estimates lead to smaller code changes.
Category: Agile
