I Don’t Do New Year’s Resolutions—That’s Waterfall
Overview: What if, instead of resolving to make one big change on New Year’s Eve, you made minor changes, evaluated them and modified your approach as the year progressed? The same applies to building software.
This time of year, talk turns to resolutions. Something about the end of the year makes us want to prepare for the next.
But how confident are you that your resolutions will hold up? I ask because many people resolve to make big improvements once a year and quickly break those resolutions—even the day after.
For this reason, I gave up New Year’s resolutions, but I’m still committed to continuously improving. This is true in my own life and in software development. Let me explain.
Missing Big Targets
To me, the tradition of making New Year’s resolutions is very much like traditional mainframe Waterfall development: You plan your enhancements—in this case resolutions—and deliver them only once a year.
You’ve spent the year with whatever behavior it is, but only now do you intend to change it, and drastically—right now! In effect, you’ve wasted months waiting until now to make a change when you could have been gradually working on it day-by-day and without so much pressure. Now that the focus is on, you decide to go big, and it rarely works out the way it’s intended to.
Constantly judging against the one big goal you want to meet makes it much easier to toss in the towel and quit. The goal is too large. It’s a binary thing where you either do the whole goal or nothing. There’s a better approach.
Attaining Small Goals
What if, instead, as the year progressed, you made minor changes and evaluated them each time? You could find out what works and what doesn’t, then modify your approach for the next few weeks.
You would do this with the idea that the “deliverable” each few weeks isn’t the end goal—it’s progress toward the end goal. You would go for smaller, attainable steps that continuously build into something closer to where you want to be.
Most importantly, as the year progressed you could incrementally benefit by building on successes and learning from errors. The amount of pressure you would be under would be much less.
Setting Incremental Software Goals
If this makes sense for self-improvement, it can also make sense for your mainframe software projects. The psychology behind it is the same: Instead of continuing to set up large, binary, pass/fail projects with far-out dates that only build up the pressure you’re already under, it would be better to start on the project now and make incremental improvements with greater quality, velocity and efficiency.
Break the project into smaller goals that can be met in short time frames, such as with two-week sprints, and deliver the benefits along the way. As problems are found, adjust and move on. You want a clear goal you can meet soon. That’s more motivating than staring at a huge, far-off goal.
Meeting these small goals is what we call continuous improvement, a hallmark of Agile Development. It’s a simple idea, and there is no better time than the present to start. So, if you’re going to make a resolution, make it that you will start using the incremental power of Agile.
Photo: Flickr: Anthony Quintano