Currently set to No Index
Currently set to No Follow

Faster to market

Advanced

difficulty

Stage 1-5

Agile IQ® Level

Metrics

Practices

Agile

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.

managers and chapter leads

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:

  • the point the teams say it is ready to release and
  • the point where it is actually released/handed over to customers.

This helps represent the impact of:

  • poor development practices and underlying design and code base for software teams
  • poor authoring and content practices for marketing teams
  • poor accounting practices for finance teams
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

hand-hold-3d-box

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.

agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close