I Don’t Do New Year’s Resolutions—That’s Waterfall
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? Yes, it has only been one day since we bade goodbye to 2017, but 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 improving—continuously, that is. 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 velocity, quality 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 for 2018, make it that you will start using the incremental power of Agile.
Start 2018 off right. Learn how your mainframe shop can become Agile in 10 flexible steps when you download our eBook, “Ten Steps to True Mainframe Agility.”
Photo: Flickr: Anthony Quintano
Latest posts by Mark Schettenhelm (see all)
- Why the Waterfall Development Methodology Has a Very Apt Name - April 17, 2018
- Mainframe and Distributed: Uniting an IT House Divided - February 13, 2018
- Waterfall to Agile SCM Conversion: Why Not Use the Best? - February 6, 2018