The Inadvertent Benefit of a Maintenance Month

Originally published January 31, 2017

A couple of years ago – in March of 2014 to be exact — I had my fill. As was usually the case, we put a technical debt item into the backlog with the promise of doing sometime later. This “later” had eluded us for years, but we kept telling ourselves we’d get to it eventually. That day, I made the decision to have our first “maintenance month” in May of that year. We would commit four weeks to address only technical debt. We do not accept external interruptions. And we would do it every six months without fail!

The original objective was to scratch an itch that had been around for too long. As a SaaS company, we are continuously in shipping mode. Every week, a new version is released. Every week, bugs are fixed. Every week, new features–small and large–make their debut. It’s a continuous race. Taking out four weeks to do nothing seemed like heresy! But, then something magical happened…

The Perceived Problem with Technical Debt

Fixing technical debt is hard to justify. It’s fixing something that is currently working with the prediction that doom will follow otherwise. A technical person might understand the argument when given enough time, but explaining it to a non-technical person is an exercise in futility. Most engineers just pack their wishes into a small box, carefully place the small box onto a shelf, next to another thousand similar boxes, with the thought that this one will be different! This one, we will come back to soon and take care of it!

The Real Problem with Technical Debt

Here’s the dirty secret of technical debt. It’s not the impending doom that should scare management. It’s the toll it takes on the self-esteem, the passion, and the trust of the engineer who has to give up on it. It’s the anxiety, the distraction, and the despair that eats away at every action that is taken that does not address technical debt. It’s like a cancer that rots both the product and the talent of a company. Nothing good has ever come from ignoring it.

The Magic of Maintenance Month

Amazingly, dedicating eight weeks per year to technical debt didn’t slow us down. I was completely unaware of how much we had burdened ourselves with these concerns until they were gone. Of course, we still have technical debt and we will forevermore. After all, good decisions in the past may not translate into good decisions today. However, I now know that we have dedicated capacity to tackle them at a regular cadence. I no longer have to worry about it and that is a huge gain already.

Another invaluable opportunity is experimenting with team combinations. During Maintenance Month, individuals from different teams group together so they can learn from each other and collaborate. This was an unexpected benefit and one we are still experimenting with. Should individuals choose their partners or should they be randomly grouped? Should there be many small teams or should there be few larger teams? We haven’t yet reached a conclusion on these. However, I believe that mixing things up regularly leads to stronger camaraderie and more fluid conversations between individuals as new relationship are built on working experience.

Finally, a regular cadence of Maintenance Months also provides an opportunity to restructure teams or shift focuses. The beauty of having a cadence is that you know when you get a chance to reset things if you need to. Changing direction, reprioritizing, and re-balancing teams is usually disruptive, but combining it with Maintenance Month gives a natural opportunity to do so.

It also means that surprises are minimized and these types of changes are only expected during Maintenance Month where they can be discussed as part of the process. It seems like a small thing, but it makes all the difference between calling a meeting immediately because of perceived sense of urgency versus postponing it a few weeks until the next Maintenance Month.

Recipe for Maintenance Month

The following guidelines for Maintenance Month are based on our experience over the past two years.

• Timebox

1. Each project must be completed within 4 weeks.
2. Complete means the project meets its Acceptance Tests and is out in production and no further action is required.
3. When in doubt, do fewer projects rather than more.

• Owners

1. Each project must have an assigned owner.
2. The owner must capture the objective of the project as Acceptance Tests.
3. The owner must be available to clarify the objective when needed.
4. The owner can have multiple projects.

• No Product Impact

1. The product team must confirm that the project does not affect the product. (otherwise, it’s a feature and not technical debt)
2. Testing is not affected by the project. No tests need to be updated.

• Scheduling

1. Avoid November, because of Thanksgiving.
2. April and October are good.

Maintenance Month projects should not impact the product or test teams. Nobody should be able to tell the difference. No customers should be directly impacted in their experience. Maintenance Month is about fixing the fundamentals without rocking the boat.

Executing this successfully also means that the test and product teams have four weeks to catch up or do their own maintenance efforts. Everybody wins!

Just Do It

My final advice is to just do it. Give it a shot. Ask for a four-week window where the agenda is set entirely by the engineers. Be extra vigilant to possible product changes hiding in plain sight. Focus on finishing every project. And when you do, enjoy a new level of serenity in your life!