Avoiding the Roadmap Triangle of Shame

All too often software engineering roadmaps are ill-conceived and badly planned, yet still get treated like gospel. Then they turn wedge-shaped and everyone's working weekends.

It can be a difficult task to balance the requirement of your stakeholders to have a solid development plan with the intrinsic difficulty of planning software development far into the future. Building software is unlike building, say, a house because software is innately unique and will have challenges along the way that are impossible to plan for. It's more like trying to build a house on the back of a fighter jet while juggling. 

Nevertheless, project stakeholders demand that we provide something they can believe in, and here's where the first failure occurs. Let's consider what generally goes into a development roadmap shown to stakeholders:

• Sellable New Features - perceived to be the main (or only) valuable output from Engineering by most of the business
• Important architectural optimizations and code refactors - often these only get included and made visible because someone in Engineering is screaming that everything is going to be on fire very soon unless this is done. Even then, there'll be an inevitable question down from the board about whether it's really necessary, or is there a quicker way to get it done so it doesn't take time away from the Sellable New Features.

What doesn't go in:

• Anything that's not a Sellable New Feature, and won't make the world end if it's not done immediately. 

 There's a fundamental issue around visibility here. All the bugs, small development items, optimisations, improvements, training, thinking time, lab time and so on are not on the roadmap, and so are quickly forgotten about when considering what Engineering should be able to achieve. Together these small things become a massive amount of time spent, but all the stakeholders see is:

Those big ticket items look like they should fit nicely into each quarter don't they? Looks like an energised, productive year ahead for the Engineering team. Ah, they'll be just fine.

The second major issue here that kills all hope of the roadmap being anything other than pure fantasy is:

The Single Line Spec (SLS).

Spec: Integrate our widget component into the API sprocket feature and expose to the Front-end.

Even if the upcoming big ticket items you're about to start development on are reasonably well-considered, there's a good chance that as your timeline moves out, the specs become more vague - maybe they are a set of wireframes in progress, or just a Single Line Spec. Inevitably there are people in the organisation who think they know how long it will take to build that thing. They are definitely wrong. Yet, the corporate machine demands a timeline, and top-down processes mean that often these SLS's are given an estimate on how long they will take to complete, so they can get neatly pigeonholed into the roadmap - start in six months, finish in another 2, job done. This then adds to the self-perpetuating lie of the roadmap's reliability. 

We have a time estimate therefore we are more confident the feature will be completed on time.

The problem is, of course that the time estimate for a SLS has been pulled out of thin air to meet the demand that there is one, rather than taking the appropriate amount of time to properly consider the work, challenges, unknowns, and whether it's possible to initially create a simple Minimum Viable Product to prove the concept, then build upon. Engineering projects don't look like a single block in a roadmap any more. They look like this:

This looks hideous and scary to your stakeholders because it doesn't seem to finish. It doesn't fit into a nice linear timeline with a delivery date at the end. "We can't show our clients who are waiting for this Sellable New Feature that thing."* "Salespeople need a big bang, fully-featured new widget that does it all at the start."**

*(you actually can if you explain it right).

**(They actually don't, if they can understand an iterative delivery approach).

So because of the perceived impossibility of squeezing an iterative delivery cycle into a linear roadmap, all too often the "Lying Roadmap" wins, and this is what's shown to stakeholders.

We're now nicely set up to fail.

At the end of Q1, there was more work than expected to do the first big ticket item, and a bunch of small stuff that wasn't on the roadmap had to be done, so we've had to push a couple of roadmap items into Q2. Don't worry though, we'll all work extra hard to do these AND the other planned items and we'll catch up..

Ah, so we're now in Q3 and those features turned out to be more complex than we thought. We've missed a few more feature deadlines, but hey, Q3 will be all hands on deck, we'll work weekends and evenings and we'll pull that sucker out of the bag.

OK, now we're screwed.

This is what I call the Roadmap Triangle of Shame™, and if your organisation's roadmap has a history of looking like this, then it means the following things:

1. The organisation is not learning from its mistakes. It should have been obvious what was happening after Q1 deadlines were missed. Maybe you even had a previous roadmap that also looked like this last year.. Does anyone believe it anymore? Yet it still keeps getting rolled out and pointed at by people with nodding heads and fixed expressions.
2. Engineering/Product teams are not taking enough time to properly scope and spec projects before committing to them. Or this only happens after the SLS has already been added to the roadmap, and the difference between real spec effort and roadmap SLS effort is brushed under the carpet.
3. There is not enough push back to project stakeholders to explain that the roadmap is a work of fiction and needs to work in a different way; They are too big and scary, jobs can be lost if they don't like what they see. Best to mollify them with something that won't come back to bite until later on.

All of which mean:

You're lying to each other.

Why would such a roadmap ever be submitted when those responsible for it know that it's at best a rough guess (and at worst complete fantasy)? Why is that roadmap STATIC? Does anyone have any trust left in what they are being given? 

The first step is to admit you have a problem

Put the spade down, and step away from the hole. If your roadmap is looking a bit triangular, it's time to change. An organization that is prepared to change its lying roadmap is one that ADAPTS:

1. Admits that it is underprepared
2. Doesn't start development until it is clear what it is building
3. Adjusts its roadmap regularly
4. Promises less
5. Talks to each other more
6. Stops the lies.

In fact, if things are already badly wrong, you may be in a better position to change than if they are only heading that way - sometimes when it's obvious something is broken is the best time to stop lying and be honest about what's wrong. If there's no trust in the process anyway, Stakeholders are probably crying out for a different approach that provides greater confidence in what can be achieved. 

Ideally things won't have to get to that level before a change can start being implemented, but there will always be a challenge to stop doing things how they're currently done and drive towards a more reliable process that people can believe in. This is hard if people still believe in a roadmap that's full of lies. This is not an easy part, but is essential. The roadmap needs to be seen for what it is, and admitting that you are underprepared with regard to scoping and specifying what the feature really is should hammer the point home that estimating that feature is impossible until more preparatory work is done.

Start that process of scoping and speccing as soon as you can, for all upcoming new features. Pull out a feature's essence, the "Minimum Viable Product", scope and release that first, and quickly, to build confidence that it is possible to release things on time when time is spent on planning. Iterate through the later, auxiliary parts, but set these as later sub-projects in the roadmap. (This is all standard agile process, beyond the scope of this article), but importantly DON'T jump in with development of anything until everyone in the team is completely clear on what they are supposed to be building. This means estimating time to build will be a lot easier, since the delivery is smaller and well understood.

The roadmap should be a living document, adjusted regularly; sticking features in and not allowing them to move means you're still lying to each other. Things will move; let them. Feed back and talk openly about why something is taking longer than expected, and adjust the scope of subsequent features if necessary to absorb delays, and you'll actually have something people will believe in. You may not achieve everything you wanted to, but you wouldn't have anyway, and knowing this early means everyone is better prepared. 

Finally, promise less in the first place - don't forget all the other stuff that roadmap stakeholders don't care about, but which takes up any engineering team's time on a regular basis. Give your team leeway to deliver on their promises even when unexpected obstacles get in the way. Over-promising, or trying to 'squeeze in' extra stuff to an already tight schedule never works and means you'll fail early and forever be trying to catch up. Being realistic and promising less will actually increase trust in the roadmap when the features are actually released on time. You might even over-deliver.