Faster to market
Advanced
difficulty
Stage 4
Agile IQ® Level
Metrics
Practices
EBM
Framework
Introduction
Time to market measures teams’ ability to quickly deliver new capabilities, services, or products. It’s one of the four key value areas of business agility and business value.
Modelled time to market
After longitudinal statistical analysis of over 100 organisations over a 5+ yr period, an increase in a team’s Agile IQ® is a leading indicator of an increase in Time to Market.
|
Agile IQ® Maturity Stage |
Average Time to Market |
|---|---|
|
Stage One |
6-12 months or longer, when 50% of teams are at Stage One, due to most following a Waterfall or ad-hoc delivery method. |
|
Stage Two |
4-6 months, where 90% of teams are typically following a Water-Scrum-Fall or hybrid delivery model. |
|
Stage Three |
6-12 weeks, when 80% of teams are at Stage Three. |
|
Stage Four |
4-6 weeks, when 80% of teams in a scaled agile program reach Stage Four maturity. |
|
Stage Five |
2-4 weeks, when 80% of teams reach and sustain Stage Five maturity. |
What is your ability to deliver faster?
The reason why executives look at delivery speed is to minimise the amount of time it takes for the organisation to deliver value. Without actively managing time to market, the ability to sustainably deliver value in the future is unknown.
Questions that leaders need to continually re-evaluate for time to market are:
- How fast can the organisation learn from new experiments and information?
- How fast can you adapt based on the information?
- How fast can you test new ideas with customers?
When many teams coordinate their work in an Agile Release Train, it is the Product Manager who is accountable for making the decision whether to release or not, particularly with respect to larger Features.
Investment in capability is vital to improving delivery speed
Improving Time to Market requires investment of time and money. A leader’s role in an agile environment is to ultimately shift from managing individuals and tasks, to building and sustaining an agile capability that improves time to market.
Invest in Skills
Agile leaders don't manage tasks, they build capability. Building capability requires an investment of time and money and requires monitoring the impacts of investment against the improvements in skills development, training and mentoring.
Invest in Automation
All teams need technical support to transfer manual tasks to technology that can do them faster, including marketing and finance teams.
Invest in Metrics
Investments require metrics, beyond just "on time and on budget", to understand how much delivery capability is improving. Report on the impacts the investment is making, not the tasks or % complete of delivery-based milestones.
When designing teams, ensure that a manager’s role is clear – building capabilities over managing and delegating tasks with investment deliberately made by executive and product management.
Value Metrics to Understand Capability Investment
To encourage adaptability, Evidence Based Management (EBM) by Scrum.org defines a list that highlights exemplar measures that might help an organisation to:
- Understand its current time to market.
- Identify the factors that influence delivery speed.
- Describe metrics that will provide leading and lagging indicators that the investment in capability improvement is yielding the desired improvements in delivery speed.
| Key Value Area | Measures |
|---|---|
|
Build and Integration
Frequency |
The number of integrated and tested builds per time period. For a
team that is releasing frequently or continuously, this measure is
superseded by actual release measures. |
|
Absenteeism rate |
Number of paid and unpaid personal leave hours / total hours. The greater the Absenteeism Rate, the longer it takes to deliver valued outcomes. |
|
Unmanaged turnover |
Total number of resignations / average head count x100 |
|
Managed turnover |
Total number of terminations / average head count x100 |
|
Lost time injury frequency ratio |
Number of lost time injuries / total number of hours worked x 1M |
|
Release Frequency |
The number of releases per time period, e.g. continuously, daily,
weekly, monthly, quarterly, per Sprint, etc. For non-software teams, consider the number of times work is handed over to the customer in the given period. This helps reflect the time needed to satisfy the customer with new and competitive products or services. |
|
Release Stabilisation Period |
The time spent correcting product problems between:
This helps represent the impact of:
|
|
Mean Time to Repair |
The average amount of time it takes from when an error is detected, including unintential rework, and when it is fixed. This helps reveal the efficiency of an organisation to fix an error. |
|
Customer Cycle Time |
The amount of time from when work starts on a release until the
point where it is actually released. This measure helps reflect an
organisation’s ability to reach its customer |
|
Lead Time |
The amount of time from when an idea is proposed, or a
hypothesis is formed until a customer can benefit from that idea.
This measure may vary based on customer and product. It is a
contributing factor for customer satisfaction. |
|
Star performing team retention rate |
Total number of star performing teams retained / average head count of star team performers x 100 |
|
Lead Time for Changes |
The amount of time to go from code-committed to code
successfully running in production. |
|
Deployment Frequency |
The amount of time between the start of a service outage and the
restoration of full availability of the service. |
|
Time-to-Learn |
The total time needed to sketch an idea or improvement, build it,
deliver it to users, and learn from their usage. |
|
Time to remove
Impediment |
The average amount of time from when an impediment is raised
until when it is resolved. It is a contributing factor to lead time and
employee satisfaction. |
|
Time to Pivot |
A measure of true business agility that presents the elapsed time
between when an organisation receives feedback or new
information and when it responds to that feedback; for example,
the time between when it finds out that a competitor has delivered
a new market-winning feature to when the organissation responds
with matching or exceeding new capabilities that measurably
improve customer experience. |
Key Actions
Reduce Batch Size
The smaller the size of features the faster they can be handled by an experienced team.
Reduce WIP
The fewer the items currently being worked on, the less spread thin the team. This results in faster throughput.
Automation
Free people up from repetitive tasks by using automated workflows, including testing and deployment.
Slice work smaller
Slice backlog items so they are only about a days total effort by the team to deliver to Done.
Self-Management
When teams are given guardrails to self-organise, time to decision-making is reduced and works flow faster.
Remove QA Gates
Quality gates only identify defects, not build-in quality. Establish and improve the Definition of Done instead.
Measure the cost of delay
Do you know the cost of delay? Prioritisation by cost of delay gets the highest value out first.
Avoid technical debt
If you cut corners on quality now, you’ll still have to deal with it later. Technical debt is a silent killer of quality.
Identify and remove waste
Muda, Mura and Muri are key areas of waste to identify and systematically remove to improve the flow of delivery.
All fields are required.
