Key Takeaways
- Agile was created by software people to uncover better ways of developing software. It provides little guidance for managers on what they should do or how they should do it.
- Common agile frameworks don't explain how the product manager gets a budget or development team; how they design the product and solution or how they integrate the initiative with the rest of the organisation and manage their expectations.
- Most organisations have responded to this gap between management and Agile by staying with plan-driven waterfall and hybrid approaches that have a track record of going well over budget while delivering much less value than predicted.
- Agile Roadmaps build a bridge between management and technical teams by adding product, project, architecture and UX planning to agile initiatives so that you can get the funding and support you need to deliver an initiative in an agile way.
- Roadmaps allow you to plan initiatives in a fraction of the time and cost of predictive methods, which means that you can deliver benefits much sooner at a lower cost.
The Situation
Most organisations use projects to deliver initiatives.
The Project Management Institute estimates that there are at least 66 million project managers in the world with at least 25% in the IT sector. This means that there are probably at least 17 million IT projects going on at any one time.
Although there has been a lot of talk in the Agile community about moving from projects to continuously funded delivery teams the research shows that the vast majority of organisations still fund initiatives through projects. 2019 Gartner research shows that 89% of organisations are using a traditional annual budgeting process for new initiatives. 2018 Gartner Research shows that although many organisations would like to move to a product-centric model, 85% are still using a project-centric one.
The Problem
Few projects meet business expectations
Anyone who has worked in the digital industry for a while knows that the majority of software initiatives, especially large staged ones, are seriously troubled. Research by the Project Management Institute shows that only 20% of projects met their goal, on time and budget, 65% were challenged and 15% failed. Research by the Standish Group shows similar results.
Research by McKinsey and the University of Oxford shows that on average 45% of large IT projects run over budget and 7% run over time while delivering 56% less value than predicted.
Most features aren't used.
At the same time, Standish Group research on internal products shows that people only use one-third of the product features we develop for them. Standish research is supported by recent research by Pendo, which shows that customers don't use 80% of features in the typical cloud software product. This research shows that we are wasting 50% to 80% of our effort on most digital initiatives.
Most projects are based on big up front planning
Seventy percent of organisations are delivering projects using a predictive approach (waterfall) or a hybrid approach (water-scrum-fall) according to PMI Research. Research by the University of Southern Denmark finds the same thing, Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices
Water-Scrum-fall (Hybrid Agile) is traditional predictive project management with construction and some other stages done in sprints.
In my experience, this "Hybrid Agile" or Iterative approach creates a lot of conflict, confusion and change requests that result in outcomes that are just as bad if not worse than a traditional staged development process. Research by the Disciplined Agile consortium that shows that Iterative (Hybrid) teams are much more likely to fail than traditional teams and are less successful than Agile or Continuous Delivery teams.
The waterfall development model originated in the construction industries where design changes became prohibitively expensive early in the development process. Project Managers in the software development industry applied this approach from the beginning because they didn’t recognise that there was or needed to be a different approach for knowledge-based creative work.
Organisations that use a waterfall or water-scrum-fall approach spend half their time and one-third of their effort (and therefore budget) developing detailed plans, requirements and designs upfront. See Phase Distribution of Software Development Effort, 2008.
Organisations use a waterfall or water-scrum-fall approach because they want to know how much an initiative will cost before they start. Proponents argue that it’s worth spending a lot of time and money upfront design because it is fifty to two hundred times cheaper to fix a problem in the requirements or design phase than it is in development or operations.
Organisations also need to develop finance, product, project, procurement and resource management plans to integrate and control activities across the organisation. Agile methods provide little guidance on how to do this.
Big upfront design causes many problems
Projects that do a big design and plan upfront lock in many assumptions early without testing them. These projects don't know if the solution design works until they test it and don't know if the requirements are right until they deploy the product. During testing, project teams always find that a lot of the assumptions they made were wrong or have changed, which leads to a lot of late changes which are very expensive.
The truth is that designs and plans decay as the environment, scope and priorities change and as we learn what the requirements and solution should be. Detailed plans decay rapidly, and architectures and strategy decay more slowly.
The cost of change is much lower in agile projects
Agile frameworks are designed from the ground up to reduce the cost of change by reducing the length of the feedback loop from years to days and minutes.
Agile's low cost of change gives stakeholders much more control over the cost of a project throughout its life. With Agile, organisations can reduce upfront design and planning to a fraction of waterfall projects because they know that they can change the scope and design during the project to deliver the most value possible within the time and budget available.
Initiative Roadmaps
Plans are worthless, but planning is everything. President Dwight D. Eisenhower.
Plans are critical because they set expectations on the goals, the strategy and the resources you need. They justify the organisation's expenditure on the initiative. They allow you to consider the problems you are likely to incur along the way and develop ways to avoid them. Plans build a bridge between management and the development team. With a plan, you can prepare for different eventualities to improve your chance of success. With a plan, you can get the commitment and resources you need to achieve your objective. Without a plan, it's unlikely that people will give you the funds or resources you need to succeed.
Initiative Roadmaps
Over the last few years, I have developed and refined an Initiative Roadmap process that allows you to define, design and plan an initiative in weeks instead of months or years. In an Initiative Roadmap, you set your goal, strategy and direction in a high-level plan so that you can get the necessary funding and support you need to build a delivery team. When the development team starts, they evolve the plan with business stakeholders to deliver the maximum business value possible within the time and budget available.
Initiative Roadmaps are useful for anyone who needs to get resources for the development of a digital product or service. They are helpful for people in general management, product management, sales, marketing, account management, project management, analysis, design and software development in a company, consultancy, Digital Agency or service provider.
I have used Initiative Roadmaps to:
- Plan a new eCommerce site for an Auto Manufacturer that allowed users to customise and price cars before going to a dealer;
- Improve the speed and performance of a Telco self-service mobile phone ordering and management portal for business customers;
- Enhance a self-service network management portal that a Telco provides to Banks and other Enterprise customers;
- Design and plan a knowledge management website for a Health Insurance company's call centre staff and
- Design and plan a new travel website for a travel company.
Before we start
Understand the problem
Initiative Roadmaps help us develop a plan to solve a known problem. If we don't understand what problem to solve or question to ask, then we need to discover the right problem to solve. To do this, we take the brief, question the brief, develop hypotheses and plan and conduct research.
Research can be qualitative or quantitative and behavioural or attitudinal. Qualitative research might involve interviews, usability studies and business process maps. Quantitative research includes analysis of your business processes, customers and product data. Most initiatives benefit from combining insights from multiple research methods.
The objective of Discovery is to get a clear business challenge summarised in a "How might we ?" statement. A how might we statement should be short and memorable with a character, goal and direction. It should be narrow enough to let you know your context, and broad enough to give you room to explore different approaches.
If we were talking about building a new suburb, the challenge might be:
"How might we provide first homeowners, young families and retired people with affordable quality homes in our new suburb as soon as possible?"
Get funding and commitment to develop a plan.
Before you start developing an Initiative Roadmap, you need to get funding and resources to do the planning. In most cases, the Sponsor will prepare a presentation for executives that explains what the business problem is and why the organisation should commit resources for a few weeks to develop a plan to solve it. Some organisations may require the sponsor to go through a formal project inception process. It is not necessary to do a business case before you start an Initiative Roadmap because the Roadmap creates a detailed business case for the initiative.
Initiative Roadmaps are an intense process that requires a significant commitment and rapid decision making. Before we start an Initiative Roadmap, we need to book people in and make sure they are committed to the process.
What are Initiative Roadmaps?
An Initiative Roadmap defines where you are trying to go and how you plan to get there. It describes the team, budget, time and resources you will need. Initiative Roadmaps integrate product planning, UX design, technical architecture and initiative planning into a viable strategy to meet stakeholders expectations. Roadmaps bring senior stakeholders together with relevant experts to rapidly design and plan a new product so that you can get the funding and resources to develop it.
Roadmaps are about the end to the end product plan, user experience, system architecture and project plan. They define multi-step processes, and multi-system data flows. Roadmaps provide teams with a context, direction and strategy for the detailed design done in sprints.
In Scrum, we avoid planning more than a few weeks ahead because we assume that any work done to detail items in the backlog "depreciates quickly and must be frequently re-estimated." Product, UX, Architecture and project roadmaps provide the big picture to inform and integrate the Product Backlog in Scrum.
With an Initiative Roadmap, we aim to avoid delay and waste by doing just enough Technical and UX architecture, design and planning just in time. To achieve this, we create a high-level product and Initiative Roadmap for the next 12 months, UX and architecture roadmaps and models for the next 3 to 6 months and detailed designs for the next 2 to 4 weeks. Our goal is to review and revise these plans every day and every Sprint. As the program and teams learn, they change their roadmaps and models.
An Initiative Roadmap is an alternative to the traditional staged analysis, design and planning process that takes one-third of your budget and half your time. Initiative Roadmaps replace Design Sprints, Business Case, Project Plan, Detailed Business Case, Business Requirements Phase, Solution Architecture Phase, UX Design Phase and the Technical Design Phase in Traditional and Hybrid Agile projects.
Why you need to plan further ahead
In my experience, teams that only focus on planning stories for the next few weeks produce narrow solutions that work well for small features but don't work well when applied to other areas of the product. So instead of developing consistent and reusable UI styles for a website, each developer creates a version of the UI style for the component they are working on, which leads to a disconnected and fragmented solution with a lot of duplicated effort.
Local optimisation plagues organisations and is very common in AI research. A team that advances in small steps can get easily trapped in a local optimum that is sub-optimal overall. In contrast, a group that looks at the bigger picture can see over the local optima to the global optima more easily.
Initiative Roadmaps allow you to develop higher-level roadmaps that let you look further ahead so that you can more easily get to the optimal solution without getting stuck in local optima.
Refer to: Ayoosh Kathuria, Intro to optimization in deep learning
Designing Roadmaps
Experience shows that a small number of smart people who come together to sketch models and develop prototypes can define a viable solution design in two weeks, that is 70% to 80% right. This is an example of the Pareto principle, where 80% of the benefit is gained from 20% of the effort. The team can then iterate to 95% right through trial and error in a few months.
Refer to Scott Ambler: Just Barely Good Enough Models and Documents
Refer to Scott Ambler: How Architects Fit in on Agile Teams
Deliverables
An Initiative Roadmap defines the:
- Business Problem;
- Objectives and Key results;
- Customer Experience Roadmap;
- Solution Architecture Roadmap;
- Product roadmap prioritised by value, size and dependencies;
- Initiative risks and issues;
- Initiative budget and resource plan;
In a traditional project, each of these deliverables would be an 80 to 100-page document with detailed and comprehensive models, spreadsheets and prototypes that takes six weeks to develop and two weeks to review. We won't be doing that.
In an Agile Roadmap, each of the deliverables will be a couple of pages of text, illustrated with 1-2 slides and illustrated through recordings, models, prototypes and spreadsheets. The aim is to provide just enough detail to allow the team to develop a plan that defines a viable strategy and reasonable time and cost estimates.
The Customer Experience Roadmap will map the end to end process flow, illustrated with black and white wireframes of critical interactions with 1 or 2 colour mockups to test the graphic design. It will not provide finished art, working code or a comprehensive blueprint for every user interface.
The Solution Architecture Roadmap will be a simple working prototype that passes data from one end to another to show how the main technical components work in our environment. It will not be a complete, detailed technical design, and it will not provide production-ready code.
Some examples from different initiatives are shown below.
How do you develop an Initiative Roadmap?
An experienced team led by a skilled facilitator can create an Initiative Roadmap in 2 weeks. On the first day of Roadmap planning, we explain the approach, set the objectives, determine the customer journey and the feature roadmap and develop the design and technical briefs. Then we simultaneously design the product, the user experience and technical architecture. At the end of Roadmap planning, we bring it all together to estimate, prioritise the features, develop a budget and document our findings.
Activities
The main activities are:
- Define the challenge and discuss the approach
- Define the business objectives and the key results expected
- Define customer personas
- Define the customer journey
- Define the product feature map
- Define the service blueprint
- Define the current technical environment
- UX sketching
- Recruit customers for testing
- Develop an architecture solution model
- Define the technical POC
- Define the UC POC
- Define the product features
- Develop UX wireframes
- Develop the technical POC
- Define the brand guidelines
- Define the initiative risks and issues
- Develop mood boards
- Review and integrate the UX and Solution models with the product features
- Develop interview scripts
- Conduct UX testing with customers
- Review the technical solution with architects
- Review the UX findings
- Review the features identified
- Estimate feature value and size and team velocity
- Develop a prioritised release plan
- Develop the budget and resource plan
- Brainstorm the risks and issues
- Define the delivery approach
- Write up the results as a detailed business case
- Review the UX, Architecture and Delivery plan with stakeholders
The Planning Team
In my experience, an Initiative Roadmap works best with a team of six to twelve people. Three to six people to run the process and three to six people to provide direction, share knowledge and make decisions. If you already have a delivery team for this product, then that team should do the planning with some help from experts. If you don't have a product delivery team available or you haven't set up the initiative yet, then you should bring together the people that you expect will be taking the initiative forward.
I estimate that there are about 70 days of work in an Initiative Roadmap spread across the team. The planning team should include a facilitator, designer, architect, business leader, business expert, technical expert and project manager. We can split each of these roles between two people if people are not available full time. For instance, the Sponsor could participate for 30 hours with the support of a Product Manager / Product Owner on their team who participates for 50 hours. And the UX/UI Design role could be split between a UX Designer and a UI Designer.
Role |
Hours Effort |
Facilitator / Agile Coach / Business Analyst |
80 |
UX / UI designer |
80 |
Solution Architect / Dev Lead |
80 |
Sponsor / Business Unit Manager / Product Manager / Product Owner |
80 |
Subject Matter Experts |
80 |
Technical Domain Expert / Enterprise Architect / Integration Developer |
80 |
Initiative Manager / Business Analyst / Documenter |
80 |
Pitfalls to avoid
Traditional managers can inadvertently sabotage the Agile Roadmap by demanding all of the deliverables that they are used to in a conventional staged planning process. For example, they may insist on a detailed:
- Business requirements document
- Solution architecture document
- Technical specification document
- UI design document with finished wireframes and art assets for every page
- Project Plan with a Gant chart.
Traditional managers may also try to turn the Initiative Roadmap into a fixed scope, fixed-price contract for the delivery of everything defined in the Roadmap without change.
You can combat these problems by bringing traditional managers into the planning processes and using your time in workshops to teach people about fixed price, fixed cost, variable scope delivery with agile teams and explain what the deliverables will be.
You may also have a problem with people who skip workshops or spend their time in workshops on laptops or phones. The facilitator should bring this behaviour to the attention of the sponsor and the planning team, explain the impact and ask the group what they should do about it.
What happens after the roadmap
After the planning team has developed the Initiative Roadmap, the sponsor can use it to request funding for product delivery. Or they may decide that the plan is too expensive and they need to find a cheaper way to solve their problem.
An Initiative Roadmap is not a one-time event that creates a fixed scope that must be delivered without change. An Initiative Roadmap is a living plan that evolves through continuous review and replanning at all levels throughout the lifecycle of the project. At the next level down, there is sprint planning, then acceptance tests, all the way down to continuous development, integration and deployment. If the team discovers that one of the assumptions in the Roadmap is wrong, then they change the plan to maximise business value within the time and budget available. It's not plan-driven, it's adaptive and evolutionary.
Scaling Initiative Roadmaps
You can use Initiative Roadmaps to plan large programs by mapping out big chunks of work that can be done in 3 to 6 months and then planning each piece as a separate initiative with its own Roadmap. Research by the Standish Group shows that smaller projects are much more likely to be successful than larger ones, so it is always a good idea to break an extensive program into smaller parts.
Scaling your program
Rather than starting a massive program in one go, it is best to start with one team, prove that it can deliver the value expected and then split it into two groups, which divide into four and so on through a process of mitosis.
You should split your teams so that each one has an external customer or an internal client. Some of these teams might deliver value to customers directly, while others provide platforms and features that support the business-facing product teams. The more independent the groups are, the better. Complex inter-team dependencies slow you down.
Growing your program over time substantially reduces risk and allows you to develop a coherent culture and strategy across teams.
Integration Team
In programs, an integration team manages the cross dependencies between groups by developing the integrated product, architecture, UX, initiative and budget roadmaps for the next six to 12 months. This team has a Product Owner, Initiative Manager, Agile Coach, Solution Architect, UX Designer and representatives from each of the individual groups. The integration team is similar to the one defined in Scrum Nexus but with a broader focus on budgets, resourcing, architecture and UX design. The integration team will lead the development of the Initiative Roadmap for new initiatives making sure to include the people who will deliver if it is approved.
Benefits
Plan faster, plan better.
Initiative Roadmaps define an approach that a Product or Project Manager can use to quickly and effectively determine the product plan, solution architecture and funding for a new initiative. With this plan, they can get a budget and resources for the project, start earlier, deliver faster, increase customer satisfaction, reduce risk and realise benefits sooner.
Roadmaps put your customer at the centre of the initiative so that you can develop a solution that meets their needs. They allow you to define a realistic plan to deliver a valuable product quickly and efficiently, on time and budget. And they put you in control of the development process so that you get the best outcome from your suppliers or develop the initiative yourself.
Initiative Roadmaps cut your planning time and cost by more than 50%, allowing you to deliver benefits much faster and catch up when you've fallen behind. The chart below shows the plan for a mid-size website redevelopment compared to what usually happens and what could happen with Agile Planning. As you can see by using Agile Planning combined with Agile Delivery, you can finish the initiative in the time it would normally take to plan it.
The Digital Director for a major car company we worked with told me that they saved 12 months and hundreds of thousands of dollars by doing an Initiative Roadmap. And the Sponsor for a Knowledge Management initiative at a health fund told me that we got further in 2 weeks than their IT organisation had done in the previous 12 months with a Water-Scrum-Fall approach.
I have developed and evolved Initiative Roadmaps over the last seven years for many large and small organisations. If you would like some help to implement this approach, contact me at murray@ev0lve.co, and we will run it for you.
References and Acknowledgements
Agile Initiative Roadmaps draw on ideas from a lot of different thinkers in the Lean, Agile, Scrum, XP, Agile Architecture, UX Design and Project Management community. I owe a lot to Kent Beck and Martin Fowler for Planning Extreme Programming, Mike Cohn for Agile Estimating and Planning, Jeff Patton for Story Mapping, Scott Ambler for Agile Architecture, Eric Reiss for Lean-Agile Product Development, Jake Knapp for Design Sprints, Jeff Gothelf for Lean UX and Henrik Kniberg for Scrum and Kanban in the trenches.
I would like to thank Dean Netherton for introducing me to Agile XP in 2004, to Ben Scown for helping me develop an Agile planning approach at Telstra in 2009 and to David Cox for introducing me to Design Sprints in 2016. I would also like to thank the many people who reviewed and provided feedback on this article.
I hope that you find that the planning approach that I describe here provides you with a better way to initiate and plan your next Digital Initiative.
About the Author
Murray Robinson, MD Ev0lve, works with organisations to design digital initiatives and organizations capable of realizing them. He has 30 years experience in IT starting as a software developer, 20 in digital, 20 in product and project management, 16 with Agile and 3 in UX. Contact Murray at murray@ev0lve.co if you would like to find out more about planning and running Digital initiatives.