top of page
outlier-logo.png

Tomorrow’s problem is today’s responsibility



Agile principles tell us not to try to solve tomorrow's problem today. The idea is to keep us on target to deliver on time by doing what’s needed today without trying to bring things forward that aren’t priorities right now. However, it’s rarely that simple. The things we develop today have the power to make our lives easier or more difficult tomorrow.


We need to think about success and failure. If we’re successful, how will we maintain that success? How will our systems develop and how can we develop them? If our systems or designs fail, how can we support them, improve them and identify exactly where the problem is?


A classic example is financial reporting. The finance team might say, “We only need to report quarterly.” So you build a system that reports and stores data at a quarterly level. But we all know that once the finance team is confident in the quarterly reports, they’ll want them monthly, weekly or even daily.


If the cost of thinking ahead and implementing in a way that leaves the door wide open to those changes is low, we should pay it now. The cost of changing later is likely to be far higher than doing it today.


And when it comes to implementation, we must always balance technical and philosophical purity and excellence against business need, impact, timeliness, longevity and, of course, cost! Don’t build a Rolls Royce when you need a mountain bike. Equally, don’t turn up with a mountain bike when you need a bus.


Sometimes building something specific that lasts for a short period of time is the right thing to do. Yes, it might be difficult to adapt in future. But if it’s designed to be ripped out and replaced when the job’s done, isn’t that good enough? It might seem like you’re building for today, engineering into a corner. But if it’s efficient to build and efficient to remove, then arguably that’s a future-positive outcome.


When it comes to picking a solution to a problem, the choice is often characterized as being between a tactical solution and a strategic one. Tactical is seen as fast and dirty: cutting corners to get the result in a quick and icky way. It probably won’t be pretty. It certainly won’t win any awards for best practice.


If we believe that, it follows that the only route to “good” work is strategic. In this dichotomy, strategic means big. Strategic means reassuringly expensive. It’s the latest version of something. Or it’s a plethora of tech that makes everyone feel advanced and nails best practice.


And the reason so-called tactical solutions often win over strategic ones comes down to perceived value. The tactical option is seen as quick to develop and quick to deliver, and value will be seen quickly but it’s only supposed to be there for a short period. There’s the promise of even more value to be delivered by a strategic option. But here lies the problem - to compete, the strategic option must deliver or unlock an astronomical level of value to justify its relative cost and time investment. The trouble is that most strategy is actually nothing more than talking points and bragging rights. It’s highly unlikely it’s going to make the grade.


It's worth having a well-tuned BS radar when you hear something justified using “strategy”. And if someone is forcing this dichotomy on you, think about why.


Because what it boils down to isn’t tactical or strategic, it’s about doing a good job. And that might mean building quick and dirty or it might mean taking the slow road. Whatever gets us where we need to go most efficiently, today and tomorrow.

bottom of page