Avoiding the All-or-Nothing Trap
How Actionable Roadmaps facilitate compromise in software development
A company I once worked with managed a fleet of hardware devices from a central location. Each of their user's devices could be diagnosed, updated, and provisioned remotely through an XML interface.
They recently switched vendors and were rolling out a new version of that device. The new generation provided an improved feature set but required a slightly different XML format.
I joined as a team lead to help handle the migration.
During the intake conversation, the business stakeholder made it clear that these new devices were much better than the older generation and that rolling them out to all users ASAP was the top priority.
The simplest solution turned out to be almost trivial. If the provisioning software detected a newer generation of the device, it would trigger an XML transformer turning the old version into the new version.
The plan we came up with was:
Plug in the XML transformer.
Go live
Develop a clean system for managing multiple versions of the XML format
The first version could roll out to market in a matter of weeks. The improved version would be developed iteratively over a few months. Fantastic!
A meeting with the head of the Engineering department killed that enthusiasm. The company apparently was notorious for introducing technical debt and not paying it off. The engineers feared that if they released an “if-then hack” into production, it would solve the problem. There would be no business incentive to build the improved version.
If we solve their problem in a quick-and-dirty way, there will never be a budget to do it well!
So, their plan turned into the nightmare of everyone trying to get things done: Building a big bang abstraction layer that plugs into all provisioning tooling before rolling it out to a single customer. Lead time: at least a year.
Engineering was holding Business hostage because they didn't trust their word.
The thing is: it wasn’t an unreasonable reaction. In Business-led organizations, engineering issues often get neglected. It's hard to slap a business value or an ROI on "clean up provisioning system's version management". Building the next feature is just more appealing.
We ended up doing what so many of us do: big bang, a 14-month horror show.
Lesson learned.
Instead of resorting to all-or-nothing tactics, we should have built an Actionable Roadmap together. That would have given both Business and Engineering the tools to do the job.
Business could have their solution on the market in a month but would clearly see that the effort involved locked resources for an extended period. While it would take an engineering team the better part of a year to build the solution, they could reap the benefits after a month already. They would have to sign off on a multi-month budget, though.
Engineering, on the other hand, would know that their first temporary fix would not become a permanent solution. They would see the allocated resources, and since both parties are involved in the road mapping sessions, they could keep the clean-up on the radar. Skipping the improved design would be breaking a public, written-down promise.
Roadmaps often get dismissed as management toys. Something to show on slidedecks in quarterly meetings. That's the wrong way to look at them.
Actionable roadmaps are a vital communication tool for building trust and compromise in a software development environment. They allow us to create technical debt and pay it back. They are the only way we can keep promises with internal and external parties.
Without them, iterative software development quickly becomes a game of digging trenches.