Roadmaps Help Software Teams Know When They’re Done

roadmapDoes your software development team know where it’s going? Sadly, many don’t. Sure, they start out with a set of goals such as develop a Windows software application to retrieve some business data, format it, present it, and allow users to search and sort. Great, let’s write some code!

But wait, not so fast! Where did this business data come from? How will the application results be used? What insights will business people gain from the software? What other insights might they expect to get from the application? What other data might be needed in the future?

I see many software teams eager to dive in and beginning implementing solutions without an understanding of where the solutions might lead them. Unfortunately, I’ve seen many cases where even the business folks had no clear idea of what they might need in the future. Essentially, the initial software application is an experiment — a trial. The early outcomes will dictate what happens in future releases.

Conducting business experiments isn’t a bad thing at all — I even encourage it. The “bad thing” is when business people conduct experiments and expect the software team to lay a foundation for future growth. I know from personal experience that throwing together some code to produce a quick result doesn’t offer a sound foundation for adding features.

It’s Easy to Get Lost Without a Roadmap

The missing link in this discussion is the software roadmap. Great software teams need a roadmap to help them understand where they’re going. The roadmap enables them to plot a course and avoid having to back-track and cover old ground.

All development approaches are susceptible to getting teams lost or simply letting them stray off course. The effect may be more discernible for agile teams because their velocity may drop as they regroup and redefine the software architecture. Waterfall teams deliver so infrequently that the effects of not having a roadmap may be easier to mask. Regardless, the net effect is the same — rework and wasted effort.

Lay It Out

It’s important for software development teams to work with business teams in creating a rough plan for the software over several releases. I say rough because the plan will change — it may change drastically. That’s okay. It’s a roadmap based on the best available information. At least everyone will be operating on the same assumptions and goals.

If the business can’t assist in defining a roadmap, the current project is an experiment. The team’s effort will be based on trial and error. That’s okay too. The point is to get everyone operating together with a common understanding of what’s being done and why.

The planning effort helps set expectations among stakeholders and developers. It also helps answer a key question that will occur later in the project — “Are we done yet?”.

photo credit: Pigsaw via photopin cc

Updated: July 21, 2013 — 10:01 pm