In my opening article I introduced the <ALT+F> framework as a tool to help IT leaders to streamline IT Operations. I discussed how the framework moves withing the MAPE (Measure, Adapt, Plan and Execute) lifecycle.
In this article I'll describe ALTPD (Average Lead Time of a Production Delivery). This is one of the most important measurements in the Measure phase of the MAPE lifecycle.
In a nutshell, ALTPD defines the average number of days that it takes a requirement to be delivered to production from the day it was requested by the business. Why is important?
In order to answer this question we need to understand the importance of delivering fast.
When the business asks for a requirement it means that probably what they are asking is meant to generate some kind of business value. In the majority of cases, we know that the value of a business requirement is higher the quickets it reaches the market (Time To Market). Therefore I assume that in an ideal world the number of days for a business requirement to reach production should be zero to maximise revenue.
This assumption is backed by the modern approach to software development: Agile and Lean methodologies are so successful nowadays because, amongst others, they bring the benefit of shortening the rollout of IT systems to production. Continuous Delivery is adopted by more and more companies for the same reasons. You will probably be familiar with the frustration of business stakeholders when requirements are not delivered to production fast enough. This was also one of the main reasons why we moved from pre-emptive methodologies such as Waterfall to less pre-emptive ones, such as Agile and Lean.
If the ideal number of days to deliver a business requirement to production is zero, any additional number of days can be considered as waste. From Lean, we know that we should aim at eliminating waste, therefore our role as IT leaders is to foster an environment where business requirements can be delivered to production as fast as possible. In doing so, we should focus our attention on quality as well, another cornerstone of Agile and Lean methodologies. However, whereas speed of delivery can be linked to revenues, quality can be linked to cost savings. Both, when applied to the delivery of an IT system, maximise profit.
The <ALT+F> framework provides a series of templates to measure IT Operations performance and amongst them we find a template to measure ALTPD.
To measure ALTPD we record some simple information:
- The feature description
- The Class Of Service (COS) for this feature
- An id linking the feature to some sort of requirements planning tool, e.g. JIRA. (This entry is optional)
- The date the feature was asked by the business
- The date the feature was delivered to production
- The number of lead days between the two dates above
There are few things to notice about ALTPD:
- The COS can be defined at different levels of detail. ALTPD can be measured from outside or inside the team. In the former case, the COS will be coarse grained and they will typically be one of the main drivers for a transformation strategy which aims at optimising Time To Market. In the latter case, they will be used from within the team, typically by Scrum Masters or, as I call them, project leaders, to help them provide better estimates for similar tasks in future
- The task id is optional, and can be linked to an electronic tracking system, e.g. JIRA
- The starting date is the date the business required a feature, not the date the requirement entered the backlog. There is a difference between the two: once the business asks for a requirement, the clock in their mind starts ticking. As we've seen, any day that passes without their requirement being delivered causes waste for the business and therefore our goal should be to shorten as much as possible this delay. This is why I talk of Lead Time as opposed to Project Length. A business requirement might have been requested a year ago, but it might take just a month to deliver
In my book, I explain how ALTPD is the driver for a number of IT performance optimisations. Apart from the arguments that we've already discussed, i.e. Time To Market, part of ALTPD (i.e. from the moment the requirement actually becomes a fully flagged project) is directly linked to development costs. This is obvious: the more it takes to deliver a project to production, the higher the development costs.
So, if ALTPD is so important, how do we go about optimising it?
From outside the team, one possible way is to apply Lean principles to business requirements by introducing queues. One of the fundamental performance optimisation principles in Lean is to reduce the Work In Progress (WIP). This can be achieved by introducing queus and by setting limits on them. In our case, IT leaders can create a business requirements queue and set a limit on it. This is not as simple as it seems: such approach needs to be agreed and sponsored by the business. From a practical point of view, the agreement should be that the business can request only enough requirements to fill the queue up, but no more. The project leaders, depending on the methodology followed, would then pick one (Lean) or more (in case of Scrum) items from the backlog and move them to the WIP queue. As soon as items are moved from the backlog to the (Scrum/Kanban) board, the business could request for more requirements by again filling the backlog queue.
This approach offers tremendous benefits: by reducing WIP the time that usually goes in project ceremonies can instead be dedicated to the projects currently in progress. This reduces the margin for errors, delays commitment (if a requirement didn't enter the backlog and therefore nobody started working on it and in the meantime the market conditions changed, there is no waste of resources) and provides the business with a fast response.
Additionally, by adopting Agile and Lean methodologies it's possible to shorten the feedback cycle and derisk the project with the added benefit that IT gives the business a tool to change priorities at a short notice (in Lean shorter than in Agile).
I witnessed situations where items have been on an unbounded backlog for years, not becuase it took long time to implement them, but because they never made the project pipeline. However the business matured a poor consideration for IT, as in their mind the requirements hadn't been delivered.
From within the team, optimising ALTPD is something else alltogether. Here, the responsibility of the Scrum Master and the team members is to focus primarily on quality, although even here reducing WIP brings its benefits. There are various tools to achieve this goal: Test Driven Development (TDD), pair programming, automated test suites for unit, integration, performance and system tests, SCM and Continuous Integration environments, Continuous Delivery, DevOps and automated builds and deployments.
Optimising ALTPD has got the following benefits:
- Maximise Time To Market thus revenue
- Minimise short, medium and long term maintenance costs by ensuring that what's delivered to production won't come back as rework in the form of production bugs
- Reduce development costs
- Derisk the project
- Increase social capital, as both the team and the business feel happier and more motivated by the results