Technological Thoughts by Jerome Kehrli

In my current company, we embrace agility down the line, from the Product Management Processes and approaches down to the Software Development culture.
However, from the early days and due to the nature of our activities, we understood that we had two quite opposed objectives: on one side the need to be very flexible and change quickly priorities as we refine our understanding of our market and on the other side, the need to respect commitment taken with our customers regarding functional gaps delivery due dates.
In terms of road-mapping and forecasting, these two challenges are really entirely opposed:

• Strong delivery due dates on project gaps with hard commitment on planning. Our sales processes and customer delivery projects are all but Agile. We know when in the future we will start any given delivery project and we know precisely when the production rollout is scheduled, sometimes up to 12 months in advance. We have most of the tine a small set of Project Gaps required for these projects. Since we need to provide the delivery team with these functional gaps a few weeks prior to the production rollout, it turns out that we have actually strong delivery due dates for them, sometimes 12 months in advance.
• Priorities changing all the time as our sales processes and market understanding progress. We are an agile company and mid-term and even sometimes short-term focus changes very frequently as we sign deals and refine our understanding of our market, not to mention that the market itself evolves very fast

These two opposed challenges are pretty common in companies that are refining their understanding of their Product-Market Fit. Having to commit strongly on sometimes heavy developments up to more than a year in advance, while at the same time changing the mid-term and short-term priorities very often is fairly common.

In this article, I would like to propose a framework for managing such a common situation by leveraging on a roadmap as a communication, synchronization and management tool by inspiring from what we do in my current company (leveraging on some elements brought by Mr. Roy Belchamber - whom I take the opportunity to salute here).

There are three fundamental cultural principles and practices that are absolutely crucial in our context to handle such opposed objectives. These three elements are as follows:

1. Multiple interchangeable development teams: multiple teams that have to be interchangeable are required to be able to spread the development effort among flexible evolutions - that can be reprioritized at will - and hard commitments - that need to be considered frozen and with a fixed delivery due date.
2. Independent and autonomous development teams: these development team need to be able to work entirely independently and without and friction from any other team. This is essential to have reliable estimations and forecasts. A lot of the corollary principles and practices I will be presenting in this article are required towards this very objective.
3. An up to date and outcome-based Roadmap. Having a roadmap that crystallizes the path and the foreseen development activities in the next 2 years is absolutely key. Such a roadmap is all of an internal communication tool, an external communication support, a management and planning tool..

In this article, I intend to present the fundamental principles behind the design and maintenance of such a roadmap that are required to make it a powerful and reliable tool - and not yet another good looking but useless drawing - along with everything that is required in terms of Agile principles practices.

This article is available as a Slideshare presentation

Summary

• 1. A Software Development Roadmap
  • 1.2 Roadmap elements
  • 1.3 Hierarchy
  • 1.4 A realistic Roadmap
  • 1.5 In the next chapters
• 2. Prerequisites
  • 2.1 A. Agile Software Development Teams
    • 2.1.1 eXtreme Programming
      • 2.1.1.1 Small-releases
      • 2.1.1.2 Testing, testing and more testing
      • 2.1.1.3 On-site customer
      • 2.1.1.5 The Planning Game
      • 2.1.1.6 XP Takeaways
    • 2.1.2 Lean Startup
      • 2.1.2.1 Pizza Teams
      • 2.1.2.2 Feature Teams
      • 2.1.2.3 Lean Startup Takeaways
    • 2.1.3 DevOps
      • 2.1.3.1 Infrastructure as Code
      • 2.1.3.2 Continuous Delivery
      • 2.1.3.3 DevOps Takeaways
  • 2.2 B. The 3 Horizons Framework
    • 2.2.1 Business economics
    • 2.2.2 The three Horizon framework from McKinsey
    • 2.2.3 Three Horizons framework - takeaways
  • 2.3 C. The Estimation process
    • 2.3.1 The roles and rituals involves in the estimation process
    • 2.3.2 Rituals are scheduled
    • 2.3.3 Now the Estimation Process
    • 2.3.4 Team Sprint velocity
    • 2.3.5 Forecasting
    • 2.3.6 The Estimation process - Takeaways
  • 2.4 D. Roadmap timeline
    • 2.4.1 Monthly roadmap update
    • 2.4.2 Back on Continuous Delivery
• 3. Conclusions and final notes

1. A Software Development Roadmap

A good roadmap implies some important characteristics:

• Aligns with company strategy, rallies all around this and steers us towards delivering on this strategy
• Focuses on delivering customer value & articulating benefits
• Excites our customers about our company & product direction
• Reflects what we have learned, over time, as an organisation
• Does not pretend to have all the answers, neither needs to

If it is done well, a roadmap is a strategic communication tool, a statement of intent and direction.
A good roadmap has to set a clear direction and simultaneously embrace uncertainty inherent in product development

Some pitfalls have to be avoided when designing a good roadmap:

• Excessive granularity – too much focus on detail and dates means it will inevitably soon be inaccurate or even obsolete!
• Mistakenly thinking every item in the roadmap demands upfront design and estimation - this is impossible and wasteful. Only the short-to-mid-term elements have to be estimated accurately.
• Believing each stakeholders must personally value every item
• Ensuring our roadmap is not conflated with our product release plan!

1.2 Roadmap elements

The essential elements of a roadmap are as follows:

• A good roadmap starts with a vision of where we are going, guides us there and explains the stops along the way. The vision is the guiding principle.
• Broad timeframes avoid overcommitment - it's the sequence that matters (now, next, future). As we move along the sequence, accurate estimations become less important. Down to the point where we don't really care about the time that might take something on which we are not going to be working before several years.
• Focus on outcomes not outputs. Themes are not granular features and functions.
• What goals will our product accomplish? What outcomes?
• Protects against claims of broken promises by explaining that changes can happen.

These elements would be illustrated as follows for instance for a RIAO - Rich Internet Application Organizer (as introduced in my "Lean / Agile Product shaping" slideshare and detailed in my "Introduction to Modern Software Architecture" slideshare.):

1.3 Hierarchy

In terms of hierarchy, we have to wonder why we are doing this, why it supports our strategy, what customer problems it will solve, and finally how to solve it.
The Roadmap is about what customer problem we're about to solve. And the Product Backlog is about how will we solve them and what solutions do we need to implement to solve these.
The roadmap is a product management concern, while the backlog is an R&D concern.

1.4 A realistic Roadmap

Let's look at something more realistic.

This example is a slightly reworked (anonymized and generified) version of the roadmap we use today (April 2021) in my current company. It is really an instantiation of all the fundamental principles expressed above and we will be using it throughout the remainder of this article to illustrate all key practices required to make it a living and yet fairly useful tool.

A first important thing is to be noted.
As we move along the timeline of the roadmap, the confidence and certainty diminishes down to the point where, in 2 years from now, the roadmap is more a collection of long term development ideas and in no way any kind of actual commitment on working on any of these.

1.5 In the next chapters

In the next chapters of this article, we will be covering all the fundamental concepts, principles and practices that need to be understood and adopted to make this roadmap a useful communication and planning tool.

2. Prerequisites

In order to be able, to design and maintain such a roadmap, some organizational principles as well as some product management principles are required.
Then, if one intends such a Product Roadmap to be more than a fancy marketing tool, really a strong communication, management and planning tool, it's essential that the forecasts are as reliable and realistic as possible. And this is fairly complicated since it relies on the ability of the individual development teams working on a specific topic to be able to work autonomously, independently and without any friction with other teams. And this in turn requires an in depth adoption of Agile Principles and practices not only in the development team but at product Management level as well.

In this chapter, we will be looking at each and every of these prerequisites.

2.1 A. Agile Software Development Teams

First, if we want to be in a situation where we can respect the roadmap timeline and have reliable forecasts, the multiple development teams working in parallel on the multiple streams need state-of-the-art agile culture, principles and practices.
The whole problem is How to build a team with a culture, an organization and a set of principles and practices that make estimations possible and forecasting reliable and accurate ?
The answer is by adopting a state of the art Agile Engineering methodologies.

The schema below is a slide that I've designed when I was a consultant carrying on digital transformation projects in big corporations. Very often I was meeting IT teams that were not agile at all. I needed a slide to explain to them what are the prerequisites if one want to embrace digital transformation.

My message here was as follows:
"Look, if you want to go digital, if you want to come up with digital products and be able to develop and adapt them at the pace that is required in the digital world, it's going to be fairly difficult if you're not an agile Corporation, if you haven't scaled agile principles and practices at the level of the whole organization.
And then scaling agile, if you haven't embraced the Lean Startup methodology, and if you don't have company wide monitoring and improvement approaches such as Kanban and Kaizen, will be difficult.
Then doing Lean Startup, Kanban, and Kaizen if you don't have a state of the art Agile software development methodology, and if you haven't embraced DevOps principles, will be difficult.
And finally doing Agile and DevOps, if you're not state of the art regarding eXtreme Programming principles and practices will be difficult."

Now, if you want to be in a situation where you have independent and autonomous teams which can benefit from reliable estimations, and eventually come up with reliable forecasting abilities, then you have to have raised agility adoption to this level in your company.

Another way to illustrate, these agile methodologies such as DevOps, Lean Startup and others would be The Periodic table of Agile principles and practices.

All the principles and practices with a red border are effectively needed for accurate planning and road mapping. All these practices are required to have independent and autonomous teams giving you the ability to parallelize development epics and be in a position where you can accurately estimate the velocity of these teams, in such a way that eventually you're able to do reliable estimations and forecasting on the items for which you need to have an accurate due date.
Now in reality the situation is more complex since at the end of the day all the practices from the table heavily depend on one another so in the end you need to have embraced most of them.

We will now review the most essential practices with direct impact on planning and forecasting abilities from these various methodologies.
We can't review all of the required practices, of course, but at least those that I believe are the most essential ones from eXtreme Programming, Lean Startup and DevOps that one needs to adopt, if one want to be able to reach the ultimate goal, which is having autonomous and independent team, giving one the ability to paralyze development items, while still being able, within teams, to have accurate planning capacity and estimations, and eventually reliable forecasting.

2.1.1 eXtreme Programming

The eXtreme Programming practices are as follows. This representation is interesting since it shows that even only within XP, all these practices depend from each others.

Let's discuss more in detail 4 essential principles when it comes to planning: Small-releases, Testing, On-Site Customer and the Planning Game.

2.1.1.1 Small-releases

And the first part I want to mention is XP's Small Releases principle, which DevOps streamlines as Continuous Delivery. The fundamental idea behind it is that if you want to master your release process, you have to release as often as possible, for multiple reasons. First, because if you release as often as possible, the releases are small. And as a result, your chances of mastering the process are much higher than if you have rare and then very large releases.

Having smaller gaps and smaller changes in your releases significantly reduces the risk inherent to the release.
But there's another reason behind it. If you ask an engineer to do something very often, he will automate it. This is not necessarily the case if an engineer does only a few releases a year, why would one bother automating it?
But if you ask your development team, your engineering team, to release at the end of every single sprint a production-ready and shippable version of the product, then your development team will automate the release process. That's what engineers do.

2.1.1.2 Testing, testing and more testing

The next topic is about testing. XP's practitioners are always saying that one has to invest the 20% of time required to reach 80% coverage of the cyclomatic complexity of the code or branch / line coverage, and not more (since the remaining 20% would require 80% of the investment) .
But if one wants to go to continuous delivery, if one wants to be in a situation where one is able to entirely automate the release process, then the 80% target is not sufficient anymore, one has to target 100% coverage.

And this is doable with different types of test. Covering more than 80% of the code complexity with unit test only is impossible. But integration tests enable to go beyond, for instance typically 90%. Then if one is able to have the product entirely built and deployed automatically on a production like environment, then one is able to implement end-to-end / functional tests using for instance protractor, Selenium or whatever. And with end-to-end / functional tests, you are able to cover the remaining 10% to reach nearly 100% coverage with your whole automated tests suite.
And this is essential if one wants to be able to have reliable forecasting abilities. Because stop the world releases are killing it. It's fundamentally unpredictable how much time it takes to complete acceptance tests, fix the remaining issues and eventually release the software if one waits for periodic releases.
One needs to entirely automate non-regression tests and acceptance tests using functional, integration and unit tests. And this will be absolutely key to reach continuous delivery.

But there's something else that needs to be accounted. In this next chart, we're looking at three typical situations of a feature development. The first situation is without any automated test, the second is with some tests implemented after the development is done, and the last situation is when embracing TDD.
This chart is explained in detail here in a previous article.

This is interesting. We have the illusion that skipping the development of tests makes us gain time. And if you look at the blue box, it does indeed make us gain time in terms of pure development time. But the time lost after the development phase exceeds greatly the time gained by skipping tests.
Writing some tests after implementing the code really helps, we can see that the development time takes longer but is really compensated by the time gained on debugging and manual testing. Not to mention the formidable documentation that unit and integration tests form.
But the striking approach is when we're putting in place TDD - enabling us to reach a close to 100% coverage of the code with our automated tests - where we spend most of the time doing pure development, which takes longer of course, but the return on investment is absolutely brilliant.

And the interesting thing when it comes to planning and forecasting is that the blue box can be estimated. This is typically what we estimate, when we do the planning game with Story Points. It's possible to estimate the time it takes to develop a feature, including the tests. On the contrary the time that it would take to debug it, manually testing it or re-understanding it is fundamentally unpredictable.
TDD brings most of the development activities back to something that can be estimated, which is the pure development time. And this is not optional. If one wants to be able to have reliable forecasts and reliable estimations, one needs to bring most of the development activities back to something that can be estimated. This is absolutely precious with TDD.

For more information on TDD, refer to my previous article.

2.1.1.3 On-site customer

XP insists on the need to have an on-site customer to streamline the development pace by being able to answer questions, provide refine specifications and, importantly, do acceptance testing continuously as development tasks are being completed.
The notion of on-site customer - having someone with a true business expertise - is replaced in scrum with the notion of product Owner.
If one wants the development teams to be independent and autonomous then one needs to make sure that this team can work on a feature peacefully and in isolation down to production readiness without any interruption and without any dependency on an external actor.
The product owner enables to do continuous acceptance testing thus avoiding stop the world events and streamlines acceptance testing as part of the development activities.
For this reason mostly, the on-site customer - or the scrum product owner - is crucial.

2.1.1.5 The Planning Game

And finally, the planning game. You need to think of it this way: imagine you're looking at a big stone somewhere in a field. Estimating out of the blue the weight of the stone is very difficult. Estimating absolute figures is a very difficult game.
But answering to another question which would be "is the stone heavier or lighter than this other stone ?" is a completely different story. It's a comparison game. And that's surprisingly easier. Finding out whether a stone is somewhat bigger than another one, but also somewhat smaller than a third one, is a much easier game.
Story points enabled to transform a very difficult estimation game into a much more a much easier comparison game.
And that's what the planning poker with Story Points is all about.
It's about finding ways to transform a difficult problem in an easier problem. And after a while, the team becomes quite good at it

And if you're able to accurately estimate a task in story points using the comparison game, then you're able to compute how many story points a team is able to do in a sprint. And if you know how many story points a feature cost and what is the sprint velocity of a team, then you can compute how many sprints does the team need to implement this very feature.
And with this, you can do forecasting and planning ... if and only if the team is able to work independently, autonomously, without any synchronization point, without stop the world events and without any friction coming from the need to collaborate with another team.
And we will see what these teams are to enable such independence.

More information on the Planning game in a previous article and further in this very article.

2.1.1.6 XP Takeaways

Summing things up:

• First, the product owner (i.e. on-site customer) - enables the team to be autonomous and work on its own without interruption by answering questions as they pop up and, more importantly, running acceptance test continuously, so that a developer can consider his task being finished as soon as possible before he moves to the next one.
• Small releases - which we will see as Continuous Delivery in the DevOps methodology - enables to avoid periodic releases as stop the world events, which would break both the autonomy and the pace of the team by forcing synchronization points everywhere on the roadmap timeline.
• TDD enables to have reliable forecasting by bringing most of the development team activities to something that can actually be estimated and forecasted, which is code implementation time. Debugging sessions, testing and re-understanding the code are activities that are fundamentally impossible to estimate.
• And finally, the planning poker estimation game enables to have reliable estimation and forecasting abilities, surprisingly and counter-intuitively much more than traditional waterfall.

2.1.2 Lean Startup

Eric Ries presents Lean Startup as the Build - Measure - Learn loop.
Steve Blank presents it as the Four Steps to the Epiphany process as follows. We won't be discussing Lean Startup in depth today but I would want to discuss two Lean Startup Practices that are crucial to shape autonomous and independent, and yet interchangeable and equivalent teams: Pizza Teams and Feature Teams.
One might refer to my previous article on lean startup to get an overview of all Lean Startup principles and practices.

Let's discuss shortly these two important principles related to Agile Teams.

2.1.2.1 Pizza Teams

I discussed in length Pizza Teams in my previous article about Lean Startup so I will only recap a few things here.

The reason for small teams is that the more people you have in your team, the more you explode the number of one-to-one communication channels. So one needs to keep a team being sufficiently small to make it so that everyone is able to understand what everyone else is working on.
One needs to keep the team sufficiently small to have an efficient organization within the team, and so the ability to have people collaborating together, for instance, the UI UX expert with the backend developer, the DevOps engineer, etc.
But the teams needs to be sufficiently large to enable efficient brainstorming, the ability to generate new ideas, interchangeability of essential resources, etc.
In my current company, we believe that the ideal size for our Feature Teams is between 5 and 8 engineers.

2.1.2.2 Feature Teams

Just as for Pizza Teams, I discussed in length Feature Teams in my previous article about Lean Startup so I will only recap a few things here.

The key point with Feature Teams is to have teams that are independent and autonomous as possible without any synchronization needs or friction with any other team. This is essential to guarantee that the team cam deliver a feature from A to Z on its own, where Z is the production rollout or release. This in turn is key to have reliable estimations and eventually forecasting abilities.
Organizing an R&D department with Feature Teams is striking in this regards.

To understand this, consider the following.
Most of the time, the way software engineering development projects or IT departments are organized in companies is by having component teams. In the component teams model, one team is taking care of the UI, another team takes care of developing the back-end, there is perhaps a data science team, another team takes are of data management and database infrastructure, and so on.
These multiple teams have to collaborate to develop a feature or to implement an evolution on the set of products that they develop or maintain. And that's where the problem is, every single team cannot go faster than the slowest of all the teams on which they all have a dependency.
Imagine that each and every feature requires some changes in the database model. And these can only be done by the database team. Then no team can go faster than the database team because they all have to wait on the database team to finally implement the changes to the database model that they require.
Components team are killing the performance of the IT development department or project as a whole.

A feature team on the other hand is able to implement a feature from A to Z, from refined specifications down to production deployment, entirely independently and autonomously.
This can only work if you have within the feature team all the competencies that are required for that: developers, UI/UX experts, data scientists, QA engineers, DevOps engineers - not necessarily to operate the software in production, but to automate the deployment and operation of the software in production - and so forth.
And since these feature teams are able to work on a feature entirely independently and autonomously, then if you know the velocity of your feature team, you know how long it will take it to implement a feature that you have been able to estimate.
Feature teams are multiplying the performance of the whole development or software development organization by several orders of magnitude. And the side benefit is they are autonomous and independent by design.

Just a little note about component teams, people are sometimes confusing component teams and product teams. While it is not acceptable to have component teams (one team working on the UI, another team working on the back end, another team working on the research, yet another working on the database and so on=, it is on the contrary crucial to have product teams.
Component teams are killing performance by introducing strong dependencies between teams.
But having a Feature Team linked not to a component, but to a product makes a lot of sense. We want to leverage and develop business expertise of the feature team. And this can't happen if a feature team is moving all the time from one product to another.

A feature team is fundamentally linked to a product or perhaps a consistent set of products (or product line), because that's the product they will start to be familiar with in terms of business understanding.
And that is essential to avoid wasting time. With experience on a product, the team can become even more autonomous and slowly reduce its dependency on the product owner to be there and working with the team all the time to understand what it has to do in terms of business requirements.

2.1.2.3 Lean Startup Takeaways

Summing things up:

• First, a feature team is an independent and autonomous team that's able to implement a feature from A to Z. And the fundamental idea behind that is that as soon as a team has any dependency on another team, its estimation and forecasts are simply not reliable anymore. Multi-team consolidated planning and forecasting is a much more difficult problem.
  From A to Z means that the team needs to have everything it takes to carry on its mission, 3rd level support, documentation, maintenance, automated test development, code reviews, IT testing, acceptance testing with the product owner, releasing, continuous delivery, continuous deployment, deployment and delivery automation, everything... And the DoD - Definition Of Done on a task or epic has to account all these elements.
  And the takeaway here is that because the team is autonomous and independent, its planning and forecasts are accurate and reliable.
• The reason you want to have many of these independent teams is that you want to be able to work on different things in parallel. You want to have a fair share of spread between the project gaps and the short term development, while retaining the ability to work on long term topics.
  And how you want to do this if you don't have different teams able to work on different things at the same time?
  So you want to have multiple feature teams in your project development organization to be able to have different core focuses at the same time.
• Finally, because a feature is being given to one autonomous team, and that team is able to work without any friction without an interruption, and more importantly, without any stop the world event, the team's velocity calculation enables to do reliable forecasting.
  As a side note, something that's important to understand as well is that the development team should never ever be exposed to customers. If all the time the team has to answer customer requests then its performance will critically suffer. First and second levels of Support need to be external to R&D.

2.1.3 DevOps

At the very root of DevOps is the wall of confusion between developers and operators. And the wall of confusion is a crystallization of the fact that developers and operators have fundamentally different objectives, and fundamentally different cultures.
A developer is challenged to deliver new functionalities to production as fast as possible. An operator, on the other hand, has the fundamental mission of maintaining the production stability, which is precisely what a developer pushing changes all the time is compromising. These two different roles in an organization have entirely different and completely opposed objectives.

Interestingly, the web giants have built organizations making this wall of confusion nearly vanish. DevOps is a lot about understanding how traditional industries can inspire from the web giants to streamline the interactions, and smoothen the relationship between developers and operators.
And DevOps relies on three pillars:

I described these principles and practices in length in my previous article on DevOps so I wont be repeating much more here.
I will just emphasize a little two aspects that are utmost essential for planning and estimations that are Infrastructure as code and Continuous Delivery

2.1.3.1 Infrastructure as Code

Again, this is very much detailed in my previous article so have a look at the section on Infrastructure as Code.

The reason why Infrastructure As Code and Continuous Delivery are essential to planning and forecasting is because both enable to automate entirely the deployment and release process - the deployment process in case of a cloud or SaaS application, and the release process in case of an application deployed on premise.
Automating release and/or deployment is crucial since we don't want stop the world events. We want a feature team to be able to implement changes on the software, release them and push them to a customer, without any friction and without any contention coming from other teams that have different speed or timelines. And this can only work if the whole release or deployment process is entirely automated. And at the end of the day, this is what DevOps is about.
We have all the possible tools today to automate machine provisioning, system configuration, application deployment, etc.

Automating all of this is difficult, I'm not saying it's easy. it's everything but easy when you implement features that involve significant technology changes to keep up to date the automated deployment process, the automated release process, etc. At the end of the day, there is a reason why courage is the most essential value in eXtreme Programming.
But again, you don't have much of a choice. That's the only way you can make teams independent from each other and avoid stop the world events. And 20 years ago, that would have been crazy. But with the tools we have today, with virtual machines, Docker containers, Ansible, Chef, Puppet, with everything you can build around these tools to make it so that you click a button and the release is entirely automated with all the tests being executed, etc. this can definitely be done. And it has to be done.
The Return On Investment in building and maintaining such automation infrastructure is absolutely striking. It enables a team to deploy to production (or create a release) independently from every other team. And this is absolutely key when planning and forecasting matters.

2.1.3.2 Continuous Delivery

The fundamental idea behind continuous delivery is that doing deployments is difficult. And because it's difficult, one has to do it as often as one can.
There are two reasons for this:

1. The first reason is that the more often you release, the smallest the changeset will be. And the smallest the changeset is, the more you master it, the more you can control it and the smallest the inherent risks are.
2. But there's another reason: if you ask an engineering team to do something all the time, they will automate it, that's the way engineers work. They will invest the time to make it so that the next time they need to do something it's as easy as pushing a button. And that's absolutely key, because if you automate your release and production rollout processes, then you can do it as often as you can.

A little note about on premise deployment.

If you want to release an application, for instance at every end of sprint or at the end of every feature and push it to a customer, then internally you have to organize the team in such a way that it makes it possible to release at every end of sprint a shippable, production ready version of the product.
Releasing the product and deploying it to any given customer has to be a product management decision. As far as the development team or the R&D is concerned, every single sprint has to finish with a production ready, shippable version. Period.
For this to be possible, you have to be in a situation where if one day you push, for instance, version 7.3.4 to a customer, then then a few months or years later you release a 9.46.5, you need to be able to push that upgrade to that very customer automatically. For this you have to build a framework that enables you to apply these upgrades entirely automatically. It should be possible all the time to push upgrades automatically. If you don't do that, if applying an upgrade to a customer involves manual steps, manual data migration, manual configuration migration, etc. then you're screwed because it would force you to potentially maintain all the individual versions you have in production at your customers. And that would kill the performance of your team with its ability to focus on the last development version only.

In short, Continous delivery is key for planning!

• You don’t want to loose time on Deployment
• You want deployment to be automated
• You want deployment and production release to happen without you worrying about it or even only noticing
• You want to be able to develop on one single branch, the latest development branch, and push any version to any customer thanks to the data migration framework maintained along the software.
• it's key to avoid multiple team synchronization

I won't detail continuous delivery any further here and would refer to my article on DevOps, specifically the sections about:

• Continuous Delivery deployments
• Zero Downtime Deployments

2.1.3.3 DevOps Takeaways

Summing things up:

• You have to be in a situation where releasing a new version of the product or pushing it to the SaaS of cloud environment is a push-a-button, anecdotal event. You don't want to lose time on releasing or deploying in production because that would mean you have stop the world events in your entire development department, killing the ability of your teams to work independently on their own feature.
  If every three months or every two months or even every month a team has to stop everything because a release process is going on, it's impossible to respect the estimations and forecasts.
• Automated tests are essential. You want to be in a situation where you push a button to deploy the software to production. This only works if you have a complete suite of automated tests and end-to-end tests that ensure the software is working 100% before it's automatically pushed to a production environment or automatically released.

2.2 B. The 3 Horizons Framework

Your might have noticed these H1, H2 and H3 notions on the roadmap. It's now time to explain this. This comes from McKinsey's 3 Horizons framework
In order to introduce the three horizons framework by McKinsey, I need to start by explaining a few concepts of Business Economics.

2.2.1 Business economics

So let's start by looking at the following charts:

On the left here, we have what we call the Technology S Curve. And it's quite typical in product development stories with a strong innovation dimension.
The technology S curve illustrates that when you invent a new product, when you invent a new technology or come up with a new offering for specific market, the progresses you make at first from a technology standpoint are huge. But after a while, continuing to invest more and more in your product or your technology doesn't make a whole lot of sense. Because after a while, the amount of investment you have to consent to develop your technology further is exploding. After a while, you have reached the maximum you can do with your technology or your innovative product. And it doesn't make a whole lot of sense at that point to keep investing in it, you better move your idea to the next level, or look at adjacent segments, or even entirely new products.

And this is shown pretty well by the technology profit curve on the right as well, which is saying basically the same thing, but from a different perspective.
When you have a new idea, when you put a new product on the market, in a real Product-Market fit situation, the money you make out of your product gets very high quite early. You make very fast a lot of profits. But after a while, this technology is being disrupted in its turn - you have competitors offering the same idea, you have alternative offering coming up, and your profit will go down. And when this happens, you have to find the next level investment, the next level innovation in your idea or develop something completely different. And again this is quite typical in companies developing product with a strong innovation dimension.

2.2.2 The three Horizon framework from McKinsey

This is at the root of the three horizons framework from McKinsey.
McKinsey is basically saying that, in order to keep developing your company, and perhaps your solution or your technology, you have to be aware, monitor, foresee and manage these situations. If you're working on your current technology, you have to be aware that it has a deadline. After a while it doesn't make a whole lot of sense to keep investing in what you're doing today. You have to identify your next idea, you have to identify the next level evolution to enhance your idea or technology that will make you reach the next level.
And also, you have to keep in mind that eventually you might need to come up with something completely new to keep developing your company further.

This reads as follows:

• Horizon 1 is about maintaining and strengthening your core business.
• Horizon 2 is about expanding your offering further for new opportunities or emerging markets.
• Horizon 3 is about genuinely new businesses, competencies and possibilities, perhaps on top of your current technology, but likely on something completely new, yet related to your product vision, the next level idea.

The best example of that is Uber. They came up with their initial application very fast. And after a while, developing the Uber application itself didn't make much sense anymore. It was working perfectly. And it started to be challenged by competitors offering. So Uber came with Uber Eats leveraging on their technology to provide a completely new product on a new market.

Again:

• The first horizon involves implementing innovations that are improving the current operations or the UX of the product or covering functional aspects that were not covered so far.
• The second horizon is about innovations that extend the human competencies or technology abilities into new related markets. It's about looking at new verticals or adjacent segments.
• The third is about disruption or high-end innovations that will change the nature of your industry and generate entirely new possibilities and competencies.

McKinsey speaks of the horizon 1 being one to two years, horizon 2 being two to four years and Horizon 3 being three to five years.
In my current company, this doesn't speak to us, since, well, we have absolutely no idea of what we're going to be doing in five years, this is like forever to us. And it doesn't make a whole lot of sense to think of it so much today aside of some high-level orientations. For us, our interpretation in terms of timeline is as follows. Horizon 1 is now to 12 months, Horizon 2 is six to 24 months, Horizon 3 is three years from now.

An important aspect of the 3 horizons model is that at every single moment, you should have a fair share of investment on the thre horizons, meaning elements from the 3 horizons in your current backlog.
If you have not reached the flattening of the profit curve, the you have mostly H1 innovations or elements, but you should also have a fair share of Horizon 2 and 3 elements.
If you have reached the flattening of your profit curve, then the ratio of Horizon 2 and 3 elements in your backlog should be higher.

2.2.3 Three Horizons framework - takeaways

Summing things up:

• You should have a fair share between the different Horizons in your backlog and your sprint development tasks. If most of the time, the majority of your investment should be on Horizon 1, there should still be a fair share of Horizon 2 and 3 elements. Whenever your reach the flattening of your curves, the ratio should change in favor of Horizon 2. But you can't avoid investing on Horizon 2 and 3 already today. If you don't, you will die.
• A little note about the stories related to individual customer integration projects or individual delivery project: for some of them, you might not know before you actually start the project or the specific implementation, all of that very customer needs, the precise scope, and hence you can't estimate accurately. In this case, you have to take some reserves. And it's fine to take reserves, you can absolutely be in a situation where you don't know exactly what the team will be working on. There are always backlog fillers tasks, tiny tasks like a typo fixing or another small change somewhere that are literally filling up your backlog. These tasks are fillers. And this is what your teams work on when they need to fill in the blanks.
• In a normal situation though, these fillers - all these tiny tasks - shouldn't be prioritized and scheduled independently, it's impossible. So as far as roadmapping is concerned, all these small tasks have to be grouped together in batches, consistent batches - grouping them together by theme, or scope or value. Such evolution batches are prioritized and scheduled as one big block. And this kind of makes sense, you're almost forced to implement all these tasks in a continuous way all the time. But you might decide that in the next six months, we will implement this batch of consistent evolution together on the platform.
• Regarding what are these stories or epics on the roadmap, most of them comes from the PMC identified topics or Project Gaps. There's also some long and large functional evolution coming from business analyst or from the product owners just as technology evolutions and maintenance come from the CTO. The project gaps are coming from delivery of course. The takeaway here is that the cardinality has to be larger, big, important topics. And if you want to schedule smaller things, group them together in consistent evolution batches.
• If you have a team that's working on H1 topics, such as project gaps or evolution batches for six months, make it so that six months after they work on H2 or H3 topics. This is crucial to avoid frustration. You can tell a team that in the coming four months they will be working on tiny and not so passionate improvements here and there, but only as long as they know that the next big technology evolution is coming up and is for them. If you have a fair amount of tasks in the teams among H1, H2, H3, everybody keeps being motivated.
  And then, if you don't do that you're somehow back to having component teams, which doesn't make a whole lot of sense.
• Finally, you want to have independent and autonomous team for estimations and reliable forecasting. And you want to have many of them to keep the possibility to have a fair share of investment between H1, H2 and H3 at any given time in your product development timeline.

2.3 C. The Estimation process

I won't spend much time on the estimation process since I detailed a few years ago all of this in a dedicated article on this very blog.
So I will just be repeating some essential information regarding how epics or stories on the roadmap are estimated and how team velocity is estimated.

2.3.1 The roles and rituals involves in the estimation process

Let's start by defining all the roles involved in the estimation process. In this regards, the most important roles are the Product Manager, the CTO, the Tech Leads and Architects, the Team Leaders and of course the Product Owners.
Their core responsibilities are as follows, at least in my current company.

For the estimation process in our context, the important rituals are the Product Management Committee, and the Architecture committee. The first is central to identifying evolutions and prioritizing them while the second is central to designing and estimating them.

The Product Management Committee identifies the opportunities and evolutions and prioritize them.
The Architecture committee is responsible to proceed with everything that is required for accurate estimations: the detailed specification of these epics and stories, their breakdown in tasks and their estimations.
It's key to estimate the short to mid-term elements accurately, but then we don't care so much in estimating something on which we will work in two years. Why would you care how much time it takes to develop something we are not even sure we will be doing? We want at all cost to have accurate estimations of the things on which we know we will be working, to prioritize and plan them efficiently. But for long term ideas, a T-Shirt sizing approach is sufficient.

2.3.2 Rituals are scheduled

All precautions should be taken to avoid interupting the development sprint all the time. For this reason, rituals are clearly scheduled and take place at a predefined time and pace. There should be no unforeseen interruption of the sprint course.
In my company, we stick to the following month organization, with 2 sprints per month:

This reads as follows:

• A sprint ends with a Sprint Retrospective (Kaizen) and starts with a Sprint Planning where the sprint backlog is filled up to the team sprint velocity by the Product Owner and the Team Leader. Tasks are discussed with all the team at the same time and some estimations may be reviewed.
  In my current company, we do both on Friday since we want everything to be ready for Monday morning regardless of the timezone of the teams.
• Of course every single day there is a Daily Scrum in the morning where everyone presents where they are and where problems are discussed and escalated to the Team Leader and Tech Lead who might schedule dedicated meetings to discuss them further if required.
  Also, every day finishes with an automated deployment of the whole product in a production-like setup on the Integration Environment.
• At the end of the sprint, a production-ready, shippable version of the product is automatically deployed on the Test Environment. This internal release is considered as a customer release as far as the development teams are concerned.
• The PMC - Product Management Committee occurs once a month. It's sometimes a very short meeting, just reviewing the updated roadmap and fine tuning priorities and sometimes a very long meeting finishing late at night, when multiple opportunities have to be discussed and prioritized.
• The ARCHCOM - Architecture Committee - is a fairly central ritual in my current company. This is where we do all of:
  • Dispatch stories among Architects, Tech Leads, Product Owners and even the CTO for design, refined specifications and tasks breakdown.
  • Discuss open points, comment and amend designs and breakdowns.
  • Proceed with task estimations
  • Identify and Challenge technical evolutions and maintenance
  As far as the estimation process is concerned, this ritual is really central. It can last a few dozens of minutes in some cases, and long hours until late in the evening sometimes. We run it every week at the same time.

2.3.3 Now the Estimation Process

Shortly put, the estimation process consists in identifying topics and evolutions in the PMC, specifying them with details, having the ARCHCOM design them and then proceeding with the breakdown in tasks for estimations, having the tasks estimated and eventually computing the overall epic or story estimations. With everything in the short-to-mid term properly estimated, the Product Manager can proceed with updating and maintaining the roadmap.
The process looks as follows:

Which reads as follows:

• The PMC decides to prioritize a new feature, a new element or an evolution, as a new story and we shall proceed with its estimation so that it can be positioned accurately on the roadmap.
• So the product manager or a product owner will be specifying the story in a detailed way with the help of the CTO perhaps, focusing on identifying as precisely as possible its functional elements. The result in our context is called a detailed story
  This closes the specification phase.
• Now comes the design phase.
  Then the CTO, a PO, an architect or sometimes a teach lead will be transforming the detailed story - which is a marketing / product formalism - into a development epic - which is a technical formalism where we cover functional design, solution design, application design, perhaps data identification, data research needs and so on.
  It can happen that the CTO creates himself some development epics for mandatory technology evolutions, refactorings, etc.
• The ARCHCOM will challenge the design and other technical elements and discuss / refine open points before an ARCHCOM member will be assigned the task to proceed with the breakdown in tasks of the development epic.
  The breakdown in task is challenged and discussed at ARCHCOM before being validate.
  It can happen that tasks are created directly from architects or tech leads for refactorings for instance or transformed from delivery wishes. In such case, they are bound to an existing epic or a container epic is created for them (for instance for a specific Project Gaps).
• Then all individual tasks can be estimated.
• With the individual task estimations finalized, the CTO or a PO will compute the total amount of Story Points at Epic level.
• The CTO or a PO will then liaise with the PM to communicate the estimations on the story.
• Finally the PM will update the roadmap accordingly and send the updated roadmap to the PMC. The next PMC can challenge the view, re-prioritize or end up taking a different decision regarding the evolution or new feature now that it knows how much it costs.

2.3.4 Team Sprint velocity

The approach is fairly usual, one needs to monitor the number of story points a team has been able to implement in the past five sprints. Then the extreme values are eliminated because they make no sense (people tend to go on holidays, people are sick, some tasks have been postponed to another sprint, etc.).
We take the second and the last but one and with these we're able to compute an upper and a lower bound. This range addresses the uncertainty inherent to software development.

As far as estimations and planning are concerned, we will take the lower bound to compute the team sprint velocity since we have to be defensive.

2.3.5 Forecasting

Now that we know how many Story Points a team can do in a sprint, we know how many it can do in a month of 2 sprints (the additional days are ignored, they form a reserve).
Add if we know how many Story Points a team can do in a month, then we know how many months a team needs to implement any given story that has been properly estimated.
Boom. Done.

As far as delivery date estimations are concerned, we will take the pessimistic estimation coming from the lower bound of the Team Sprint capacity.

2.3.6 The Estimation process - Takeaways

Summing things up:

• First a note about something specific to our context in my project company. In our model, the project gaps are the only items on which we decide to have hard commitments.
  In our model, we know that we have to start any given customer delivery project at a precise moment in time and that it has to be in production at another precise moment in time. So we need to make sure we will deliver the missing functionalities sufficiently in advance for our integration team or delivery team to be able to integrate them at the customer sufficiently in advance.
  So we don't have much of a choice, we need to have at least some elements of our roadmap that are strong commitments. And in our model, these are the project gaps.
  To handle this, we make sure the project gaps are well balanced between the different teams. They become the only items from the roadmap that can't be moved, they are frozen items; we want to ensure that we will respect their delivery dates.
  The way we do that is that we consider them as frozen once they are scheduled. Once they are planned, they can't move anymore.
• The estimation game tells us the total story point for each and every story of epic that we want to follow on the roadmap. So assuming two things, the amounts with the team sprint velocity, we know how many sprints and how many months will be required to implement a story or an epic. So we can put it on the roadmap. The key word here is reserve!. Take reserves, more reserves and even more reserves.
  In our model, sufficient reserve is taken by the fact that we schedule these elements for the end of a period, the end of the month in the three to six months timeline, and then the end of a quarter in the next periods, or even the end of the year in the following period. And by doing so, most of the time, we find out who have sufficient reserve taken when laying these elements down the roadmap.

2.4 D. Roadmap timeline

The roadmap timeline is also an important aspect. The whole principle is to avoid having a timeline with too many different deadlines since they would be impossible to follow and only bring noise, but we have to have a sufficient number since they form our scheduling unit.
A good number of terms of scheduling deadlines is eight. Eight deadlines are easy to follow and with a reducing granularity approach, they provide enough scheduling and synchronization points to successfully draw a 24 to 36 months roadmap.

Which reads as follows:

• The Next 3 months are followed on three elements. This makes it more than 1/3 of the roadmap dedicated to this shortest term and is a reflection of the fact that we follow and monitor things carefully on this short term roadmap. In addition, we're having strong commitment there and any change on the activity plan of the next three months should really be considered and weighted very carefully since we commit on most of these elements.
• The next 2 elements are related to the following 2 quarters. This makes 1/4 of the roadmap timeline dedicated to a 6 months period and is an indication that we want a fine control over the next priorities past the shortest term 3 months period. This is where changes can happen frequently as we discover our market or sign new deals. Priorities can change thre but it has to be backed by strong business objectives.
• The following 2 elements are related to the following 2 semesters. This is the mid term roadmap basically related to what we will do in a year or so. This is really rather indicative and estimations there do not necessarily need to be precise, a T-shirt sizing approach can be sufficient.
  The elements on the mid-term roadmap yet need to be realistic and correspond to the vision we have today, even though that vision can entirely change.
• The last element being the following year is really related to the long-term roadmap, a basket of ideas.

2.4.1 Monthly roadmap update

The roadmap is updated every month and a trick needs to be found to ensure that whatever happens and wherever we are within the year, we keep tracking 8 baskets, not more and importantly not less.
This is done by tricking the vision and adapting some periods to fit the specific situation in which we are within the year.

By tricking the period this way every month, we make sure that we only follow eight different buckets in the in the roadmap since anything beyond eight wouldn't make a whole lot of sense, at least in our model.

Again, one aspect that is absolutely critical to be in a position where we can have reliable forecasts is to avoid at all cost stop-the-world events (refactorings, releases, etc.)
Stop-the-world releases or refactoring, or big technology evolutions that require synchronizing the teams, are killing the ability of a team to work independently and autonomously. So eventually, it's killing the ability of a team to respect the forecast on schedule and planning. These have to be avoided at all cost.
And interestingly, even though implementing a big refactoring or technology evolution without stopping the world is much more difficult, from a purely technical standpoint, most of the time, it's absolutely doable. It will be more expensive. It will indeed take longer. But it's absolutely doable.
And it's absolutely worth it. Because avoiding stop the world events enable the team to respect and fulfill expectations in terms of forecasts and planning.

2.4.2 Back on Continuous Delivery

Continous delivery is very hard to reach in the mind of software development teams working on SaaS platforms.
But think of the web giants. Think of what they are doing ...
Let's see some examples. Amazon is deploying code in production every 11 seconds, on average. Netflix is pushing code to production 1000 times a day. They have even developed Chaos Monkeys, which is a software literally killing VMs, services and containers all the time in production, as a way to force developers to design for failure. Facebook, before 2016, were cherry picking the features in a few release trains a day. They don't do that anymore, they push the master branch directly in a dozen of release trains a day.

Now that's what the Web Giants manage to do. If you embrace the same techniques - they are using state of the art XP, agile, Scrum, DevOps and lean startup principles and practices, then you can do this as well.

And even if you do on premise deployment, it still makes sense to do continuous delivery since it forces you to automate your release process.
As far as the development teams are concerned, every sprint ends up with a shippable and production-ready version of the product. And because Database migration scripts are maintained along the software, you end up in a situation where it's perfectly feasible from a technology standpoint to push this version at a customer. It's perfectly doable because you have designed the product and developed it this way.
If the developments teams stick to this, then releasing the product as an actual end-customer version becomes purely a Product management decision, not any more a technical concern. At the end of every feature development, Product Management has the possibility to decide to transform the internal release into a customer release and give it a proper version number.

3. Conclusions and final notes

In terms of conclusion I would say that embracing the core Agile practices from XP, Scrum, DevOps and Lean Startup enables a company to have reliable forecasting and planning abilities which eventually lead to design a relevant and useful roadmap.
This principles and practices enables the company to have autonomous and independent teams, which are then able to work on a development topic or technology evolution without interruptions and without and friction with other teams, which is key to have their real-life development pace aligned with estimations and forecasts.
In addition, multiple autonomous teams have the possibility to work in parallel on multiple development topics which enables the company to have a fair share of development in the multiple Horizons.

Some tools are required to give life to all of this and I will leave the reader to discover them hereunder:

My final words would be that such an Agile roadmap has the potential to be much more that a communication tool, it's really an internal alignment tool and provides the high-level management view to align everyone in the company towards the common product development objectives.

This article is available as a Slideshare presentation