Plans
Roles
Support
Customers
The complete Software Engineering Intelligence platform
Get the full suite of Plandek intelligence tools for actionable delivery insights at every level
Book Demo
PRODUCT OVERVIEW
USEFUL PAGES
Data-driven insights for engineering leaders
2025 Software Delivery Benchmark Report
Download Now
PRICING
ABOUT
ACADEMY
Solutions
Platform
Pricing
About
Academy
Your voice matters: Join the GenAI adoption conversation - contribute to our industry research.
Written by
Head of Professional Services, Plandek
We work with Agile teams of all different shapes and sizes, and predictability is a front-of-mind theme for almost all – as the words “Agile” and “predictable” don’t always go hand in hand …
So, how can development teams maintain their Agility and improve their delivery predictability? So, when stakeholders ask the predictable question, “Are we on schedule?” they can give a sensible answer.
Product-based Agile software development teams delivering small increments very regularly may spend little time worrying about forecasting.
But often, Agile teams are established to deliver major milestones that the business expects at a certain point and for an agreed budget, so they will need to forecast effectively or risk being accused of being “Agile and late!
In our experience, Agile teams’ forecasting tends to be pretty inaccurate. It is often based only on a simple observation of backlog, velocity and word-of-mouth reassurance from the teams themselves.
In our opinion, a really meaningful forecast requires a broader set of empirical data reflecting all the potential sources of project delay.
* There is a separate debate as to whether an Agile software development methodology is appropriate in a “project“ context like this, but that is for another day.
Logic dictates that there are six possible reasons why a project is late – the so-called “Logical Six”. Three of the Logical Six are in direct control of the technology team:
And the other three are in control of the business sponsors interacting with the technology team. These are:
In our view, you will never really be able to accurately forecast and improve your delivery predictability unless you collect metrics which track all of these six levers.
Only then will you really understand whether a project is likely to be “late” and what needs to be done to get it back on track?
The “Logical Six” – the six ultimate sources of project delay
So, what are the metrics that relate to the six sources of project delay – and are critical to delivery predictability and improved forecasting accuracy?
The table below shows our favourite metrics in each of the areas. We encourage Delivery Managers to focus on these when working with the Delivery Team Leads to create more realistic forecasts of delivery timing.
In summary, the metrics are:
The key delivery metrics require surfacing data from a myriad of sources, including workflow management tools, code repos, and CI/CD tools – as well as collecting quant feedback from the engineering team themselves (via collaboration hubs).
The complexity of the data and multiple sources make this sort of data collection very time-consuming to do manually and really requires an end-to-end delivery metrics platform to do at scale.
Delivery metrics platforms are available, which consist of a data layer to collate and compile metrics from multiple data sources and a flexible UI layer to enable the creation of custom dashboards to surface the metrics in the desired format.
If we use metrics to track and analyse the Logical Six drivers of project progress, we will get a much clearer picture of real project progress. By this, we mean:
The improved forecast and related mitigations can be presented together in a Root Cause Red, Amber and Green (RAG) Progress Report.
Root Cause RAG reports are far more effective than traditional RAG progress reporting, which often sheds very little light on actually why a project (with a required go-live date) is behind schedule and what needs to be done to bring it back on track.
In contrast to a traditional RAG approach, the Root Cause RAG Report (see the example below) clearly shows:
Done well, Root Cause RAG Reports can be a really effective means of presenting our (more accurate) forecasts in a way that stakeholders can understand and, therefore, can be an important step in reducing lateness and bringing the technology team and the internal client much closer together.
As discussed, however, it relies on an understanding of the metrics that actually determine project lateness and a means of collecting those metrics.
Example Root Cause RAG Report
This article was originally published on InfoQ.
Free managed POC available.