Updated: Jul 20
This is a topic that has come to the surface (again) lately. “Can you have a Product Roadmap and still be an agile organization?”
The answer is short - of course you can.
The problem is - that is the wrong question and taking the next natural step of asking how you can be agile and have a Product Roadmap will take you down a long, and ill-conceived path of frustration.
The better questions to ask are:
Why does your company want a roadmap?
Will this [answer to above question] be the only or primary function of the roadmap?
Look at those two answers and then ask - are these answers compatible with an Agile for Business Outcome model?
This line of questioning will lead you down a healthy path of really examining your decided business outcomes. Once you have those you can choose Agile or not to achieve them.
Here is another little exercise that might help....
Let’s look at this story - this is a typical origin story for the “how can we BE agile with a roadmap”.
….Some executive decided “let’s be agile”. Consultants were hired, training ensued, sprints were started, standups were mandated - "we got that engineering team in top shape".
Then the next QBR (quarterly business review) came up and there were not any of the little red/yellow/green markers on the roadmap for engineering -
What has happened?
It is heresy.
Agile has destroyed planning.
Now - there are many underlying issues with this story.
One that jumps out is that the “transformation” was “done to” the engineering team instead of “being engaged with” the whole of the organization. If this is your story, you must start here and decide what Business Outcome Agile is supposed to be solving and if your team is really ready to put in the hard work to achieve the value it will provide.
This is like going to your local DIY box store and picking up a rake - then heading home and deciding what to do with it. Why pick a tool before you understand the job.
It could be that your company is just happy with the status quo. Stop reading too may LinkedIn headlines - change for change sake is not healthy and all companies do not HAVE to be Agile mindset companies.
Another potential issue from this story Is a lack of executive understanding of the impact in moving to a Business Agile mindset.
Here are a couple of examples on the path to that correction/discovery:
Is it the CFO; has a primary tool for long term budget forecasting been disrupted. If so, this is a very real concern and a place to focus. Agile does support long term planning from a budget planning point of view. Remembering that in a healthy Agile environment WHAT you are working on does not define the people budget goes a long way to achieving this kind of result. Things like EPIC T-shirt sizing will provide the basis of team size and resources needed for budget estimation.
Is it the CTO; has her method of holding her team accountable (hitting the plan) been disrupted. If so, this is a real problem and might be a show stopper if the CTO is not aligned to use other methods for Team Accountability. Roadmaps in a healthy Agile environment are not tools of accountability, they are planning tools. From the Manifesto - “We value responding to change over following a plan.” As the “transformation happened, so should the methods and tools for measuring and holding teams and team members accountable. Measure things like the ability to pivot and customer value deliverables.
Nothing good will come from “bad Agile”.
If your company defines itself and its ability to deliver value based on the ability to hit dates and items on a roadmap, you are not in the Agile mindset.
If you want to move to the Agile mindset, first ask why, get buy-in to that why, then start the hard journey to get there. In my opinion, and experience, it is worth the effort.
However, do not try and “do both”