Monday Morning #TipOfTheWeek: One of the things that I learned early on as I started exploring XP (eXtreme Programming) was the XP mantra: build only what you need, not what you expect to need.

When building your backlog, focus only on what you need now or expect to need soon – at most a month or two out. The same holds for software – code only the things you need so that you can release them sooner.  Most product teams tend to load up on the future. It’s what most businesses do in practice because it’s what most leaders have been trained to do.

But as we’ve all learned from our pandemic experience, things can flip totally towards the unexpected. Remember all those detailed yearly plans for 2020? Well, a lot of them got chucked out the window. A better way is to have a detailed plan for the quarter and have high-level plans with potential contingencies for the following quarters. This is where rolling planning shines.

As an engineer, I fell into this trip with my team early on, building software that we expected to need. We built a bunch of scaffolding with specific features in mind that were supposed to be needed in 6 months. By the time six months rolled around, it turned out we didn’t need them at all. Talk about software bloat. By then, it was difficult to remove some of the stuff that we had built because other things that we needed were already dependent on them to some degree.

Guidelines that can help when reframing to build what only you need:

1. Design for modularity—Keep things small and focused so pieces can easily be reused or replaced when needs change. This advice applies to backlogs (Story Mapping with Releases comes in handy for this one) and software engineering (via patterns and reusable components).
2. Write proper tests – You might think this is only for engineers, but you’re mistaken. Yes, software tests ensure the code you build today is reliable and easier to maintain tomorrow. But for backlog items – have you ever considered doing continuous prototyping and testing? A little learning can help move you in better directions when you have tests – both software and product/UX tests.
3. Leave room for learning and discovery – Don’t lock your team into assumptions by building too far ahead. Focus on what’s needed now to avoid rework later when things inevitably change.

The goal of agility isn’t to build more—it’s to build just enough to deliver value quickly and iteratively. Remember – always focus on solving the right problems at the right time.