Not a Gantt Chart. The Play for Visual Roadmaps and Strategic Agility.

Golden Nuggets, Honest, Unbiased Thinking, Opinion, Entertaining Long Reads and Mini Guides of Practical, Pragmatic and Shared Know How from me as an Agile Practitioner to help you Accelerate your Journey towards Enterprise Agility.

Responding to Change | Pitfalls of Plans | Why Roadmaps | Roadmap Types | Stategic Use

In this article, I want to unpack why Agile Ways of Working use various forms of Visual Roadmaps over Traditional Waterfall Gantt Charts, WBS, PERT, EVA and CPA.

It’s a source of frustration between the two approaches to development and delivery, much talked about, much debated and widely misunderstood and poorly collaborated on.

It’s another reason Lean Agile and DevOps Ways of working aren’t as effective and as well adopted, practiced, embedded and set free as they should and need to be.

So let’s deep dive into “Visual Roadmaps” in a generic sense, how they are applied in Lean, Agile Ways of Working for Product Development, Service Management, Lifecycle Management, Agile Software Development, Agile, Digital, Cloud, Technology or DevOps Transformation and in Building Capabilities for Business Agility or Enterprise Agility.

Then we’ll look at how to do it better to drive better outcomes for no more Gantt Charts.

The Friction and Pain Points Around Agile Roadmap Adoption

Plan vs Change Driven

Waterfaller’s always want big up front, detailed plans, that’s because their modus operandus is command and control and they feel they must give explicit instructions/requirements to follow.

Agilists are all about responding to change over following a plan. They empower the team, to develop the solution, based of Epics, Capabilities, Themes, Features and Stories – all forms of User Stories of different size, scale, scope, quality, and complexity -but reflective of the end user, the stakeholders, the customer, or consumer and not the HIPPO.

So one is all about super costly, big upfront, detailed analysis and orders, the other is more chilled out and likes to have more just in time communication, collaboration and just enough confirmation to get the job done to meet current expectations. The Drill Sergeant vs the Hippie!

This is the first source of friction between project/product/programme management, and traditional Managers and those following Lean Agile Leadership styles, having Agile Growth Mindsets and follow the Agile Manifesto.

Scientific Theory vs Hybrid Theory

The next source of friction still lies in the mindset, thinking or approach differences.

The HIPPO shouts, do it faster, for the same quality, less cost and with fewer people.

The PM and PMO run away and do Critical Path Analysis, they decide the longest shortest way to deliver. Then they do some Program Evaluation and Review Technique, working out the parallel, sequential, start, finishes, what can overlap, “Crashing” or “Crunching” the plan e.g. the Gantt Chart as they call it, to only find out, they need more resources, more money, more time, and less scope...and as a cynic, probably still never deliver any value.

The HIPPO and the other HIPPOs all shout in anger and frustration at the PMO Board Meeting

So the Agilist in the room says – we can do this a better way, we fix the resources, are okay with last minute scope changes and we will work in an incremental fashion in timeboxes to deliver features in releases over time to realise your vision Mr and Mrs HIPPO’s.

Then you guessed it, “Give me the plan then”

“That’s not a plan, it’s got no milestones, no dates, no nothing, get me Gantt chart”

“Didn’t you learn the 6Ps, Piss Poor Planning Prevents Poor Performance son….”

Sir -this is the strategic roadmap, it sets out your north start vision and how we will achieve it in chunks, that you want, at points in time to solve the problems we are having in the market and that our customers are having, so this is a win -win, its more predictable, we only fund features that are valuable to users and the business saves time, money and effort…

The CFO and COO HIPPOs – “I like the sound of that”, “me too” …” Let’s do it!”

So we have got a mind shift change, from detailed plan to a strategic, constantly changing roadmap based on customer, market, business stakeholder and end user feedback.

Familiar story?

Agile and Product Portfolio Management Software

The next source of friction is squarely blamed on software developers, software product owners, managers and vendors of Enterprise Agile Planning, Collaboration, Product, Portfolio and Values Stream Management tools.

Why?

Their lack of creativity or ingenuity in design and the constraint of being interoperable for integration to GitHub, Confluence, JIRA, ProductPlan, Aha!, Monday, Wrike....

We go on telling people that Lean, Agile and DevOps is all about iterative, small batches based on fast feedback loops and then the geniuses behind these tools kill us, literally undo our work with poor UXD, poor coding, poor graphics and thought leadership, woops sales docs on how good their shite it.

They represent Roadmaps as defacto or proxy Gantt charts by using bar charts.

So that gives the Waterfallers and Command and Controllers, the Old Skool Management League, the ammunition to kill us over their demands for numbers, milestones, timelines, all these precise, highly uncontrollable, uncertain assumptions are now back on the table. Well shit me.

Agile has been exploited by consultancies, software vendors and others and that has made the Agile Manifesto, Agile Values, Principles and Practice become devalued as they aim to commoditise, retrofit and monetise products that are not fit for Agile purposes.

Then in their arguments, they simplify their offerings by combining Release Notes, Feature Set Descriptors and Dependency Links like predecessor and processes tasks in parallel and sequential work break down structures, (WBS).

No wonder we are in trouble here. All to sell, sell, sell and not represent the what, how and why we use Roadmaps rather back to support Scientific Theory of old skool managers wo make poor buying decision for the Agile Community trying to work in Agile Ways.

So be super cautious when choosing your Road mapping tools to not be using a Gantt Chart tool with some hyped Apple’esque UXD overlays and the word Agile chucked in.

Interpretation

You’re gonna laugh out loud, but, another friction point is based on what we are familiar with and know as a roadmap.

I am talking the London A-Z, a Street Directory or Highways Map.

People associate the word and concept of roadmaps with these linear maps that allow them to navigate in straight lines to places. We use Google Maps, Waze or whatever more often now, but its embedded.

This subliminal, sub conscious bias and long held interpterion leads us down the wrong pattern of thinking for Agile Roadmaps in that they are not linear, more like Snakes and Ladder boards, Chess boards and other strategy games, where the shortest route isn’t the optimal one, sacrificing a pawn to checkmate in 3 more moves or sliding down, and sidewards to go upwards and onwards.

Food for thought, always be pen minded and explore other people point of view before raging ahead! When we get promoted, it upwards usually, that how the minds of managers think,, short term not longer.

Problem or Challenge Orientation

Traditional Managers and Leaders hate this.

“Bring me a solution not a problem or more problems”

“I cant tell the board that we have problems”

That glass half full not empty mindset that’s not focused on the customer or markets reveals itself in their demands of roadmaps and in understanding them.

To be customer centric, focused, putting them at the heart of all that we do, design, deliver in having a relentless focus on them, isn’t what traditional scientific managers do, they are inward looking, order barking, cost saving, cutting, literally doing less with more types, quality of expereince, loyalty isn’t top of mind, let alone market growth, just gaming their bonus is.

In Agile, we live to solve problems, issues, challenges, remove impediments, barriers and blocks because we are more socially orientated and mission or purpose driven as opposed to scientific thinking bureaucrats.

So why do we use Roadmaps then?

We’ll overcoming the adversity of our masters, we try and use Roadmaps over Gannt Charts to:

• Strategically outline the big picture for success
• Visualise that North Star in an easy on the eye Infographic
• To source ideas from other than HIPPOs eg the external market, end users/customer and stakeholders
• To prioritise our Go to Market plan to deliver but will change based on feedback, trends, demands, needs, wants, desires and things we didn’t know then but do now
• Align our work to the Portfolio Canvas
• Align our work to the Portfolio Vision
• Align and support the Portfolio Innovation/ Lean Start Up Funnel
• Align our work and make trade-offs to the Business/Enterprise Strategic Themes, Growth Plans and OKRs
• To push work to teams and for teams to pull the right work, at the right time, at the right speed and way
• To maintain competitive advantage, show our innovations to fend off competition or threats

So nothing that a Gannt, PERT, WBS, CPA plan does or promotes as a way of working! as they are engrossed in finite tactical execution detail.

So what a should a Roadmap be then?

A better way to manage ideas, innovation, and value delivery…

Well, those things above of course! And that statement in a nutshell.

A visual, constantly changing, strategic high level/big picture rough direction of travel outline on a single page that communicates the solutions that might be implemented to help the product, service, experience, platform or organisation move forward.

Simples.

Its not done once upfront and forgotten, its not stuck or set in stone, it’s not a definite plan of execution, it can’t be held up and shouted about as to why this and that wasn’t done and it helps to pivot or persevere with the creation, delivery, flow and realisation of value or not, optimising it in real time.

So it’s a key artefact for managing, leading and working in an Agile way to achieve Business Agility.

Types of Visual Roadmaps

Unlike a Gannt Chart, there isn’t just one way to fit all solutions.

We have many types of Roadmaps to suite our Lean Agile Ways of Working as lightweight artefacts that are just enough just in time to do what they need to do – spark communication, collaboration and confirmation of ideas, work, and value as we have the right level of detail to hand, in order to progress.

Here are a few to look at:

Feature based:

Visualise functionality that a containerised microservice or product might have in the future i.e. self-tying/tensioning shoe laces for activities based on ML, AI and IoT sensors

Goal based:

Visualise future state increments like in OKRs each goal is the Key Result Area or the DA Onion e.g. Disciplined Agile Delivery, Disciplined DevOps, Disciplined Agile IT and the Disciplined Agile Enterprise using the layers of an onion diagram

Release

Visualise potentially shippable increments or versions of working software, product, services or platform, items etc eg Annual Release Cycle vs Quarterly vs On Demand

Product

Hybrid of Goal, Feature and Release

Improvement

Sometimes used by government, public bodies, and the private sector to visualise how they are taking and using consultation feedback, suggestions, and complaints onboard to improve services or provision of X

Idea

If you’re a VC, run a Lab/Studio or have an R&D function – you’ll have a lot of ideas you’ve crowd sourced, inner sourced and generated yourselves to visualise for testing, learning and experimenting, so they’re used to prioritise and rank ideas from most to least important, viable, doable, desirable, achievable etc

NorthStar

Mission-aligned, they show what’s being evaluated and assessed across portfolios, businesses and brands in the enterprise to pivot, persevere, acquire, invest, merge, diverge, restructure or divest/ retire to achieve the business vision.

Technology

Visualise technology currently available today and highlights improvements that are scheduled in the future eg COBOL based IBM main frames are going to be replaced at end of life with PHP LAMP based AWS servers

IT Systems

Visualise core enterprise architecture capabilities and future IT needs and improvements that may be made depending on new emerging technologies, best of breed and best in class factors

Transform/ation/itive

Visualise the current state vs incremental step changes in capability, capacity, market share, new markets, organisational design states e.g. pyramid, meritocracy, sociocracy to holacracy or bureaucratic, Lean, Agile, DevOps, Flow, Business Agility

Two Roadmaps that aren’t Roadmaps

The Now, Next, Later Roadmap

These visualise what's being worked on now currently, what queued up in priority to be worked on next and then later.

I am not a fan of these, they are really just the far left hand columns of Kanban Boards and unless they are Portfolio Kanban Boards, they will be far too low level in detail as task, jobs to be done or work items.

Jobs-to-be-Done Roadmap

These are not roadmaps in my point to view either, they are task lists and Kanban style boards at best with perhaps a cooler name to organise and manage time.

Doing it better – Kaizen Practices for Visual Roadmaps and banishing Gannt's

Products, services, experiences, and platforms should be judged on their delivery of value to users.

Roadmaps are a tool to express what the value of a product will be and how that value will be understood, released, and realised in increment/iteration or cycles across its useful lifecycle.

Roadmaps are so you understand your customers and your markets and can so No to HIPPOs and Teams.

So, you’ve learnt about the pain points, frustrations and frictions, and some types of roadmaps applied in the Lean Agile Ways of Working environment.

In the next section, I want to highlight how we can do Roadmaps and Road mapping better than what those tools are forcing us into, so ignore that feature and wind it back a bit until they catch up!

First Principles or Guardrails to Inspect, Learn and Adopt

•  Roadmaps should 100% focus on value
• Roadmaps should show customer problems, not solutions
• Roadmaps should take you towards your north star vision, guiding in increments or iterations
• Roadmaps should visualise what you’re trying to achieve on a single page e.g. like a POAP
• Roadmaps should represent a state of consensus within your team, product ownership or solution management group/function
• Roadmaps should avoid single feature MVPs - aim for MMFS - Minimum Marketable Feature Sets
• Roadmaps should not just include new stuff, there is in life and end of life maintenance too
• Each product, service, expereince or platform should have its own roadmap representing the value it will create, deliver, and flow to market
• Roadmaps should not be static, but developed iteratively and regularly under version control
• Roadmaps should be openly accessible, transparent, visible information radiators for those that need to see, access, refer and use them in wikis, repos, collaboration tools and intranet portals
• Roadmaps should be accessible outside of your organisation unless there is a super valid security reason against publicly display them for openness, transparency, and accountability
• Roadmaps should be easy to understand with no low-level details
• Roadmaps should have relatable vision, mission, or objectives statements at the top showing linkages
• Roadmaps should show clear priorities over agile planning horizons – quarters for the first year, halt year for the second year and year only for anything beyond year 3 – following the Cone of Uncertainty principles
• Roadmaps should avoid using linear graphs, steps, bar charts – Agile is not linear – it responds to change roadmap is open and available in the public domain (unless there is a very good security reason not to).
• Roadmaps are to capture intent only and allow for last minute change, feedback, ideas – they are not set plans of execution – rough guides only
• The format should be consistent across your organisation and identifiable as a repeatable, high quality asset or artefact
• They have ownership by Product, Service, Expereince or Platform Owner/Manager who is identified on them

How should a Visual Roadmap Look then to for Strategic Agility?

Well, not a Gannt chart for starters!

 Here are some great reference examples:

The Onion Diagram

This shows 4 the transformative states with the NorthStar goal being the DAE from the Disciplined Agile Roadmap and Scaled Lean Framework.

The Continuum

This infographic provides a visual reference going back and forth, so it doesn’t present a definite line, by having interlocking points. Deliberate VUCA built in !

The Pipeline

I’ve drawn this in both MS Visio and Lucid Chart. Good way to show progress at different paces as you normally would, sometimes you accelerate, sometimes you slow down to smell the coffee and sometimes you takes some dips and turns when your testing, learning, or experimenting.

The Cycle

A great way to show iterations or cycles of improvement by quarter eg you intend to 4 releases based around learning and feedback

The Radar

This is a visualisation in Aha!, it gives you a strategic product view of how your horizons and activities are linked. It’s a complicated one, but good if you’re looking at making trade-offs or aligning existing work with new ideas, goals, feature as you can tag each one and show layers separately to showcase the potentially what the future might hold.

So what you don’t see in any of my reference examples is anything that’s close to a Gannt chart, a Bar chart, a PERT chart, WBS, a step ladder like say the Capability Maturity Model which shows linear moves across each state of maturity.

MS Word and PowerPoint even has better option in Smart Art or Insert Shapes than any of the above which only lead to frustration, locked in plans, traps, firefighting and little to no agility, so just don’t do it.

Who should be involved in building a Roadmap?

The most effective roadmaps are developed based on multiple collaborative inputs, sources of data, feedback and people.

It is not a top down exercise of telling, instructing, controlling, and commanding from the top.

It’s not just a bottom up approach either, to hand ball it over the fence.

Stakeholders from within the organisation at every level should be include – from Cleaners, Reception, to CEOs Managers and Call Centre staff.

Every function should have a chance to contribute as well from IT, Portfolio, Operations, Engineering, Production, Manufacturing, Design, Finance, Sales and Marketing to Legal.

This will freak out the Waterfaller’s and Traditionalists…

Customers, Vendors, Partners, Alliances – folks from your ecosystem – you don’t innovate in isolation, there is always dependencies and inter-dependencies across supply, delivery and value chains. Open the doors, see what good stuff happens.

Also, you’ll be more aware of the outside world, bring it in and be ahead of any potential lags in technology, regulatory roadblock’s, changes, trading standards and the VUCA stuff so you can be prepared like a Boy Scout.

Continuous Near-Term Road Mapping - A Key Agile Practice

This practice, discipline or technique will force you into being Lean and Agile.

Agile has planning horizons, shock horror, it’s not a free for all undisciplined thing that some think it is, or make it because they are doing, thinking or being it right.

So when doing a Roadmaps, we align them to:

The micro planning horizon

This is the daily work, the stuff talked about at Scrums, Stand Ups, Huddles etc.

The Sprint Horizon

The two-week block of work that the Product Owner pulls from the Product Backlog with the Product Manager to the Sprint Backlog for the team to pull and commit to in the upcoming Sprint.

Iteration or Release Horizon

This is the potentially shippable or shippable version control release of an entire new product, a defect/bug fix, or new feature or feature set to an existing product, service, expereince or platform.

120 Day Horizon

So the Sprint and Iterations cover the 30, 60 and 90 Day Horizons/Quarters, next is the Half Year. Yes…365/2 is 182.5, but we don’t work 365 days a year, the max a FTE does is circa 220 days after weekends, holidays and public days off, minus any sick, parental or bereavement leave etc.

Annual

Kinda no such thing as you’ve covered Yr 1 and 2 above in Sprints, Release, Quarters and Halfs, so its really now what you don’t know unless you’ve got a crystal ball, magic wand or genie in a bottle, so you cannot plan with any level of certainty, accuracy or assumption beyond 18 -24 months, better yet is a max of 12.

This is the difference with Agile Planning, our Strategic Views hover above everything, but we plan in 1, 10, 30, 60, 90 and 120 day horizons to manage risk and waste and do this on a rolling wave, so planning never stops and starts like how the Waterfaller’s and Traditionalist’s do it once yearly and potentially waste years’ worth of effort, activity, planning and budget in things that don’t deliver or create value.

So Refreshing your Roadmaps at the Agile Onion or Agile Planning Horizons aligns your strategy to the strategic approach of your Lean Agile Business.

Sorted. That’s what we refer to as Rolling Wave or Near Term Continuous Road mapping, we get close, but to the end, just in time and just enough, we keep moving incrementally forward based on feedback from customers, markets, stakeholders, our ecosystem and global operating environment – not 3 BA elicitation and requirements gathers exercise or 6 weeks of discovery activity. We are a Continuous Everting culture.

Why will your Teams Love Visual Roadmap and Agile Planning

Here is my last effort to convert you away from the horrors, hassle’s, pitfalls and failures of Gantt charts.

It will make you listen to customers

You’ll find out what your customers want by capturing problems, challenges, needs, wants, desires and ideas in one place, directly on your roadmap.

Prioritise the right features – build the right things

No more HIPPOs knowing what best, Set and rank features based on what matters most to customers and markets problems and challenges and your business goals – not vanity projects

Crafting Visual Roadmaps is Engaging and Creative

Whether you do a POAP or use a tool, a really good no bar charting tool just because they cant work out how to integrate tools, it builds teamwork, consensus, buy in, collaboration, creates communications and confirms you are doing the right things, at the right time, the right way.

Report on progress using a Visual Information Radiator

Use lists, pivot tables, sliders, images to visually make an impact, not expect everyone to be able to read, understand and interpret Gannt, PERT, CPA, EVA and other trad PM charts. They are boring even for those that have to stare at em.

Reinforce, Support, Do, Be Agile!

Yes, work with agility, lean up, stop waste, focus on value and integrate it with Lean, Kanban, Scrum, Design Thinking, UXD, Product Planning, Engineering, pretty much everyone, with no duplication, all synced up on the same page, singing from the same hymn sheet, firing on all 4, 6, 8, 10 or 12 cylinders, not firefighting, not swinging X@~#% etc.

What a Roadmap Isn’t

 A Gannt Chart

A Milestone Planner

Fixed Plans Set in Stone

A Backlog

Instructions to Tell the Team what to do

A Percentage Complete or Status Report

A Project Management Tracker

A Master Plan

Conclusion

Quoting the UK Gov Service Manual for Agile Delivery:

Roadmaps need to be easy to understand, and simple to adjust when priorities change - as often happens with agile ways of working.

They are a high-level powerful visual presentations on a page to help get buy-in on your strategy, they are collaborative, requiring widespread engagement and a fluid conversation for confirmation, a compromise among different priorities, are a dynamic, strategic artefact that reflects your long-term product vision, not set in stone, always at the ready to be updated based on your direction of travel.

In a digital world full of VUCA, you can no longer predict what’s going to happen years out.

You need to adjust to market changes, customer requirements, stakeholder needs, and other influences rapidly, responding, learning, and adapting to change over a plan.

Therefore, Visual Roadmap are a living artefact allowing for Strategic Changes bringing Agility. No more Gantt charts.