Avoid Technical Debt with Planning

So, you get it. Technical debt is bad. So what do you do about it when you have it?

First step is probably to try and avoid digging yourself deeper.

One of the most misunderstood things about agile practices is planning. For some reason, people sometimes take to the extremes and throw planning out the window. It is just as silly as it sounds. Our challenge is not to code without planning, it is about how much planning we actually need, and how closely do we follow a plan when we learn how it doesn’t exactly fit.

We learn what truly needs to be done, by doing the work.

The art is in the rough plan, and letting your technical practices guide you through it.

If you can plan a bit, you might be able to see some rough patches ahead. Having strategized around them once, you’ll be far better prepared when you’re neck deep in them for making better decisions in the moment.

It can be almost like you’re practicing planning the first time. The value in what you are doing is not necessarily in that rough document or summary you produce, but rather the value comes from the act of producing it.

Think about that. It’s kinda “meta”. The value you get from planning, is in the conversations, with the right people at the table, as you all talk about what you need from this thing you’re building. You’ve all gotten into a room, unscrewed the tops of your heads, dumped your thoughts all over the table, and rummaged through them trying to come up with a plan.

It’s not like you forget about everything that wasn’t the chosen plan when you leave the room.

Planning is a tool you can use to avoid accumulating technical debt to begin with. It’s not the only tool. It’s not a perfect tool. It’s just a tool, and you can use it.

And understanding that the value lay in your planning session makes it easier to let go of that plan that doesn’t quite fit when it’s time.