Standards

This standard reinforces the principle that when delivery fails, the response must prioritise insight over blame. By replacing judgement with curiosity, we encourage teams to explore system-level root causes, not personal faults. This enables continuous improvement, protects psychological safety, and promotes open dialogue across functions and roles.

It supports the policies to “Prioritise Learning Over Performance in Retrospectives” and “Create Resilience Through Empowered Teams” by creating a cultural norm where failure is used as fuel for growth. Without this, teams may conceal issues, miss learning opportunities, and erode trust.

This standard ensures that teams are encouraged and supported to experiment safely within defined boundaries. Experimentation is essential to innovation, adaptability, and learning—but only when it’s safe-to-fail. Teams must be able to test ideas without fear of punitive consequences or significant harm to customers or systems.

It supports the policies “Create Resilience Through Empowered Teams” and “Treat Change as a Constant” by embedding small, reversible, and observable experiments as a core delivery habit. Without this standard, risk aversion can block innovation, slow progress, and reduce team confidence in making informed change.

This standard ensures that change is embraced as a normal and continuous part of digital delivery, not a disruption to be resisted. By treating change as an expected condition, teams can design systems, workflows, and mindsets that are adaptive, resilient, and focused on continuous evolution rather than rigid control.

It supports our policy to “Treat Change as a Constant” by embedding change-readiness into delivery culture and system architecture. Without this mindset, change becomes feared, delayed, or poorly managed—resulting in brittle systems, reactive teams, and missed opportunities for improvement.

This standard ensures that teams are not only accountable for delivering value, but are also empowered to manage the associated risks and build resilience into their delivery practices. Teams must be able to make local decisions, adapt to emerging challenges, and recover from setbacks without waiting on centralised intervention.

It supports the policies “Create Resilience Through Empowered Teams” and “Build Confidence Through Frequent Releases” by distributing responsibility for safety and responsiveness where it belongs—within the teams closest to the work. Without this empowerment, risk is escalated unnecessarily, agility is reduced, and delivery becomes fragile.

This standard ensures that software releases are designed to minimise risk, increase team confidence, and enable faster feedback. By keeping changes small and delivering frequently, teams can reduce the impact of failure, improve predictability, and build trust with stakeholders.

It supports the policies “Build Confidence Through Frequent Releases” and “Design for Controlled Change, Not Just Fast Change” by embedding release practices that are safe, observable, and reversible. Without this approach, releases become high-stakes events that delay value, amplify defects, and erode confidence.

This standard ensures that agility extends beyond individual teams through synchronised cadences, planning cycles, and coordination practices that align delivery efforts across the broader system. Shared rhythms such as cross-team planning events, integrated system demos, and joint retrospectives enable early identification and management of interdependencies, maintain alignment of delivery priorities, and support the seamless flow of value across teams.

It supports policies to “Elevate Agility Beyond the Team Level” and “Design Delivery Systems for Flow” by breaking down silos, creating systemic visibility, and enabling fast, coordinated delivery at scale. Absent this standard, teams risk fragmentation, duplication, delayed feedback, and increased delivery friction.

This standard ensures teams prioritise delivering working software frequently, even if it means releasing smaller, incremental value rather than waiting for fully complete feature sets. By embracing early delivery, teams gain faster feedback, reduce risk, and sustain momentum.

It supports the policy “Deliver Working Software Frequently” by favouring continuous progress and validated learning over striving for perfection. Without this mindset, teams risk delayed releases, misaligned solutions, wasted effort, and missed feedback opportunities that impede iterative improvement.

This standard ensures that teams use flow-based metrics to continuously evaluate and improve their delivery performance. Metrics such as cycle time, lead time, throughput, and work in progress (WIP) enable teams to identify bottlenecks, reduce waste, and make informed decisions based on real delivery data.

It supports our policies to “Make Continuous Improvement a Delivery Habit” and “Design Delivery Systems for Flow” by grounding improvement efforts in tangible evidence. Without this, improvement becomes subjective, disconnected from real delivery outcomes, and unlikely to produce sustainable results.

This standard ensures retrospectives are consistently leveraged to drive meaningful improvements both at the team and systemic levels. Retrospectives provide structured opportunities to reflect on delivery, identify sources of friction or waste, and experiment with targeted improvements. When performed effectively, they foster a culture of ownership, trust, psychological safety, and relentless learning.

It supports our policies to “Reflect, Learn, and Improve Relentlessly” and “Make Continuous Improvement a Delivery Habit” by embedding deliberate improvement as a natural part of delivery flow. Without this, teams risk repeating mistakes, missing systemic patterns, and disengaging from continuous improvement.

This standard ensures delivery systems are intentionally designed to enable rapid, actionable feedback and minimise unnecessary delays throughout the entire delivery lifecycle—from ideation through deployment and beyond. High-performing teams embed feedback mechanisms as foundational elements, enabling continuous observation, learning, and adaptation without waiting for late-stage results.

It supports the policies “Design Delivery Systems for Flow” and “Elevate Agility Beyond the Team Level” by empowering teams and organisations to make timely decisions, reduce costly rework, and accelerate the path from concept to customer value. Without this focus, feedback becomes slow, fragmented, or irrelevant—resulting in inefficiency, quality degradation, and eroded stakeholder trust.

This standard promotes the use of hypothesis-driven development (HDD) to reduce risk and increase learning when building digital products. By explicitly stating assumptions and testing them through measurable experiments, teams ensure that what they deliver actually drives the intended outcomes.

It supports the policy “Shape Roadmaps to Learn, Not Just to Deliver” by encouraging delivery that validates value incrementally rather than assuming success up front. HDD allows teams to pivot early, double down on what works, and stop investing in features that don’t deliver value.

This standard ensures that teams prioritise their work based on outcomes that matter to the business and its customers. Rather than focusing on volume of output or subjective preferences, teams must use evidence and metrics to sequence work that delivers the greatest impact.

It supports the policies “Prioritise the Highest Value Work” and “Align Work to Clear Value Streams” by shifting backlog conversations from tasks and features to business goals, customer outcomes, and clear economic trade-offs.

This standard ensures that teams anchor all delivery decisions in clearly defined customer and user value. By working backwards from desired outcomes—rather than forward from tasks or features—teams can focus effort where it matters most. This mindset shifts delivery from output to outcome, ensuring resources are invested in initiatives that make a tangible difference.

It supports our policy to “Prioritise the Highest Value Work” by reinforcing the importance of value clarity and alignment. Without this approach, teams risk over-delivering on low-impact features while underinvesting in what truly benefits customers and the business.

This standard ensures that delivery decisions are made with a holistic understanding of the interconnected systems in which they operate. System thinking enables teams to recognise dependencies, feedback loops, and unintended consequences—reducing waste and aligning efforts across organisational boundaries.

It supports our policy to “Understand the Whole System, Not Just the Parts” by embedding a mindset of optimisation for the whole, not sub-optimisation of parts. Without this, teams may inadvertently duplicate effort, introduce friction, or solve the wrong problems.

This standard ensures that planning efforts remain flexible, iterative, and responsive to change. Instead of relying on exhaustive upfront planning that often becomes obsolete, teams adopt progressive elaboration—refining plans as more is learned throughout the delivery lifecycle.

It supports the policy “Avoid Over-Planning the Future” by enabling learning-led adaptation. In dynamic environments, excessive upfront certainty can create rigidity, lead to waste, and disconnect delivery from real-time discovery. Progressive elaboration enables better decision-making and faster delivery of value.

Delivering work in thin, testable slices enables rapid feedback, reduces delivery risk, and supports a continuous flow of value. By breaking down features into minimal, valuable increments, teams can learn quickly, validate assumptions early, and reduce rework.

This standard supports the policies “Embrace Iteration over Perfection” and “Reduce Time from Idea to Impact” by promoting short learning loops, improving predictability, and ensuring that delivery aligns with evolving user needs.

This standard ensures that teams test assumptions early by running small, focused experiments before making significant product, architectural, or operational commitments. In complex environments, evidence-based learning is essential for reducing uncertainty, validating value, and avoiding waste.

It supports the policy “Embrace Iteration over Perfection” by embedding fast feedback loops and lightweight exploration into delivery workflows. Without this standard, teams risk investing heavily in unproven ideas, leading to rework, missed opportunities, or customer dissatisfaction.

This standard ensures that feedback is continuously gathered and acted upon across the entire delivery lifecycle—from discovery and design to deployment and operations. Timely, actionable feedback enables teams to adapt quickly, reduce waste, and build products that meet real user needs.

It supports the policies “Create Feedback Loops Everywhere” and “Embrace Iteration over Perfection” by embedding reflection, validation, and improvement into day-to-day work. Without these loops, assumptions go untested, issues emerge late, and course corrections become costly and difficult.

Limiting Work in Progress (WIP) is essential for maintaining flow, reducing context switching, and ensuring high-quality delivery. This standard ensures that teams focus on completing work before starting new items, creating predictable throughput and improving delivery cadence.

It supports the policies “Make Work Visible and Limit WIP” and “Embrace Iteration over Perfection” by encouraging flow-based thinking and disciplined prioritisation. Excessive WIP creates hidden queues, stalls feedback, and leads to burnout and delivery delays.

This standard ensures that teams continually reduce the time it takes to move an idea from concept through to customer impact. In fast-moving environments, long lead times create risk, reduce feedback quality, and limit a team's ability to respond to change.

It supports the policy “Reduce Time from Idea to Impact” by placing a disciplined focus on optimising flow, minimising delays, and eliminating unnecessary handoffs and process bloat. Without attention to lead time, delivery becomes sluggish, costly, and disconnected from real user needs.