You are currently viewing Why Your Agile Methodology Needs a Roadmap

Why Your Agile Methodology Needs a Roadmap

Let’s talk: 

So, a lot of the really large enterprises that I’ve been to have made the decision over the past couple of years to go with the Agile methodology for their software development. In theory, this isn’t a bad idea.  

The Agile methodology allows you to fail quicker – which is a good thing – meaning instead of getting several months down the road with software development and then presenting to your business stakeholders and having them say, “Wow, that’s not at all what I was looking for,” Agile allows you to show your progress incrementally and do demos for your business users so that they can see what your progress looks like, tweaking it as they go.  

But there’s a fundamental problem with how I’ve seen large enterprises implement the Agile methodology.  

They say, “This methodology is great, and it promotes a lot of good project management fundamentals.” But they seem to put by the wayside some of the really important things that you would do during a Waterfall project, like writing requirements and putting together a roadmap for where they would eventually like to get to.  

The roadmap piece, especially, is a very, very important part of any sort of software development. I like to use the analogy of a trip to Texas when talking about how these enterprises use the Agile methodology. Basically, it’s as if they say, “Hey, I’d like to go to Texas.” And then I ask them, “Where in Texas do you want to go?” And they say, “I don’t know, but let’s start walking.”  

That’s really not the way you want to go. Roadmaps allow you to do things like decide to plan a trip to Austin on a certain date, book specific flights, reserve the hotel you want, and choose the restaurants you’d like to visit.  

Those things are kind of important when you are trying to march toward something. You can’t just put together a bunch of user stories saying, “I’d like the ability to do this and this” without a cohesive idea of what all those things together will mean for your business.  

I caution people using the Agile methodology to use the proper rigor around a project. It comes to building that roadmap and having requirements that can then be broken down into smaller Agile user stories so that their development team will actually be able to start building incrementally. 

This goes back to another piece that I’ve talked about in other blog posts: gathering an inventory of all the things that you want to do and then sequencing the work in a logical order. Order of Operations, as always, is super important. That’s no different in Agile than it is in any other software development methodology.  

So, your best course of action will be to build a cohesive roadmap for what you want to be able to do, when you want to be able to do it. Next, break all of those things down from a requirement standpoint into smaller Agile user stories that developers can develop to. Finally, sequence all of the sprints in the Agile methodology so that you get to those places incrementally.  

These demos of your progress that you do for the business should be building towards something rather than just building out a bunch of disparate pieces of functionality that don’t necessarily show the business users that you’re making any sort of progress at all. 

Make sure you have a roadmap and do your due diligence with your requirements.  

Love, Tim