Thirty Days to Better Software

Reflective Improvement is number 2 of Alistair Cockburns 7 properties of successful teams. Of these 7, Alistair says the top 3 are core properties for success. Reflective Improvement is so important, because it gives such a big bang for the buck.

One of my favorite blog posts is Steve Pavlina’s “30 Days to Success”. Most people talk about self-improvement as though it’s and earth-shattering all-or-nothing event. They wait until December 31, put together a list of things they’re going to do to “improve,” and the task seems so monumental, by January 7 they’ve given up on all of them. Alternatively, they argue forever about why they can’t use better practices, or why those practices won’t work for them, even though they’ve never actually tried.

Neither of these approaches is likely to produce many concrete results. But a better way opens up to us, once we realize that a New Year’s resolution doesn’t have to be permanent, and it doesn’t have to be a big deal. For example, what do you do when someone says test-first programming just wouldn’t work for them, even though they haven’t given it a real chance. The real problem has nothing to do with test-first. The real problem is that they don’t want to commit to something they’re not used to and have no real experience with. That’s hard.

So let’s make it easy. Don’t commit. Let’s just try it out, give it an honest chance. We’ll try it for a month. Then we’ll know whether it works. After a month, if we decide we don’t like test-first, we’ll stop using it. Even if test-first is a total flop, it will only be a burden for a month. Some people stick with whole careers they hate, for years. We can stick with a new practice for only a month. And trying it will give us concrete experience that we can use to make informed choices regarding this practice.

But if we decide that test-first does have advantages, we’ll keep doing it. After a month, it will be that much easier to commit to it. In fact, it will be natural for us to keep doing it, because after a month it will almost be second-nature to us.

This is the power of ongoing reflective improvement. Every month, ask yourselves what you want to keep doing, what you want to stop doing, and what you want to try to do. Take a baby step. Make a small change. Over the next month, measure the results of this change. Then repeat ad infinitum. All those little baby steps, with active feedback, will take you places. That’s up to 12 concrete improvements each year, each of which we know works.

You can use this to improve almost any part of your software development. Consider a 30-day trial the next time someone says:

• Maintaining unit-tests will slow us down too much.
• We don’t have time to refactor.
• A bullpen lacks privacy and would be too noisy.
• We can’t switch from SourceSafe to Subversion.
• Daily stand-up meeting? That’s crazy!
• We’ll never do code inspections.
• I love shooting down your ideas!

This is easy when you do monthly retrospectives. They tie together the trials and maintains ongoing Reflective Improvement. But even if not, the 30-day trial can be an effective part of your team’s Reflective Improvement. For example, you could schedule a retrospective for 30 days from when you started the trial. Then you can decide whether to keep the new practice or discard it.

-TimK