Defining the Two Operating Models

Before we explore why organisations struggle, we must clearly define the two operating models at the heart of this discussion, and more importantly, understand the theory of the business that underlies each one.

Every organization operates on a theory of the business ¹: a set of assumptions about the environment, the organization’s mission, and what it must do to succeed. Understanding the theory of our business begins with two foundational questions: Who is the customer, and what does the customer value? But it doesn’t end there. We must also understand the constraints we operate within, technological, regulatory, resource, competitive, and environmental factors that shape what’s possible. Without explicit answers to these questions, “value delivery” becomes an empty phrase.

Each operating model embodies a fundamentally different theory of the business and makes fundamentally different assumptions about the customer, what they value, and the constraints within which value must be delivered.

The Predictive Operating Model

Core assumption: The environment is predictable enough that organisations succeed through efficiency, standardisation, and control.

Underlying beliefs:

• Demand changes slowly.
• Work can be understood and specified upfront.
• Variability signals defects and should be minimised.
• Planning provides more certainty than adaptation.
• Performance improves through specialisation and hierarchical coordination.
• Management’s role is to optimise throughput and control deviation.

Customer and value assumptions: Customers primarily want consistency, reliability, and quantity. Value comes from standardised output delivered at lower cost and with minimal variation. This model fits environments with long product cycles, slow-changing needs, and stable demand.

How the model operates: The Predictive Operating Model is built on Taylorism and Scientific Management ². It separates planning from execution, functions from one another, and thinking from doing. Decision-making flows vertically. Work is governed through predictive plans, fixed scope and resources, detailed procedures, stage gates, and individual accountability. Output is the dominant measure of performance.

Where it works: This theory of the business is not wrong. It performs exceptionally well when its assumptions hold, predictable environments, repetitive work, limited uncertainty, and markets where efficiency and consistency create advantage.

The Adaptive Operating Model

Core assumption: The environment is dynamic enough that organisations can only succeed through continuous learning, rapid adaptation, and proximity to customers.

Underlying beliefs:

• Demand shifts frequently and unpredictably.
• Work cannot be fully known upfront; it emerges through discovery.
• Variability provides information rather than noise.
• Fast feedback is more reliable than detailed prediction.
• Performance comes from empowered, cross-functional teams.
• Clear, adaptive goals at every level provide direction without constraining discovery.
• Success requires continuous alignment to customers, stakeholders, and the environment.
• Management’s role is to design systems that enable learning, innovation, and quick adjustment.

Customer and value assumptions: Customer needs are diverse, evolving, and context-dependent. Value is created by solving specific customer problems, not by producing generic output. Organisations win by learning faster than competitors, adapting continuously, and delivering outcomes that matter in the customer’s current context. Where the Predictive Operating Model optimises for volume and repeatability, the Adaptive Operating Model optimises for relevance, impact, and adaptability.

How organisations discover value: Customer value is discovered through direct observation, rapid experimentation, real usage data, and continuous engagement with real users. In dynamic markets, discovery is an ongoing activity rather than an occasional research exercise.

How the model operates: The Agile Product Operating Model aligns with empiricism and continuous value delivery. It organises persistent cross-functional teams around products or value streams, decentralises decision-making to those closest to the work, and measures success through outcomes and customer impact. The model depends on transparency, inspection, and adaptation, supported by short feedback loops, modern engineering practices, and a commitment to technical excellence.

Where it works: This theory of the business succeeds when uncertainty is high, customer needs evolve rapidly, and competitive advantage comes from learning speed, responsiveness, and continuous alignment between what the organization delivers and what the market needs.

Why This Distinction Matters

These are not simply different management styles, nor is this a story of “modern vs traditional” or “agile vs waterfall.” The contrast is contextual, not moral. The Predictive Operating Model fails only when its assumptions stop matching reality, when the environment becomes too uncertain, too complex, and too fast-moving for prediction and control to work effectively.

Understanding the theory behind each model clarifies why transition is so difficult: you’re not just changing processes, you’re challenging fundamental assumptions about how success happens.

The Predictive Operating Model Was Fit for Stable Markets

The Predictive Operating Model was not a mistake. It was brilliantly designed for its context, an environment where its theory of the business held true.

During the Industrial Age, markets were stable and predictable. Demand grew steadily over long periods. Competition was limited. Products had decades-long lifecycles. In textiles, steel production, and large-scale manufacturing, success came from optimizing efficiency and driving down costs through standardization and economies of scale. The assumptions underlying the Predictive Operating Model, predictability, stability, knowable work, matched reality.

Frederick Winslow Taylor developed scientific management for exactly this environment, and Henry Gantt popularised it. When work is repetitive and predictable, breaking it into specialized tasks and optimizing each step makes sense. When markets change slowly, detailed upfront planning works. When products remain unchanged for years, separation of planning from execution causes minimal waste. Variability could be treated as a problem to eliminate because the “right way” was relatively stable.

The Predictive Operating Model delivered extraordinary results in stable markets. It built railways, scaled factories, and powered economic growth throughout the 20th century. The model succeeded because its theory of the business matched the actual environment: success truly did come through efficiency, standardization, and control in predictable work within predictable markets.

Why the Predictive Operating Model Fails in Dynamic Markets

Markets began shifting toward greater complexity and volatility in the early 20th century, and this exposed the limits of the Predictive Operating Model. By the mid-20th century, Toyota demonstrated a different way of working that reintroduced people into the centre of the production system, giving teams direct responsibility for quality, problem-solving, and continuous improvement. The pace of change accelerated again in the 1970s with the microprocessor revolution, and by the 1990s the internet had fundamentally changed how quickly ideas spread and how rapidly markets evolve. Today, AI amplifies this acceleration further, providing tools that enable teams to process information, align with stakeholders, and deliver value at unprecedented speed and scale.

Today, most markets are dynamic, customer needs change rapidly, technology enables new competitors to emerge quickly, and product lifecycles measure in months, not decades. Uncertainty is the norm, not the exception.

But it’s not just market volatility that challenges the Predictive Operating Model. The broader environment in which organizations operate has become fundamentally unstable. Regulatory changes like tariffs reshape entire supply chains overnight. Social movements like the remote work revolution force companies to reconsider workplace models, productivity assumptions, and organizational structures. Political shifts, elections, policy reversals, create cascading effects across industries. Economic shocks, pandemics, financial crises, disrupt assumptions that seemed solid months earlier. These environmental forces don’t just affect markets; they affect an organization’s ability to respond to markets. The confluence of market dynamics and environmental volatility creates both the challenge and the opportunity: organizations that can sense and respond rapidly gain advantage, while those locked into rigid structures fall behind.

The environment has shifted, but the Predictive Operating Model’s theory of the business has not. Organizations continue operating on assumptions of predictability in environments characterized by uncertainty, where both what customers need and how organizations can respond change continuously. This mismatch between theory and reality generates massive waste.

• Planning waste emerges when organisations invest months creating detailed plans that become obsolete within weeks. Requirements gathered at the start of a project no longer reflect market reality by the time delivery begins. Change control boards slow response to learning, turning agility into a bureaucratic exercise.
• Decision-making waste occurs when hierarchical approval chains delay action. By the time a decision escalates through management layers, the information is stale and the opportunity has passed. Teams closest to customers lack authority to respond to what they learn.
• Innovation waste happens when rigid processes and risk-averse cultures kill experimentation. Ideas must fit into predetermined roadmaps. Small experiments that could provide fast feedback are blocked by governance processes designed for large capital investments. Teams cannot explore what customers actually need.
• Human potential waste is perhaps the most painful. Talented people are treated as interchangeable resources, assigned to projects based on availability rather than capability or interest. Individual utilization metrics drive behaviors that undermine team collaboration. Separation of planning from execution means those doing the work cannot apply their insight to improve it.
• Market disconnect waste grows as organisations become insulated from customer reality. Layers of management separate decision-makers from actual users. Success is measured by delivery of planned outputs, regardless of whether those outputs create value. Teams ship what was specified months ago, not what customers need today.

The Predictive Operating Model operates at fundamentally the wrong speed for dynamic markets. While the market iterates daily, the organisation plans annually or bi-annually. While customer needs evolve continuously, the organisation delivers in large batches after months of work. This speed mismatch is not a minor friction, it is a structural incompatibility rooted in an obsolete theory of the business that no longer reflects how markets actually behave.

The Adaptive Operating Model Enables Success in Dynamic Markets

The Adaptive Operating Model structures organisations for speed, learning, and adaptation. Its theory of the business, that success comes through continuous learning and rapid adaptation in complex, changing environments, matches the reality most organizations face today.

At its foundation lies empiricism: the practice of making decisions based on observation and experiment rather than prediction and assumption. Scrum , as a social technology, makes work transparent, creates regular inspection points, and enables rapid adaptation based on what is learned ³. Kanban , as an observability pattern, makes workflow visible and measures actual delivery performance, enabling teams to see and improve their systems.

Decentralization is essential, not optional. Mary Parker Follett recognized nearly a century ago that effective organisations distribute authority to where knowledge resides ⁴. In dynamic markets, that knowledge lives with teams close to customers and technology, not with executives insulated from both. Decentralization enables fast decisions based on current information. It eliminates escalation delays and management bottlenecks that plague hierarchical structures. However, decentralization only works when goals are clear and adaptive at every organizational level, from company strategy through product goals to sprint objectives. This clarity of purpose proves challenging for most companies, particularly because unlike the fixed targets of industrial planning, these goals must evolve as learning occurs while maintaining coherent direction.

Cross-functional, persistent teams form the organisational structure. Each team possesses all skills needed to deliver value without dependencies on other teams or handoffs to specialized functions. Teams stay together over time, building deep capability and psychological safety. They own outcomes, customer value and business impact, not just outputs like features or story points. Today’s teams increasingly include AI team members augmenting human capabilities. Modern AI tools now make it possible to coordinate these teams effectively at scale, maintaining clear alignment with customers and stakeholders while preserving team autonomy and speed.

Fast feedback loops replace predictive planning. Teams deliver working software frequently, ideally continuously, and observe real customer behaviors. Product Managers make decisions based on actual usage data and customer feedback rather than assumptions documented months earlier. Sprint Goals provide coherence and focus while allowing teams to adapt their approach as they learn ⁵. Service Level Expectations establish predictable flow without requiring detailed estimates.

Technical excellence is mandatory, not aspirational. Teams must practice Continuous Integration and Continuous Delivery as Kent Beck and Jez Humble have taught us ⁶. Automated testing provides the safety to move quickly. Infrastructure as Code enables rapid provisioning and recovery. Monitoring and observability reveal how systems behave in production. AI-assisted development accelerates capability building while maintaining quality and enabling teams to focus on higher-value problem-solving. These practices are not tools or processes, they embody a DevOps ethos that breaks down barriers between building and operating software.

The Adaptive Operating Model matches the speed and uncertainty of dynamic markets. It structures organisations to learn and adapt continuously rather than predict and control.

Operating-Model Hygiene: Why Organizations Regress

Many organisations transition away from hierarchical structures only to drift back over time. Start-ups begin as nimble network organisations with direct communication and fast decisions ⁷ [^Laloux]. As they grow, departments emerge. Managers accumulate authority. Planning processes formalize. Approval chains lengthen. Within a few years, the organisation has recreated the Predictive Operating Model.

This regression is predictable. The Predictive Operating Model’s theory of the business, control through prediction and standardization, is deeply familiar. Most leaders experienced it throughout their careers. Under pressure, people default to known patterns. When faced with coordination challenges, the instinct is to add management layers. When facing uncertainty, the reflex is to demand more detailed plans. The old theory reasserts itself because it feels safer, even when it has become obsolete.

Organizations build up what we might call operating-model cruft, accumulated structures, processes, and behaviors that no longer serve the current context but resist removal. A new approval process gets added to prevent a single failure. It never gets removed when the risk passes. A management layer forms to coordinate between teams. It persists even after teams become more self-sufficient. Individual performance reviews drive behaviors that undermine team collaboration, but changing them feels too risky.

Without deliberate operating-model hygiene, the continuous practice of examining and removing organisational structures, processes, and behaviors that no longer serve their purpose, organisations inevitably regress. This hygiene means regularly asking Drucker’s fundamental question: “If we were not doing this today, would we start?” ⁸ If the answer is no, the practice must be abandoned. Does this approval process still serve us? Does this management layer enable or impede fast feedback? Does this metric distribute authority or concentrate it? Does this structure build team capability or create dependencies?

Operating-model hygiene requires refactoring organisational structures just as we refactor code. Remove processes that no longer serve their purpose. Eliminate management layers that have become bottlenecks. Disband cross-functional coordinating bodies that exist only because teams lack necessary skills. Challenge individual metrics that undermine collaboration.

But Drucker taught that abandonment alone is insufficient, it creates capacity, not capability. Organizations must pair systematic abandonment with purposeful innovation: the disciplined creation of new practices that support the current mission. This means building technical capabilities like Continuous Delivery and automated testing, establishing outcome-focused management practices, creating persistent cross-functional team structures, developing routines for empirical discovery and rapid experimentation, and investing in skills that enable adaptability. Without purposeful innovation to replace what is removed, organizations drift.

This work never ends. Organizations exist in constant tension between forces that drive toward hierarchy and control and forces that enable distributed decision-making and adaptation. Effective operating models depend on continuously pruning what no longer works while intentionally building what the future requires. Without this dual discipline, the Predictive Operating Model reasserts itself.

Making the Transition

Transitioning from a Predictive Operating Model to an Adaptive Operating Model is not a simple process change. It requires fundamentally changing your organization’s theory of the business, the core assumptions about how success happens. This demands shifts in structure, culture, measurement, and leadership that reflect the new theory.

Structure must change to persistent, cross-functional teams aligned to value streams or products. Functional departments become communities of practice rather than organisational silos. Project teams and resource pools must go, they are incompatible with the Agile Product Operating Model.

Measurement must change from output to outcome. Evidence-Based Management provides the framework: Current Value, Unrealized Value, Time to Market, and Ability to Innovate. These measures focus on value delivery and system capability, not individual productivity or task completion. Velocity, utilization rates, and other behaviors-distorting metrics must be abandoned ⁹.

Leadership must change from command-and-control to system stewardship. Drucker defined management through five responsibilities: setting objectives, organizing work, motivating people, measuring performance, and developing people ¹⁰. Under the Predictive Operating Model, managers set objectives through prediction, organize work through functional silos, motivate through supervision and utilization targets, measure output and efficiency, and develop narrow specialization. The Adaptive Operating Model requires different interpretations: managers define clear goals and constraints rather than detailed plans, design persistent cross-functional teams as the primary organizational structure, create conditions for mastery and autonomy by removing impediments, measure outcomes and system capability through Evidence-Based Management, and build broad adaptable capability through continuous development ¹¹. Critically, leaders must maintain goal clarity throughout the organization while allowing those goals to evolve with learning, a discipline most companies find difficult because it requires balancing stability of direction with flexibility of approach. Without explicitly redefining the manager’s role, organizations default to Predictive Operating Model behaviors regardless of their stated intentions.

Culture must change to support transparency, experimentation, and psychological safety. Teams must be able to surface problems without fear of blame. Failure in controlled experiments must be recognized as learning, not punished as incompetence. This cultural shift takes time and consistent leadership behaviors.

Many organisations attempt these changes incrementally, hoping to avoid disruption. This rarely succeeds. The Predictive Operating Model is coherent, its pieces reinforce each other because they all flow from the same theory of the business. Individual performance reviews support functional silos. Functional silos necessitate project structures. Project structures require resource allocation and individual utilization measurement. These elements form an interconnected system, all built on assumptions of predictability and control.

Changing one element while preserving others creates internal contradictions that prevent real transformation. Organizations end up with “Agile teams” reporting through hierarchical management structures, measured by predictive metrics, organized into temporary project assignments. This is not transition, it is the Predictive Operating Model with different terminology. The underlying theory of the business remains unchanged.

Effective transition requires system-level change. The organisation must commit to restructuring around products, establishing cross-functional teams, shifting to outcome-based measurement, and supporting leaders who steward systems rather than control work. This takes months of focused effort, not years of gradual adjustment.

OpenSpace Agile provides a mechanism for system-level change without multi-year programmes or imposed transformation ¹². Leaders define outcomes and constraints, and the organisation self-organises to design and implement the changes. The people who do the work shape the operating model, which increases ownership, alignment, and speed. A short cadence of Open Space events creates the forum for surfacing problems, proposing solutions, and committing to experiments that reflect the realities of the work.

These experiments run in fast cycles with clear feedback, allowing the organisation to learn what works in its context rather than copying someone else’s playbook. Effective changes get amplified, ineffective ones are dropped, and the operating model evolves through participation rather than prescription. This enables meaningful organisational shifts in months by removing the bottlenecks of traditional change management and allowing those closest to the work to drive improvement.

Call to Action: Redesign Your Operating Model

If your organisation competes in dynamic markets, and most do, the Predictive Operating Model is costing you. Every day. Wasted effort. Missed opportunities. Frustrated teams. Lost customers.

The question is not whether to change, but how quickly you can change.

Start by acknowledging the mismatch. Your operating model embodies a theory of the business designed for different conditions. It is not bad, it is unfit for current context. The assumptions embedded in your structures, processes, and leadership behaviors were built for a world that no longer exists.

Commit to operating-model redesign built on the Adaptive Operating Model . Establish clear, adaptive goals at every level that provide direction without constraining discovery. Structure persistent, cross-functional teams around value streams. Distribute decision-making authority to those teams. Measure outcomes and system capability, not outputs and individual activity. Develop leaders who design systems rather than control work. Organizations delivering value through products can implement this through specialized approaches like the Product Operating Model or Agile Product Operating Model .

Let the organisation shape its own transition. OpenSpace Agile provides the structure: you set the direction, your people design the path through rapid experiments and continuous learning ¹². This creates change in months, not years.

Implement continuous operating-model hygiene. Regularly examine structures, processes, and behaviors. Remove what no longer serves. Challenge what creates dependencies or delays feedback. Resist the gravitational pull toward hierarchy and control.

This is not easy work. But it is necessary work. The Predictive Operating Model’s theory of the business, success through prediction and control in stable environments, cannot deliver value effectively when environments are uncertain and fast-changing. Organizations that complete this transition, adopting a theory of the business built on learning and adaptation, will thrive. Those that don’t will continue generating waste while wondering why their “Agile transformation” failed.

The choice is yours: maintain an operating model built on assumptions about markets that no longer exist, or redesign your organisation around a theory of the business that matches the reality you face today.

What is one structure or process in your organisation that generates waste because it assumes stable, predictable work, and what would operating-model hygiene lead you to change?

References:

Every large-scale delivery conversation eventually drifts into the same dead-end: “How do you manage dependencies?” The assumption is baked in, that dependencies are inevitable, so the best you can do is build a Gantt chart, track them, and hope for the best.

That assumption is wrong. Dependencies are not a law of nature. They are, as a rule, a symptom of poor system design. The ethos you should adopt is simple: don’t manage dependencies, remove them. Dependencies are systemic problems, not individual failings. Blaming teams or people misses the point; the system itself is what generates dependency waste.

When you manage dependencies, you’re committing to ongoing overhead: coordination meetings, dependency boards, artificial milestones, and cross-team politics. When you remove them, you restore autonomy, accelerate flow, and reduce risk. The cost of managing dependencies grows exponentially with every new team and integration point. The benefit of removing these compounds.

This post reframes the question. Instead of asking how to manage dependencies, let’s explore how to design systems of work that eliminate them.

Step 1: Align Work, Teams, and Architecture

Dependencies don’t just appear by accident; they are often created when work, team structures, and architecture are misaligned. Without clear alignment, every piece of work risks bouncing between silos, waiting on specialists, and suffering from endless handoffs. That is the problem: dependencies are the tax you pay for poor organisational design. Getting alignment between the work coming in, the teams who own it, and the architecture they work within is the single most effective lever to reduce this tax. Start by examining the flow of work into the system and then design accordingly. Misalignment creates dependencies, which in turn generate delay and rework. Alignment is not optional; it is the prerequisite for autonomy and predictable flow. Leadership must own this alignment, teams cannot fix systemic misalignment by themselves.

What you’d observe:

• Teams blocked waiting for another group to deliver a component.
• Integration schedules instead of continuous delivery.
• Architects handing down plans disconnected from the team topology.

Impact:

• Delays compound as work zig-zags across silos.
• Teams cannot deliver end-to-end value.

Design your organisation so that work, teams, and architecture line up

When teams can deliver value without waiting for others, most “dependencies” vanish. Dependencies are often just silos masquerading as inevitabilities.

• Structure teams to own a vertical slice of customer value, not a horizontal layer of technology.
• Use Conway’s Law as guidance: your architecture will mirror your communication structure. Intentionally shape both.
• Collapse handoffs. Give each team persistent ownership of the product or service they deliver.

Step 2: Make Contracts Explicit

Many teams have other teams that depend on them, yet the terms of those dependencies are often left implicit. Each capability should provide a clear published contract that others can rely on. When changes are required, subscribers must be engaged to avoid breakage. In practice, this can mean maintaining multiple versions of contracts or APIs so that legacy consumers continue to work.

What you’d observe:

• Teams are guessing at how another service behaves.
• Breaking changes are introduced without warning.
• Communication channels are full of “who owns this API?” questions.

Impact:

• Surprise defects at integration time.
• Long cycles of rework.

Document contracts between capabilities

Explicit contracts turn invisible risks into manageable, testable agreements. Teams understand who relies on them and what will break if they make changes. This makes coordination predictable and largely automated.

How:

• Define service contracts for every API, integration, or shared capability.
• Use patterns like consumer-driven contracts and the tolerant reader to protect against breakage.
• Maintain a catalogue of who depends on what, visible and owned.

Step 3: Clarify Ownership

It should be clear which team owns each feature, component, or integration point, and exactly how to reach them. Ownership is more than a name on a slide; it means team-level accountability for decision‑making, maintenance, and evolution. Teams across the organisation should know which team to approach for changes, who approves modifications, and how issues will be triaged. Without this clarity, features drift, defects bounce between groups, and hidden dependencies multiply. Stable ownership over time is crucial; frequent changes in ownership create systemic churn.

What you’d observe:

• Multiple teams touching the same codebase.
• Bugs bouncing between groups.
• Nobody is sure who can approve a change.

Impact:

• Confusion, delay, and political friction.
• Hidden dependencies on individuals or “shadow owners.”

Resolve by establishing clear ownership lines

Ambiguity is the breeding ground for dependencies. Clarity lets others adapt or negotiate when overlap is unavoidable.

How:

• Map every application, service, and integration to a single accountable team.
• Make ownership visible in tooling (Wiki, Whiteboard, Azure DevOps, GitHub, etc.).
• Establish communication paths to clarify who to engage with when non-contract dependencies arise.

Step 4: Actively Manage the Rare Remainders

After all of that, there are still going to be some dependencies that are inescapable. These need to be actively managed by the feature team that is the subscriber and raised to leadership as signals of systemic weakness that require intervention and redesign.

What you’d observe:

• A handful of dependencies remain despite alignment, contracts, and ownership.
• Work items in one team are directly blocked by delivery from another.

Impact:

• Delivery risk where elimination wasn’t possible.
• Leadership attention consumed by coordination rather than improvement.

Manage only these

Dependencies you can’t remove should be visible, owned, and tracked. But the point is to treat them as defects in your organisational design, not facts of life. They are alarms that something still needs to change. They represent system design debt, not normal work.

How:

• Track explicit dependencies between backlog items.
• Use shared reviews or joint planning where strictly necessary.
• Escalate them so leadership sees them as design flaws to resolve, not work items to shuffle.
• Treat them as exceptions to be removed long-term, not normal operating procedure.

Systemic View

Dependencies exist because of how you design systems of work. A flawed system will always overpower the best intentions of the people inside it. The behaviours you see are simply the consequences of the structures you created.

• Siloed teams generate handoffs and queues that slow everything down.
• Ambiguous ownership breeds uncertainty and political friction.
• Implicit contracts guarantee surprises and rework.

These are not accidents; they are deliberate design choices, even if unacknowledged. Left unchecked, they act as amplifiers of waste, magnifying delay, variability, and risk across the organisation. Dependencies are one of the clearest forms of systemic waste and delay, and every appearance of them is a call to redesign.

The answer is not to manage harder but to redesign. You remove the cause rather than chase the symptom. That is the work of stewardship: shaping structures, policies, and boundaries so that flow becomes natural and dependencies are engineered out of existence.

Organisations that aggressively eliminate dependencies consistently show:

• Faster cycle times.
• Fewer integration defects.
• Higher team morale due to autonomy.

Frameworks like Nexus put dependency management front and centre, but the real lesson is that dependencies are signals of poor alignment. The Kanban Guide emphasises WIP limits and flow efficiency; dependencies are often the hidden WIP that destroys predictability. Evidence-Based Management encourages us to inspect value delivery capability; dependencies are one of the clearest capability killers.

Closing the Loop

When someone asks, “How do you manage dependencies?”, the radical answer is: you don’t. You redesign your teams, architecture, and workflow to eliminate dependencies from the outset. You only manage what’s left when all else fails, and you treat every remaining dependency as a design flaw to be removed. That’s how you maximise autonomy, accelerate flow, and reduce risk.

Stop normalising dependency management as a project management activity. Managing dependencies is treating the symptom. Leadership must instead redesign the system to eliminate the cause. Every dependency you remove is a gift to your teams and your customers. So next time someone asks you how you manage dependencies, give them the only honest answer: we don’t; we remove them.

When the Metric Becomes the Target

Metrics are never neutral. Once teams are judged by how closely they meet estimated timelines or planned outputs, those metrics stop reflecting the truth. The more visible and enforced the target becomes, the more teams adapt, not to improve outcomes, but to survive the system. What follows is a cascade of distorted behaviours: silence replaces honesty, delivery becomes performance theatre, and metrics become tools of compliance rather than learning. The following patterns are not outliers; they are systemic symptoms of measurement misuse.

Malicious Compliance: When Teams Give Up on Caring

When systems overemphasise compliance, teams don’t rebel; they comply. Maliciously. They log the hours. They meet the metrics. They do exactly what’s asked; but no more. They stop asking questions. They stop raising concerns. They stop caring.

This kind of mechanical compliance doesn’t improve delivery; it undermines it. Developers fill in timesheets at the end of the week with whatever gets approved. They make up hours to satisfy reporting tools. What ends up in the system looks clean and green, but it’s fiction.

And what gets lost is far worse: safety, curiosity, technical excellence, and any sense of pride in the outcome. A culture of malicious compliance breeds disengagement, risk blindness, and degraded quality. If you’re measuring in six-minute increments, you’re not managing for value. You’re auditing obedience.

Green Shifting: When Metrics Replace Truth

Once metrics become the focus, honesty becomes optional. Teams under pressure to hit targets will show green status until the very moment they can’t hide red anymore. This phenomenon, sometimes called “green shifting,” isn’t a failure of individuals. It’s the predictable result of a system that rewards status optics over empirical feedback.

When the dashboard matters more than the work, risk gets buried. Quality is sidelined. And problems that could’ve been solved early are deferred until they explode. This isn’t management; it’s theatre.

Fear-Driven Delivery

When performance is judged by how closely estimates match actuals, teams shift into survival mode. Psychological safety evaporates. People stop flagging problems, bugs, and risks. It’s not due to apathy, but fear of missing the number. Defects get buried. Safety is deferred. Risk is hidden.

The focus moves from building the right thing to defending the wrong metric.

When you penalise unpredictability, you don’t get more predictability. You get fear, silence, and a culture optimised for hiding reality. This is how delivery becomes theatre.

Distorted Behaviours and False Success

Comparing estimates to actuals can be useful for learning, but when it becomes a performance metric, it changes behaviour. Teams are no longer incentivised to improve forecasting; they’re incentivised to look predictable.

What happens next is entirely predictable:

• Padding: Teams inflate estimates to guarantee hitting the target.

In one large organisation, teams were told they could deliver no more than five points per story, and no more than 24 points per sprint. The result? Teams padded everything to hit exactly 24 points. Story sizes gravitated to five points regardless of complexity. Innovation vanished, curiosity died, and delivery became a game of maximising perceived output. They met the metric perfectly and completely undermined the point of estimation. This is what happens when the system is designed for optics, not outcomes.

• Risk aversion: Complex and innovative work is avoided because it’s difficult to estimate.
• Scope distortion: Work is redefined midstream to match the estimate.
• False success: Projects finish “on time” and “on budget,” but deliver little value. Many organisations never validate whether the promised benefits were actually realised. One team might deliver a multimillion-dollar system, only for no one to ever measure its usage or customer impact. The project is declared a success, but no one checks if it made a difference. In some cases, even the most advanced organisations fall into this trap. The cost of not checking actual outcomes is hidden until it’s too late.

These aren’t edge cases; they’re rational adaptations to a distorted system. The result is a culture of compliance, not curiosity.

Thurlow’s Law of Metric Distortion: “Any metric you measure will appear to improve in the short term. This doesn’t mean the system improved, only that people adjusted their behaviour to game the metric.”

The System Learns to Lie

This principle highlights a broader risk. Once teams realise they’re being judged on metric performance, they start optimising for appearances. They stop focusing on delivery, learning, and value. The metric becomes a distraction from what really matters. It reinforces behaviours that prioritise green dashboards over working software. This is how green shifting starts. Status reports stay green until the moment they can no longer hide the red. It’s not deceit. It’s self-preservation. In a system optimised for appearances, truth is delayed until failure is unavoidable. The focus shifts away from delivery, learning, and value.

The Evidence Behind the Trap

Studies from Lederer & Prasad, Jørgensen, and others show that using estimation accuracy as an evaluation criterion strongly influences behaviour, and often negatively. When estimation accuracy becomes a KPI, it reshapes incentives across the system, often with unintended results. One experimental study (Lorko et al., 2022) found that when participants were rewarded solely for estimation accuracy, they systematically overestimated and deliberately slowed down to “finish on schedule.” The appearance of control was preserved, but efficiency was lost.

Another study (Jørgensen & Grimstad, 2008) showed that people who knew they’d be judged on their estimates produced more biased and less realistic figures. They weren’t aiming for truth; they were aiming for safety.

This is a textbook example of Goodhart’s Law. When a measure becomes a target, it stops being useful as a measure and starts driving the wrong behaviours.

Goodhart’s law:  “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”

Trust Is a Two-Way Street

If you treat your engineers like they’re untrusted contractors who need to account for every six-minute increment, don’t be surprised when morale tanks. One developer put it bluntly: “If you’re going to track me like a machine, don’t expect me to act like an innovator.” Research shows employees who feel trusted are more engaged and productive. Conversely, heavy time tracking breeds a culture of micromanagement and mistrust. More than half of knowledge workers say time tracking actually prevents them from doing their best work. When people feel every minute is under a microscope, they’re less likely to ask questions or offer improvements. You’re starving your team of psychological safety, and with it, the conditions for innovation, quality, and honesty. When people are punished for missing estimates, they stop raising risks. They stop discussing trade-offs. Data becomes performative. The real work gets buried under ritual. The system becomes more predictable on paper, but more brittle in reality.

Bad Estimates Don’t Make You a Bad Developer

Software development is creative problem-solving. No two tasks are truly alike. You can’t reliably predict how long it will take to untangle a thorny bug or integrate a library. Sometimes, a “quick” fix can turn into a two-day rabbit hole. So why beat people up when they miss an arbitrary prediction? Estimating in hours assumes everyone is equally experienced and works at a constant pace. They don’t. Pressuring developers to “improve” their guesses assumes effort and duration are predictable. In knowledge work, they’re not. It only creates stress and encourages padding or sandbagging. It’s a game with no winners.

Time Pressure Kills Quality

When management’s only lever is the schedule, quality suffers. Tom DeMarco and Tim Lister, in Peopleware, warn that unreachable deadlines force developers to cut corners: “Workers kept under extreme time pressure will begin to sacrifice quality… deliver products that are unstable and not really complete.” Lab studies back this up. Developers under tight time pressure work faster, not better, and quality drops. And when shortcuts pile up, the cost isn’t just bugs, it’s fragile systems, frustrated customers, and eroded trust.

Hours Worked Do Not Equal Value Delivered

Customers don’t buy effort, hours, or estimation accuracy. They buy working software that solves their problems. A day spent cleaning up architecture might look unproductive on a timesheet, but it delivers enormous long-term value. Optimising for logged time only encourages burnout, presenteeism, and a celebration of busyness over outcomes.

Metrics like velocity or hours measure output, but they don’t measure the value customers care about. It’s better to track what matters: how frequently you can deliver features, how quickly you recover from failures, and whether you’re improving the user experience. These metrics help track how fast you’re learning (Time to Market), how much waste exists in your delivery process (Ability to Innovate), and whether users are sticking around and benefiting from what you’ve delivered (Current Value).

What to Do Instead

If you’re serious about improving delivery outcomes, stop obsessing over time. Time-based metrics show what happened, not what mattered. They miss the nuance of complexity, cognition, and asynchronous problem-solving. When you treat delivery like stopwatch management, you reward appearances over insight.

Evidence-Based Management (EBM) is a way of managing with data that reflects actual outcomes and system capability. It helps leaders move beyond speculation by focusing on what is observable and valuable.

Good decisions start with real data, not guesses. EBM helps teams and leaders focus on what actually delivers value, not what was forecast, promised, or imagined.

In large-scale systems, direct customer contact is rare. That makes feedback loops even more critical. We must rely on proxy signals like usage trends, satisfaction scores, defect trends, and change failure rates to know if we’re on track. Not every team needs direct access to the customer, but every team needs access to evidence that what they shipped is working.

EBM encourages decisions based on what is actually happening, rather than what was predicted. Forecasts can support decision-making, but only when used transparently to explore assumptions, not when turned into compliance targets. When forecast accuracy becomes a performance metric, it violates empiricism by rewarding appearances rather than actual outcomes.

Leadership must create transparency around outcomes, not intentions. This means embracing metrics that reflect customer value, system health, and delivery capability, even when they challenge the status quo.

Let’s be clear: in complex, knowledge-based work, there is no meaningful diagnostic value in “estimate vs actual.” Take, for example, a cross-functional team building an internal developer platform. In the first quarter, leadership tracked the estimated vs actual across epics to improve forecasting. Developers quickly learned to overestimate tasks, avoided exploratory work, and padded estimates to match targets. The numbers looked better, but progress slowed, innovation stalled, and valuable refactoring work vanished from the backlog. By the time leadership realised the disconnect, technical debt had doubled. The team hadn’t become more predictable; it had simply become more cautious and less effective. This is the cost of measuring the wrong thing. It leads to the wrong conclusions.

“Estimate vs actual measures the work, but the waste lives in the gaps , the wait, the handoff, the delay. So you’re optimising the wrong thing.” - Nigel Thurlow

This is a clear example of Systems Thinking, as outlined in The Flow System (Thurlow et al., 2020). The true constraint rarely lies in the task. It lies in the system: the queues, context switching, blocked dependencies, or fragmented communication paths that hinder the delivery of value. In most cases, the constraint lies in the workflow, rather than in the functions themselves.

Even when used “diagnostically”, estimate vs actual as a metric misleads:

• It ignores queues, rework, and dependencies, which are often the actual sources of delay. Lean thinking teaches us that to improve flow we must visualise queues, limit work in progress (WIP), and actively manage handoffs; none of which are addressed by focusing on task-level estimate variance.
• It reinforces the illusion that better estimation leads to better outcomes.
• It promotes local optimisation over systemic improvement.

A reminder of Thurlow’s Principle of Estimation Distortion above!

A Better Path Forward with Evidence-Based Management

EBM organises improvement around four Key Value Areas (KVAs):

• Current Value - Are We Delivering Value to Customers and Stakeholders Today?
• Unrealised Value - What additional value could we deliver in the future?
• Time to Market - How quickly can we learn, respond, and deliver?
• Ability to Innovate - How effectively can we change and adapt the product?

The metrics we use should support these questions, not distract from them. Here’s how EBM-oriented alternatives compare:

To understand and improve delivery, stop obsessing over how close your guesses were. Instead, measure how your system behaves across the value stream and under varying flow loads. EBM encourages the use of actionable, outcome-aligned metrics that reflect actual system health, rather than projected compliance.

• Cycle time trends can reveal delivery latency across the value stream, but must be interpreted with caution. Without understanding the nature and complexity of the work, as well as its value, these trends are just noise. Measure flow to inspect how the system behaves, not how long individual items take.

  ℹ️ Note

  Cycle time only tracks how long one piece of work took. It says nothing about what the customer waited for or whether the system is flowing well. Lead time tells you how long the customer waits, starting from the moment a request is made until they receive something usable. Always measure from the outside in.

• Work item ageing reveals stuck or neglected work, or requirements that were added and then discarded.
• Flow efficiency indicates the proportion of total time spent progressing work versus waiting. It’s a measure of delay, not value. But beware: systems often mask latency by moving queued work into “in progress” prematurely. High flow efficiency with unchanged lead time may signal gaming.
• Throughput variance only tells you something if your work items are roughly the same size. If not, throughput becomes noise. Teams that right-size work can use this as a stability signal. Otherwise, avoid using it as an indicator of performance.

If you must discuss estimates, use them to explore assumptions and complexity, not to evaluate people. The ultimate goal is to deliver meaningful outcomes to customers. That requires embracing uncertainty, surfacing impediments, and improving system capability. The aim is not to enforce forecast compliance. Value lies in understanding, not accuracy.

• De-emphasise ’estimate vs actual’ entirely. It is a false signal in complex domains.
• Reward flow mastery, not forecasting tricks.
• Focus on learning, adaptability, and real customer outcomes.

Estimation should support informed conversations about uncertainty. It should not become a tool used to force predictability.

Quantitative vs Qualitative

Most metrics in delivery are quantitative, including lead time, flow efficiency, and throughput. But numbers don’t tell the whole story. If you want to know whether you’re building the right thing, you need qualitative feedback: real customer conversations, issue sentiment, satisfaction narratives, and behavioural observations.

Quantitative data tells you what happened. Qualitative insight helps you understand why.

No chart or trendline can replace a conversation with a frustrated user or a support ticket that describes unmet needs. The most resilient teams blend data with dialogue, metrics with meaning.

Radical Candour: Have the Courage to Stop

This isn’t about shielding teams from accountability. It’s about holding ourselves accountable to a higher standard of leadership. Framing time estimate accuracy as a condition for trust is a failure of leadership. It signals a lack of psychological safety and a misunderstanding of how complex work unfolds. True leadership fosters environments where learning is safe, discovery is encouraged, and performance is judged by value, not conformity to expectations. It’s not helping them grow; it’s punishing them for unpredictability inherent in complex work. Radical candour means caring personally and challenging directly. The challenge here is to stop clinging to false certainty and instead focus on the outcomes that matter for your business and your customers.

Don’t replace one flawed proxy with another. Metrics like cycle time, throughput, or flow efficiency are helpful, but only as part of a broader conversation about value, quality, and improvement. Alone, they tell you nothing about whether you’re solving the correct problems or improving customer outcomes. Consider adopting Evidence-Based Management and DORA to shift focus toward empiricism and value flow across the organisation. Talk with your team about impediments and improvements rather than the hours they logged. When you remove the spotlight from the clock, you’ll find your people deliver better software, enjoy their work more, and build trust along the way.

In Summary

The Estimation Trap appears to be a process improvement effort. But underneath it creates a fear-based culture that rewards gaming and punishes uncertainty. It distorts delivery and kills innovation in the name of control.

All quantitative measures can do, is inform of system efficiency. They cannot inform of system effectiveness!

Instead of asking, “Why didn’t we match our original estimate?” ask, “What did we learn, how did we adapt, and are we improving the outcomes that matter?”

Real progress starts when people feel safe enough to tell the truth about complexity, risk, and what it actually takes to deliver. That’s the objective measure of a team delivering meaningful outcomes, improving their system, and creating value for customers.

References

1. Thurlow, Nigel; Turner, Brian Rivera; Helm, John. The Flow System: The Evolution of Agile and Lean Thinking in an Age of Complexity (2020)
2. Lederer & Prasad (1998). “A causal model for software cost estimating error”
3. Lorko et al. (2022). “Hidden Inefficiency: Strategic Inflation of Project Schedules”
4. Jørgensen & Grimstad (2008). “The impact of irrelevant and misleading information on software development effort estimates”
5. Jørgensen (2004). “A review of studies on expert estimation of software development effort”
6. Abdel-Hamid et al. (1999). “The dynamics of software project performance”
7. Peopleware Book Summary
8. Impact of time pressure on software quality
9. Why Managers Should Focus on Outcomes, Not Hours
10. Accelerate: The Science of Lean Software and DevOps (Forsgren, Humble, Kim)
11. SPACE Framework Whitepaper (GitHub)
12. Why Leading Agile Teams Focus on Customer Value

The Kanban Guide frames Kanban as a strategy to optimise the flow of value through a system. That phrase, “flow of value,” has helped teams shift from managing task queues to pursuing outcomes. But it can also obscure the truth.

Does value actually flow? Or is it just work that moves?

Value is not a mystical force.

Value is validated by the customer. Never before. Until the customer confirms it solved a problem, improved their life, or moved a meaningful metric, it’s just work. Calling it “flow of value” without qualification is misleading.

In knowledge work, such as software development, services, and product discovery, most of what flows through the system is hypotheses, not guarantees. Assuming WIP equals value encourages:

• Closing tickets before a release
• Shipping features with no telemetry
• Pushing large batches through based on stakeholder opinion

It hides waste and sidesteps accountability.

The Kanban Guide helps by pointing to potential value. Work items are bets, nothing more. Managing flow well means reducing the time it takes to validate whether those bets pay off.

Scrum reinforces this by focusing on maximising the potential for value, not assuming it. That is why empirical control exists: transparency, inspection, and adaptation. There is no inspection without delivery to the customer.

Why the manufacturing metaphor fails

In manufacturing, value accumulates visibly. Raw material becomes a part. A part becomes a product. Waste is obvious. In knowledge work, it’s invisible. We’re not assembling. We’re exploring.

You don’t know if something is valuable until it’s in the hands of users. That is why “flow of value” only makes sense in hindsight. Day-to-day, you’re managing the flow of potential value.

Finishing a feature doesn’t deliver value. It creates the possibility of value. If no one uses it, or it solves the wrong problem, it’s a waste. Intent is not impact. That is why systems of work must optimise for learning, not motion.

Unfinished work delivers no value. It clogs the flow and delays feedback. Measuring WIP, lead time, and cycle time isn’t micro-management. It is how we ensure we’re learning fast enough.

Useful shorthand with context

“Flow of value” is not a declaration of certainty. It is deliberate shorthand for the pursuit of work believed to be valuable. That belief isn’t enough. You need to make intent visible, validate early, and cut what doesn’t deliver. This means building systems where each item has a purpose. Why does it matter? How will we know? If those questions can’t be answered, it’s just noise.

Value isn’t defined at deployment. It begins with a hypothesis and ends with validation. Efficient delivery pipelines mean nothing if they’re optimising junk. Observability is how you fix that. Define start and end points. Limit WIP. Measure time to feedback.

Attach outcomes to cards. Acceptance criteria. OKRs. Usage metrics. Use SLEs to forecast the time to learning. In DevOps terms, version everything, automate validation, monitor behaviour, use feature flags, and ship small. Then measure. Learn. Adapt.

If your system isn’t designed to validate outcomes, it isn’t flowing value. It is flowing assumptions.

Radical candour: stop lying to yourselves

If you’re calling every backlog item “value” and measuring success by throughput alone, you’re lying to yourself. You’re accountable for maximising product value, not just moving work.

Kill unvalidated work. Break big bets into small, testable increments. Use data to kill features that fail. Stop equating motion with impact.

Every item should have a testable hypothesis. Every workflow should surface whether it was delivered. Use flow metrics to measure time to feedback. Run forecasts, but act on what you learn. And stop promoting through environment-linked branches. It’s a waste. Move to trunk-based flow. Ship fast. Learn fast.

Summary

“Flow of value” is not free. It’s not automatic. And it’s not a slogan.

It’s a claim. Claims require evidence.

Used lazily, it breeds complacency. Used rigorously, it drives alignment, urgency, and focus. That is the difference between being busy and being valuable.

This isn’t a theoretical issue. It’s not about mindset. It’s a systemic constraint. The more you load a delivery system, the slower and more unpredictable it becomes. The more you try to force progress by starting new work, the less likely it is that anything will finish.

At a certain point, no estimate matters because wait time is dominating lead time.

Estimation and flow are not interchangeable

It’s tempting to believe that delivery problems are caused by poor estimation. If only the team were better at sizing or forecasting, things would be more predictable. But the underlying assumption here is flawed: it assumes the issue lies with how the team understands the work, not with how the system behaves under load.

A team may estimate that a task will take two days of effort. That estimate might be reasonable, given what they know. But if that task sits in a review queue, or is waiting on test, or is delayed due to someone being pulled onto another “high priority” initiative, then that two-day effort turns into a ten-day cycle time. The estimate wasn’t wrong. It was irrelevant.

In a system where most of the time is spent waiting, refining the accuracy of the effort estimate achieves very little. It’s a distraction from the core issue, which is that the system is too congested to behave predictably.

Little’s Law doesn’t care about your process

The relationship between WIP, throughput, and cycle time is not arbitrary. It’s defined by Little’s Law :

WIP = Throughput × Cycle Time

This relationship always holds, but it depends on a key assumption: that throughput is reasonably stable. And this is where many teams fall over.

In most software teams, throughput does fluctuate , sometimes significantly. That variability comes from inconsistent work item sizes, unclear requirements, frequent interruptions, blockers, technical debt, lack of test automation, and reactive priorities.

Unless a team is managing WIP aggressively, working in collaboration, and applying consistent flow policies, the idea of “stable throughput” is optimistic at best and misleading at worst. This is exactly why Scrum , Kanban , and other flow-based systems place so much emphasis on visualising work and limiting WIP: to stabilise throughput so you can get the benefits of predictability.

So yes, Little’s Law is always valid. But applying it usefully requires more than a theoretical understanding. It requires operational discipline. It requires systems that dampen variability rather than amplify it.

In fact, multiple industry studies and real-world examples have consistently validated this behaviour. One case study by Troy Magennis describes a team that introduced WIP limits and began swarming on blocked work. As a result, their 85th percentile cycle time dropped from 35 days to 14 days, even after halving the team size. Meanwhile, their throughput increased from 1.07 to 1.41 stories per day (Magennis, T., Impact of WIP Limits on Throughput and Predictability, 2016).

Another example comes from Ultimate Software, documented in Making Work Visible by Dominica DeGrandis , where a payroll team implemented WIP limits lower than the number of developers to force collaboration. This change led to a 69% reduction in story cycle time and a 79% reduction in average queue wait time. Their conclusion was simple: controlling WIP shortened how long work spent in the system and dramatically improved predictability.

The more work you start without finishing, the longer everything takes to get done. That delay introduces variability, and that variability is what destroys the trustworthiness of your plans.

Most teams don’t lose predictability because the work is hard. They lose predictability because everything is in progress, and very little is actually flowing.

You don’t need to measure to see the damage

You don’t need metrics dashboards to identify when WIP is too high. You can see it in the way work moves ,  or doesn’t.

If you reach the middle of a sprint and everything is “in progress” but nothing has been finished, that’s a signal. If developers are working on individual items and handing them off downstream to test or review, you’re operating a batch-and-queue system, and your flow efficiency is likely sitting around 5–15%.

That means 85–95% of the total time a work item spends in the system is just waiting. And yet we still treat the active effort as the part worth optimising.

This is why “estimating better” doesn’t help. Your estimates cover the 5–15%. The problem lives in the 85–95%.

Collaboration is the early warning system

In my experience, if a team isn’t working together, in pairs, mobs, or focused swarms, WIP is already too high. The more localised the work, the more parallelisation. The more parallelisation, the more queues. And the more queues, the longer and more variable the cycle time.

Solo work in a collaborative delivery system isn’t faster. It’s fragmented. And it usually results in a board full of items “almost done” by the time you hit the sprint review.

There’s a reason experinced teams limit WIP to fewer items than there are people. It forces collaboration. It surfaces blockers. It reduces context switching. And it creates the conditions where delivery actually becomes predictable.

Multitasking is just unmanaged WIP

It’s easy to hide WIP inside individual calendars. A developer working on four items in parallel is managing four invisible queues. They’ll tell you they’re “almost done” with all of them, but none of them are finished.

Every switch between tasks adds cognitive load ( Mark et al., 2005, UC Irvine ). Studies have shown that with five parallel items, you lose up to 75% of productive time to context switching alone (Weinberg, G., Quality Software Management: Systems Thinking, 1992; DeMarco, T. & Lister, T., Peopleware, 1999).

We don’t account for this in planning. We assume that “utilised” means “productive.” It doesn’t. It means slow, error-prone, and unpredictable.

So even if each individual item is small and well-estimated, the system is still under strain. And that strain manifests as delay.

The fix isn’t effort. It’s flow.

I’ve worked with teams that improved throughput and predictability without changing how they estimated, or increasing capacity, or working longer hours. They simply reduced WIP and focused on finishing.

Another example comes from a workshop documented by Julia Wester and Daniel Vacanti, where a team reduced their average cycle time by 55% over four sprints by combining visible WIP limits with service level expectations. There was no change to the work, the people, or the tooling. The only thing that changed was the system of work: work was finished before starting more, blockers were made visible, and delivery became more even. This kind of operational clarity consistently outperforms speculative estimation.

They didn’t do more work. They just stopped pretending that all the started work was progress.

The result? Less stress. Fewer surprises. And a forecast that didn’t fall apart after day two.

If you want predictability, stop flooding the system

You don’t get predictability from planning harder.

You get it from flow. You get it when work finishes at a consistent rate. You get it when the system is stable enough that estimates are actually meaningful.

If you’re struggling with predictability, don’t start with estimation. Start with WIP. Look at how many items are currently in progress. Look at how long they’ve been sitting. Look at how many are waiting on something else to move first.

Then ask: what would happen if we cut our WIP in half?

What would we have to do differently to actually finish things instead of constantly starting new ones?

That’s where predictability begins, not in a planning session, but in the shape and health of the system itself.

References

• Wester, J. & Vacanti, D. (2019). Actionable Agile Metrics for Predictability. Leanpub. https://www.actionableagile.com/book
• Magennis, T. (2016). Impact of WIP Limits on Throughput and Predictability. Focused Objective. https://focusedobjective.com
• Mark, G., Gonzalez, V. M., & Harris, J. (2005). No Task Left Behind? Examining the Nature of Fragmented Work. UC Irvine, CHI Conference. https://www.ics.uci.edu/~gmark/chi08-mark.pdf
• Weinberg, G. (1992). Quality Software Management: Systems Thinking. Dorset House Publishing. https://www.dorsethouse.com/books/qsmvol1.html
• DeMarco, T. & Lister, T. (1999). Peopleware: Productive Projects and Teams. Dorset House Publishing. https://www.dorsethouse.com/books/peopleware.html
• Magennis, T. (2016). Impact of WIP Limits on Throughput and Predictability. https://focusedobjective.com
• DeGrandis, D. (2017). Making Work Visible: Exposing Time Theft to Optimize Work & Flow. IT Revolution Press. https://itrevolution.com/products/making-work-visible

Let’s be clear: coding was never the bottleneck.

If you’re still organising your system of work like it is, managing capacity by developer headcount, measuring velocity in story points, handing off tickets from BA to Dev to QA, then AI isn’t going to save you. It’s going to expose you.

The First Way of DevOps Was Always the Warning

The First Way of DevOps is Systems Thinking. It’s the relentless focus on flow, from idea to delivery. Not just within development, but across the entire value stream.

So why is everyone panicking about code-writing agents?

Because most organisations never understood the First Way in the first place. They thought DevOps was about pipelines, YAML files, and infrastructure automation.

They forgot it was about fixing the system.

AI isn’t breaking your delivery model. It’s just revealing how broken it already was.

If You Map Your Value Stream, the Bottleneck Isn’t Where You Think

Do the work. Map your system. What you’ll likely find is this:

• Work sits in queues waiting for “clarification”
• Teams are blocked by signoffs, dependencies, or overburdened specialists
• Test feedback takes hours, days, or never comes at all
• Quality is gated by QA teams, not engineered into the product
• Your best developers are busy merging branches, not solving problems

In that mess, how is code ever the constraint?

AI Hallucination? Or Garbage In?

Yes, AI sometimes generates code that doesn’t compile or misbehaves. But let’s not act like human-written code is immune to those flaws.

Garbage in, garbage out. If your acceptance criteria are vague, your architecture is a mess, and your quality is outsourced to downstream testers, you’re giving AI the same bad inputs that led you here in the first place.

You don’t fix that by blaming the tool. You fix that by adopting disciplined engineering practices:

• Test-First development so intent is explicit
• Observability built in from the start
• Definition of Done that includes operational readiness
• Autonomous teams accountable for outcomes, not output

The problem isn’t the LLM. The problem is the system it landed in.

QA Is Not a Team. It’s a System Responsibility.

If you still have a separate QA team running tests after “dev is done,” you are perpetuating one of the core dysfunctions that made DevOps necessary.

Quality is not something you inspect in later. It’s something you build in from the start, with design, pairing, automation, and feedback.

AI won’t fix this. But it will make it more obvious.

So How Do You Test AI-Generated Code?

The same way you should already be testing human-typed code:

• Write the test before the code
• Make quality part of the Definition of Done
• Deploy frequently, observe outcomes, adapt fast

AI doesn’t change that. It just removes the excuse that “we didn’t have time.”

If You’re Still Blaming the Tool, You’re Not Owning the System

AI isn’t the enemy. Your culture is. Your delivery model is. Your lack of flow is.

If your teams can’t ship working software reliably today, AI isn’t going to help.

But if you’ve invested in autonomy, flow, and observability, if you’ve taken the First Way of DevOps seriously, then AI is a force multiplier.

The bottleneck was never the code. It was the way you worked.

If you’re still using multiple team projects in Azure DevOps to represent every application, every team, or every product, you may be paying the price in fragmentation, lost observability, and poor flow. That might have made sense in TFS 2005, but it’s a liability in 2025.

The real path to high-performing teams? One Project to rule them all. One Azure DevOps Project, multiple teams, focused goals, observable flow. Scaled, not scattered.

I have been advocating for  One Team Project to rule them all almost from the beginning with  Project of Projects with team Foundation Server 2010   and my stance has not changed, although the Azure DevOps product has a over the years.

TL;DR;

The “many teams and projects” model in Azure DevOps is Microsoft’s own recommended setup, and one they use internally. It can make life easier for portfolio management and cross-team collaboration. But it comes with a price: increased complexity in setup, configuration, and ongoing maintenance. You’re trading operational simplicity for structural flexibility.

“One project to rule them all [Teams] and in [Azure DevOps] bind them” - Martin Hinshelwood, 2010

When should you have multiple Projects in Azure DevOps?

Microsoft  clearly advises that projects are there to support multiple business units  and gives the following reasons for creating multiple projects:

• Support custom work tracking processes for specific business units within your organisation
• Support entirely separate business units that have their own administrative policies and administrators

I removed three reasons they give from this list, as they are generally irrelevant for most organisations. The first was the permission boundary, which I will handle below; another was for testing customisations, and the last was for a separate public OSS project.

Nowhere does Microsoft, as the creator of Azure DevOps, advocate for a Project per project, initiative, or effort within your organisation.

Why Multiple Organisations and Projects Break Down at Scale

In most organisations, we aim to create cross-functional teams capable of delivering across a portfolio, at least within a defined funding stream or budgetary unit. As organisations grow, they typically segment into multiple funding streams, but decision-making around where and how to apply funding remains centralised within each unit.

Azure DevOps’ organisational and project boundaries can hinder this flexibility.

Multi-Organisation Boundaries

• P&L Boundary: Separate organisations represent separate billing scopes; licensing, builds, storage.
• Query Boundary: You cannot query across organisations inside the same tenant. To get a full view, you’re forced into third-party tooling like Power BI.
• Linking Boundary: While you can link work items across organisations (e.g., “Consumes From”, “Produces For”, “Remote Related”), these links are largely superficial. They aren’t usable in Delivery Plans, Backlogs, or Boards.

Multi-Project Boundaries

• Query Boundary: While you can technically query across projects, you can’t create a unified backlog. Planning becomes fragmented and requires external tools like Portfolio++ to stitch things together.
• Boards: You cannot create a board that visualises work across multiple projects. That’s a hard platform limitation.
• Team Focus: When individuals belong to multiple projects, their focus splinters. Backlogs fragment. Priorities conflict. The result? Increased wait time, context switching, and delivery delays.
• Security: Permissions, policies, and groups must be duplicated and managed separately across projects. That’s more overhead and more risk.
• Shared Assets: Test cases, source, pipelines, environments, these are far harder to reuse or coordinate across projects.

Every additional Organisation and Project adds friction that Azure DevOps is not designed to resolve. These aren’t flexible abstractions; they are hard boundaries and are by design.

None of these constraints provides anything that a single project and a sane Area Path strategy couldn’t already achieve, with less overhead and more coherence.

Should you have many projects?

Here is a summary of the three options:

• One project, many teams - If your teams are aligned, your backlog is coherent, and you’re operating within a single organisation, then one project is the sweet spot. You get unified governance, consistent processes, and minimal admin overhead. Each team can tailor their boards and iterations while still feeding into a shared backlog and reporting structure. Visibility is baked in, if someone wants to see what’s happening, they can. Coordination is simpler, reuse is natural, and roll-up metrics just work. Most importantly, it reduces cognitive and operational overhead, letting teams focus on delivery, not bureaucracy.
• One organisation, many projects, and teams - This model is useful when you’re juggling different processes, delivery cadences, or security needs. You trade a bit of simplicity for flexibility. Each project has its own process templates, permissions, and settings, which makes sense if the work is fundamentally different, but it adds friction. Cross-team visibility suffers, reuse gets clumsy, and roll-up reporting becomes harder. You’re coordinating across silos, not within a system. If you’re using this model, you’ve likely optimised for isolation over collaboration. That might be intentional, but it comes at a cost.
• Many organisations - Only use this if you need ironclad isolation, think separate business units, external contracts, or compliance constraints. This is the most expensive model in terms of overhead, administration, and collaboration. There’s no natural visibility across orgs, no shared queries or boards, and zero cross-org reporting. Everything has to be duplicated or integrated manually. That might be acceptable if you’re supporting legacy TFS structures or strict multitenancy, but it kills flow. If you’re working across orgs and still need to coordinate, you’re solving a problem your tooling should have prevented.

I have always advocated for larger projects and use the following rule of thumb:

If you have money, people, work, or products that interact in any meaningful way, then they should really be in a single Project.

Let’s not pretend this is theoretical. Microsoft’s own Developer Division (DevDiv) utilises a single Azure DevOps project to manage source code, builds, releases, test cases, and work items for over 2,000 engineers. For the Windows team at Microsoft, it’s more like 15,000 people in one Project.

If that’s not proof this scales, what is?

The Strategy: One Project. Many Teams. Clear Constraints.

A modern Azure DevOps project is designed to scale horizontally using Teams, and Area Paths and not by creating new team projects. This means that you need to deliberately design your strategy to avoid it becoming a total midden.

Inside Azure DevOps, while teams are a flat list, they are linked to Area paths, a hierarchy, to determine which work items are included in the teams view, and thus their backlogs and boards.

Here’s how it works.

1. Use Area Paths to Represent Departments and Products

Your Area Path hierarchy is the backbone of visibility, governance, and scale. Treat it as a map of how your products are delivered, not how your org chart looks. It should reflect the product structure and value streams, not departmental politics.

Create a distinct leaf node for every delivery team. This gives you fine-grained control for permissions, test plan isolation, dashboard targeting, and scoped visibility. Intermediate levels should reflect coherent product or platform groupings, enabling roll-up views without breaking team autonomy.

1MyProject
2 ├── Product A
3 │    ├── Team 1
4 │    └── Team 2
5 ├── Product B
6 │    ├── Team X
7 │    └── Team Y
8 └── Platform
9      └── Shared Services Team

If your hierarchy matches your architecture and delivery teams, you unlock real traceability. If it mirrors your reporting lines, you’ll spend your time fighting visibility gaps and access problems.

2. Define Azure DevOps Teams with Clear Area Path Ownership

Each Azure DevOps Team is a lens into a defined slice of the Area Path hierarchy. That lens determines what work shows up on its backlog, board, and delivery plans. Clear, non-overlapping ownership is essential if you want visibility without duplication, focus without conflict.

The key? Design the Area Path hierarchy with intent, then map each team to a specific leaf node. Use the “include sub-areas” option carefully. Avoid overlap. One work item, one team board.

• Want a unified Platform view? Create an Azure DevOps Team at the higher-level node and include all sub-areas.
• Need a delivery team focus? Map them to their own leaf node and exclude others.
• Building a Portfolio Kanban? Use higher-level Areas with Epics and Features only, leave Backlog Items to delivery teams.

Here’s a common, pragmatic split:

• Feature team Boards: Configure to show Backlog Items only.
• Portfolio Boards: Configure to show Epics and Features only, with “include sub-areas” on.

This setup enables delivery teams to focus on tactical work, while leadership tracks strategic progress, all in the same project, without duplication.

3. Use Iteration Paths for Cadence, Not Structure

Keep Iteration Paths consistent across teams where possible. This enables consolidated reporting and facilitates shared understanding of delivery cycles.

When Team A says that the work will be done by Sprint 23, what does that mean? If Team B is on a different candidate, then this could be their Sprint 45, or the Shared Platform Teams Sprint 3.  A balance of autonomy and alignment is important when lots of folks are working together in the same value stream.

If you must deviate (e.g. teams with different Sprint lengths), isolate only the differing branches.

4. Secure by Area, Not by Project

One of the most common justifications for multiple team projects is “security.” But Azure DevOps already supports:

• Granular permissions on Area Paths
• Repos permissions
• Pipeline-level permissioning
• Environment and Library security for deployments

You can grant fine-grained access control to individual teams, stakeholders, or systems without fragmenting your project into unmanageable silos.

What About Reporting?

If you’re using one Azure DevOps project with clearly defined Area Paths and Teams, reporting becomes dramatically simpler, more powerful, and more honest.

Everything you need is in one place: Work Items, Repos, Pipelines, Releases, Test Plans. That means dashboards, boards, analytics views, and Delivery Plans just work, with no duct tape, no spreadsheet exports, no cross-project hacks.

• Use Dashboards for high-level visibility tailored to stakeholders.
• Use Delivery Plans for planning across multiple teams and value streams.
• Use Portfolio Backlogs to track progress across Features, Epics, and Initiatives without duplicating work.
• Use Analytics Views and Power BI to correlate flow, throughput, and cycle times across teams, products, and time.

And when you need more:

• Portfolio++ provides rich roadmap and status visualisations that work across queries, teams, and even projects.
• ActionableAgile brings deep flow metrics, cycle time scatterplots, throughput charts, WIP ageing, directly into your Azure DevOps instance.

Final Word: Optimise for Flow, Not Structure

Azure DevOps isn’t just tooling; it reflects how your organisation thinks about delivery. If you design for control, you’ll get silos. If you design for flow, you’ll get visibility, alignment, and adaptability. Its an intrinsic part of your systems of work.

Every new project boundary introduces delay, friction, and duplication. Every extra organisational boundary kills collaboration and wrecks observability. You don’t need more buckets. You need better boundaries inside one.

Design your system of work to reflect how you deliver value, not how your teams report. Use one project. Use Area Paths and Teams to model structure and scale. Secure it properly. Report from it meaningfully. And let your delivery system evolve with clarity, not chaos.

Don’t build around exceptions. Build for flow.

One Project. Many teams. Clear constraints. Value, continuously delivered.

Definitions

It’s clear that everyone refers to things within Azure DevOps differently, and naming is not Microsoft’s strong suit. Here is what I mean when I use terminology in this post:

• Tennant - Not really within Azure DevOps, but intrinsically linked is the Microsoft Entra ID tenant that provides the security with Users and Groups.
• Organisation - The big bucket of stuff and the almost absolute boundary for Azure DevOps. For argument’s sake, it’s a “database” with unique IDs and clear boundaries. Also known as “Collection” in Team Foundation Server (TFS).
• Process - The definition of the types and workflows of those types as well as the available backlog levels. Previously known as “Process Template”.
• Project - The first level bucket after Organisation that provides a security and feature boundary. Used to be called “Team Project”.
• Value Board - visualisation of the flow of value at a particular backlog level. This is just called “Board” in Azure DevOps, but I wanted to make my distinction clearer.
• Task Board - visualisation of tasks within value represented as value pinned to the left, and sub-tasks flow across the board.

References

• About projects and scaling your organization - Azure DevOps | Microsoft Learn
• Scaling Agile to large teams - Azure DevOps | Microsoft Learn
• Plan your organizational structure - Azure DevOps | Microsoft Learn

So what do you need?

1. A Clear Strategy

I’ve worked at a few customers that have tried, unsuccessfully, to implement OKR, and every time it comes down to a lack of leadership in defining and communicating clear strategies that everyone can understand.

“Is there a product charter that lays out the mission and strategic goals? Do all members of the team understand both, and are they able to see how their work contributes to both?” , DIB: Detecting Agile BS

Strategy should drive execution. If you don’t know where you’re trying to go over the next 1 to 5 years, OKRs won’t help. They’ll float. They’ll drift. They’ll get turned into a quarterly to-do list that looks busy but delivers nothing that matters. Worse, they can just become a work breakdown structure and a disaster waiting to happen.

2. A Culture That Embraces Transparency, Inspection, and Adaptation

OKRs will fail if your organisation tries to turn plans into contracts, hide things it does not like, or resist feedback. We need to be open by default. We need to welcome inspection and are willing to adapt.

Change is something to be expected and the norm rather than the exception. This is about building systems where learning is baked into the way that we do things. Agile, Scrum, and DevOps all share the same fundamental requirement for success. If you are failing at them, then OKRs will not solve any problems. You need to look in the mirror and deal with what’s there first.

OKRs surface misalignment; they are as much like a mirror as Scrum is. They expose a vague strategy and an incoherent execution. But they only help if people feel safe to inspect and adapt. Without that culture, OKRs become fear-driven, and the outcomes become distorted.

3. Team Agency

OKRs only work if the people doing the work have the agency to shape how they deliver outcomes. If you’re still managing with command-and-control, resource allocation, individual performance metrics, centralised plans, and siloed functions, admit it. You don’t want agility. You want a Gantt chart and a work breakdown structure. You’ll never unlock the creativity and accountability that OKRs demand.

“Are teams empowered to change the requirements based on user feedback?” “Are teams empowered to change their process based on what they learn?” , DIB: Detecting Agile BS

OKRs work best when teams self-manage against shared constraints. This requires clarity on purpose, context for decision-making, and boundaries that support autonomy rather than inhibit it.

4. A Belief That Outcomes Matter More Than Output

OKRs are fundamentally about outcomes. Not effort. Not headcount. Not feature delivery. If your leaders still reward activity over impact, OKRs will feel performative and punitive.

You have to believe that measurable, meaningful change is the point. Everything else is just activity.

Shifting to an outcome mindset means asking better questions:

• What behaviour are we trying to change?
• What evidence will show we’re making progress?
• How can we empower teams to find better ways to achieve the outcomes?

Without this mindset, OKRs will get gamed, ignored, or weaponised.

The OKR Structure

OKRs exist to translate strategy into action. That’s it.

• Objectives clarify where you’re going.
• Key Results define what success looks like.
• Execution is how you actually move toward it.

A simple, powerful format: “I will [Objective] as measured by [this set of Key Results].”

This structure gives you clarity, focus, and alignment. And when used well, it drives the shift from output to outcome.

Too often, organisations obsess over the Objective and treat the Key Results as a laundry list. That’s a mistake. It’s the Key Results that create leverage. They force clarity. They reveal intent. They make progress inspectable.

Why Do We Need Objectives?

Objectives provide direction in the chaos and reconnect execution to strategy. Without them, you’re just busy. And busy doesn’t mean valuable. We just have output.

The purpose of objectives is to:

• It forces you to focus. Limit the number. Ruthlessly.
• Connect directly to your strategic goals.
• Give teams something meaningful to rally around.
• Shift the conversation from “what are we doing?” to “why does it matter?”

The objectives help us resolve the goals from Scrum or Evidence-based management and can create the intent from intent-based leadership. They make the strategy visible and the contribution clear.

A well-written objective is outcome-oriented and time-bound. Not vague. Not incremental. And never written as “continue doing X.”

Why Do We Need Key Results?

Key Results aren’t just metrics. They’re commitments.

They:

• Push teams to define what success looks like
• Enable autonomy by giving teams room to decide how to achieve it
• Anchor discussions in data, not opinions
• Help leaders focus on enablement, not interference

Key Results aren’t there to punish failure. They’re there to surface learning. If you hit 100% of your Key Results every time, your goals were too easy.

That’s not success. That’s sandbagging.

Execution Isn’t Optional

OKRs aren’t a quarterly workshop. They live and die in the execution. If you’re not inspecting progress weekly or biweekly, they will drift. Strategic priorities will get lost in the noise of delivery.

You need a cadence. A rhythm. A system for:

• Reviewing progress
• Re-aligning focus
• Adapting based on learning

Additionally, reassess your OKRs at least every quarter. But don’t wait until the end to find out if they mattered. The feedback loop is the heartbeat of OKRs. Without it, they become theatre. With it, they become a mechanism for continuous adaptation.

OKRs are iterative and outcomes incremental

You won’t get it right the first time. Or the second. Or the third. You’ll write vague Objectives. You’ll write vanity Key Results. You’ll set goals that are either too big or too small.

That’s fine.

OKRs are a practice. You refine them over time. The point isn’t perfection. The point is progress. Use a retrospective on your OKRs and refactor your goals. Treat them as living artefacts. That’s how you get better.

  
flowchart TD
VMV["Vision, Mission, Values\n(5 to 20 years)"]
STR["Strategies\n(1 to 5 years)"]
OBJ["Objectives\n(Quarterly to Yearly)"]
KR["Key Results\n(Quarterly to Yearly)"]
ACT["Activities (Execution)\n(Day to Day)"]
MEA["Measure\n(Day to Day)"]
LEA["Learn\n(Weekly to Quarterly)"]

    VMV --> STR
    STR --> OBJ
    OBJ --> KR
    KR --> ACT
    ACT --> MEA
    MEA --> LEA
    LEA --> STR

    classDef yellow fill:#f9c74f,stroke:#333,stroke-width:1px;
    classDef green fill:#90be6d,stroke:#333,stroke-width:1px;
    classDef blue fill:#43aa8b,stroke:#333,stroke-width:1px;
    class OBJ yellow
    class KR green
    class ACT,MEA,LEA blue


  

This is what OKRs make possible: a living connection from strategy to execution, and back again. This is the cadence that drives organisational agility. This is why OKRs matter.

If you’re struggling to make OKRs stick, don’t blame the tool. Inspect your system. Look at your strategy. Look at your culture. Look at your cadence.

Because you can’t shortcut clarity. You can only create the conditions for it to emerge.

Agile for software development is a delivery discipline grounded in technical leadership, empirical control, and engineering excellence. If your so-called “Agile transformation” doesn’t touch your code, your infrastructure, your deployment pipelines, or your product strategy, then you’re not Agile, you’re just busy.

Agile Isn’t a Mindset. It’s a System of Work.

The term “Agile mindset” has become a smoke screen for vague, feel-good language that conveniently ignores the hard parts: architecture, observability, checkability, and releasability. A mindset doesn’t ship working software. A system does.

Agile is a strategy for managing complexity. It draws on an empirical ethos to deal with uncertainty. While Agile principles support this ethos through practices like continuous delivery, frequent reflection, and embracing change, they stop short of formalising it. Agile leaves room for interpretation, which is both its power and its weakness.

Instead of prescription, Agile encourages conditions that make learning and adaptation possible:

• Deliver working software frequently.
• Reflect regularly on how to become more effective.
• Embrace change, even late in development.

This isn’t methodology. It’s operational discipline.

Behaviour Is Necessary, but Not Sufficient

Yes, agility requires certain behaviours: collaboration, openness to change, and continuous learning. But those behaviours are not the whole picture. They’re the byproducts of well-designed systems, not the system itself.

If you want teams to behave “agile,” you need to:

• Give them working CI/CD pipelines.
• Define a clear and realistic shared quality standard.
• Stop flooding them with WIP and start managing flow.
• Align work to meaningful goals with clear delivery expectations.
• Enable them to ship to production regularly and reliably.

Without engineering and system design, Agile behaviours collapse under pressure.

Engineering Practices Are the Backbone of Agility

Agile without engineering is theatre. You might have sticky notes and daily standups, but if you can’t deliver reliable, high-quality software frequently, you’re not Agile.

Here’s what engineering excellence looks like in Agile:

• Continuous Integration & Deployment (CI/CD): Small, safe, frequent releases.
• Automated Checking: Fast, repeatable validation that gives developers confidence.
• Infrastructure as Code: Reproducible environments with version control.
• Telemetry and Observability: Insight into live systems for fast feedback and debugging.
• Design for Replaceability: Modular, cohesive systems you can change without fear.

These are not “nice-to-haves.” They are foundational. If your teams can’t ship to production at regular, sustainable intervals, you’re not Agile, you’re just going through the motions.

Stop Outsourcing Agile to Coaches Who Don’t Code

A big part of the problem is that we’ve allowed Agile to be colonised by people with no engineering background. They talk about collaboration, but not architecture. They push for psychological safety, but ignore version control hygiene. They love retrospectives but can’t read a cycle time chart.

This isn’t a personal attack. It’s a call for accountability.

If you’re coaching Agile teams and you don’t understand modern engineering practices, DevOps, CI/CD, telemetry, checkability, you’re not equipped to lead agility in software.

Agile is not a therapy session. It’s not a motivational poster. It is a system of delivery designed to maximise value under conditions of uncertainty. And if we want to keep calling it that, we’d better start treating it with the rigour it deserves.

“A bad system will beat a good person every time.”

Deming’s insight isn’t a philosophical quip, it’s a brutal truth. In Agile environments, we often celebrate the heroics of individuals, when we should be interrogating the design of the system. Good people trapped in bad systems burn out, give up, or conform.

This is where Larman’s Law comes in: “Organisations are implicitly optimised to avoid changing the status quo middle-management and specialist roles, power structures and political boundaries.” It explains why many Agile initiatives fail. Not because people resist Agile, but because the system resists accountability.

Agile invites change, but organisations repel it. Instead of redesigning systems of work, they repurpose Agile into just another management fad. Sticky notes go up. Certifications get handed out. But the constraints, silos, and dysfunction remain untouched.

If your structure still depends on project gates, command hierarchies, and stage approvals, you haven’t adopted Agile. You’ve institutionalised waste.

Systems produce outcomes. Not individuals.

Want to see agility? Look at the architecture. Look at how teams form, flow, and deliver. Look at what the system makes easy and what it makes hard. If it’s easier to follow process than to deliver value, your system is broken, no matter how agile your people are.

Finally

Let’s kill the myth:

• Agile is not a mindset. It is a discipline.
• Agile is not only about behaviour. It’s about delivery.
• Agile is not a feeling. It’s a feedback-driven engineering strategy.

Agile is the deliberate design of systems that enable autonomy, accountability, and continuous delivery of value.

If you’re not delivering, you’re not Agile. Period.

There is a stubborn, Taylorist holdover in many companies, the belief that work gets done when someone is told exactly what to do. The assumption is that certainty comes from control, clarity comes from instruction, and delivery comes from compliance.

It doesn’t.

In complex systems, command-and-control is not just ineffective, it’s a bottleneck. The moment you start “assigning tasks,” you’ve already failed to design a system that enables flow, autonomy, and accountability.

You Don’t Need to Tell People What to Do in a Well-Designed System

In organisations grounded in empirical process control, leadership isn’t about orchestrating every move. It’s about creating the conditions where teams can inspect, adapt, and deliver value continuously.

Modern management is not about allocating tasks. It’s about removing the need for anyone to allocate tasks in the first place.

When teams are working against clear goals, with shared understanding, visibility of work-in-progress, and constraints that enable, not restrict, decision-making, they don’t need instructions. They need clarity, context, and trust.

Great systems aren’t static. They evolve through structured feedback loops, Sprint Reviews, Retrospectives, operational telemetry, and small experiments. Inspection and adaptation are what make systems empirical, not just idealistic.

Taylorism Is for Factories. You Run a Cognitive Organisation.

If you’re still managing by job title, project plans, and hour-counting, you’re not running a professional organisation. You’re running a factory LARP. The playbook you’re using was written for physical labour and linear processes. Not software. Not services. Not strategy.

And yet, I still see it everywhere:

• Product Managers dictating solutions instead of problems.
• “Team leads” reviewing every commit instead of enabling continuous integration.
• Managers handing out tasks like Halloween sweets and then wondering why delivery is unpredictable.

You don’t need more control. You need a better system.

Leadership Is Creating Systems That Don’t Need You

Real leadership isn’t about your presence. It’s about what happens in your absence.

This is the ethos behind Scrum, Kanban, and DevOps:

• Scrum gives you a social technology for solving complex problems adaptively.
• Kanban gives you observability of the value stream and how work flows, or doesn’t.
• DevOps ensures the loop from idea to value is short, safe, and inspectable.

Together, they form a coherent strategy for managing systems of work without resorting to micromanagement. When teams understand their constraints, have the tools to respond to change, and are accountable for outcomes, not just activity, they no longer need to be told what to do.

Speed is not the goal, but it is a critical capability. In a competitive environment, reducing time-to-market isn’t just about efficiency, it’s how organisations learn faster, respond sooner, and stay ahead of disruption. For a deeper dive into why frequent delivery is a competitive advantage, read There Is No Place Like Production .

Telling People What to Do is an Expensive Workaround

Every time you assign a task manually, you’re compensating for a failure upstream:

• Lack of a clear Product Goal.
• Incomplete or incoherent Backlog.
• Pushing work into the system until it overloads
• No service-level expectations.
• No WIP limits.
• No autonomy in the team.

You’re treating the symptom instead of fixing the system.

And let’s be honest, if you have to tell people what to do, why did you hire professionals?

Design the System. Get Out of the Way.

If your team is waiting for instructions, your system has no intelligence. If you’re managing to utilisation, your system has no flow. If your engineers are busy but not delivering, your system has no value.

Stop focusing on the people. Start focusing on the system.

Scrum is not about rituals. DevOps is not about pipelines. These are practices that expose the health of your system. And if your system requires constant intervention, it’s not a system. It’s a mess.

So stop telling people what to do. Instead, design a system where people know what to do, and have the freedom, clarity, and support to do it. Here are 10 things that you can do to augment your system:

1. Establish Intermediate & Tactical Goals

Without goals, people default to following orders or invent their own. Goals create the shared context necessary for autonomous decision-making and are the foundation for meaningful self-management.

• Action: Define a clear Intermediate Goal (Product Goal) that articulates a compelling direction over multiple deliveries, and Tactical Goals (Sprint Goals) for each delivery that anchor short-term decisions in purpose.

• How: Use Sprint Planning to make the Sprint Goal explicit and transparent. Ensure the Product Goal is visible in the content and context of the Product Backlog and re-validated during each Sprint Review. Use our Sprint Planning Recipe to get started and then adapt it as needed. Write Sprint Goals as meaningful, outcome-focused objectives that can be met incrementally. If every Sprint ends with “we worked on some tickets,” then your Product Goal is either missing, or worse, meaningless.

• Why: Without shared goals, teams wait for direction. With them, they can negotiate scope, prioritise wisely, and confidently navigate complexity. For more depth read:  The Goal – Eliyahu M. Goldratt & Jeff Cox , Measure What Matters – John Doerr , Evidence-based Management Guide

Too often, the Product Backlog becomes a list of features instead of a narrative arc that advances a meaningful goal. When you write backlog items without a Product Goal, you are setting the team up to deliver outputs instead of outcomes.

Product Goals are not aspirational fluff. They are intermediate strategic goals that define value in a complex system. When absent, the result is drift. When present, they unlock focus, flow, and accountability.

2. Enable Self-Management with Constraints

Agency without boundaries is chaos. But command-and-control masquerading as clarity is just as destructive. Real autonomy comes from deliberate constraints that define how freedom is expressed, not whether it exists.

• Action: Clarify and operationalise constraints through an explicit Definition of Workflow, and clear organisational boundaries of responsibility and accountability.
• How: Codify these boundaries collaboratively with the team; it’s their workflow. Then, create a Definition of Workflow that defines the way that work flows through their system. Don’t worry about every edge case; create based on the common case of work. This DoW forms part of your Use Working Agreements that express how the team will self-manage within organisational expectations.
• Why: Teams can’t be accountable for outcomes if they’re not authorised to choose how they deliver. But without boundaries, chaos replaces clarity. Autonomy is not abdication, it’s engineered through deliberate, negotiated constraints.

Professionalism is rooted in clear, shared expectations, delivered through disapline. A team that understands how work flows, where decisions are made, and what quality signals readiness at each stage doesn’t need micromanagement, they already operate within a system that tells them what excellence looks like.

3. Stop Misusing Estimation, Start Right-Sizing

Telling people what to build, in what order, and how long it should take kills creativity and accountability. It fragments ownership and encourages compliance over curiosity. Worse, it masks the real problem: your system doesn’t support flow, so you fall back to control.

• Action: Move away from abstract estimation rituals and fixed task assignments. Instead, introduce right-sizing practices, splitting work based on historical flow metrics like cycle time and throughput and Scatter Plot analysis.
• How: As a team, regularly review a scatter plot of your cycle times and investigate outliers to deepen your understanding of what ‘small enough’ looks like. Use that insight to reduce batch sizes where possible and provide stakeholder clarity where constraints exist. Visualise blocked or ageing work daily to keep flow visible, and use backlog refinement to slice work for predictability, not precision.
• Why: The issue isn’t estimation itself, it’s turning estimation into something it was never meant to be. Right-sizing is still estimation, just done in a simpler and more honest way. When teams right-size work to match their flow and capacity, they ship more consistently, adapt faster, and own their commitments.

Traditional estimation is often misused as a proxy for distrust or certainty in uncertain domains. When you right-size instead, grounding delivery in data and observability, you shift from permission-based planning to capability-based planning. That’s not just more efficient. It’s fundamentally more respectful of the people doing the work.

4. Introduce Pull Systems with WIP Limits

Introducing a work-limited pull system is key to understanding capacity and planning for a successful delivery . Push systems undermine accountability, responsibility, and ownership by enforcing direction from above. When teams have work pushed onto them without control or influence over the timing or readiness, their sense of ownership evaporates. This loss of autonomy directly stifles self-organisation and self-management, leaving teams disempowered and reactive.

Push systems flood teams, forcing them into reactive firefighting and constant context-switching. The focus becomes merely “showing progress” rather than genuinely delivering value. This model not only overwhelms teams but also actively erodes their ability to take responsibility for outcomes, as decisions are stripped away from those who do the work.

In contrast, pull systems enhance accountability and ownership by starting with readiness. Teams pull work into their systems only when they have the capacity, when tasks are right-sized, and when the system is genuinely ready to support the flow of work.

• Action: Implement explicit WIP limits and establish pull-based workflows at strategic, product, and team levels. Start with clear team-level WIP limits and a robust Definition of Workflow to outline readiness. Expand this discipline to portfolio and category levels, ensuring system-level flow is protected.
• How: Regularly inspect cumulative flow diagrams, throughput run charts, and ageing WIP. Use these insights to identify bottlenecks and overloaded stages. Rising ageing WIP is your signal that the system has shifted back to push dynamics.
• Why: Genuine ownership and accountability flourish when teams have autonomy over their workflow, responding to actual system conditions rather than artificial deadlines. This approach enhances predictability, reduces burnout, and creates sustainable delivery. Deadlines are met naturally as work is continuously delivered, not forced through the system.

WIP limits are not about control, they are about providing meaningful feedback. They indicate when your system reaches capacity, signaling the team to focus and prioritise effectively. Pull-based systems are essential for sustainable, predictable value delivery. If your teams constantly feel overwhelmed and lack autonomy, it’s time to recognise this as a systemic issue: your organisation is pushing rather than enabling.

5. Use evidence-based management practices

Measuring hours worked or tasks completed tells you nothing about whether the work mattered. Effort is not value. Activity is not improvement. Velocity is not progress.

• Action: Replace effort-based reporting with outcome-oriented metrics. Use the four key dimensions of Evidence-Based Management, Time to Market (TTM) , Current Value (CV), Ability to Innovate (A2I) , and Unrealised Value (UV), to inspect delivery capability and guide improvement.
• How: Start simple. Use your existing delivery tools (like Azure DevOps or Jira) to extract basic data, Cycle Time, Throughput, and Lead Time. These give you data for Time to Market (TTM). For Current Value (CV), talk to customer support, review NPS data, or run basic satisfaction surveys. To identify Unrealised Value (UV), review abandoned roadmap items, market research, or competitor offerings. For Ability to Innovate (A2I), look at how often your work is blocked, how long code sits before being merged, and how frequently you ship. Use this data in Sprint Reviews and Retrospectives to track system health, not individual effort. Bring these insights into planning conversations to anchor decisions in reality, not assumptions.
• Why: Teams that understand the outcomes of their work, how long it takes, how it impacts customers, what’s left unrealised, and where they’re blocked, are far more likely to own both the delivery and the improvement. If you want teams to care about the product, show them how it performs. Without evidence, we fall back to opinion, status, and hierarchy. With evidence, we can act with purpose.

Evidence-Based Management replaces arbitrary judgement with actionable data . It doesn’t just measure outcomes, it enables accountability for them.

6. Deploy Frequently to Production

Nothing signals trust like letting teams ship. But more than that, frequent delivery to production is the fastest path to feedback, accountability, and customer impact.

• Action: Enable teams to release a usable, production-grade increment every Sprint, including the first. This doesn’t mean a perfect product, it means a valuable step forward, hardened enough to be used.
• How: Establish CI/CD pipelines with automated quality gates (unit tests, integration checks, security scanning). Use feature toggles, dark launches, and audience-based rollout to mitigate risk. Set a working agreement that “done” means releasable. If it’s not going to production, it’s not done.
• Why: When teams ship regularly, feedback cycles shorten, risk is reduced, and decision latency collapses. They see real impact and adapt quickly. You stop debating hypotheticals and start responding to evidence. Most importantly, you stop managing perception and start managing product.

There’s no place like production . Everything else is theatre.

7. Invest in Professional Scrum Masters & Product Owners

Most Scrum Masters and Product Owners are either appointed without preparation or promoted into the role without development. The result? They don’t coach, guide, or lead, they coordinate. And when those roles fail to create clarity and enable delivery, managers step in to fill the vacuum with control.

• Action: Hire or develop Scrum Masters and Product Owners who demonstrate competence across three domains: technical fluency, business acumen, and organisational change leadership.
• How: Provide structured learning journeys that combine high quality training with hands-on mentorship from experienced practitioners. Assess candidates or internal staff on their ability to enable delivery systems, not just facilitate meetings or write stories. Require evidence of contribution to system improvement, cross-team alignment, and customer impact.
• Why: Competent SMs and POs anchor the Scrum Team in purpose and delivery. The Scrum Master builds capability, encourages flow, and fosters empiricism, and modern engineering practices. The Product Owner sets the tone for product leadership and modern product development practices. When these roles function well, the team no longer needs daily direction from management, because the system is aligned, and delivery is deliberate.

Scrum Masters are not passive facilitators. They are system stewards, accountable for enabling transparency, optimising flow, and coaching both teams and managers to operate within an empirical system. If they’re not improving the system, they’re part of the dysfunction. If you want to understand what separates a competent Scrum Master from a glorified coordinator, read Why Most Scrum Masters Are Failing, and What They Should Know .

The problem isn’t Scrum. The problem is that we keep filling these roles with people who aren’t ready or worse never will be. Raise the bar, or get out of the way.

8. Collapse Siloed Structures

Separate roles create handoffs, and handoffs create dependency . Dependency creates delay. Delay kills flow.

• Action: Form cross-functional, preferably longer-lived teams with full accountability for discovery, delivery, and validation.
• How: Restructure teams so they include the skills necessary to take work from idea to production: business analysis, UX, engineering, QA, and operations. Co-locate (physically or virtually) these disciplines inside a single team and ensure they share the same Sprint cadence, goals, and delivery responsibility. Use the Definition of Workflow to clarify interaction points and shared responsibilities within the team and eliminate those outside it. Audit each department and reassign specialists to teams where they can contribute continuously, not sporadically.
• Why: You can’t ask for autonomy while forcing work through stage-gated departments. Real teams don’t wait for someone else to finish, they swarm. They co-create. They ship. When you eliminate silos, you eliminate the excuses that justify command-and-control. What’s left is a team that owns its outcomes.

Structure should follow flow, not function. Organise around value creation, not roles. That’s how you collapse the gap between intent and impact.

9. Use Sprint Reviews for Stakeholder Alignment

Sprint Reviews aren’t demos. They’re not a PowerPoint parade or a status update. They are working sessions with stakeholders, strategic checkpoints to make decisions based on what we’ve learned.

• Action: Use Sprint Reviews to inspect the working increment, review delivery data (T2M, CV), gather market feedback, and adapt the Product Backlog collaboratively with stakeholders present.
• How: Set the expectation that each Sprint Review includes real stakeholders, not just internal roles. Open with a restatement of the Product Goal and the Sprint Goal. Show working software, not slides. Invite feedback that informs priority and scope decisions. Use evidence, customer feedback, analytics, cycle time charts, to frame the discussion. End with a shared agreement on what’s next and update the Product Backlog live.
• Why: Involving stakeholders early and often surfaces assumptions, shortens feedback loops, and reduces the need for managers to chase status. It shifts product delivery from projection to inspection. When everyone sees the same data and the same increment, there’s no room for spin. There’s just the truth, and the next step.

10. Teach Managers to Serve Systems, Not Direct People

Managers clinging to authority are a bottleneck. They inject delay, decision paralysis, and unnecessary oversight. If you’re telling people what to do every day, you’re not leading, you’re throttling flow.

• Action: Shift managers away from individual oversight and toward system stewardship. Equip them to visualise flow, reduce friction, and amplify team autonomy.
• How: Train managers to read and act on delivery metrics, cycle time scatterplots, cumulative flow, WIP ageing. Introduce them to the constraints that enable team performance: WIP limits, service-level expectations, clear definitions of workflow. Encourage regular system health checks, where are delays? What blockers repeat? Where are policies implicit when they should be explicit? In retrospectives, ask managers not “who failed?” but “what failed in the system?”
• Why: You don’t scale impact by managing more people. You scale it by creating an environment where people don’t need to be managed. When managers see themselves as designers of flow rather than allocators of effort, the entire system becomes more resilient, more responsive, and more humane.

This isn’t about abdicating control . It’s about relocating it into the system where it belongs.

How Does the Agile Manifesto Relate?

While the Definition of Done is specific to Scrum, its essence connects directly to the values and principles of the Agile Manifesto. The manifesto doesn’t define a DoD explicitly, but it demands working software as the primary measure of progress and calls for continuous attention to technical excellence and good design. These principles implicitly require teams to set and meet clear standards of completeness and quality.

In Agile, “Done” is characterised not by formal documents or bureaucratic sign-offs but by tangible, working outcomes. The focus is on delivering increments of value that are potentially shippable, ensuring continuous feedback, and maintaining sustainable pace. This spirit is what Scrum formalises with its Definition of Done: an explicit, transparent commitment to what quality means, grounded in Agile’s broader ethos of delivering working software and embracing change.

Why Define Done?

The Definition of Done is not optional. It is the shared understanding that tells everyone , Developers, Product Owner, stakeholders , what quality bar each increment must meet to be considered usable, releasable, and valuable. Without it, you deliver chaos disguised as agility.

If your organisation has no defined standards, your team must create its own. But let’s be blunt: if you have multiple teams on one product, they must align on a shared Definition of Done. No excuses, no fragmentation. Without this alignment, you jeopardise integration, delivery, and the product’s reputation.

“The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.” , Scrum Guide 2020

Done Means Releasable

Done is not about user stories, requirements, or business value. It is about whether the increment is in a state that the Product Owner can say, “Yes, let’s ship it.” No hidden work, no deferred testing, no “we’ll fix it later.”

A robust Definition of Done ensures:

• Transparency on what’s been completed.
• Predictability in delivery.
• Shared accountability for quality.
• Protection of the product’s and organisation’s reputation.

Start with a Seed, Grow It Over Time

Your DoD does not need to be perfect on day one, but you do need to start. Run a facilitated DoD workshop. Involve the Scrum Team, relevant stakeholders, and anyone representing critical gates like security, architecture, UX, and compliance. Define what “Done” looks like across four layers:

1. Organisational DoD – minimum standards to protect reputation and compliance.
2. Practice DoD – engineering or discipline-specific standards (e.g., security, performance).
3. Customer DoD – any client-specific requirements.
4. Team DoD – additional agreements the team needs to deliver quality.

Without this clarity, you’re not managing risk; you’re just rolling dice.

Characteristics of a Strong Definition of Done

• Short, measurable checklist , automate verification wherever possible.
• Mirrors shippable , the Product Owner should have the option to ship at the Sprint Review (if not doing continuous delivery).
• No further work required , if additional work is needed, you weren’t Done.

This is not subjective. “Approved by the Product Owner” is not a DoD item. The DoD is an objective, verifiable standard.

Examples of DoD Items

Here’s what good engineering practices might embed:

• Code passes automated quality checks (e.g., SonarQube) with no new critical issues.
• Unit, integration, and acceptance tests are automated and pass.
• Security scans run in CI/CD pipelines and show no high-severity vulnerabilities.
• Documentation is updated and linked to the increment.
• Code reviews or pair/mob programming sessions completed.
• Automated deployment pipelines confirm repeatable, error-free delivery.

Continuous Reflection and Improvement

Your DoD is not static. You must review and improve it continuously , at least every Sprint Retrospective. When you uncover new failure points, you integrate them into your DoD.

If your increment no longer meets the quality bar, stop Sprinting. Fix the foundation first , that’s called a Scrumble. It’s a deliberate pause to repair quality, not a failure. Once resolved, your DoD should evolve to prevent recurrence.

Practical Steps

1. Run a DoD Workshop , include Developers, Product Owner, stakeholders, and relevant experts.
2. Document and Share , make the DoD visible, accessible, and owned by the team.
3. Automate , reduce human error by automating checks wherever feasible.
4. Review Regularly , build DoD reviews into retrospectives.

Final Word

The Definition of Done is not bureaucracy. It’s the backbone of your Scrum implementation. Without it, you don’t have empirical process control; you have chaos. Without it, you can’t deliver continuous value; you deliver continuous risk.

Professional Scrum Teams are accountable for quality. Own it. Define it. Evolve it.

Always ask: “Would you be happy to release this increment to production and support it? You are on call tonight.” If the answer is no, it’s not Done.

Too many organisations frame capacity as “how many hours does each person have?” or “how many tasks can we assign this sprint?” They fall into the trap of breaking complex, systemic work into artificial personal quotas, focusing on individual loading rates instead of collective flow. This leads to managers obsessing over how ‘utilised’ each person is, mistaking busyness for progress. Teams become overloaded with microtasks, pulled into multitasking, and lose sight of flow efficiency and value creation. This mindset traps them in local optimisations, overload, and multitasking chaos. Everyone looks busy, but value delivery crumbles. Deadlines slip, work piles up, and predictability collapses.

We need to shift from individual task-level tracking and micromanagement to managing the system of work.

Three Levels of Capacity Planning: Strategic, Category, Team

Effective capacity planning happens at three distinct but connected levels: portfolio (strategic), category (product or business unit), and team (execution). Each level has its own constraints, its own levers, and its own accountabilities. If you blur these levels, you end up with local optimisations, overloaded systems, and unpredictable delivery. If you handle them deliberately, you enable scalable, reliable flow across the entire organisation. This post lays out what matters at each level, where most organisations fail, and how to focus on the right system levers to improve predictability and value delivery.

Portfolio Level (Strategic)

At the portfolio level, individual capacity is irrelevant. Portfolio-level delivery is not the sum of people’s hours or team headcounts. It is about the system’s ability to progress and complete major initiatives across the organisation.

Traditional project management has well-established strengths , especially in controlling scope, budget, and schedule , but repeatedly makes the same flawed assumptions when applied to complex, system-wide delivery. To connect better, we should acknowledge where traditional methods excel and then explain why they hit limits at scale or in domains like software engineering, where variability and complexity cannot be fully controlled. It assumes that if you know how many people you have and how many hours they can work, you can calculate how many projects you can run. It treats capacity as a static sum of people, ignoring system dynamics like waiting times, handoffs, coordination overhead, and priority collisions. It assumes that by assigning people to projects and filling calendars, you maximise delivery. In reality, you simply increase work in progress, dilute focus, and create organisational thrashing.

Flow-based, lean thinking demands a different focus. The real constraint at portfolio level is not team speed. It is how many initiatives the organisation can meaningfully progress in parallel before bottlenecks, cross-team dependencies, or funding constraints stall progress. This speaks directly to Lean’s core emphasis on optimising the system as a whole, not optimising local team measures. As Deming stressed, managing parts in isolation leads to suboptimisation , the real improvement comes when leadership steps back and improves the flow and constraints at the system level. It is about how efficiently the system moves work across teams, products, and functions, independent of how busy individuals are.

Tracking individual capacity at portfolio level leads to local optimisation and wastes effort. Managing portfolio-level WIP, cross-team flow, and initiative-level progress gives you real, actionable capacity insight. Trying to map individual team throughput directly to portfolio delivery without addressing cross-initiative coordination, system WIP limits, or systemic blockers is a guaranteed failure.

Specifically, leaders fall into the trap of believing:

• That if every team improves throughput, the portfolio improves – false.
• That we can just sum team metrics to get total portfolio capacity – false.
• That we can ignore portfolio-level WIP and still forecast accurately – false.

The shift required is from “how many hours can we extract from people” to “how much value can the system deliver, predictably, given its real constraints.” This is why traditional project management fails at scale. It looks down at tasks and people when it should be looking up at systems and flow.

Category Level (Product / Business Unit)

At the category level, the biggest mistake is assuming you can simply roll up individual team flow metrics to understand category capacity, without managing cross-team dependencies, shared bottlenecks, or category-level WIP.

Why is this wrong?

Teams within a category rarely operate in isolation. They share architectures, platforms, specialists, and decision-makers. Even if each team shows good local flow, the category’s overall delivery can be blocked by cross-team dependencies, shared capacity limits (such as UX, security, or operations), or coordination overhead (like release alignment or integration cycles).

Traditional thinking assumes category performance equals the sum of teams’ performance. In reality, category performance is governed by the speed of the slowest shared bottleneck and the organisation’s ability to coordinate across flows.

What needs to shift:

• Apply category-level WIP limits on how many initiatives or epics are in play across all teams.
• Focus on improving cross-team flow and dependency management, not just local team throughput.
• Measure flow across the value stream, not within isolated team swimlanes.

The mistake is failing to treat the category as an interconnected system. Local team improvements mean little if the category’s delivery is constrained by systemic coordination, shared services, or unmanaged WIP.

Team Level (Execution)

The core mistake at the team level when moving to flow metrics is assuming that flow metrics like throughput or cycle time are just “better tracking” of individual performance, rather than system-level indicators of work preparation, flow, and blockers.

Why is this wrong?

Traditional teams apply flow metrics to individuals, asking: “How many tasks did you finish?” or “What’s your personal throughput or cycle time?” This creates local pressure, gaming, and false signals because flow metrics were never designed to evaluate individuals. They measure how well the team system moves work end-to-end.

Teams also often skip the upstream preparation work, thinking that flow metrics alone will fix predictability, without addressing key conditions:

• Right-sizing work
• Defining clear pull-ready conditions
• Setting and respecting WIP limits

What needs to shift:

• Treat flow metrics as team-level health signals, not personal performance measures.
• Focus on improving system conditions , work size, WIP, and dependencies , to improve flow, not squeezing people for more.
• Use metrics to guide improvement conversations, not to monitor or punish individuals.

The mistake is misapplying flow metrics as individual productivity tools instead of using them to improve team system flow. Without addressing preparation, WIP, and collaboration, adding flow metrics just creates new reporting noise.

What needs to change

The shift from individual capacity thinking to system-level flow demands disciplined, pragmatic changes across the organisation. This is not a matter of adding a few charts or running reports , it’s a change in ethos. It is about treating capacity as an emergent system property, not a mechanical sum of parts.

Focus on Throughput, Lead Time, and Efficiency

Rather than fixating on individual or team utilisation, shift your measurement to system-level flow. Pay attention to:

• The number of items completed per sprint or delivery cycle (noting this assumes work items are similarly sized; otherwise, throughput comparisons can be misleading).
• The average lead time from work start to completion, helping reveal system bottlenecks and delays.
• Process cycle efficiency (PCE): the proportion of time work actively moves versus all non–value-adding activities (not just waiting), exposing inefficiencies across the system. This includes unnecessary committees, bureaucratic processes, and other activities that exist only to service themselves rather than delivering value.

The goal is not to ask, “Who can take on more?” but to ask, “What does our system reliably deliver, and how can we improve flow without overburdening people or teams?”

Stop Misusing Estimation, Start Right-Sizing

Stop wasting time trying to predict perfect effort estimates.

Instead, apply the Lean principle of reducing variability and batch size, using queuing theory to improve system flow. But be clear: software engineering lives in the complex domain, not the clear or complicated domain where variability can simply be engineered away. We cannot eliminate variability entirely, but we can reduce unnecessary variability by defining a clear definition of workflow, supported by approaches like One Engineering System (1ES) and platform engineering. These strategies help standardise and stabilise the environment, tools, and pipelines , leaving only the unavoidable, context-driven variability that belongs to the real problem space.

To right-size effectively:

• Break work into small, similarly sized, meaningful slices that fit smoothly through your system.
• Focus on cutting work to a shape the system can absorb predictably , not wasting time on abstract story points or inflated complexity debates.
• Use historical throughput and cycle time data to calibrate what ‘small enough’ looks like in practice, not in theory.
• Make right-sizing part of your working agreements and backlog preparation, ensuring teams only pull work that meets clear, shared readiness standards.

The issue isn’t estimation itself, it’s turning estimation into something it was never meant to be. Right-sizing is still estimation, just done in a simpler and more honest way. This is not about squeezing people harder; it is about designing a steady, sustainable system where predictability is built directly into the shape and handling of the work.

Apply WIP Limits and Enforce Pull

Stop treating WIP limits as a mechanical cap or a reportable metric. They are a deliberate, disciplined strategy to protect system flow and predictability. Set clear limits on how many initiatives, epics, or stories are in play , not on how many tasks an individual can juggle. Once the system reaches its limit, stop adding work. Enforce pull: nothing new enters until capacity is truly available. Multitasking is toxic; kill it without hesitation. This is not about pushing people harder; it’s about designing the system so work flows cleanly and teams can focus, finish, and deliver predictably.

Forecast With Empirical Data

Stop pretending forecasts are about precision. Forecasting is about understanding what the system consistently delivers and using that to set realistic expectations, with the important caveat that this relies on the assumption of a relatively stable system, as Lean approaches depend on system stability for predictability. This also means recognising how system constraints align with legal mandates, statutory requirements, and interdepartmental dependencies , especially in public sector or regulated environments where external obligations shape the boundaries of what can be delivered and when. If your teams typically deliver 6–8 items per sprint, then forecast 6–8 , no sandbagging, no overpromising, no wishful thinking. Use past variance to shape your delivery ranges and confidence levels. Forecasting is not about heroic assumptions; it is about respecting the boundaries of what your system can actually achieve. Teach leadership that predictability comes from protecting system health, not demanding unrealistic outputs or pushing teams beyond sustainable limits.

Monitor Flow Health Holistically

Flow health is not just a dashboard; it is the living pulse of your system. Go beyond counting throughput and look deeper:

• Rising cycle or lead times , these are your early-warning signals of hidden bottlenecks creeping into the system (and, as noted earlier, low PCE includes more than just waiting , it also covers other forms of systemic waste and non–value-adding activities).
• Aging WIP , when work lingers without progress, it is a red flag that something is stalled or blocked.
• Low PCE , when too much time is spent waiting instead of progressing, it signals waste accumulating across the system.

These are not vanity metrics. They reveal how your system is truly performing, regardless of how full calendars look or how busy people appear. Build regular inspection of these health indicators into your operating rhythm. Use them not for blame or micromanagement, but as fuel for system-wide conversations: Where is flow breaking down? What needs to change? Where can we intervene to unblock, simplify, or improve?

Healthy flow is not a side effect; it is a deliberate, ongoing outcome you must design, monitor, and continuously tune.

The change is not cosmetic , it’s a fundamental rethink of how you approach planning, forecasting, and delivering across all levels of the organisation.

The Role of Leadership

Leadership is not about control or oversight; it is about creating the conditions where teams and systems can thrive. Lean leadership models humility, removes systemic obstacles, and relentlessly focuses on delivering customer value, not just improving internal measures. Leaders must step back from the temptation to manage individuals and instead take accountability for enabling the system of work. That means:

• Enabling true autonomy at the team level, giving teams the space to own their work and delivery, without micromanagement.
• Actively protecting WIP limits and pull discipline across the system, even when external pressures or senior stakeholders demand more.
• Investing in backlog refinement, right-sizing, and preparation so that teams pull only well-shaped, high-value work , and have the capacity to deliver it predictably.
• Focusing measurement on system health , time-to-market (TTM), process cycle efficiency (PCE), throughput, and lead time , not individual utilisation, heroics, or busyness.

Leaders are accountable for creating an environment where flow is deliberate, predictable, and sustainable. This is not about pushing people to work harder; it is about tuning the system so teams can focus, collaborate, and deliver value without unnecessary friction or disruption. True leadership means enabling the system, not extracting from the people.

Reframing the Conversation

Lean capacity planning reshapes how we think about delivery, focus, predictability, and most critically, continuous learning and relentless improvement , the true core of Lean thinking.

Stop asking, “How many tasks or hours can we assign?” Start asking, “How much value can the system deliver, at what lead time, and with what efficiency?”

If you’re not measuring system health indicators like PCE or TTM, you are flying blind.

This is not about making teams go faster. It is about creating smarter, healthier flow. Get the fundamentals right, and you unlock sustainable, reliable delivery that serves both your customers and your organisation.

A topic branch is a short-lived, focused branch in your source control repository that isolates a single unit of developer work. This is not a month-long feature branch. This is not “we’ll merge it someday” work. A topic branch is something you code, test, and integrate in a few hours or, at most, a couple of days.

The moment your topic branch stretches beyond a few days, take it as a warning:

• Integration will get harder.
• Merge conflicts will multiply.
• Your risk of defects or unintended behaviours will spike.
• Reviewing and validating costs more

If you let a branch sit for too long, you are building up integration debt that will bite you later. Topic branches, and thinking about them as just that, topics, is an essential practice in modern software engineering.

The Strategic importance of Topic Branches

We want to consistently emphasised the importance of technical practices that enable flow, adaptability, and resilience in software teams. Whether addressing trunk-based development, continuous delivery , or engineering excellence , the message remains the same: discipline in the small enables success in the large. Topic branches fit directly into this pattern. They are not just a coder habit; they are a deliberate tool that reinforces modularity, integration, and continuous feedback, all cornerstones of modern software delivery.

From a technical leadership perspective, topic branches are pivotal because they enable:

• Modularity , you isolate changes to a narrow scope.
• Continuous delivery , you keep the mainline ready for release.
• Clear code reviews , you limit pull requests to atomic, understandable units.
• Collaborative accountability , the team shares responsibility for integrating small changes frequently.
• Support for agile development practices , you align technical work with the team’s tactical Sprint Goals and Product Goals.

Without topic branches, you create a fragile system of work. Without topic branches, you make integration harder. Without topic branches, you slow down your delivery pipeline and increase the chance of failure.

Practical Patterns for Tactical Implementation of Topic Branches

Building on the strategic importance we need actionable patterns that technical leaders and teams can apply. It is not enough to understand why topic branches matter; you need pragmatic, grounded approaches that translate strategy into engineering practice. For most teams and most projects, GitHub Flow (the branching model, not the cloud tool) is the most effective model. It is a trunk-based model with minimal overhead and complexity. GitHub Flow treats the main branch as the production-ready line and uses small, short-lived topic branches for all work.

You branch off main, do your small unit of work, push frequently, and merge back as soon as possible , ideally the same day, or next day at the latest. Your branch is:

• Focused on a single task or issue.
• Continuously tested (locally and via CI).
• Reintegrated quickly to avoid drift.
• Reinforces context disapline

If you have a larger application with more engineers and the need to make changes in the production line, then Microsoft’s Release Flow, which is almost identical to “Github Flow” with the addition of a versioned release branch. One could say that  Release Flow inherits and extends Github Flow.

Compare this to the traditional Git Flow approach that models less mature braching stratagies, which adds layers of feature, develop, release, and hotfix branches. While Git Flow can still be useful in some legacy or non-continuous delivery setups, it introduces far more overhead and complexity. It reflects a strategy from the pre-CD world.

Gitflow Flow, and its derivatives, simplifies this: fewer long-lived branches, fewer merge headaches, more emphasis on incremental delivery.

Leading change through Branching Stratagy

If you are leading a team, the presence or absence of disciplined topic branching tells you a lot.

• Short-lived topic branches = a team practising modularity, integration, continuous feedback, and accountability.
• Long-lived feature branches = a team accumulating integration risk, delaying delivery, and likely violating agile principles.

You need to push the team to keep branches small, focused, and short-lived. Review your branching strategy regularly. Make sure it supports, not undermines, your goals of flow, agility, and quality. And above all make sure its clear what each branch is for and how it should be used.

If your team is struggling with long-lived branches, get serious:

• Introduce trunk-based development practices with GitHub Flow or Release Flow.
• Enforce limits on branch lifespan.
• Tighten your CI/CD loops.
• Teach your team the cost of integration delay.

Remember: your branching strategy is not just a technical choice. It is a critical enabler of continuous value delivery .

If your automation strategy looks something like this:

• Manual SQL deployments from someone’s laptop
• Azure Pipelines building unversioned assemblies
• Manual deployment to dev and test environments
• TeamCity rebuilding new unversioned assemblies
• Octopus Deploy is deploying from Team City to staging and production
• Selenium tests running on a black-box scripted node that only one person monitors

You’re not building a product. You’re building chaos. You’re not scaling a team. You’re scaling dysfunction.

Fragmentation Is Not an Engineering Strategy

When every team uses a different deployment tool, stores secrets in a personal vault, and runs tests on unmonitored boxes, you’ve created a system that no one understands and no one can change safely.

This isn’t flexibility. It’s fragility.

Fragmentation leads to duplication of effort, inconsistent results, increased cognitive load, and slower delivery. You waste time debugging pipeline differences instead of building product value. And every deviation from a shared system adds risk to quality, security, and compliance.

Engineering excellence comes from enabling consistency where it matters, creating common foundations that support autonomy without sacrificing reliability. It comes from designing systems that are observable, changeable, and resilient, systems that empower teams through clarity, not confusion.

This kind of fragmentation also violates the core ethos of DevOps : continuous delivery of value through the union of people, processes, and products. If your toolchain is stitched together by tribal knowledge and Slack messages, you’re not enabling flow. You’re creating friction.

DevOps Is Not Tooling. It’s Feedback, Flow, and Learning

DevOps isn’t a toolkit war. It’s the discipline of enabling feedback, flow, and continuous learning across the entire product lifecycle.

• It’s about amplifying feedback loops, build, test, and release systems that surface issues early and often.
• It’s about enabling flow, removing friction between commit and customer, reducing handoffs and rework.
• It’s about fostering learning, capturing telemetry, responding to incidents, and improving from every iteration.

DevOps without visibility is cargo cult. DevOps across disconnected systems is just automation theatre. And DevOps without learning is just technical debt in fast-forward.

Building One Engineering System (1ES) through Platform Engineering

If DevOps is the ethos, then Platform Engineering is the strategy, and One Engineering System (1ES) is the execution model.

Platform Engineering is not just infrastructure automation. It’s a practice grounded in DevOps principles that aims to improve every development team’s time-to-value, compliance, cost control, and security through improved developer experiences and governed self-service. It’s both a mindset shift and a system of reusable tools and services.

Platform Engineering teams build and evolve Internal Developer Platforms (IDPs), paved paths that reduce cognitive load, eliminate manual gates, and guide teams safely toward production.

These platforms:

• Help developers be self-sufficient (e.g. starter kits, templates, IDE integrations)
• Encapsulate patterns into reusable services
• Automate security and compliance checks
• Streamline operations and infrastructure management

1ES, pioneered at Microsoft, embodies this by unifying:

• Azure Pipelines for end-to-end CI/CD
• Azure Repos , Boards, and Artifacts as a single source of truth
• Infrastructure as Code, Policy as Code, and integrated telemetry

The result: a secure, observable, scalable system where guardrails are built in and teams can move fast without creating risk.

No handoffs. No tool silos. No black-box deploys. One path from idea to production that every team and every skillset contributes to.

You may be thinking that “this breaks self-management” and the agency of the teams. But self-management in Agile doesn’t mean chaos. Scrum Teams don’t self-manage in a vacuum, they operate within the boundaries defined by the organisation. Self-management means giving teams the autonomy to solve problems within a clearly defined system of constraints. That system of constraints, your engineering boundaries, your compliance requirements, your platform capabilities, is your Platform Engineering strategy, and your 1ES is your implementation of that strategy. It defines what good looks like. Those boundaries must be engineered and not left to tribal knowledge. If you want consistent results, define the edges and let the teams operate freely within them.

Consolidate. Standardise. Enable.

If you want scale, you must design for it. That means:

• One build system.
• One deployment path.
• One way of managing secrets, tests, telemetry, and deployments.

Azure Pipelines is capable of it all. With templates, approvals, gates, agents, deployment groups, and environment strategies, everything you need to build a 1ES-style delivery platform is already there. Yes, there are other tools, but if you are already rooted in the Microsoft stack, then these purpose-built tools fit like a glove.

Stop spreading your delivery process across half a dozen tools with no visibility. Pick a platform. Make it great. And let your teams focus on product, not plumbing.

Engineering excellence isn’t about choosing the coolest tools.
It’s about building a system of work that enables every team to deliver safely, sustainably, and continuously.

Stop optimising for familiarity. Start optimising for flow.

Treating these two forms of agency as equivalent is not just careless; it is dangerous. It leads to brittle systems that optimise yesterday’s decisions while failing to recognise when the game has changed.

When we talk about human agency, we are speaking about strategic intent , the setting of direction, the framing of purpose, the shaping of hypotheses, and the stewardship of ethical, political, and systemic choices that no model or algorithm can or should automate. AI agency, by contrast, is about tactical optimisation , rapid experimentation within bounded parameters, local improvements, efficiency gains, and the relentless pursuit of better tactics without changing the fundamental strategic frame.

Put simply: AI optimises inside a system. Humans adapt and redefine the system.

Mapping Agency to Adaptive Systems

In professional practice, I map human agency and AI agency to different layers of decision-making:

The strategic layer demands human discernment because it must constantly negotiate ethical trade-offs, respond to uncertainty, and reset direction as new information emerges. Tactical layers benefit from AI’s raw speed, capacity for pattern recognition, and ability to handle enormous volumes of data. There is synergy, but it is not a partnership of equals. Humans govern; AI serves.

  
flowchart TD
A([Decision Point]) --> B{Is strategy or purpose changing?}
B -- Yes --> H[/"Human Agency"/]
B -- No --> C{Is ethical or political judgement required?}
C -- Yes --> H
C -- No --> D{Is the problem fully bounded and optimisable?}
D -- Yes --> AI(["AI Agency"])
D -- No --> H

style H fill:#f9f,stroke:#333,stroke-width:2px
style AI fill:#bbf,stroke:#333,stroke-width:2px


  

The Risks of Overdelegating Adaptation

Organisations that overdelegate adaptive work to AI systems are not buying efficiency; they are actively sabotaging their future relevance. The risks are not hypothetical; they are immediate and compounding:

1. Collapse of Strategic Sensing

Adaptive systems are grounded in weak signal detection, hypothesis-driven exploration, and the willingness to be wrong and change course. AI, by its nature, is trained on existing data distributions and past patterns. It cannot, on its own, identify when the landscape has fundamentally shifted. Blindly optimising yesterday’s patterns only accelerates strategic obsolescence.

2. Fragility under Complexity

AI systems operate well under known constraints but become brittle in the face of novel complexity. When the operating environment changes outside the model’s training range , as it inevitably will , organisations that have outsourced strategic sensing and adaptation will fail catastrophically and rapidly, long before any dashboard or model warns them.

3. Erosion of Human Accountability

When critical adaptive work is offloaded to AI, responsibility becomes diluted. Who is accountable for outcomes? Who owns ethical consequences? If decision-making collapses into model outputs without human interrogation, the result is not augmented intelligence; it is abdicated leadership .

A Pragmatic Approach to Human-AI Collaboration

To work responsibly with AI in adaptive systems, organisations must operationalise clear agency boundaries:

• Humans are accountable for strategic direction, purpose setting, and system definition.
• AI is responsible for tactical optimisations within clear, human-defined parameters.
• Human intervention is mandatory at all escalation points where adaptation is required.

This boundary is not a theoretical construct; it should be a live operational discipline embedded into system design, governance practices, and escalation frameworks.

Optimisation without adaptation is a recipe for irrelevance.
Adaptation without optimisation is a recipe for chaos.
Only through disciplined agency boundaries can we achieve resilient, continuously evolving systems.

Final Thought

In the rush to automate, organisations must resist the seductive but dangerous myth that AI can replace human agency in complex adaptive environments. AI optimises, but it does not adapt. It cannot perceive new purpose. It cannot lead. It cannot be held accountable.

Strategic intent, adaptive reframing, and ethical stewardship remain irrevocably human domains.

Those who forget this are not merely inefficient.
They are obsolete in the making.

If you’re still writing business logic in SQL Stored Procedures, it’s time to stop. If you still have code that stores business login in  SQL Stored Procedures its time to refactor!

I’m not saying rewrite everything at once. That would be ridiculous. It’s a massive cost with no direct stakeholder value. What I am saying is this:

From this point forward, stop creating new business logic in stored procedures.

And when you must change one, refactor that logic out into testable, mockable, maintainable code.

This is not about doing everything at once!

Take inspiration from the Azure DevOps team. When they decided to eliminate their suite of brittle, long-running system tests, they didn’t try to replace them in a single sprint. It took them four years of consistent work, in three-week sprints, to fully remove and replace those tests with something better. One step at a time. That’s what change looks like.

Break the cycle of adding more mess to the mess. Every stored procedure you don’t write is a future bug you won’t have to debug in production. Every time you choose code over SQL for business logic, you’re reclaiming control of your system.

Stored Procedures are the wrong place for Business Logic

Let’s be clear: this isn’t an abstract architectural debate. The reasons stored procedures are a bad place for business logic are grounded in hard-learned lessons from real teams, real outages, and real maintenance headaches. If you’re serious about engineering excellence , you need to treat stored procedures as a legacy constraint, not a strategic tool.

1. They can’t be tested properly - You need a full database instance with seed data. You need to run a slow test harness. There’s no mocking, no fast feedback, no isolation. If it can’t be unit tested, it can’t be trusted. Long-running system tests do not tell you if the code works, only that the long-running system tests that you created work.
2. They don’t participate in CI/CD - Stored procedures are almost always deployed manually or via fragile SQL scripts. While it can be automated by things like Redgate, it’s often still brittle, breaks reproducibility, and blocks automated pipelines.
3. They aren’t version-controlled like real code - While you can have them under source control, they are “copied” into source control... either by Readgate or manually by a developer. Manual tasks are risky! Remember the Knight Capital Group!
4. They tightly couple your logic to the database - That kills portability and locks you into a specific database engine. It also makes testing, debugging, and observability painful. There have been attempts in the past to create “Unit Tests” for stored procedures, but they have largely been abandoned in favour of just getting our logic out of that scenario.
5. They don’t scale - Stored procedures run on the most expensive, least scalable part of your infrastructure: the database server. Business logic belongs in services that can scale out.
6. They violate the separation of concerns - Your database should store and retrieve data. Your application should handle logic. Stored procedures blur that line and create a big ball of mud.
7. They’re hard to reason about - No dependency injection. No composition. No mocking. No telemetry. No proper logging. Just deeply procedural code with limited tooling support. If you have to rely on a debugger to see if your code works, you are doing it wrong.

Before you write the next line of business logic in a stored procedure, ask yourself: is this something I want to debug at 2am with no tests, no telemetry, and no rollback plan?

That’s the reality of stored procedures. They make every part of your engineering practice harder. Get the logic out. Put it where it belongs, alongside the rest of your tested, observable, maintainable code.

The strategy: don’t rip, refactor

You don’t need permission to start this. You don’t need a project. You just need a commitment to modern engineering discipline:

• When you build new features, do it in application code, not SQL.
• When you touch an existing stored procedure, refactor it. Move the logic into testable code.
• Leave a thin wrapper if necessary, but relocate the behaviour.

This is a pay-as-you-go modernisation strategy. It lets you progressively reduce technical debt without halting delivery.

The benefits are compounding.

Every time you refactor, you:

• Increase the ability to create unit tests
• Improve maintainability
• Enable faster feedback loops
• Reduce runtime costs
• Shrink the surface area for bugs
• Move toward continuous delivery

No single change flips the system. But every change you make is a step away from the fragile procedural past and toward a sustainable engineering future.

The outcome?

This isn’t about dogma. It’s about discipline. Modern software development demands testability, traceability, observability, and scalability. Stored procedures give you none of that.

If you’re maintaining logic in stored procedures, you’re fighting your tooling, your pipeline, and your team. Stop doing that.

Start small. Move incrementally. Raise the bar.

Modern software is built in code, not SQL.

If your developers do not have operational agency, control over environments, deployments, telemetry, and remediation, you are not doing DevOps.
You are automating fragility.

There Is No Place Like Production

We have already established that production is the only place real feedback happens . UAT, staging, demo environments, none of these reveal how real users behave, where real bottlenecks emerge, or where real pain points lie.
Real outcomes, real telemetry, and real consequences only happen in production.

If developers do not have operational authority over production, they are blindfolded. They can build, but they cannot learn. They can deploy, but they cannot observe. They can script, but they cannot improve.

Without production feedback, Continuous Delivery collapses into Continuous Guessing.

Automation without Agency is Fragile

Most so-called “DevOps transformations” fail because they stop at tooling. They build beautiful pipelines that developers cannot influence. They deploy artifacts that developers cannot monitor.
And when something goes wrong? They are forced to raise a ticket to an ops team who barely understands the context of the change.

This is organisational malpractice.

Automation is not enough.
Pipelines must be developer-controlled.
Environments must be developer-managed.
Telemetry must be developer-owned.

If your developers are second-class citizens in your own delivery ecosystem, you are manufacturing helplessness at scale.

Operational Agency Is Non-Negotiable

True DevOps demands that developers have operational agency, including:

• Deploy to production anytime – without raising a ticket, without scheduling a “release train,” without begging for a window.
• Own telemetry – define, collect, and act on usage, performance, and error data directly from production.
• Roll back or forward – respond to incidents with speed and autonomy, without waiting on a change advisory board.
• Observe and adapt – monitor real user behaviour and adapt deployments and product strategy based on live signals.

This level of ownership must also be reflected in your Definition of Done , ensuring that telemetry and operational readiness are part of what it means for work to be complete.

Agency without feedback is noise.
Feedback without agency is paralysis.
You must have both.

DevOps Without Operational Agency Is Dead on Arrival

Every time you separate developers from operational decision-making, you break the feedback loop. You turn “continuous” delivery into ceremonial delivery.
You destroy agility . You disempower your people. You institutionalise blame instead of learning.

If you want real DevOps, you must give developers real control.

Yes, this requires real trust.
Yes, this demands real engineering maturity.
Yes, this will expose the weaknesses you have been hiding behind process theatre.

But the alternative is worse: a hollow shell of DevOps, where the only thing “continuous” is your excuses for why it still takes six months to learn whether your features work.

Real resilience is not about having good people with pagers. It is not about heroes. Heroes emerge when systems lack resilience. They hoard work, avoid transparency , and justify cutting corners by claiming they are “doing whatever it takes.” In reality, they introduce silent risks, undermine teamwork, and erode quality standards.

If your resilience depends on a hero, you are not resilient. You are vulnerable and you just have not been exposed yet.

Resilience is a Core Feature

Resilience must be treated like any other core feature. It must be designed, built, and continuously improved. It must be part of your product definition, your architecture, and your engineering culture. It must be owned by the same people who build the product. At Microsoft, the Azure DevOps engineering teams did exactly that, they built resilience which was engineered into every layer of their system , not handed off to a separate Ops team, not left to wishful thinking. Engineers owned their live site experience end-to-end form ideation to validation and all of the design, build, test, release and run in between.

Incidents were expected, contained, and learned from, not blamed on individuals. They did not hope for resilience. They built it.

If they did have an incident, they would own it, not just fix the problem and sweep it under the rug.

Build for Containment, Not Perfection

Every serious product needs resilience capabilities: telemetry, rapid roll-forward, observability, and risk containment.

Without telemetry, you cannot see what is happening. Without rapid roll-forward, you cannot respond fast enough. Without observability, you cannot understand why things are happening. Without risk containment, small failures turn into major outages.
If you have to shut down your entire platform to fix one feature, you have already failed.

Microsoft’s teams built telemetry into everything. They measured customer experience directly , failed or slow user minutes , not just server uptime. They tuned alerts to detect real-world impact. They used safe deployment rings with deliberate bake times to catch problems early. They separated deployment from exposure using feature flags, and stopped cascading failures with circuit breakers and throttling.

Failures were not exceptional. Failures were normal.
Resilience was not improvised. It was engineered.

Treat Resilience as a First-Class Investment

Resilience is not free, but the cost of neglecting it is far higher. Downtime kills customer trust. Outages cost revenue. Slow recovery wrecks morale. Ignoring resilience is gambling with your business.

Treat resilience like a feature. Design it. Engineer it. Continuously improve it. Put it in your Definition of Done . Make it part of every code review, every architecture discussion, every release decision. If you are not actively designing for resilience, you are designing for fragility whether you mean to or not.

Build for failure. Measure resilience empirically. Improve relentlessly.

Pragmatic Steps to Build Resilience

You do not need permission to start. You do not need to fix everything at once. You just need to move with intent:

• Instrument everything. If you cannot measure it, you cannot manage it.
• Make every change reversible or overridable. Progressive delivery, feature flags, and automated deployments are minimum standards.
• Build for isolation. Cells, circuit breakers, and throttling prevent one failure from taking down the system.
• Treat incidents as system signals, not team failures. Every incident is feedback for your product and your organisation.

Failure is Inevitable. Your Response is Optional.

You will never eliminate failure. That is not the goal.
The goal is to ensure that failures are small, contained, quickly detected, and rapidly recovered without compromising your product or your business.

If you want resilience, build it deliberately. Make it part of your product. Treat it with the same seriousness as security, scalability, and usability. Anything less is just gambling that the next crisis will not be the one that takes you down.

Resilience is not heroism. Resilience is system design.
Own it as you would any other critical feature. Because it is one.

You can install all the stand-ups, backlogs, retrospectives, and planning sessions you want. Without genuine agency, you’re not transforming. You’re decorating.

Agentic Agility is the bridge between doing Agile and being agile. It reconnects the mechanical adoption of frameworks with the deeper need for autonomy, purpose, and empirical adaptability. Without agency, agility remains performative theatre. With agency, it becomes adaptive strength.

Hollow Transformations vs. Human and System Agency

Most transformations stall because they focus on ceremonial compliance:

• Stand-ups happen daily
• Stories are “written”
• Retrospectives are “held”
• Boards are “managed”

Meanwhile, decision latency remains high, impediments are tolerated, and delivery remains brittle. The system stays paralysed by learned helplessness.

Transformation is about a shift in beliefs and constraints, not just behaviours:

• Individuals must believe they can shape outcomes.
• Teams must be enabled to change how they work.
• Organisations must evolve policies, structures, and practices that block responsiveness.

This is the ethos behind Agentic Agility: fostering human agency (the ability to act with intention) and system agency (the capacity for the system itself to adapt).

When we focus transformation efforts solely on compliance and ceremony, we institutionalise fragility. When we focus on agency, we unleash resilience.

Agentic Agility and Evidence-Based Management

You cannot manage what you cannot measure. You cannot empower what you cannot observe.

This is why I have consistently pointed to Evidence-Based Management (EBM) as a cornerstone for real change. EBM gives organisations the tools to:

• Measure actual outcomes, not outputs.
• Challenge assumptions with data, not dogma.
• Adapt strategies based on evidence, not inertia.

Without an evidence-based feedback loop, agency collapses into chaos or bureaucratic decay. EBM operationalises Agentic Agility by aligning action with impact.

Transformations without agency are short-lived. Transformations without evidence are blind. Transformations with neither are inevitable failures.

Real Agility is Agentic Agility

Agentic Agility reframes transformation away from ceremonies and towards capacity:

• Capacity for individuals to act intentionally.
• Capacity for teams to shape their working systems.
• Capacity for organisations to evolve dynamically in response to reality.

The next evolution of agility will not be led by those who install more frameworks. It will be led by those who build organisations capable of thinking, learning, and acting for themselves.

Agentic Agility is not an option. It is the missing lever for real change.

Here is a pragmatic checklist for engineering true business resilience and continuity:

Observability and Telemetry First

You cannot manage what you cannot see. You cannot fix what you cannot detect.

• Embed telemetry at every level: application, infrastructure, business processes.
• Define service level objectives (SLOs) for your critical systems and actually measure against them.
• Monitor leading indicators, not just trailing failures.
• Establish a live site culture, not a “we’ll find out when customers call” culture.

If your systems are invisible until they explode, you are not resilient; you are negligent.

Decouple Systems Aggressively

Coupling is a time bomb. When one piece falls, everything else falls with it.

• Bounded contexts are non-negotiable. Embrace them.
• No logic in the data tier. Databases store data, not behaviour. If your business rules are locked in SQL, you are one outage away from a complete operational collapse.
• Avoid shared databases. Duplicate data if necessary. Loose coupling beats data purity.
• Prefer asynchronous messaging. Synchronous systems are brittle under load and fail catastrophically.

Resilience comes from isolation. Systems must fail independently, not cascade like dominoes.

When the User Profile Service takes out the entire system

For a long time I have worked with the Azure DevOps teams at Microsoft as an strategic customer and MVP and I have witnessed this lesson firsthand. One of the major outages of Azure DevOps was triggered by something that, at first glance, seemed trivial: the Profile Service. When the Profile Service went down, developers could no longer commit code, and product owners could not update backlog items. Why? Because the system could not resolve your friendly name from your authenticated ID.

The service was so tightly coupled into critical user flows that its failure crippled the entire platform.

In response, the teams created “live site incident” repair work and moved the Profile Service behind a circuit breaker. If the Profile Service went down again, it would degrade gracefully, not drag down the entire experience.

As an anecdotal aside, a few months later another unrelated service failed, and, unsurprisingly, it also took down large parts of the system. That was the final straw. The teams went on a full-scale mission to introduce the circuit breaker pattern across every service, making sure no single point of failure could collapse the platform again.

Decoupling and graceful degradation are not academic exercises. They are mandatory if you value continuity.

Treat Deployments as Routine, Not Special

Every deployment is a practice run for disaster recovery. If deployment is a risky, complex, orchestrated event, you have already failed.

• Implement Continuous Delivery (CD) so that deployments happen safely, frequently, and predictably.
• Use feature toggles to separate code deployment from feature release.
• Automate rollbacks. A failed deployment should not require heroics.

If your organisation fears deployment day, it is structurally fragile.

Empower Teams to Act Without Hierarchy Paralysis

In a crisis, the last thing you want is a command-and-control bottleneck. Empowerment is a precondition to survival.

• Pre-delegate authority for critical systems response.
• Train teams on incident management procedures, disaster recovery, and failover operations.
• Decentralise decision-making to the people closest to the work.

In crisis, minutes matter. Top-down control costs lives and revenue.

Assume Everything Will Fail; Design to Recover Fast

Hope is not a strategy. Failure is inevitable. Recovery speed determines survival.

• Chaos engineering is not optional; it is responsible practice.
• Design for graceful degradation. Partial failure is better than total failure.
• Practice recovery drills. Don’t just have a DR plan; rehearse it until it is boring.

If you are not recovering faster than your competitors, you are losing.

DevOps, Site Reliability Engineering , and Evidence-Based Management

Business resilience is DevOps in action: the union of people, process, and products to enable continuous delivery of value to end users. Resilient systems emerge from the daily discipline of CI/CD, Infrastructure as Code (IaC), and monitoring as first-class citizens.

It is Site Reliability Engineering (SRE) lived, not aspirational. SRE teaches us that availability, latency, performance, efficiency, change management , monitoring, and emergency response are all product features, just as important as the user-facing ones.

It is Evidence-Based Management (EBM) made real. Metrics like Mean Time to Recovery (MTTR), Deployment Frequency , and Customer Satisfaction are not vanity measures; they are survival metrics. They inform whether your investment in resilience is paying off or just theatre.

Resilience is not a project. It is an ethos. You must architect it into your systems, invest in it continuously, and operationalise it ruthlessly.

Otherwise, you are gambling with your business and calling it strategy.

We created jobs like scanning groceries, cleaning toilets, packing boxes, and driving taxis not because they were noble pursuits, but because we needed to systematise output. We shaped them at the height of industrialisation under the false assumption that most people were incapable of thinking critically or creatively. That assumption was, and remains, wrong.

Humans harnessed fire, developed tools, built cities, and explored space. Yet we still have people herded into checkout lanes scanning barcodes for £10 an hour because we have convinced ourselves that’s all they can do. This is not dignity. It is systemic failure.

Robots started the change by replacing physical repetition. AI is accelerating it by replacing cognitive repetition. Neither are threats to humanity. They are threats to the systems that tried to industrialise it.

Scientific Management: A Philosophy of Subjugation

Frederick Taylor’s Scientific Management, better known as Taylorism, was never about human potential. It was about control and compliance. It engineered mediocrity, not mastery.

• Task and Bonus Systems: Set quotas just above sustainable capacity. Underpay unless “targets” are hit. Replace pride in craftsmanship with fear of poverty.

• Departments and Specialisation: Teach people one sliver of a process. Reduce communication. Stifle systemic understanding. “Efficient,” yes. Humane, absolutely not.

• Job Titles as Status Symbols: Create hierarchies not based on contribution or value, but on titles and politics. Reward political manipulation over problem-solving.

These patterns are not relics of history. They are alive and well in most organisations today. Hierarchies still prioritise power over outcomes. Standardisation still trumps collaboration. Fear still motivates more than trust.

We industrialised people because it made them easier to control. Now, automation and AI are finally taking those shackles off.

The Knowledge Age Demands Heads That Count

In a knowledge economy, compliance is worthless. We do not need more human robots performing repeatable tasks. We need humans solving problems, thinking critically, and delivering outcomes.

The organisations that thrive are the ones that realise this. They pay people enough that food and shelter are no longer their motivators (re Daniel Pink). They create environments where autonomy, mastery, and purpose are what drive performance, not carrot-and-stick bonus schemes.

If your workforce needs extrinsic rewards to perform, you have already failed them.

If You Are Still Paying Bonuses, You Are Still in the Industrial Age

Organisations still running bonus schemes, still obsessed with job titles, and still measuring success by output rather than outcome are clinging desperately to an age that is already automated away.

You are not preparing for the future. You are delaying your own obsolescence.

The simple truth:

Change your company, or change your company.

The knowledge age is here. It is not waiting for your permission.

AI: The Next Step Towards Restoring Humanity at Work

AI is not replacing humans. It is replacing the work that never deserved a human in the first place.

Writing repetitive reports. Copying data between systems. Processing endless low-value approvals. AI is the natural continuation of automation, taking rote cognitive tasks off our plates the same way robots took rote physical tasks out of our hands.

This is not a threat. It is a liberation.

Every time AI replaces another mechanical task, it creates space for something better: creativity, strategy, empathy, innovation.

It gives us the opportunity to do work that demands distinctly human qualities, qualities that no machine can replicate.

If your organisation sees AI as a threat to its workforce, it is a sign you have industrialised your people. If you see AI as a tool for elevating humanity, you are building for the future.

Robots freed our hands. AI is freeing our minds.

The only real question is: Are you ready to stop treating people like machines?

Spain’s national blackout. Portugal’s cascading failures. Oracle’s hospital cloud outage. Heathrow’s catastrophic shutdown. These were not accidents. They were not rare, unpredictable events. They were the inevitable consequences of bad engineering, shallow product thinking, and organisational self-delusion.

Resilience is not a checkbox. It is not a compliance exercise. It is not a hope and a prayer filed away in a disaster recovery plan. Resilience is hard. It is costly. It must be engineered, tested, and verified under real-world conditions, or it does not exist.

Bad Engineering

Real resilience assumes things will fail. Networks will fail. Authentication systems will fail. People will make mistakes. If your architecture does not assume failure at every level, you are not resilient; you are brittle.

Spain’s energy grid collapsed because it was optimised for efficiency, not survivability. No dynamic rerouting. No true load isolation. No meaningful observability. Their system was designed for perfect operating conditions that do not exist outside PowerPoint decks.

Oracle’s outage was even worse. Critical healthcare systems went offline because Oracle’s cloud infrastructure had no effective multi-region failover. Their architecture did not degrade gracefully; it fell over completely. That is not resilience. That is negligence at scale.

Bad Product and Continuity Thinking

Resilience is a product capability. If your product cannot survive failure, it is not a product. It is a liability.

Spain, Portugal, Oracle, all treated continuity as an afterthought. As long as the lights were on today, everything was declared fine. Until it was not.

Real product leadership demands harder questions: When, not if, this part fails, how will our system recover? How will our customers experience it? How fast can we restore service? How much risk are we carrying, and is that risk acceptable?

If those questions are not part of your roadmap, your architecture, and your operational strategy, you are not building resilience. You are building a house of cards.

Organisational Blindness

The real failure sits higher up the chain. Leadership failed to create a culture that prioritised operational survivability over operational fantasy.

I have lived through this firsthand. At Merrill Lynch, I participated in two major disaster recovery exercises. Both were declared “successful.” Both were complete failures.

Not a single system restored was actually usable. Systems were technically “back online”, but functionally, nothing worked. And the root cause was obvious: Active Directory, the system everything depended on for authentication, was never successfully recovered. Without it, every other “restored” system was dead weight.

Ironically, my application was successfully restored. We assumed it would have been usable, if Active Directory had been available. But we never found out. Two years running, the same critical dependency remained broken, and nobody was willing to call it what it was: systemic failure hidden behind fake success metrics.

Heathrow Airport offers another textbook case of organisational blindness disguised as resilience. When a fire broke out at one of their substations, they publicly blamed the disruption on their third-party power supplier. What they failed to mention was critical: Heathrow receives power from three independent substations, any one of which can fully power the airport alone.

The real problem was not the power supply it was a fluctuation in the power supply. It was Heathrow’s own disaster recovery system, designed to “protect” infrastructure by shutting everything down that detected that fluctuation and activated.   The result? Heathrow’s entire IT backbone collapsed. It took the rest of the day to get basic systems running again, and much longer to recover from the cascading operational chaos.

Instead of owning the internal failure, leadership pointed fingers outward. It is the same story everywhere: an unwillingness to face the reality that their own fake resilience made the disaster worse.

Real Resilience: Iterating Over the Pain

Not every story ends in failure. There are organisations that do it right, and the difference is discipline.

Take Rackspace. During catastrophic floods in London, when almost every other datacentre in the city failed, Rackspace’s facility stayed operational. Their backup generators worked exactly as expected. While others blamed suppliers and scrambled for excuses, Rackspace quietly kept their customers online.

When asked why their systems worked when everyone else’s failed, the CEO simply held up a key.

It was the key to the power room.

Every month, without fail, he would walk down, unlock the main breaker, and physically pull it, shutting off external power. Not in theory. Not in a simulation. A real, full transfer to emergency backup power under real-world conditions.

Because of that brutal discipline, they did not hope their disaster recovery systems would work. They knew. They had tested it, again and again, under real conditions. They iterated over the pain.

And that is the lesson:
If something is hard, you must do it more often, not less.
If failure is painful, you must lean into it, not avoid it.

Only by living through controlled, intentional failures, early, often, and brutally, can you build true resilience.

You cannot wait until it matters. You cannot prepare only on paper. You must earn resilience by testing your systems, exposing your weaknesses, and getting punched in the face repeatedly until you are strong enough to survive the real thing.

Resilience Is Built, Not Bought

You cannot buy resilience from a vendor. You cannot inherit it automatically because you deployed to “the cloud.” You cannot declare yourself resilient by writing it into your incident response plan.

Real resilience is built. It is designed in. It is iterated over. It is relentlessly tested. It is painful, slow, and expensive. But the alternative, the fragility we saw in Spain, Portugal, Oracle, and Heathrow, is far more costly.

If you are not engineering for failure, you are engineering for collapse.

Fragility is not an accident. It is a design choice.
Pretending otherwise only guarantees you will learn the hard way.

But self-management is not simply a label you apply to teams. It demands something deeper and harder: real agency.

Without agency, Scrum collapses into shallow ritual. Without agency, accountability is performative, not real.
Without agency, you are not doing Scrum. You are enacting a fragile imitation of agility.

Scrum Is Agile , and Agile Demands Self-Management

Agile and Scrum are often conflated or treated as separate. Let us be clear: True Scrum is Agile. Scrum operationalises Agile principles with discipline, transparency , and empiricism. It creates a bounded environment where teams can thrive.

The Agile Manifesto (2001) made it clear:

The best architectures, requirements, and designs emerge from self-organizing teams.

Self-organisation was never about anarchy. It was about teams owning how they deliver value. Agile assumes teams will figure out the best way to achieve goals , not be told exactly what to do.

Scrum sharpened this requirement in the 2020 Scrum Guide:

Scrum Teams are cross-functional and self-managing, meaning they internally decide who does what, when, and how.

Self-management is not a bonus feature. It is the foundation. Without it, Scrum is impossible.

Agency: The Prerequisite for Accountability

Agency is the power to make decisions and act toward outcomes you are accountable for. It is inseparable from accountability itself. Without agency, accountability is a façade , a mechanism for assigning blame rather than empowering success.

Scrum defines clear accountabilities:

• Product Owner : Maximising value.
• Developers: Delivering a usable Increment every Sprint.
• Scrum Master : Enabling the Scrum Team ’s effectiveness.

These accountabilities assume that those who hold them have real authority to act .

When organisations strip away decision-making power but leave accountability in place, they are not enabling agility. They are constructing a system of learned helplessness.

The Myth of “Self-Managing” Teams

Many organisations today claim to embrace “self-managing teams” but operate in ways that directly undermine them:

• Sprint Goals are dictated, not created.
• Work is assigned to individuals by managers.
• Technical decisions are second-guessed by external authorities.

This is not self-management. This is hierarchical command-and-control wrapped in daily standups and sticky notes.

If your team cannot decide how to achieve the Sprint Goal, they are not self-managing. They are being managed under a different name.

Weak Scrum Masters Enable Weak Scrum

Scrum Masters are accountable for the effectiveness of the Scrum Team. Yet in practice, many are limited to scheduling events and taking notes , with no real authority to challenge systemic dysfunction.

A Scrum Master without agency is not fulfilling their accountability. They are facilitating ceremony without enabling change.

Scrum Masters must:

• Teach leadership and teams what true self-management entails.
• Coach teams to take ownership of their processes and outcomes.
• Mentor individuals to step into accountability with courage.
• Facilitate organisational evolution, not just event logistics.

If you are a Scrum Master and you cannot do these things because of organisational resistance , you must raise it visibly. Otherwise, you are complicit in the degradation of Scrum.

Why Weak Implementations Collapse

When organisations adopt the appearance of Scrum without enabling the conditions for Scrum, dysfunction inevitably follows:

• Daily Scrums become status reporting.
• Sprint Reviews become formalities with no real inspection.
• Retrospectives become meaningless because the team lacks the power to change anything.

Scrum without agency becomes a theatre production. A ritualistic reenactment of agility, without any of the outcomes.

When organisations complain that “ Scrum doesn’t work ,” the reality is usually simpler: they refused to enable it to work, and they ignore the evidence of their own dysfunction .

The Path Forward: Fight for Agency

If you are serious about creating real, resilient agility:

• Scrum Masters must coach, teach, mentor, and cause real change , not just facilitate ceremonies.
• Product Owners must demand the authority to own the backlog and drive product strategy .
• Developers must guard their right to decide how to build and deliver working product Increments.

And leadership must understand: if you want the results Scrum promises, you must create the environment Scrum requires.

Self-management is not optional. Agency is not optional. Without them, you have nothing.

Conclusion

Scrum depends on self-management, and self-management depends on agency. Remove agency, and you remove the heart of Scrum. All that remains is empty ceremony, a hollow simulation of Agile values.

If you truly want the benefits of Scrum , adaptability, resilience, continuous value delivery , you must be willing to do the hard work of granting real agency to those accountable for outcomes.

Scrum without agency is not Scrum. It is theatre.

Choose what you want to build.

The Definition of Done (DoD) is an objective, measurable standard of quality , not a negotiable target. Keep it clear, enforceable, and automated to ensure every Increment meets professional expectations.

Definition of Done - The Organisational quotient

For a product to deliver real value, its quality criteria must align with organisational and market expectations. It should meet a minimum quality standard that ensures usability while safeguarding the organisation, its employees, and its users. Any failure to do so could damage the organisation’s reputation and trust in the product.

This means organisations should define a business DoD that may include:

• Regulatory compliance
• Market readiness (e.g., beta testing completion, go-to-market strategies)
• Customer experience and feedback incorporation
• Financial viability assessment
• Alignment with broader company objectives

Without this business-level perspective, teams risk optimising for technical completeness while missing the broader value delivery picture. The result of many iterations of the organisational definition of done for a product might look like:

Live an in production

gathering telemetry

supporting or diminishing

the starting hypothesis

This short sentence packs a lot into it, and it’s a commercial product definition of “done” for a team I have collaborated closely with for over 17 years.

1. “Live an in production” - done here mean that it is in the hands of real users

2. “gathering telemetry” - done here mean that the Developers must add code that collects relevant information from usage, performance, and such…

3. “supporting or diminishing the starting hypothesis” - Done here means that the team must define success metrics before building a feature or capability, ensuring that the collected data provides clear evidence of whether the intended outcomes are being achieved.

None of these elements define the “why” or “what” of what we’re building, those are captured in the backlogs. Instead, they establish the minimum quality standard required for work to be considered done.

Definition of Done - Translating Organisational Standards into Team Practice

While Scrum Teams are self-managing, that doesn’t mean they can do whatever they want. They operate within a structured environment, within a balance of leadership and control that upholds both autonomy and accountability. Scrum isn’t anarchy; it’s a social technology that enables self-management within clear constraints, Scrum events, commitments, and organisational expectations.

Each Scrum Team must interpret the organisational Definition of Done within their context, shaping an engineering-level DoD that aligns with it. While examples can guide them, it’s the team’s responsibility to determine what Done means within organisational constraints.

In addition to supporting the organisational definition of done, a robust DoD ensures that work meets a consistent level of quality before it is considered complete. This includes engineering practices , preferably within the bounds of a shift-left strategy , such as:

• Writing Unit and Integration Tests – with a preference for shifting testing earlier by adopting Test-Driven Development (TDD) and automated integration testing, ensuring issues are caught before coding progresses too far, and preferably making tests a prerequisite for writing new code.

• Performing Code Reviews – Rather than manual code reviews create automate code quality checks using static analysis and enforce good practices before manual reviews, allowing developers to focus on deeper logic and architectural concerns, and preferably integrating peer reviews into the development workflow, such as pair or mob programming.

• Adhering to Security and Compliance Requirements – try embeding security scanning into CI/CD pipelines with automated dependency checks and policy enforcement, catching vulnerabilities before they reach production, and preferably treating security as code, ensuring it evolves alongside development.

• Maintaining Updated Documentation – Automate as much of your documentation updates as possible using tools that generate API references and architecture diagrams directly from code, keeping documentation relevant and accurate, and preferably making documentation a non-negotiable part of the Definition of Done (DoD).

• Ensuring Deployments are Automated and Repeatable – Implement Infrastructure as Code (IaC) and continuous deployment pipelines to guarantee consistent, error-free releases, and preferably shifting validation left with feature flags, automated rollback strategies, and deployment previews.

Each aspect contributes to quality, reducing the likelihood of defects and technical debt . However, quality isn’t just a technical concern, it is an economic and strategic one.

The Evolution of Done Over Time

New teams often start with a weak DoD that doesn’t yet guarantee releasability. A brownfield product with legacy constraints may have a DoD that initially excludes automation, testing, or continuous deployment due to existing technical debt. Over time, through Sprint Retrospectives and deliberate improvements, the DoD should:

1. Start at a minimal viable level (e.g., basic testing, peer reviews).
2. Expand to include automated testing , security checks, and CI/CD.
3. Reach a state where every increment is truly releasable.

An experienced Scrum Team should aim for a DoD that ensures shippability at the end of every Sprint. Anything less introduces unnecessary risk and delays value realisation.

Common Misconceptions

1. Can the DoD Change Per Sprint?
   Yes, but only to increase quality. The Sprint Retrospective is the right place to discuss DoD improvements, not reductions. However, if an issue arises, address it immediately, don’t wait for the Retrospective.

2. Can the DoD Be Lowered to Deliver More Features?

   No. Quality is a long-term investment, not a short-term lever to pull for speed. A Scrum Team has no authority to cut quality, that’s a financial and risk decision made at the highest level. This authority rarely sits with project managers or middle management. If someone asks you to lower quality, tell them to get it in writing from the financial director.

3. Can We Have Different DoDs Per Backlog Item?

   No. The DoD is a universal standard applied to all work, ensuring consistency in quality. Acceptance Criteria define specific conditions for a backlog item, but these conditions do not belong in the DoD.

4. Should the DoD Be Fluid and Change Every Sprint?

   No. A fluctuating DoD signals dysfunction unless it’s always improving. Constant changes undermine transparency and disrupt planning. Evolution should be deliberate, incremental, and focused on raising quality, not shifting goalposts.

DoD as a Strategic Lever

A strong DoD isn’t just about engineering, it’s about protecting revenue, managing risk, and ensuring predictable delivery. Weak DoD practices lead to costly rework, delayed releases, and customer dissatisfaction. By embedding security, compliance, and quality checks into the development cycle, organisations reduce their exposure to financial and reputational risks. Teams that consistently meet a well-defined DoD can deliver with greater confidence, improving forecasting and market responsiveness.

A strong DoD reduces rework, increases predictability, and aligns technical work with business value. As organisations evolve, so should their quality expectations. This continuous refinement is not just a technical necessity, it’s a competitive advantage.

Leadership requires a different kind of expertise, expertise in change, collaboration, coaching , facilitation, conflict navigation, communication, team development, personal growth, and a ballance of leadership with control . These are non-negotiable.

But these skills alone are not enough; we should recognise that for leaders to be successful, domain-specific mastery matters too. A Scrum Master who understands the technical, business, and organisational context their team operates in can better remove impediments, facilitate learning, and support adaptation.

This idea doesn’t replace the core leadership capabilities. It builds on them.

For a Scrum Master to be an effective Teacher, Mentor, Coach, and Facilitator, they require a deep understanding, or mastery, of the team’s work, the business they operate in, and the organisation they are navigating.

Mastery in this context means knowledge and understanding of the philosophies, methods, practices, and techniques relevant to the domain in which the team operates. If a team is developing medical devices, the Scrum Master should understand that field’s regulatory and quality requirements. If they are working in industrial design, they need familiarity with prototyping, material constraints, and production processes. If they are developing software, they should understand software development practices, including Continuous Delivery , Test First , and DevOps principles.

Without this domain knowledge, how can they effectively help the team deliver value?

There are three key areas of mastery that make a Scrum Master truly effective: Technical Mastery , Business Mastery, and Organisational Evolutionary Mastery.

Three Masteries of an effective Scrum Master

Many individuals take on the Scrum Master role without fully developing the expertise needed in even one of these masteries, let alone all three. This gap in competence can hinder the Scrum Team ’s ability to navigate challenges effectively and maximise their potential. They often fall into the assumption of the knowledge fallacy trap because they don’t have the skills, knowledge, or experience to identify the deficiency in or corruption of a key practice or capability for the Scrum Team to be effective.

While it is not mandatory to have all of these masteries to the same depth, depending on the size of the organisation and others working in the same field, a great Scrum Master possesses these three critical masteries that enable them to serve the Scrum Team, the Product Owner , and the organisation effectively.

1. Technical Mastery

One of the core capabilities of any team is their ability to deliver a valuable, usable product. For a Scrum Master to coach them on creating that value, they need to understand what effective looks like in the context. If they are working with a hardware team, they should understand product engineering and manufacturing constraints. If they are in finance, they should understand financial modelling and compliance.

The key is domain-specific technical mastery that allows them to facilitate discussions, remove impediments, and guide the team towards better practices. If they are working with software teams they should be able to teach and coach the team members in the technical practices for software, for example:

• Coach the Developers in SOLID principles – ensuring that the team adheres to fundamental object-oriented design principles to create maintainable and scalable software.
• Facilitate the adoption of Static Analysis & Linting – Encouraging automated code quality checks to catch defects early and enforce coding standards.
• Mentor the team in Pair Programming – Promoting collaborative coding to enhance knowledge sharing, reduce defects, and improve overall code quality.
• Instill Test-Driven Development (TDD) practices – Guiding the team to write tests before code, ensuring robust, verifiable, and high-quality software.
• Enable Continuous Integration and Deployment (CI/CD) – Driving automation and frequent delivery to accelerate feedback loops and improve release reliability.
• Advocate for Cloud and DevOps principles – Teaching the team how to leverage cloud-native architectures, Infrastructure as Code (IaC), and automated operations.
• Ensure Clean Code and Refactoring discipline – Encouraging best practices that result in readable, maintainable, and scalable codebases while reducing technical debt .

In other contexts, like designing hardware, creating movies, or creating financial accounts, they would need to teach and coach the technical practices that make sense for those contexts. These skills help the Scrum Master serve the Scrum Team and increase their effectiveness.

The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in self-management and cross-functionality;

• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done ;

• Causing the removal of impediments to the Scrum Team’s progress; and,

• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

  , The Scrum Master, Scrum Guide

Without technical mastery within the relevant domain, guiding a Scrum Team towards high-value product delivery is challenging.

2. Business Mastery

The Product Owner is a key position that sets the tone for product leadership and defines success within the organisation. For them to be successful, they must implement modern product management practices and have a value-driven mindset. The Product Owner should be accountable for and have the authority to maximise the value of the product and the effectiveness of the Product Backlog . Not every person who takes on the accountability of the Product Owner role will already possess these skills or even be aware that they should. Developing expertise in modern product management practices and value-driven decision-making is an ongoing journey. Since an effective Scrum Team requires an effective Product Owner, it falls within the accountability of the Scrum Master to teach, coach, and mentor the Product Owner as needed. This requires that they understand the business context of the Scrum Team and its product as well as the product management processes, techniques, and practices that a Product Owner might use to maximise the value of the Scrum Team’s work.

This includes that the Product Owner is able to:

• Leverage customer insights and market research – The Scrum Master helps the PO incorporate data-driven insights from customer feedback, competitive analysis, and market trends to inform Product Backlog decisions.
• Articulate the strategic vision of the product – The Scrum Master should coach the PO on clearly defining and communicating the long-term vision of the product to stakeholders and the Scrum Team.
• Actively manage stakeholders, their desires, expectations, and outcomes – The Scrum Master mentors the PO in engaging with stakeholders effectively, ensuring alignment without compromising product integrity.
• Developing and explicitly communicating intermediate strategic goals – The Scrum Master supports the PO in setting achievable, incremental objectives that drive value and guide the Scrum Team.
• Ensuring that the Product Backlog is transparent, visible, and understood – The Scrum Master teaches the PO how to refine, prioritise, and maintain a clear, actionable Product Backlog.
• Using evidence-based management techniques to optimise outcomes and value delivered – The Scrum Master coaches the PO on leveraging data, metrics, and experimentation to make informed product decisions.
• Work with Developers daily to clarify and renegotiate the Scope of the Sprint – The Scrum Master facilitates collaboration between the PO and Developers to ensure continuous alignment and adaptability.

Scrum Master Service to the Product Owner

• Ensuring that goals, scope, and product domain are understood by the Scrum Team.
• Helping the Scrum Team understand the need for clear and concise Product Backlog items.
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.

, The Scrum Master, Scrum Guide

Without business mastery, a Scrum Master cannot effectively support the Product Owner or ensure the team’s alignment with business goals.

3. Organisational Evolutionary Mastery

Most organisations operate within traditional hierarchical structures that prioritise control and predictability, which often conflict with the adaptability and empirical approach that Scrum fosters. Scrum enables teams to embrace change, iterate quickly, and focus on delivering value in an environment of uncertainty. To bridge this gap, Scrum Masters must actively guide organisations towards a more dynamic, self-organising model that supports agility and responsiveness to market shifts. Many Agile transformations fail due to a lack of understanding of how organisations truly function and evolve, making this mastery critical for any Scrum Master seeking lasting impact.

Key aspects include:

• Navigate organisational structure and politics – Helping teams and leadership understand and adapt to the organisation’s hierarchy, decision-making processes, and political dynamics to remove impediments.
• Apply change management principles – Facilitating sustainable change by addressing resistance, fostering adoption, and ensuring alignment with Agile values.
• Engage stakeholders effectively – Ensuring that decision-makers, sponsors, and key influencers understand Agile principles and support the Scrum Team’s ability to deliver value.
• Lead Agile and Lean transformations – Driving organisational agility by educating leadership, coaching teams, and embedding Lean thinking into strategic planning and execution.
• Influence leadership to remove systemic impediments – Advocating for structural and cultural changes that enable agility and improve value delivery across the organisation.
• Foster a culture of continuous learning and adaptation – Encouraging a mindset of experimentation, feedback, and iterative improvement at all levels of the organisation.

Scrum Master Service to the Organisation:

• Leading and coaching the organisation in its Scrum adoption.
• Planning Scrum implementations within the organisation.
• Helping employees and stakeholders understand Scrum and empirical product development .
• Causing change that increases the productivity of the Scrum Team.

, The Scrum Master, Scrum Guide

Without organisational mastery, a Scrum Master will struggle to drive lasting, meaningful change within the organisation.

Conclusion: Can a Scrum Master Be Effective Without These Skills?

While the entire Scrum Team is accountable for delivery, the Scrum Master ensures the conditions for success by addressing systemic issues and empowering the team to work efficiently. They do not execute the work themselves but are responsible for enabling outcomes, ensuring that the Scrum framework is effectively applied, fostering collaboration, and removing impediments that hinder progress.

A Scrum Master’s role is not passive; they actively influence the team’s ability to deliver by facilitating strategy, ensuring alignment with business goals, and advocating for organisational change where necessary. Without technical, business, and organisational mastery, they risk being ineffective in guiding the team towards high-value delivery.

While a Scrum Master can function without deep technical knowledge, they will be far more effective if they understand the technical, business, and organisational context they operate in. Mastery in these three areas allows them to serve their teams better, drive value, and enable true agility within the organisation.

Scrum Masters don’t need to be coders, but if their team is developing software, they should have mastery in software development as well as whatever domain is relevant to the industry their team operates in. The Scrum Master is is not a juniors or entry level activity. They should be experienced professionals with a deep understanding of the three masteries.

While there are no absolute right answers, some answers are better than others. Scrum Masters should continuously seek to deepen their knowledge in all three mastery areas to best serve their teams and organisations.

Can One Be Held Accountable for What One Has No Control Over?

TL;DR; - Accountability without authority is a contradiction. If Scrum Masters and Product Owners are expected to deliver results, they must have the authority to remove impediments, challenge dysfunction, and enforce alignment where necessary. Influence is critical, but influence alone is often not enough. True leadership means balancing empowerment with decisive action, ensuring teams are both autonomous and accountable. Without the authority to act when needed, accountability becomes an empty expectation.

Leadership, Authority, and Accountability

Product Owners and Scrum Masters balance leadership, authority, and control by providing clear intent, fostering initiative, and reinforcing accountability. They guide rather than micromanage, ensuring the team understands the vision and goals, has the autonomy to execute, and remains accountable for outcomes. When intervention is needed, they step in decisively while preserving the team’s ownership of their responsibilities.

Product Owners and Scrum Masters lead through influence but must assert authority when needed, Product Owners to maximise product value, and Scrum Masters to enable the effectiveness of the Scrum Team . Effective leadership balances autonomy and alignment, ensuring teams self-manage while staying accountable to commitments and organisational goals.

Context Dictates Authority

The authority wielded by the Product Owner is more widely recognised and acknowledged, so why not the Scrum Master ?

The Scrum Master is accountable for the Scrum Team’s effectiveness. This accountability demands both leadership and, within the right context, a degree of authority. While some argue that a Scrum Master should have no direct authority, this ignores the reality that influence alone is often insufficient to drive change in certain organisational contexts.

The argument against Scrum Masters having authority is often based on a misunderstanding of self-management. According to the Scrum Guide, self-managing teams decide who does what, when, and how. However, this autonomy is bounded by Scrum events, commitments, and organisational needs. The key is the freedom to decide how to deliver value, without ignoring accountability, strategy, or constraints.

In practice, the level of authority a Scrum Master should exercise depends on the organisational landscape. In a command-heavy environment, excessive control leads to blind obedience, stifling self-management. Conversely, a leadership-heavy approach without structure creates chaos. The Scrum Master must navigate this balance, adapting to the constraints of the organisation while continuously working to remove impediments to the team’s effectiveness. The organisational constraints being the very things that may be  reducing the effectiveness of the Scrum Team.

The Duality of Leadership and Control

Leadership in a Scrum environment is about guiding the team toward continuous improvement . However, leadership without some degree of control is often ineffective. Control, in this context, does not mean command and dictate, it means ensuring that the Scrum framework is upheld, that organisational impediments are actively removed, and that the team operates within its defined constraints.

Some argue that the best Scrum Masters might be managers, while others argue that a Scrum Master should not have authority. Both perspectives have merit but must be contextualised.

• The idea that a Scrum Master can be a manager works in an organisation where a manager understands and embodies servant leadership. When a manager removes impediments, provides clarity, and champions agility without imposing control, they function effectively as a Scrum Master.
• The notion that a Scrum Master should not have authority assumes an ideal state where influence is enough. However, in many organisations, without a minimum level of authority, such as the ability to hold the team accountable for Scrum adoption or to challenge organisational constraints, Scrum Masters struggle to fulfil their accountability.

Practical Considerations

Scrum Masters must master the art of situational leadership. Some teams require a hands-off coach, while others benefit from more direct guidance. A Scrum Master should have the authority to:

• Enforce Scrum framework adherence when teams attempt to dilute its effectiveness.
• Challenge anti-patterns that hinder agility.
• Influence and escalate organisational impediments effectively.
• Ensure that the team continuously inspects, adapts, and improves.

Conclusion

Accountability without authority is a flawed concept. The Scrum Master, and the Product Owner, must operate within the context of their organisation, leveraging both influence and, where necessary, the authority to drive meaningful change. The key is not about wielding power but about ensuring the team is empowered while working within the system they are part of, always striving to evolve that system toward greater agility.

References:

• Why Does a Scrum Master Not Have Authority?
• Your Next Scrum Master Should Be Your Manager

Process Cycle Efficiency (PCE) Drives Flow, Not Individual Productivity

Kanban isn’t about individual productivity; it’s about optimising the flow of work through a system. When you measure an individual’s cycle time, you ignore the real bottlenecks, queues, dependencies, and wait times that slow everything down. A person might complete tasks quickly, but if those tasks get stuck waiting for reviews, approvals, or other handoffs, the overall system remains inefficient. If you want faster delivery, fix the system, not the people.

As Nigel Thurlow puts it: “You never measure a person, ever. You only ever measure a process. You improve the system, never the people within it. If you’re measuring an individual person to try and blame them, then you’re ignoring what’s wrong with the process that’s causing it.”

Encourages Local Optimisation Over System Improvement

Measuring individual cycle time leads to bad incentives. If someone is judged on how fast they complete their own tasks, they’ll prioritise speed over impact. This can lead to:

• Focusing on tasks that make them look efficient rather than what benefits the team.
• Taking on work too early, creating unnecessary work in progress (WIP).
• Cherry-picking simple tasks to appear fast rather than tackling what actually moves the system forward.

Kanban is about improving the whole workflow. Look at Process Cycle Efficiency (PCE) and Throughput together, one improves the other.

Ignores Work in Progress (WIP) and Blockers

A fast-moving individual doesn’t mean fast-moving work. If the system is overloaded with WIP, nothing gets delivered faster. Work often gets stuck in queues, waiting for handoffs, or blocked by dependencies. Measuring individual cycle time won’t tell you where the real problems are.

Instead, track:

• Total WIP, to ensure the system isn’t overloaded.
• Time in queue vs. time in progress, to identify bottlenecks.
• Blocked work items, to find systemic delays.

Misrepresents Collaboration and Dependencies

Knowledge work isn’t assembly-line work. It requires handoffs, reviews, and collaboration. Measuring an individual’s cycle time isolates their part of the work but ignores the time it spends waiting on others. Worse, it discourages teamwork, if people are penalised for long cycle times, they’ll avoid collaborating because it slows them down.

Optimise for flow across the system, not just individual speed.

Creates Unintended Behaviour

If people are measured by their personal cycle time, they may:

• Rush work, sacrificing quality to look fast.
• Avoid complex or high-value tasks, because they take longer.
• Hoard work, keeping tasks they know they can finish quickly rather than distributing work across the team.

None of this improves system flow. It just distorts behaviour.

What Should You Measure Instead?

At the end of the day, the Kanban Method (as opposed to kanban) is designed to improve flow (basically Process Cycle Efficiency) by improving throughput (units per unit time) by removing constraints (which includes bottlenecks) in the system. Make the system more effective by making it more efficient. - Nigel Thurlow

If you want to improve flow, focus on:

• customer lead time ( time to market ) - the total time from when work is requested to when it is delivered to the customer.
• Work in progress (WIP) limits - to reduce bottlenecks and improve flow.
• Process Cycle Efficiency (PCE) - the ratio of active work time to non value added time.
• Bottlenecks and blockers - to identify systemic constraints.
• Throughput - the rate at which something is produced or delivered..

Bottom Line

Kanban is about improving the system, not monitoring individuals. Measuring individual cycle time distracts from real systemic inefficiencies and leads to bad behaviours. Instead, optimise for end-to-end flow and make sure work moves smoothly across the whole system.

As Thurlow emphasises: “If there are training or skill gaps, that’s a system problem, not a person problem. Someone failed the person by not providing the right training, support, or experience.” This reinforces why the focus should always be on fixing the system, not blaming individuals.

Want to improve your Kanban flow?

If you need help setting up meaningful Kanban metrics, let’s talk. We can identify the right measurements to improve your system without falling into the trap of individual cycle time metrics.

Continuous delivery is not a pipe dream. If the organisation is willing to invest, it’s achievable for every software product, regardless of complexity or legacy constraints. And that’s the challenge.

The organisation must be willing to invest significant time and effort in enabling it. Microsoft’s Azure DevOps team exemplifies this. They transitioned from shipping new features every two years to delivering value every three weeks, increasing their annual feature delivery from 25 to nearly 300 at their peak.

This evolution was not the result of a silver bullet but a deliberate effort to modernise architecture, eliminate technical debt , automate relentlessly, and embed a culture of continuous improvement . It is an ongoing evolution that has paid dividends for every year of effort invested. They delivered 58 features at the end of the first year of investment, rising to over 250 features after four years, later stabilising at just over 300. This is the power of continuous delivery.

TLDR

Every software system, no matter how complex or archaic, can be updated, tested, and deployed continuously, without delays, bottlenecks, or manual interventions. This is the core of Continuous Delivery (CD): software always in a deployable state, ready for frequent, reliable releases.

What is holding you back?

Many teams believe they cannot achieve continuous delivery and instead claim:

• Their product is too big and complex
• Their teams lack the skills
• It’s not possible in their regulated industry

Every single one of these justifications is illegitimate and reflects either the team’s unwillingness to learn or the leadership ’s unwillingness to invest. These are excuses, not realities.

In reality, systemic and continuous underinvestment in quality, scalable, and supportable products is to blame.

This failure is not driven by the engineers or managers doing the work, but they have enabled it. The cause lies squarely in the business, even if they did not consciously make it.

“If you put people under pressure to deliver, they will increasingly and systemically decrease quality to meet whatever ridiculous deadlines you give them.”

The result is unchecked technical debt, high bug rates in production, significant rework, and unmet expectations.

This is not a terminal condition but a challenge to manage and overcome. The key lies in intentionality. Without tackling the root causes of complexity for new capabilities, slow releases, and frequent production issues, process changes will fail to deliver meaningful results.

The Evolution of the Developer Division at Microsoft

Like every other company that has built software at scale, Microsoft fell into the usual traps of long release cycles, single-pass coding, and poor testing quality. For the Developer Division, responsible for Visual Studio, Team Foundation Server, and other software engineering tools, this resulted in a two-year release cycle, a four-year customer feedback loop, and fixing 75,000 bugs to get Visual Studio 2010 out the door.

Market forces pushed them to evolve. They could no longer meet the demands of an increasingly dynamic market, and a four-year response time to customer needs was unsustainable. While laggards might remain, it’s the early adopters who drive new business and shape emerging markets. Failing to keep them engaged signals a decline that, if left unchecked, can be fatal, but recovery is possible with decisive action.

Azure DevOps emerged as the result of decisive action by Microsoft’s Developer Division, triggered by an urgent need to break free from their two-year release cycle and four-year customer feedback loop. They didn’t inherit perfection, they faced legacy code, fragmented processes, and a monolithic release cycle. Their transformation began with small, incremental changes, but success required deeper, systemic shifts:

• Automate Everything: This cannot be emphasised enough. Automate every possible task. If something cannot be automated today, create a plan to rework the architecture until it can be. From testing and deployments to upgrades, certificates, passwords, and environments, automation should be the default, not the exception.

• Trunk-Based Development: The cognitive load and resulting complexity from supporting multiple versions of your product significantly increases complexity and risk. Long-running branches, especially when promoting by branch, slow the delivery of working software to real users. Adopting Trunk-Based Development practices eliminates this risk by ensuring that all code integrates continuously into a single shared branch.

• Feature Flags: To maximise both quality and value, it’s essential to test new capabilities in production while gradually exposing them to users, reducing risk. This approach shortens feedback loops and enables swift adaptation to emerging market opportunities. Since we can’t predict which features will deliver the most value, we validate hypotheses by running small experiments with real data. Effective use of feature flags is crucial for these experiments, ensuring safe, controlled releases that drive continuous improvement.

• Shift-Left: Shift from testing quality at the end (QA, Staging, UAT) to embedding it throughout the development process. Use hypothesis-driven practices and unit tests at every stage to ensure high quality from the start. Discovering a security vulnerability in staging often means the flaw is deeply embedded, leaving no time or budget for proper fixes, only quick patches that hackers easily exploit. Instead, conduct security tests, code reviews, and performance checks continuously, as close to code creation as possible.

• Iterate Over Pain: If a task is hard or error-prone, you should do it more often. Any activity, like releasing, that feels difficult or frequently leads to errors deserves focused attention. Repeated practice exposes weak points, allowing you to refine the process and reduce risk. Avoiding the pain only ensures it remains a persistent threat.

What can we learn?

If you want to be able to adapt to market opportunities or surprises, then you need to be able to shift quickly. This means that any software system, regardless of its complexity, architecture, or purpose, should be updated, tested, and deployed in a continuous flow without delays, bottlenecks, or manual interventions. This is the ethos of Continuous Delivery (CD), where software is always in a deployable state, enabling frequent and reliable releases.

In the world of modern software engineering its no longer an optional thing. It’s a business demand.  Too many business opportunities have been missed because we are too slow to deliver and too slow to turn feedback into usable working products on a short enough timeline.

How short your timeline needs to be is a question for your business… what is your effective planning horizon. For Starbucks PoS its 48h; for Windows , its ~120h, for Facebook its just a few minutes.

Measuring your velocity

Velocity isn’t just about how much work gets done, it’s about how fast you move from idea to outcome. It’s about closing feedback loops quickly, enabling continuous improvement, and delivering valuable increments faster.

In 2018, Buck Hodges from Microsoft’s Azure DevOps/Team Foundation Server team introduced four key metrics to evaluate and enhance the software development and deployment process:

• Time to Build: This metric measures the duration from code commit to the completion of a successful local build on a developer’s workstation. It reflects the amount of time a developer needs to wait to know if their code compiles.

• Time to Self-Test: This refers to the time taken to execute automated tests after a build locally. A shorter Time to Self-Test reflects fast tests and enables quicker feedback on code quality. Efficient self-testing cycles catch defects early, reduce rework, and maintain code integrity.

• Time to Deploy: This metric tracks the time required to deploy a build to a production environment. Shorter deployment times increase velocity by enabling rapid feedback and value delivery . Minimising the Time to Deploy is crucial for rapidly delivering features and fixes to end users. Continuous integration and delivery (CI/CD) pipelines are essential for optimising this metric.

• Time to Learn: This encompasses the period from deployment to collecting and analysing user feedback or telemetry data. Reducing Time to Learn ensures teams quickly understand user interactions and make informed decisions for future development. Faster learning cycles mean teams adapt quickly, prioritise effectively, and avoid wasting time on low-value features.

These metrics represent stages in the flow of work from ideation to outcome. They are not the only metrics or stages, but they represent and expose significant bottlenecks in this case, and they are 100% within the control of engineering. Engineering did not require any outside approval to measure and optimise these stages. Accountability for improvement lies squarely within the team.

By monitoring and optimising these metrics, development teams can achieve a more streamlined and responsive DevOps workflow, leading to faster delivery of high-quality software. However, these metrics are focused on the work of engineers building the product, and there may be other things in the application lifecycle that may have a bigger impact on you and your teams.

It’s crucial to take a holistic view of metrics, and the Evidence-Based Management (EBM) guide is a great starting point. It offers example metrics that can either be adopted directly or adapted to fit your context. When choosing metrics, focus on the four Key Value Areas (KVAs) defined by EBM:

1. Current Value (CV): Measures the value delivered to customers or stakeholders today, reflecting satisfaction and success based on the current product.
2. Unrealized Value (UV): Identifies potential future value by highlighting gaps between what customers have and what they need or desire.
3. Ability to Innovate (A2I): Assesses how effectively the organisation can deliver new capabilities, features, or products without being constrained by technical debt, process bottlenecks, or organisational drag.
4. Time to Market (T2M): Evaluates the speed at which ideas, features, or fixes move from concept to production, directly impacting responsiveness to market demands and customer needs.

These four areas provide a balanced view, ensuring you don’t just measure output but focus on the outcomes that drive business success and customer satisfaction .

The Path Forward

Ultimately, when deployments are automated, code is well-tested, and processes are streamlined, teams can respond faster to customer needs, market changes, and business opportunities. Azure DevOps’ and Windows evolutions proved that the barrier to continuous delivery is not technical complexity but organisational will.

No matter where you start, the path to continuous delivery is through addressing the complexity that is slowing you down head-on. Prioritise automation, enforce code quality and relentlessly improve your processes. The result is not just faster releases but better software, happier teams, and more satisfied customers.

If Azure DevOps can do it with their scale and complexity, so can you.

The only question is whether you’re willing to do what Azure DevOps, Starbucks, and countless others have done: stop hiding behind complexity, and start delivering continuously.

The Myth of the Junior Scrum Master

Too often, organisations treat the Scrum Master role as a checkbox on a hiring matrix, assuming that anyone can step in and “facilitate” a few events. This mindset reduces the Scrum Master to a glorified meeting scheduler rather than the steward of effectiveness that they are meant to be. The reality is this: Scrum Masters are not made in a two-day certification course, they are forged in the crucible of real-world experience within high-performing Scrum Teams.

This aligns with the points made in The Incompetent Scrum Master , which highlights that many Scrum Masters lack the depth of knowledge and experience necessary to be effective. The best Scrum Masters are not those who simply “get certified” but those who have lived and breathed Scrum within a team, demonstrating real-world competence before stepping into the role.

Additionally, a Scrum Master must have first-hand experience of working within a Scrum Team. This doesn’t mean they have to been a coder; Scrum Teams are made up of Business Analysts, Testers, Flow Designers, and many other roles that contribute to delivering great products. But they must have seen what a cohesive team looks and feels like, and they must have experienced how a great Scrum Master and Product Owner operate.

That said, I believe that a Scrum Master for a Scrum Team delivering software should be able to code. They should be able to understand and critique the quality of the work being done in order to understand and affect the Scrum Team’s effectiveness. While they may not be writing production code daily, their ability to engage meaningfully with developers on code quality, DevOps practices, and architectural decisions is invaluable. Without this understanding, how can they genuinely support the team in delivering high-quality software?

The best Scrum Masters:

• Have worked within a Scrum Team for years, developing their craft as a Developer, Product Owner, or another key role.
• Have demonstrated their ability not just to deliver work but to enable agility through lean thinking, continuous improvement , and servant leadership .
• Possess technical mastery, business mastery, and organisational evolutionary mastery, the three pillars of a truly competent Scrum Master.

A person whose knowledge of Scrum is limited to a two-day certification course will struggle to land a real Scrum Master job; and rightly so. Just as a company wouldn’t trust its entire departmental finances to someone who just completed a “Financial Mastery in Two Days” course, they shouldn’t entrust the success of a multi-million-dollar project to someone whose entire experience is a “ Professional Scrum Mastery” online session.

Additionally, many organisations attempt to cut costs by hiring a “junior” Scrum Master at half the salary, while expecting full performance. The result? A Jira lackey and reporting serf, someone who is bullied into administrative tasks rather than empowered to drive agility. It’s the equivalent of hiring a “junior” chef at a discount and making them sweep the yard before every shift, then blaming the methodology when the food is awful.

Scrum Masters Are Chosen by the Team, Not Imposed by Management

A Scrum Master should not be an external hire brought in to “fix” a team. Instead, they should rise naturally from within the team, selected by their peers who trust them to safeguard the team’s effectiveness.

This approach ensures:

• The Scrum Master has credibility within the team, they have already earned the respect of their colleagues.
• They understand the organisation’s constraints, culture, and history, enabling meaningful change without naive disruption.
• Their selection is based on demonstrated competence, not just theoretical knowledge or a certification.

If a team does not trust or respect their Scrum Master, they won’t follow them. The Scrum Master must be someone who has already shown leadership, not someone who needs to “grow into the role.”

The Accountability of the Scrum Master Is Heavy, And It Requires Mastery

Scrum Masters, as all leaders, should not lead only through authority, they should lead through influence. That influence comes from mastery of three key domains:

1. Technical Mastery – A deep understanding of software development , DevOps, modern engineering practices , and the realities of delivering high-quality products. This doesn’t mean they have to code daily, but they must understand how technical decisions impact agility.
2. Business Mastery – The ability to align Scrum Teams with the broader business strategy, ensuring that the work they facilitate delivers real, measurable value. This does not take away from the Product Owner but instead supports it.
3. Organisational Evolutionary Mastery – The skill to enable systemic change, remove organisational impediments, and cultivate a culture of agility beyond the team level.

While Scrum Masters should lead through influence and servant leadership, they are not powerless. The concept of intent-based leadership, where they also hold authority, can be incredibly effective. The best Scrum Masters know when to serve and when to step up with authority to drive change. They wield the accountability of the role not just as a facilitator but as a true leader, ensuring that agility is not merely an aspiration but a reality.

This concept is further reinforced in The Scrum Master is Accountable for Delivery , which highlights how Scrum Masters must take ownership of delivery effectiveness and drive the team towards meaningful outcomes. Does this still sound like a junior position?

Scrum Masters Should Wield Their Accountability with Competence from Day One

The idea that a Scrum Master should “learn on the job” is dangerous. A Scrum Master should be able to step into the role with full competency from day one, because they have already been functioning as a de facto Scrum Master within their team before ever taking on the title.

This is not about gatekeeping, it’s about effectiveness. If a Scrum Master is learning the fundamentals while on the job, they are not serving the team, they are hindering it.

This is also why hiring a Scrum Master should be an intentional and rigorous process. As outlined in Hiring a Professional Scrum Master , organisations often make the mistake of prioritising certifications over experience, failing to assess whether a candidate truly embodies the role. A Scrum Master is not someone who simply “facilitates” but someone who actively drives effectiveness, navigates complexity, and enables continuous delivery of value.

Conclusion: Scrum Masters Are Born Fully Formed

A Scrum Master is not a role that should be taken lightly. It is not a career ladder step, nor is it something one can simply “train” into without prior deep experience. The best Scrum Masters emerge naturally from within the team, already demonstrating the mastery required before they ever assume accountability formally.

The Scrum Master role demands mastery across technical, business, and organisational domains. Anything less is inadequate and frankly does not fulfil their obligation to the Scrum Team, the Product Owner, or the business.

If you are looking for a Scrum Master, don’t look at certifications or job titles. Look at the people who have already been leading without the title, those who have already demonstrated their competence in making the team more effective. That’s your Scrum Master.

One such paradigm shift in software delivery is audience-based deployment.

Gone are the days of rigid Dev-Test-Staging-Production pipelines. These traditional environments are costly, slow, and fundamentally flawed . They delay feedback loops, hinder innovation, and reinforce outdated notions of software stability.

Instead, modern software engineering demands a smarter approach: deploying directly to real users in production but in a controlled, incremental manner.

For those familiar with ring-based deployment, audience-based deployment is not a new concept; it expands on it. Ring-based deployment is a proven strategy, widely used at scale by companies like Microsoft with products like Windows and Microsoft Teams. Audience-based deployment simply extends this principle by providing even finer-grained control over who gets access to a given change based on account types, user profiles, or organisational groups. This approach allows teams, like the Azure DevOps team, to release software to small, targeted user groups, enabling faster feedback, reduced blast radius, and progressive rollout strategies.

This approach enables:

• Faster feedback from real-world conditions, not simulated test environments.
• Reduced blast radius by limiting exposure of potentially risky changes.
• Progressive rollout strategies, improving resilience and adaptability.

Retaining Context Without Environmental Branching

While you may need to retain some environmental context for compliance or operational reasons, your branching structure should not model it. Creating branches that mimic Dev-Test-Staging environments is costly and counterproductive. It increases complexity, delays feedback, and reinforces silos rather than fostering continuous delivery . Instead, focus on:

• Using feature flags to control exposure.
• Implementing progressive rollouts instead of environment-based branching.
• Relying on observability and monitoring rather than artificial environments.

By shifting away from rigid environment-based branching, teams can iterate faster and detect issues in real-world scenarios without unnecessary overhead.

I don’t think this is easy; it’s not. Teams making this shift face teething problems; adapting workflows, enhancing observability, and upskilling in DevOps and CI/CD practices. Success here isn’t just technical; it’s cultural. Organisations must embrace automation, foster real-time monitoring capabilities, and embed progressive delivery into their engineering ethos. It requires significant discipline and a relentless focus on the usable working product that many teams just don’t have.

How Microsoft Transformed Deployment

Microsoft’s transformation to DevOps and audience-based deployment has been an industry-defining journey, starting with the Visual Studio and Azure DevOps (was Team Foundation Server) teams in the Developer Division and later extending to Windows and Office.

Key Lessons from Microsoft’s Evolution:

• Be Customer Obsessed – Prioritise user experience and collect telemetry to refine deployments.
• Iterate Over Pain – If it’s hard and painful, do it more often until it becomes just another activity.
• Adopt a Production-First Mindset – Deploy as continuously as possible, with safeguards to protect end-users.
• Enable Team Autonomy with Enterprise Alignment – Empower teams while ensuring strategic cohesion.
• Shift Left on Quality – Detect and address issues earlier in the development cycle.

These were hard-learned lessons from the transition of Team Foundation Server from one delivery every two years to one every three weeks. This was also the catalyst for them to move their product to the cloud, ultimately leading to the Azure DevOps product we have today. There was a key realisation that closing feedback loops is much harder if you are delivering a locally installed product. Not every customer takes every release, and not every customer allows the vendor to truly understand the usage patterns.

If you want to build products that meet your customer’s needs, then you need to get ahead of those needs. If you respond to customer requests, then you are too late to meet their need, and are costing them time and money while you go build what they asked for. Getting ahead of that loop, crossing the chasm, requires that you are able to engage with early adopters and collect telemetry and feedback much closer to the development cycle. Feedback on something that you shipped two years ago is largely useless if your priorities have changed since then.

Audience-based deployment allows you to control which users and which accounts get access to new features. This means that you can start to engage with early adopters even within an organisation where most users are late adopters.

This connection to the users, the telemetry it provides, and the closeness of the feedback to the build that allows you to maximise the value, the ROI, of the work that you do is the business reason to move in this direction.

The Azure DevOps team revolutionised Microsoft’s approach.

The Azure DevOps team revolutionised Microsoft’s approach to deployment by pioneering a ring-based deployment strategy that allowed for:

1. Incremental feature releases with real-time telemetry analysis.
2. Production-first mindset, shifting quality assurance left.
3. Automated stops to rollouts triggered by observed failures.
4. Continuous monitoring to reduce release risk.

This strategy proved so effective that it became the foundation for deploying changes to Windows, an operating system with a vastly larger and more diverse user base. And more scary indeed is that Windows is an installed product that needs to support an almost infinite set of configurations.

Windows: Scaling the Model to Millions

Windows took inspiration from Azure DevOps’ success and implemented the ring-based model at an unprecedented scale:

1. Internal to Microsoft - Im not necessarily privy to the details of this, but there have been hints and stories told by folks on the inside. (~70,000 members)

   1. Internal Channel - Nightly changes tested internally by a small subset of engineers.
   2. Dogfooding Channel – Microsoft employees use new versions before external customers.

2. Windows Insider Program - Anyone can join this just by opting in. (~17m members)

   1. Canary Channel – This is for highly technical users who get builds from the dev branch every few days.
   2. Dev Channel – For enthusiasts; gets builds every few weeks from the dev branch
   3. Beta Channel - This is for early adopters and gets early builds every month or so from the release branch
   4. Release Preview - For those looking for just an early peek but want stability. Builds every 3 months or so from the release branch about 3 months before they hit GA.

3. General Availability - Finally, changes are staged and rolled out to everyone else (~900bn machines worldwide)

This approach enables them to:

• Detect failures early, before they affect millions of users.
• Refine features based on telemetry and user behaviour.
• Confidently scale releases while maintaining stability.

This isn’t just DevOps done well; it’s a learning engine driving continuous improvement across Microsoft’s ecosystem. Today, you will find this model and variants of it on all of Microsoft’s platforms.

For example, I am in the Insider group for Microsoft Teams, with my account in R3, with both R3.5 (preview) and R4 (ga) ahead of me… and yet I can be in a call with folks from any of the rings from R0 all the way to R4. We each get different features and capabilities and a different product stability level.

Why You Should Ditch the Old Way

Beyond the inefficiencies of traditional environments, the old way accumulates waste, relearning, duplicated effort, and maintaining outdated processes, all drain resources. Each additional environment introduces overhead in familiarization, regression testing, and upkeep, diverting attention from work that delivers actual value. The cost isn’t just financial; it’s an innovation tax.

Most organisations still cling to the traditional Dev-Test-Staging-Production model because it feels safe. But let’s be honest:

• Testing environments are never identical to production. Data, scale, and real-world user behaviour differences mean you’re testing a mirage.
• Delayed feedback loops increase risk. The longer it takes to discover issues, the harder and costlier they are to fix.
• It stifles innovation. Slow, gated releases hinder rapid iteration and experimentation .

The alternative? Deploying directly to your users, but smartly.

Making the Shift: Key Strategies for Audience-Based Deployment

We first need to accept that rolling forward is the only viable option! If a team has just failed to roll forward, what makes us think they have the skills to execute the more complex task of rolling back? Rolling back is often more risky than pushing a fix forward, as it can introduce inconsistencies, data mismatches, and unexpected failures. The key is to design rollouts to be fail-safe, ensuring issues are detected early and addressed immediately without needing a complex rollback process.

“I was a big proponent of the rolling forward strategy. 10+ years ago, I said that if a team screwed up a database upgrade, most likely they will not succeed with a database downgrade. Sometimes downgrade means data loss. When we do deployments, we upgrade binaries first by creating new VMs and switch traffic to them. We keep old VMs running for 3 hours, so that we can go back to an old binaries if we detect any user impacting issues. After 3 hours we deallocate VMs, but do not delete them. If we detect an issue 3+ hours after deployment, we can still start VMs and go back to previous binaries. When we start database upgrade, we delete old VMs. At this point there is no going back to an old binaries.” -Vladimir Khvostov, Principal Software Engineer at Microsoft - Azure DevOps

The Azure DevOps team does allow for limited rollback under specific circumstances, but only for binaries, never for data.

Want to embrace audience-based deployment? Here’s how:

1. Feature Flags & Toggles – Control feature exposure dynamically without redeploying code.
2. Progressive Delivery – Gradually expand releases based on telemetry and user feedback.
3. Real-Time Observability – Use logging, metrics, and tracing to detect issues immediately.
4. Automated Rollout Halts – Deployments should automatically pause if telemetry detects anomalies or performance degradations, ensuring issues are caught before they escalate.
5. User Opt-In Programs – Encourage beta testers and early adopters to participate.

The Future of Continuous Delivery

In an interconnected world, production is the ultimate reality check. Audience-based deployment isn’t just an evolution of DevOps,it’s the logical next step in delivering value faster, safer, and smarter.

The question is, are you ready to embrace it?

Is your team still relying on pre-production environments? What’s stopping you from adopting audience-based deployment?

Value exists only when it is realised, and the only way to realise the value in software is to release it.

No matter how well-intentioned or carefully crafted a plan might be, until a product is delivered and used, its potential remains locked away. Each day of delay represents not only a missed opportunity to create value but also an accumulation of costs - from lost feedback to the risks of market irrelevance. Even the best directions and strategies are hypothetical until they are tested and validated through frequent releases . The Standish Group’s CHAOS Report has consistently shown that projects with long, waterfall-style cycles have significantly lower success rates than those with frequent iterations. Only 29% of traditional projects succeed, while agile projects that release frequently succeed 42%-64% of the time. The difference? Rapid, incremental validation of assumptions.

• Are teams delivering working software to at least some subset of real users every iteration (including the first) and gathering feedback?
• Is feedback from users turned into concrete work items for sprint teams on timelines shorter than one month?
• Are teams empowered to change the requirements based on user feedback?

From US DOD: Detecting Agile BS

The reality is simple: value can only be realised through delivery. No matter how clear your direction or how promising your assumptions about value may seem, they are worth nothing until they are tested and validated through release.

Why Frequent Releases Are Critical

Transparency is the cornerstone of both Scrum and Agile. Delivering a usable, working increment at the end of every Sprint provides the baseline for:

• Inspection: Stakeholders and the team can evaluate progress, functionality, and alignment with goals.
• Adaptation: Course corrections based on real-world feedback rather than assumptions.

Without delivery, transparency is lost. You are left with only assumptions, untested and unproven, that create an illusion of progress while value remains unrealised. The DORA ( DevOps Research and Assessment) metrics highlight that teams with shorter Lead Time for Changes (LT) are more competitive, as they can push value to users faster and adapt to market changes in real time. Companies with longer LT are often left struggling to keep pace with customer needs, suffering the cost of missed opportunities.

Every unreleased increment leaves value on the table. Each assumption about value, no matter how well-informed, is a risk. Agile and Scrum are designed to mitigate this risk by focusing on short feedback loops:

• Frequent releases validate value early and often.
• Delayed releases magnify risks, wasting time and resources on work that may not deliver the expected value.

The cost of unrealised value grows exponentially the longer a product remains unvalidated. It’s not just a financial cost but an opportunity cost: the insights, iterations, and refinements that could have been gained from early feedback are lost. Change Failure Rate (CFR), another DORA metric, consistently demonstrates that larger, infrequent releases are more prone to failure. By releasing smaller, more frequent updates, organisations can mitigate risk and ensure smoother deployments.

What happened with Windows 8?

For example, I’d offer the outcome of the release of Windows 8 after 6 years of engineering and 6 years of UI/UX validations as evidence of this folly… all be it a significant one. Microsoft spent millions on the work that you would expect around validating that they were doing the right thing in labs and prototypes. It was not until the first Beta of Windows 8 that the true extent of the backlash became evident… but it was too late to do anything about it. The release of Windows 8 wiped billions off Microsoft brand loyalty and recognition, a loss that they have only recently recovered from. Had Microsoft leveraged frequent, iterative releases and shorter feedback loops, they could have detected these issues years earlier, before they became a full-scale business risk. Which is what the changes for Windows 10 were all about, and why we skipped Windows 9. Clear delineation of brand, and a new licence and release model that focused on frequent, iterative releases and shorter feedback loops. Windows 11 is a product delivered almost continuously to production with thousands of people getting daily builds and millions getting weekly.

The Cost of Delayed Delivery

To illustrate, consider a hypothetical scenario: a team works tirelessly for a year, refining their understanding of value and direction. At the end of that year, they release a product that indeed delivers value. But at what cost?

• Lost Value: During that year, customers could have been engaging with early increments, providing critical feedback, and validating assumptions. Each missed iteration represents an unrealised value.
• Opportunity Cost: Competitors may have released sooner, capturing market share and leaving the delayed team playing catch-up.
• The Lack of Adaptation: With no increments released, the team had no chance to inspect, adapt, or pivot. The final product, while valuable, is a result of guesswork rather than empiricism.

Teams that release infrequently also face longer Mean Time to Restore (MTTR), as failures in large deployments take significantly longer to diagnose and fix. Research from DORA indicates that high-performing teams restore service 168x faster than low-performing teams, primarily due to frequent, smaller releases that allow for quicker recovery from incidents.

Scrum and Agile advocate for frequent releases precisely to avoid these costs. The feedback gained from early and frequent releases is invaluable in steering the product towards maximum value with minimal waste.

Conclusion: Delivery Turns Assumptions Into Value

The act of delivering usable increments frequently is not just a practice; it is the foundation of everything else. Everything before delivery is an assumption, and all non-delivered product represents a cost of delay.

Every unreleased increment represents value left on the table. Every delay increases the cost of missed opportunities, lost feedback, and unnecessary rework. By releasing frequently, teams unlock the full potential of Agile, ensuring that value is realised early, often, and with confidence.

Delivering the right thing at the right time begins with getting it into the hands of users as early and as often as possible. Anything less is just an expensive assumption.

TL;DR

If teams still promote code through a Dev → Test → Staging → Production model, they are doing it wrong. This model inevitably leads to a branch promotion strategy, adding friction, increasing risk, and delaying value delivery .

• GitHub Flow is a simple option for continuous delivery .
• Release Flow is a good choice when production needs to exist for some time.
• Git Flow? That bloated mess belongs in the past.

Branching should be a tool to support flow, not an administrative overhead that slows everything down. If a model requires multiple merges to get code into production, it is already behind. Reverse integration, which involves pulling changes from downstream branches back into upstream branches, is fraught with danger and should be avoided.

The Failure of the branch Promotion Model

This model was meant to provide structure and control, but in practice, it leads to teams confusing environments with branches.

The typical pattern looks like this:

1. Code is committed to a Dev branch.
2. It moves to a Test branch for QA.
3. It advances to a Staging branch for approval.
4. It is finally merged into Production.

What started as an environment management strategy becomes a branch promotion model, where:

• Features wait in queues instead of shipping immediately.
• Merge conflicts create unnecessary rework.
• Hotfixes bypass the process, breaking consistency.
• Rollbacks require painful cherry-picking instead of simple toggles.
• Reverse integration causes unpredictable failures and last-minute surprises.

This is a linear, gated approach that kills agility. Instead of focusing on delivering value, teams get stuck in a cycle of merging, resolving conflicts, and firefighting. Reverse integration only amplifies the chaos, introducing instability at the worst possible moments.

Branch Promotion is a Symptom of Organisational Dysfunction

If teams are passing code between branches like a baton in a relay race, they are reinforcing a broken process. This is just waterfall with more Git commands.

Instead of treating branches as milestones, teams should focus on continuous integration and delivery. That means:

1. Every change merges into main as soon as it is ready.
2. Deployment is decoupled from release using feature flags.
3. Testing happens in production-like environments without blocking releases.
4. Rollbacks are instant; simply toggle a flag instead of reverting code.

Reverse integration breaks this model by introducing last-minute, untested changes into upstream branches, increasing risk and eroding confidence in deployments. Instead of integrating forward with stability, teams are forced into reactive fixes that create further instability.

This eliminates the bottlenecks of branch promotion. Instead of waiting weeks for a merge to move through environments, code is always deployable.

Supporting Multiple Versions in Production

Branch promotion models often significantly increase cognitive load as engineers may be forced to support multiple versions in production. This excessive complexity increases the chances of reverse integration, where engineers must back-port features and fixes to different production versions, introducing further instability.

In these scenarios, Developers face constant challenges in tracking which code changes apply to which versions, leading to a higher risk of errors and regressions. Maintaining multiple live versions not only complicates testing, debugging, and feature rollouts but also makes it nearly impossible to ensure consistency across environments.

An extreme version of this is branch-by-customer, where separate branches are maintained for different clients. This is one of the most unmanageable and expensive practices, requiring extensive manual effort to maintain, patch, and update. Merging changes across multiple customer-specific branches is error-prone and time-consuming, leading to unpredictable behaviour and instability. Avoid at all costs.

Git Flow

Git Flow was an attempt to support many of the old branching models, but it is a bloated relic that needs to die! If teams are still using Git Flow, it is time to stop.

It introduces:

• A develop branch that adds unnecessary friction as it needs to be integrated into main.
• release/\* branches that delay deployment.
• hotfix/\* branches that signal a broken process.

Teams that adopt Git Flow reinvent branch promotion, creating an overcomplicated merge-heavy workflow that belongs in the past.

Mainline Branching Practices

The alternative is to use trunk or mainline development where all code is integrated continuously into the main, and there are only ever short-lived topic branches for a few developers to work together on something small.

The two main options relevant here are GitHub Flow and Release Flow.

GitHub Flow

One of the easiest to understand, implement, and do well is GitHub Flow. For most teams its the only branching model they will need as it provides that speed and simplicity that enable fast turnarounds and low cognitive load. It looks like:

1. Developers work in short-lived feature branches.
2. They open a pull request against main.
3. Code is reviewed, merged, and deployed immediately.

One would expect the pull request to be as automated as possible within the context of modern software engineering practices :

• Automated tests to validate every change.
• Continuous deployment to eliminate hand-offs.
• Observability and monitoring to detect issues early.

Reverse integration is completely unnecessary in GitHub Flow because all changes integrate forward, reducing complexity and risk.

Release Flow

For teams that need to support multiple versions in production, Microsoft’s Release Flow extends GitHub Flow without unnecessary complexity for the specific purpose of having a release version that you need to help until the next release is ready. Microsoft developed this because it took longer than their 3 weeks for Sprint to deploy new versions of Azure DevOps to the thousands of databases that they used.

• All work merges into main.
• When a release is ready, a version branch (e.g., release/1.2) is created.
• Fixes are always made into the main and cherry-picked into the release branches or, if necessary, implemented again.

This keeps development fast while maintaining stability where needed. It avoids regression by always fixing into `main`. Critically, Release Flow continues to avoid the pitfalls of reverse integration, ensuring that all changes move forward in a controlled, predictable manner.

Keep It Simple, Keep It Fast

Branching should enable fast delivery, not slow it down.

• Want to ship continuously? Use GitHub Flow.
• Need to maintain live versions? Use Release Flow.

If teams still promote branches through environments, it is time to rethink the strategy. Reverse integration is a dangerous practice that adds unnecessary risk and complexity. The best branching model is the one that gets in the way the least. Stop promoting branches. Start delivering value.

TLDR;

Modern software engineering practices have made it easy to ship to production and validate that your product is of a quality level that would allow it. I would expect every Scrum Team to:

• deliver working software to at least some subset of real users every iteration, including the first
• turn feedback from users into concrete work items on timelines shorter than one month
• change the requirements based on user feedback

At a very minimum, I expect them to deliver their increments to production at least once per Sprint, preferably continuously.

Delivery as the Fundamental Measure of Progress

Scrum Teams are measured not by what they start but by what they finish, and more importantly, by what they deliver. A Done Increment is only as valuable as its ability to drive change and provide feedback in the hands of real users. Anything less is just inventory.

It’s time to shift the focus: delivery is not an afterthought, it is the measure of progress. In the 1990s, releasing software to production was a cumbersome, risky process, and the Scrum Guide was written in that world. Today, with modern DevOps capabilities, continuous delivery is not just possible, it is expected.

If a Scrum Team is producing Done Increments but not delivering them, they are not actually doing Scrum, they are simply simulating progress.

Done Is Not Enough

A Done Increment, according to Scrum, meets the Definition of Done : it is properly tested, meets quality standards, and is potentially shippable. But potential is not value, realised value comes only from delivery.

The distinction between Done and Delivered is simple:

• Done means the work meets an internal quality standard.
• Delivered means the work has been put into production and is creating impact.

If an Increment remains in staging or internal QA, it does not matter how refined or polished it is, it is not delivering value.

Why This Matters

The speed of market responsiveness defines competitive advantage today. A product that remains undelivered provides no feedback, no learning, and no adaptation. Organizations that mistake Done for Delivered risk falling behind more responsive competitors who understand that speed to value is everything.

A feature sitting on a shelf has the same business impact as a feature that was never built.

Delivery is what separates successful Scrum Teams from ineffective ones.

How to Ensure Delivery Becomes the Default

Scrum Teams must reframe their Definition of Done to include deployment while ensuring that they don’t inadvertently compromise it. Every Sprint should result in increments that go into production. Here’s how teams can bridge the gap:

1. Automate Everything

   If your release process requires manual intervention, it is a liability. CI/CD pipelines eliminate constraints and ensure every increment is delivered safely and efficiently. Don’t end up like the Knight Capital Group or CrowdStrike.

2. Treat Delivery as a First-Class Citizen

   The goal of every Sprint should not be to produce an increment, it should be to deliver value. A backlog item is not complete until users are benefiting from it.

3. Inspect User Impact, Not Just Internal Quality

   Sprint Reviews should not be about demonstrating functionality in a staging environment; they should be about real user impact. What changed for the customer? What insights did we gain from their usage?

4. Break Down Barriers

   Silos between development, operations, security, and compliance must be removed. Cross-functional teams should be fully empowered to deploy without external dependencies.

5. Make Undelivered Work Visible

   Track work that is “Done but not Delivered.” If work is piling up, ask why. This is an issue of flow, not just completion.

Remember usable working product is how we manage risk and deliver value . If you are not delivering, you are not managing risk, and you are not delivering value.

Conclusion

In 2025, there is no reason why a Done Increment should not be delivered. The tools, practices, and knowledge exist. The only thing standing in the way is outdated ways of thinking.

Delivery is no longer just an aspiration, it is the fundamental measure of progress. The ability to deliver frequently, safely, and reliably is what makes a Scrum Team truly professional.

The question is no longer “Are we Done?” but “Have we Delivered?”

Let the record show that I believe that, if you’re in the kind of organisation that will still fund Scrum Masters despite a long-in-the-tooth Scrum adoption, then you can bet your ass the Scrum Master is accountable for delivery. That’s because they should be facilitating the “aha” moments required of the team to address things like capacity, understanding, and level-setting with product and stakeholders when goals are just too big or infeasible.

Elle Anderson

Scrum Masters should embrace their accountability for creating an environment where delivery is not just possible but inevitable. Effectiveness begins with delivery, then expands to encompass value, learning, and continuous improvement. This dual focus ensures that the Scrum Team not only meets the minimum bar but thrives well beyond it.

The Scrum Master is accountable for Delivery

The success of a Scrum Team begins with their accountability for delivering a usable, working product at the end of every sprint, including the very first one. This principle is the backbone of Scrum’s empirical process, ensuring the team generates valuable feedback for continuous improvement of their product and the system. A working increment is non-negotiable; without it, there’s no way to inspect and adapt effectively or measure progress towards the team’s goals. By focusing on delivery as the minimum bar for effectiveness, the Scrum Team builds a foundation that doesn’t just deliver but delivers value consistently.

Effectiveness is More Than Delivery, but Delivery is a Minimum.

The accountability of the Scrum Master for delivery

At the heart of this framework lies the Scrum Master, who holds a pivotal accountability: enabling an environment where delivery becomes not just possible but inevitable. This accountability isn’t about executing the work but ensuring the team has the resources, strategies, and support needed to thrive.

The Scrum Master is accountable for the effectiveness of the Scrum Team, and to achieve that, they need to have a level of authority that fits the context of the Scrum Team and the organisation. Ideally, they can pursue this accountability using influence and leadership , but in many organisations, this is impossible without an appropriate level of authority.

Can a Scrum team be considered effective if they don’t deliver? The Scrum Master is accountable for the team’s culture and its collective ability to effectively deliver value each and every Sprint. If they fail to fulfil that accountability through the inability of the Scrum Team to deliver value, then they should be held accountable for that failure by the business. The Scrum Guide makes it clear that the Scrum Master’s accountability for the team’s effectiveness inherently ties to delivery, as the production of a usable increment every sprint is the foundational measure of a team’s success. The business holding the Scrum Master accountable for delivery in no way dilutes the collective accountability of the Scrum Team; instead, it reinforces the importance of every team member’s role in achieving this shared goal.

It’s entirely likely that your next Scrum Master will be your manager .

But what about the Scrum Team’s Shared Accountability for Delivery?

The Scrum Guide (2020) makes it clear: the entire Scrum Team is accountable for delivering a valuable, useful increment every sprint. That said, while delivery is a collective responsibility, the role of the Scrum Master has a unique slant: they are not players on the field but the coach. Their accountability lies in fostering an environment where effective delivery can happen consistently.

Using a football analogy, the coach is ultimately held accountable for the team’s performance. They are responsible for strategy, facilitation, and ensuring the team has the resources and focus needed to succeed. The players, however, still own the execution. In Scrum, the Scrum Master is similarly accountable for enabling outcomes, not by doing the work themselves but by ensuring that the Scrum framework is effectively applied and the team functions optimally.

While the entire Scrum Team is accountable for delivery, the Scrum Master ensures the conditions for success by addressing systemic issues and empowering the team to work efficiently.

Effectiveness Beyond Delivery

Effectiveness in a Scrum context spans far beyond simply delivering increments of software. However, let’s be clear: delivery is the baseline. Without delivery, the concept of effectiveness becomes moot. As I often say, “Effectiveness starts with delivery.” From there, we can layer on concepts like:

1. Delivering Meaningful Value: Effectiveness isn’t about shipping anything and everything in the backlog. It’s about delivering increments that provide tangible value to the customer and the organisation. Efficiency doesn’t mean you’re effectively delivering meaningful and impactful things.

2. Maximising Value While Minimising Waste: A truly effective team doesn’t just execute orders. They challenge assumptions, reduce unnecessary work, and focus on outcomes, not output. Scrum Masters facilitate this by fostering a culture of curiosity and continuous improvement.

3. Empowering Autonomous Teams: The hallmark of an effective Scrum Master is the ability to cultivate a team that self-manages and self-optimises. This requires creating psychological safety , enabling conflict resolution, and empowering the team to make decisions.

4. Collaborating with Adjacent Teams: Effective Scrum Masters actively work with and enable adjacent teams to align efforts, remove cross-team dependencies, and foster organisational coherence. By promoting collaboration across teams, they ensure a seamless flow of value delivery across the organisation.

5. Fulfilling Organisational Accountability: The Scrum Master has an accountability to the organisation beyond the team. This involves educating leadership about Scrum, advocating for systemic improvements, and helping the organisation embrace new ways of working. By bridging the team and the broader organisation, Scrum Masters enhance alignment and drive strategic value.

Why Delivery Is the Minimum Bar

Here’s the reality: without delivery, there is no effectiveness to measure. Consider the Agile Manifesto’s first principle: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Delivery is not the end-all-be-all, but it is the minimum bar of competence for a Scrum Team. A team that consistently fails to deliver usable increments cannot claim to be effective, no matter how skilled or engaged they are.

Although from a single instance, this quote embodies the common failure of Scrum Teams to even meet this minimum bar:

The code that was done never arrived at production, nor did it come close to meeting DoD’s requirements, and by most standards, we did not deliver anything.

While the team may have contributed to organisational learning or questioned the value of a particular initiative, their inability to deliver working software regularly is antithetical to Scrum. Cancelled sprints or pivots in direction are valid within the framework, but they do not negate the fundamental expectation: each sprint ends with a usable increment.

Effectiveness requires delivery, but delivery itself is not the sole measure of effectiveness. It is, however, the critical foundation. A football team that consistently fails to score cannot be described as effective, no matter how skilled its players may be.

The Scrum Master’s Accountability in Delivery

The Scrum Master is a lean -agile practitioner with technical mastery , business mastery, and organisational evolutionary mastery that can provide training, coaching , & mentoring as needed within the context of the team, the product, and the organisation. This is not an entry-level position but represents an experienced product professional who can enable the whole Scrum Team to take accountability for delivery by:

• Ensuring Transparency : Helping the team and stakeholders maintain clarity on progress, impediments, and value delivery through well-facilitated events and effective artefacts.
• Removing Impediments: Proactively identifying and enabling the removal of blockers that hinder the team’s ability to deliver.
• Enabling Technical Excellence : The Scrum Master should have sufficient technical skills within the Scrum Teams’ work context to advocate for and enable practices like design patterns, Test-Driven Development (TDD), automated testing , and continuous integration , all of which are critical for sustainable delivery. Great Scrum Masters will also be able to teach these techniques.
• Facilitating Empiricism: Supporting the team in working empirically by fostering a cadence of inspect and adapt cycles, ensuring that learning is continuously integrated into delivery.

When delivery falters, stakeholders naturally look to the Scrum Master to understand and address the root causes. By taking ownership of systemic issues and facilitating improvements, the Scrum Master ensures the team’s consistent ability to deliver effectively.

They take accountability for delivery!

Here’s the kicker: handoffs are not Lean, Agile, or DevOps . They are an anti-pattern that introduces waste, increases cycle time , and makes collaboration difficult.

TL;DR

Handoffs are a silent killer in software development. They create inefficiencies, reduce quality, and destroy agility. If your organisation is still riddled with handoffs between siloed teams, you are doing it wrong. Embrace cross-functional teams, optimise for flow, and maintain organisational hygiene to ensure only the minimal set of rules and alignments needed to deliver value effectively. Together, these practices protect your ability to focus on creating value.

What Are Handoffs?

Handoffs occur when one team or individual completes a task and passes it to another team for further work. Examples include:

• Developers handing off features to testers.
• Testers handing off validated features to operations.
• Business analysts tossing requirements over the fence to developers.

Each of these transitions is a point of failure, introducing delays, miscommunication, and opportunities for rework.

The Hidden Costs of Handoffs

Handoffs come with a plethora of hidden costs that undermine agility and efficiency. Compounding these challenges is the build-up of organisational cruft, rules and processes that outlive their usefulness. This cruft can further slow progress and obscure value delivery . Each of these costs impacts not only the immediate work but also the organisation’s ability to deliver value quickly and sustainably.

1. Loss of Context: Valuable information is lost when tasks move from one team to another. Teams waste time trying to re-establish the original intent. Moreover, the cost of context switching exacerbates this issue. When questions arise that cannot be answered immediately, team members often feel compelled to start new tasks, increasing work in progress (WIP) which in turn increases cycle time. This leads to further delays and amplifies the loss of context, making it even harder to regain clarity and focus on the original work.

2. Increased Cycle Time: Every handoff introduces a delay, pushing your delivery timelines further out. This delay often stems from an increase in batch size as teams attempt to locally optimise for handoffs, which ironically leads to even longer cycle times. Larger batch sizes also bring significantly higher risk, as larger changes are more prone to defects and harder to integrate.

3. Reduced Quality: Misunderstandings and lack of accountability often lead to defects and lower overall product quality. The increase in cycle time and the loss of context also contribute to growing technical debt , making it much harder to identify and fix bugs in larger deployments. This, in turn, further degrades the overall quality and increases the risk of failures in production.

4. Decreased Morale: Team members stuck in silos feel disconnected from the bigger picture, leading to frustration and burnout. This disconnect erodes their sense of purpose, a critical element in achieving “autonomy, mastery, and purpose” as described in Daniel Pink’s Drive. Without a clear connection to the end-to-end delivery of value, team members lose motivation and struggle to see the impact of their work.

Together, these hidden costs act as multipliers, compounding each other and magnifying the negative impact on your organisation’s ability to deliver high-quality software efficiently. Addressing one cost often reduces others, making it crucial to tackle these issues holistically.

Why Do Handoffs Persist?

Handoffs are a symptom of functional silos. Organisations that structure themselves by discipline (e.g., separate teams for development, testing, and operations) create natural barriers to collaboration. This approach is a holdover from the “Scientific Management Method” developed during the Industrial Revolution when workers were mechanised to optimise for narrow, repetitive tasks rather than holistic, value-driven outcomes. Even well-meaning attempts to implement Agile often retain these silos, resulting in what I like to call “ hybrid Agile ” , a mismatched combination of Agile practices and traditional command-and-control management. This ineffective blend perpetuates the very silos and inefficiencies that Agile aims to eliminate.

The Solution: Eliminate Handoffs

Eliminating handoffs requires a mix of modern engineering practices and a commitment to automation. By automating repetitive tasks and adopting strategies like “testing in production,” organisations can significantly reduce the friction and delays associated with traditional handoffs. This approach enables faster feedback loops, improved quality, and a seamless delivery pipeline.

To achieve true agility, a focus on eliminating handoffs is necessary by implementing cross-functional teams and optimising flow. Here’s how:

1. Create Cross-Functional Teams - Bring together individuals with all the skills needed to deliver end-to-end value. A cross-functional team might include developers, testers, designers, and operations personnel working collaboratively towards a shared goal. No sub-teams. No silos.

   Pro Tip: Co-locate teams in timezones and use collaboration tools like Microsoft Teams or Slack to ensure seamless communication.

2. Adopt Continuous Delivery Practices - Automation is a cornerstone of Continuous Delivery (CD). By integrating automated testing , deployment, and monitoring into your pipeline, you ensure quality at every step while reducing manual intervention. Moving towards “testing in production” becomes a natural evolution of this strategy, allowing teams to gather real-world feedback quickly and address issues proactively.

Continuous Delivery (CD) eliminates the need for separate testing or deployment phases. Build pipelines that automatically validate and deploy changes, ensuring quality at every step.

3. Leverage Test-First Development - Adopt Test-Driven Development (TDD), Behaviour-Driven Development (BDD), or Acceptance Test-Driven Development (ATDD). Writing tests first ensures clarity and reduces rework, as discussed in You are doing it wrong if you are not using test first .

4. Minimise Work in Progress (WIP) - Limit WIP to reduce context switching and improve focus. A lower WIP means fewer handoffs and faster delivery cycles.

5. Invest in Collaborative Refinement - Backlog refinement should be a team sport. The entire Scrum Team , including the Product Owner and Developers , must collaborate to clarify and break down work items. See more in If your backlog is not refined then you are doing it wrong .

6. Shift Left and Own It - All of these practices contribute to a “shift left” strategy, where quality, security, and deployment considerations are addressed earlier in the development lifecycle. Ultimately, the team that creates a feature should also own it in production, including gathering and acting on feedback. This end-to-end ownership fosters accountability, ensures quicker feedback loops, and allows teams to continuously improve based on real-world usage.

Organisations inevitably accumulate cruft, unnecessary rules, outdated processes, and misaligned practices. These accumulate quietly over time and, if left unchecked, undermine agility and the ability to focus on value creation. To combat this, periodic acts of organisational hygiene are essential. These involve critically assessing and removing unnecessary constraints, ensuring the organisation maintains only the minimal set of rules and alignment required to deliver value effectively. When combined with a shift-left approach and a relentless focus on flow, these practices help organisations stay lean, adaptive, and aligned with their goals.

Handoffs might seem inevitable in large organisations, but they are a choice. By reorganising your teams, adopting modern engineering practices, and embracing a Lean-Agile mindset, you can minimise handoffs and unlock true agility.

Remember: every handoff is an opportunity for waste. Eliminate them, and watch your teams thrive.

References

1. Daniel Pink, Drive: The Surprising Truth About What Motivates Us
2. The 2020 Scrum Guide - Scrum.org
3. Martin Hinshelwood, You are doing it wrong if you are not using test first - NKD Agility
4. Martin Hinshelwood, If your backlog is not refined then you are doing it wrong - NKD Agility
5. The Agile Manifesto - AgileManifesto.org
6. Don Reinertsen, Principles of Product Development Flow

What challenges has your team faced in eliminating handoffs? Share your experiences and thoughts in the comments below. Let’s start a conversation about how we can all build better, faster, and more collaborative teams!

Contrast this with the Definition of Done (DoD). The DoD is your team’s objective compass, a binary, quantifiable checklist that ensures every Increment meets professional-grade quality. It’s non-negotiable and should be firmly rooted in your product’s brand, user expectations, and technical robustness.

TL;DR:

Don’t confuse subjective goals with objective quality. In Scrum, the Definition of Done (DoD) is a crucial, measurable bar of quality, not a negotiable outcome. Keep it clear, objective, and automated wherever possible to ensure that every Increment meets professional standards.

Product and Sprint Goals: Subjective by Design

Goals in Scrum are aspirational, meant to challenge teams and align efforts towards strategic outcomes. The Product Goal represents a long-term objective, while the Sprint Goal offers a short-term milestone. Together, they guide the team like a compass through the wilderness., helping maintain direction even through surprise obstacles and side quests. However, achieving these goals isn’t always guaranteed. Progress is iterative, incremental, and constantly adapting to new insights - a bit like chasing a moving target.

Definition of Done: The Objective Measure

Unlike goals, the Definition of Done is a steadfast benchmark for quality. It defines the bare minimum for an Increment to be considered complete. Without it, teams risk releasing poorly constructed, subpar products that erode user trust and damage the brand. A solid DoD ensures consistent quality across all deliverables, instilling confidence in both internal teams and end users.

Establishing a Solid Definition of Done

There is a key message in the Scrum Guide that is often overlooked that plays a critical role in establishing the DoD.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product. - Scrum Guide 2020

For me this suggests that there should be some kind of Organizational or Product DoD. I think of this as comming from the business. This is driven by the business and should reflect the businesses intent for quality in the product. That might be the minimum level of quality required by the business to protect their brand, their customers, and their employees.

An example of a Organizational or Product DoD for a team working on a cloud product might be:

“Live and in production, gathering telemetry that supports or diminishes the starting hypothesis.”

This sets a clear bar for delivery while supporting empirical learning and iterative improvement. It stays clear of the technical detail and jargon of an individual teams DoD and focuses on its objective and purpose for the product. It implies much, from ideation to delivery while minimizing imposition on the teams. It creates alignment of intent while maintaining autonomy of implementation. It recognizes that every team needs a unique DoD that is relevant for their context.

Each team working on a product would then be responsible for creating a DoD that is appropriate for their context within that product.

This is the seed that will grow into each teams unique quality bar that reflects this DoD. A robust reflection should be:

1. Objective and Measurable: Avoid vague criteria and instead focus on things that you can measure.
2. Comprehensive: What are all the things that need to be true for a production deployment of your product to be deployed to production?
3. Living Document: The teams DoD as needed to reflect evolving standards, technologies, and stakeholder expectations of the product as it grows.

Common Pitfalls

Despite its critical importance, the DoD is often misunderstood, undervalued, or even undermined. Teams frequently:

• Blur Subjective and Objective: Adding criteria like “approved by the Product Owner ”, which shifts focus from quality to stakeholder satisfaction. Any “approved by … person or department” should be strictly avoided.
• Overlook Automation: Relying on manual checks leads to inconsistencies and slower feedback loops.
• Treat the DoD as a Maximum: Viewing it as a ceiling instead of a floor hampers innovation and improvement.

Practices for Defining Done

To maintain focus on quality, consider the following practices:

1. Automate Everything: Automated tests and CI/CD pipelines should validate DoD compliance as part of the development process. If you have things that cant be automated right now, plan the work to change the product to enable those activities to be automated.
2. Review Regularly: Incorporate DoD reviews in retrospectives to ensure its relevance and alignment with current product and organizational needs. Keep a list of “things that need to be true to deploy to production that we cant do yet”, and regularly move these to Done.
3. Train Teams: Ensure every team member understands the DoD and its importance in delivering professional-grade Increments.
4. Separate Quality from Approval: Keep subjective approval processes distinct from the DoD to avoid undermining its objectivity.

Conclusion: The Quality of Done

In Scrum, the Definition of Done is your minimum bar for quality. It’s the safeguard against technical debt , the foundation for stakeholder trust, and the cornerstone of professional-grade delivery. By keeping your DoD objective, measurable, and focused on quality, you empower your team to build products that meet, and often exceed, user expectations. Remember, the DoD is a minimum bar, not a maximum aspiration. Raise it periodically and watch your product’s quality soar.

What’s Your Take?

We’d love to hear your thoughts! How does your team define and enforce the Definition of Done? Have you faced challenges distinguishing subjective goals from objective quality measures? Share your experiences and insights in the comments below!

A significant portion of Scrum Masters (about 61%*) have either never read the Scrum Guide, lack technical proficiency relevant to their teams, or have only a superficial grasp of how to apply Scrum principles.

It’s no wonder many are being laid off.

Frankly, I’m not surprised, and I’d argue that most Scrum Masters are incompetent and should be let go. Unfortunately, some of the 39%* who are competent are also being affected by these layoffs.

Why are we here?

About 15 years ago, as “agile” was gaining widespread attention, the supply of individuals with strong technical, business, and organizational expertise remained relatively limited. Building those skills takes time, and the initial talent pool was small.

Faced with increasing demand for teams and products, companies worldwide struggled to find qualified people. As a result, they pressured recruiters to fill positions quickly. Since there weren’t enough skilled candidates available, companies lowered their standards, filling roles with individuals who had only completed a two-day PSM/CSM certification course.

Thus, the position we found ourselves in pre-pandemic!

The recent challenges to economic stability have led most companies to “tighten their belts,” prompting a closer evaluation of the value they receive for their spending. Agile Coaches and Scrum Masters have largely failed to make a measurable difference, or even to define metrics by which their impact could be assessed. After more than 20 years of agile methodologies, there are still no clear standards or ways to measure the effectiveness of Scrum Masters. Without measurable impact, companies are questioning the need for the expense.

However, many companies that have reduced their number of Scrum Masters are still hiring, just with higher expectations. Now, they demand competence . They want to know exactly how a Scrum Master will contribute to the business’s success and how that impact will be measured.

What should a Scrum Master for a software team know?

The core accountability of a Scrum Master is the effectiveness of the Scrum Team ! Can you help them be effective if you don’t understand the practices within that team’s context? Of course not, but what does that look like? What are the practices that you should expect your Scrum Master to understand?

“A Scrum Master is a lean agile practitioner with techical mastery, business mastery, and organsiational evolutionary mastery!” - Lyssa Adkins**

I would expect a Scrum Master for a software team to know:

• Scrum: its values, underlying principles, and how to apply them effectively. This includes understanding the Scrum framework (roles, events, artefacts) and the purpose behind each element.

• DevOps: understand the three ways of DevOps, common practices, and how to apply them effectively. This means knowing automation, infrastructure as code (IaC), and continuous feedback loops.

• Modern Engineering practices : everything from DevOps, plus… CI/CD, SOLID principles, test-first strategies, progressive rollout strategies, feature flags, 1ES ( One Engineering System ), observability of product. Familiarity with design patterns, refactoring, and coding standards.

• Agile/lean beyond Scrum: a strong understanding of other Agile/lean philosophies like Kanban , XP (Extreme Programming), and TPS. Know when and how to integrate elements from other frameworks and strategies to complement Scrum.

• Release Planning: understanding what release planning entails, how to break down product roadmaps, and how to forecast releases while balancing priorities. Be able to facilitate discussions with the Product Owner and Developers about product increment goals.

• Product Discovery & Validation: understanding what needs to be built and how to make decisions based on limited knowlage. Know and understand evidence-based management and hypothesis-driven engineering practices.

• Stakeholder Management: understanding how to work with stakeholders, communicate progress, manage expectations, and foster alignment. Know how to teach the team to shield themselves from external pressure while still delivering value.

• Scaling Agile: Understand frameworks for scaling Agile, such as Descaling, LeSS, or Nexus. Be able to coach teams on how to function effectively within a scaled environment and manage dependencies.

• Coaching and Facilitation Skills: the ability to coach the team towards self-management, continuous improvement , and collaboration. Skilled in facilitation techniques like liberating structires to be able to facilitate meetings and events.

• Conflict Management: possess the ability to navigate the grone zone safely leverage managed conflicts within the team and foster a healthy team environment for ideation and discovery. Understand team dynamics and how to encourage constructive feedback and communication.

• Metrics and Continuous Improvement: familiarity with Agile metrics (e.g., Cycle Time , Work Item Aging, Work In Process, Throughput ), and how to use them to enable improvement. Ability to encourage the team to reflect on these metrics and find ways to improve.

While the Scrum Master may not directly perform the tasks mentioned above, they are accountable for ensuring that these tasks are carried out effectively. This involves training and mentoring teams in the necessary practices, and once the teams have a solid understanding, knowing when to shift towards coaching and facilitating the team, their stakeholders, and the broader organization.

When everyone around is incompetent, competence looks like an ideal!

Some have pushed back, saying this list is too idealistic. However, I see it as the starting point for a Scrum Master, not the end goal. While someone is on their journey to becoming a Scrum Master, they should be working within a team and learning. All the foundational knowledge is covered, at least at a beginner level, in courses like APS, APS-SD, PSM, PSPO, and PSK. That’s roughly 90 hours of classroom time, or just over 11 days of learning.

Does that make you an expert in all these areas? No, of course not, that would be unrealistic. But it’s a start. It’s about knowing these processes and practices exist and having the opportunity to try them out within a team.

Theory and Practice….

“Without theory, there is no learning. That is, without theory, there is no way to use the information that comes to us. We need a theory for data. We need a theory for experience. Without theory, we learn nothing.” - W. Edwards Deming***

Reference

• * Assessment of knowledge based on Scrum Match model and their published data

• ** Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins

• *** System of Profound Knowledge by W. Edwards Deming

Yet, teams often overlook these clear signals. This raises the question: Why does such a disconnect exist between receiving these critical signals and acting on them? What barriers within teams and organizations prevent them from hearing and responding to these alerts?

We can draw parallels to Toyota’s manufacturing process and its concept of the “andon” chain. This chain enables any worker to stop the entire production line upon detecting a flaw, addressing problems immediately instead of allowing defective products to proceed. This approach, critical to Toyota’s quality assurance, symbolizes a commitment to excellence and continuous improvement .

When American car manufacturers adopted this concept, they installed the physical chain, but workers hesitated to pull it. The underlying fear was that stopping the line would result in punitive measures rather than being viewed as a positive step toward quality maintenance. This situation reveals a profound truth: the effectiveness of such systems lies not in their physical presence but in the culture and philosophy that empower their use. Thus, it’s not the “andon” chain that’s broken; it’s the systemic failure to foster an environment that encourages and values its use.

This analogy highlights the challenges of implementing Agile and Scrum within organizations. These philosophies act as the software development and product management ’s “andon” chain, signaling when something goes wrong and necessitating action. However, if an organization’s culture or a team’s mindset does not align with principles of transparency , continuous improvement, and feedback responsiveness, these signals will remain ignored.

The primary barrier often stems from fear, fear of repercussions, fear of change, or the inertia of existing practices that discourage deviation from the norm. A lack of understanding or commitment to Agile and Scrum’s underlying philosophies may also contribute to a superficial implementation that fails to capitalize on these frameworks’ full potential.

To reap the benefits of Agile and Scrum, organizations must cultivate a culture that not only listens to but also values and acts upon the signals these philosophies provide. This involves creating an environment where halting the metaphorical production line to fix issues is celebrated rather than discouraged, embedding continuous improvement into the organization’s DNA, and deeply understanding and practising the principles of the Agile Manifesto and the Scrum Guide.

Only then can organizations address the systemic issues blocking success, paving the way for meaningful and sustainable improvement.

The program structured around a series of sprints in Minecraft, aimed to mirror the real-world complexities and dynamism present in product development projects. Starting from the initial chaos of Sprint 1, where participants grappled with the inherent complexity of a new project, the program progressively unfolded to reveal the power of Scrum. By Sprint 2, the fruits of understanding empiricism and embracing a philosophy of flexibility were evident. The teams learned to navigate and adapt to complexities with much less stress and frustration.

However, it was Sprint 3 that truly tested the resilience of the system we had built. With the introduction of unforeseen challenges, such as mobbing in Minecraft and the accidental loss of the project world, the teams were thrust into a scenario of significant complexity. Yet, the response was remarkable. The team’s ability to quickly organise, adapt, and maintain direction despite these surprises highlighted the real power of Scrum. It wasn’t about rigidly adhering to rules but about maintaining enough structure to guide while allowing for adaptability to unforeseen challenges.

This experience was not isolated to the Minecraft world. In a real-world scenario, one of the participating teams faced the need to cancel a Sprint due to a shift in business direction. Their response, a seamless adaptation to extend the next Sprint while maintaining the cadence for stakeholders, exemplified the philosophy of Scrum. It’s about choosing how to handle exceptions, focusing on adaptability over strict adherence to rules.

The Scrum Guide outlines ten elements that must be followed, all of which support the principle of empiricism. These elements serve as guardrails, ensuring visibility, inspection, and adaptation. However, everything beyond these is guidance, allowing teams the flexibility to navigate their unique challenges and opportunities.

Here are the MUST elements from the Scrum Guide:

• The emergent process and work must be visible to those performing the work as well as those receiving the work.

• The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.

• If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.

• For Product Owners to succeed, the entire organization must respect their decisions.

• The Sprint Goal must be finalized prior to the end of Sprint Planning.

• [The Scrum Team ] must fulfill (or abandon) one [Product Goal] before taking on the next.

• In order to provide value, the Increment must be usable.

• If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.

• If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

• If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

As I reflect on the past sessions and the growth observed in the participants, it’s clear that Scrum is not a methodology but a philosophy. A philosophy that empowers teams to embrace complexity, adapt to changes, and continuously seek improvements. It’s about understanding that the path to success in an ever-changing environment is not through rigid rules but through adaptability and resilience.

How has pragmatically embracing the philosophy of Scrum enabled you to navigate complexity and adapt to change in your projects?

However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of work-in-progress and breeding a culture of hands-off responsibility, Blocked columns can become the silent saboteurs in your workflow.

Blocked Columns on Kanban Boards Obfuscate Workflow and Undermine Effectiveness:

Kanban boards serve as the visual representation of the crucial steps involved in knowledge discovery. However, labeling a column as “Blocked” does not align with the essence of this visualization.

“The nature of a column is that it represents a state an item will flow through. Introducing a Blocked Column would imply that the normal flow of work would involve the vast majority of items to be Blocked before they get done”

Will Seele | LinkedIn

When tasks are relegated to the Blocked column, there is an alarming tendency for team members to disengage from those tasks, erroneously expecting the issues to be resolved by some external force. This mindset breeds several detrimental consequences:

1. Stagnation of Work Items: Tasks lodged in the Blocked column tend to remain there indefinitely. As time goes by, these work items become stale and outdated.

2. Inflation of WIP Limits: As the Blocked column accumulates more tasks, teams are often tempted to increase their Work In Progress (WIP) limits for the Blocked column. This is a red flag indicating that the team perceives the issue as someone else’s responsibility.

3. Loss of Contextual Information: When a task is tagged as Blocked, it is essential to understand which stage of the process it is obstructed in, as this guides the necessary action for resolution. By lumping tasks into a generic Blocked column, this critical information is lost.

4. Loss of Priority Information: Tasks are typically selected based on their value. However, once a task is shifted to the Blocked column, it is stripped of its priority status, which is vital for efficient workflow management.

5. Back-and-Forth Movement: Transferring a task to the Blocked column necessitates moving it back to its original state once the block is cleared. This back-and-forth movement is not only cumbersome but also increases the likelihood of errors and mismanagement.

It’s imperative to recognize that ‘Blocked’ is distinct from ‘Waiting’. They are not interchangeable. Especially in workflows that involve approval, legal compliance, risk assessment, or governance considerations, tasks are not Blocked per se, but rather waiting for input or feedback. This waiting period needs to be accurately captured, and the sources of delay must be identified and addressed. Knowledge of these elements and the duration of delays is fundamental in tackling and resolving the root causes.

In light of these pitfalls, it is crucial for teams to approach the use of Blocked columns with caution. Instead, a more efficient approach may involve annotating tasks with specific information about the blockages and keeping them within their respective stages, thereby maintaining transparency , accountability, and the integrity of the knowledge discovery steps.

How do you show that a work item is blocked In Azure DevOps ?

By far the best way to indicate blocked is to use a Blocked tag on your Work Item.

You can also increase the transparency by enabling a colour for the tag. Just be careful not to over use it, too many colours can reduce transparency and making it harder to see important information.

References:

• Addendum-to-Kanban-Guide-implementation-options-details-2-1.pdf (kanbanguides.org) <–Page 15

• English - Kanban Guides

• https://prokanban.org/wp-content/uploads/2022/08/thekanbanpocketguide.pdf

• The Principles of Product Development Flow: Second Generation Lean Product Development

• When Will It Be Done?: Lean-Agile Forecasting to Answer Your Customers’ Most Important Question by Daniel S. Vacanti | Goodreads

You can watch the video below to hear what we say, but it’s also worth framing the problem and the need for change here. I welcome all feedback!

What is Traditional Training?

Traditional learning is typically delivered over a short period of time, mostly with consecutive sessions, sometimes with a little more space. The idea in the traditional format is to get the participants to a level of understanding/knowledge as quickly as possible.

This typically takes the form of 2 full days of training for your PSM/CSM or other agile class.

We have “Learn a new Concept” that enables participants to remember the content and then follow that up with “Practice with Examples” to enable understanding.

This would fulfil the first two stages of Bloom’s Taxonomy for Teaching, Learning, and Assessment. For some participants, this is enough for them to infer greater learnings, but for most, it is not.

Without a substantive change to the participant’s mental models, it is unlikely that the ideas will stick or the seeds germinate into real change.

What is Immersive Learning?

Immersive learning is typically delivered over a much longer period and may look like a combination of consulting, coaching , and teaching. For example, our immersive programs are delivered one half-day weekly for 8-12 weeks.

Like traditional training, we have “Learn a new Concept” that enables participants to remember the content and then follow that up with “Practice with Examples” to enable understanding. However, we follow up with an “Outcome-based Assignement” that enables the application of things we have taught to their real world of work and a “Facilitated Reflection” where they can Analyse the outcome.

In effect, we close the learning loop with empiricism. A feedback loop is created.

This would then fulfil an additional two stages of Bloom’s Taxonomy and enable, over time, the last two.

Why is traditional not working?

While traditional learning has been used for many years in many industries, it has a significant and known downside. Most folks only remember a fraction of the content presented to them.

This can be augmented with additional homework to enable more connections with the content but it has little to no additional value and can at times have a negative impact. Every participant is different, and we have experimented with providing watching, reading, and writing content… but there is little apatite for it with participants and very few partake.

Ultimately very little is remembered in the weeks and months that follow a traditional classroom session.

I’ve been delivering traditional training for over ~13 years, and even with augmentations to the format, I’ve seen limited value for companies. There needs to be more than training to enable organisations to get the perceived value for most people. This results in an expectations gap where they have trained hundreds of people and have not seen things improve or change.

In the 13 years of traditional training, where I would travel onsite, I have seen it have a palpable impact only twice… both times, it was combined with consulting, coaching… and a little ass-kicking to get things moving.

However, it’s only sometimes possible for most trainers to follow up to the depth the customer needs. Perhaps you have another training in another country next week… but this customer needs more help… (pre-pandemic I was travelling 300 days a year with customers. This took little time to follow up).

As we all moved into the pandemic and things moved online, I got breathing space between engagements where I was not in an airport. I was able and willing to engage, collaborate, and coach at my desk. But folks needed more time. The had their day job, their issues, and the mandatory training course from last week or last month needed to be more interesting.

I even offered additional consulting for every student, cumulative for companies with private classes, and still, I am still waiting for something to happen. Less than 5% used it, and I could not get above 6% even with follow-up.

Queue immersive formats.

Why is Immersive Always a Better option?

By bringing the classroom content into the workplace and having participants try or do things from the learning in that environment we have a chance to close the feedback loop and have participants not just gain knowledge and understanding, but also be able to apply, and analyse the outcomes.

This would enable double-loop learning, where participants can apply the ideas learned in their own environment and then come back around and make real, lasting changes to their mental model and the mental model of those around them in their environment.

Even this is a rather simplistic linear view, and you could imagine multiple instances of the image above stacked on top of each other and the feedback from the “Outcome -based assignment” that is applied in the workplace not only goes from the previous session to the next, but also to traverse the instances of the sessions to reinforce and continuously update the learning loops.

For example, a participant may try something after session one and then ask to participate in exploratory learning of the outcomes, as they continuously happen in sessions 2, 3, 4, etc.

My attraction to immersive classes stems from contrasting experiences: the lasting impact of a detailed MongoDB course, complete with weekly homework and a final exam, versus the fleeting memory of a two-day crash course in team management, which left me overwhelmed and fatigued. These experiences have shaped my preference for immersive learning.

This continuous reinforcement and engagement, both from the qualified expert instructor and the other participant peers engaged in similar outcomes, multiplies the effect of the training and embeds new mental models in all of the participants.

For double-loop learning to be effective, participants need to be able to make a substantive change to their mental models as they progress through the content. This deeper change and learning is enabled by the application in the workplace and the analysis of what happened and why that comes from the “facilitated reflection”.

Double-loop learning is not guaranteed by participating in immersive learning, but it does enable it.

So, is traditional learning dead?

Traditional two-day classes are of the past, and immersive multi-week classes are of the future. That is not to say that tradition is dead; it will be around for a long time as we transition, but we must transition.

Immersive takes what we learned teaching traditional classes, in Scrumorg’s case, for 13 years, and adds more value, learning, and opportunities for change.

Immersive learning is the future of Agile and Scrum training, hopefully, all learning.

Webinar: Exploring the Different Ways People Learn: A Discussion about Immersive Learning Formats

In this video, Scrum.org ’s Product Owner Sabrina Love and Professional Scrum trainers Alex Ballarin , Joanna Płaskonka , and myself ( Martin Hinshelwood ) discuss the evolution and effectiveness of immersive learning in Agile environments. We delve into how this approach enhances practical application and reflection, making it a superior method for real-world problem-solving. 🤔💡

Check out the full webcast on Exploring Immersive Learning in Agile Environments

NKDAgility provides immersive learning!

NKDAgility’s Immersion Training reimagines traditional classroom learning. Our approach involves:

• Incremental Classroom Learning: Engaging live sessions spread over several weeks, each lasting up to 4 hours. This structure allows learners to understand each concept at a comfortable pace thoroughly.

• Outcome-Based Assignments: Assignments linked to each session emphasize practical application and innovation, catering to various skill levels and backgrounds.

• Facilitated Reflections: Each class starts with a reflective session where learners discuss their assignment experiences with their Professional Scrum Trainer, fostering peer learning and actionable insights.

This Immersion Training is designed to offer a more interactive, reflective, and practical learning experience, ensuring knowledge acquisition, application, and growth. Join us for a transformative educational journey.

Starting in 2024, we will be running immersive classes in bundles as Learning Journeys that you can book together or on their own! Our 24Q1 bundles are:

• Professional Scrum Product Owner & Product Backlog Management Skills

• Professional Scrum Master & Professional Scrum Facilitation Skills

• Professional Agile Leadership Essentials & Evidence-Based Management (PAL-EBM)

On top of a discount of 20% that has been applied to all prices until 31st May 2024, we offer a price-by-country model that has additional discounts automatically applied to all of our classes based on your location.

BOOK TODAY <– Regional pricing, bulk discounts, & and alumni discounts are available!

If you are underemployed, we can also create custom payment plans to help you out. Just ask!

References

• Blooms Taxonomy :: Resource for Educators

• Double-loop learning - Wikipedia

• Duke Study: Homework Helps Students Succeed in School, As Long as There Isn’t Too Much | Duke Today

• Is homework a necessary evil? ( apa.org )

• Immersive Learning Overview - naked Agility with Martin Hinshelwood ( nkdagility.com )

These sins promised personal suffering, societal decay, and eventual destruction if left unchecked. Fast forward to our modern era, as we traverse the intricate landscape of software development , particularly through the lens of the agile approach, we find these age-old Greek sins echoing in the challenges and pitfalls agile teams often encounter. The striking parallels remind us that while times have changed, the essence of human challenges remains consistent. This journey involves identifying these pitfalls in the agile world and drawing wisdom from ancient Greek insights to navigate and overcome them.

The Sins of Agile: Pride (Hubris)

Watch the video

In ancient Greece, Hubris was considered an excessive self-confidence, often the root of all sins. It warned against overestimating one’s abilities to the point of challenging the gods themselves. In the agile context, Martin discusses how this excessive pride can lead teams to believe they’re infallible, often overlooking critical feedback and insights. Such teams might think their approach is beyond reproach, leading them to dismiss valuable external perspectives. This can result in resistance to change, even when evidence suggests adjustments are needed. The essence of agility is adaptability, and an overabundance of pride can stifle this, hindering a team’s growth and evolution.

The Sins of Agile: Envy (Phthonos)

Watch the video

In the wisdom of ancient Greece, Phthonos or Envy was a caution against the resentment stemming from seeing others possess what one desires. It was a warning about the dangers of coveting another’s success without understanding the journey behind it. In the agile landscape, Martin sheds light on how this envy often manifests when teams and organisations blindly emulate successful agile models, such as the “Spotify model”, without tailoring them to their unique needs and circumstances. This blind imitation, driven by envy, can lead teams astray, causing them to adopt practices that might not align with their goals or organisational culture . The key takeaway is to focus on one’s unique journey, drawing inspiration from others but constantly adapting it to one’s context.

The Sins of Agile: Gluttony (Gastrimargia)

Watch the video

Ancient Greeks perceived Gastrimargia, or Gluttony, as a warning against overindulgence and excess. It wasn’t just about food but about consuming more than one’s fair share in any aspect of life. In the agile domain, Martin delves into how this gluttony is mirrored in the realm of product development . He touches upon the tendency of teams to bloat their product backlogs, hoarding tasks and features, often more than they can realistically handle. This overindulgence leads to inefficiencies, with teams spreading themselves too thin, trying to tackle more than they can manage. The essence is to maintain a lean backlog, prioritising tasks that deliver genuine value and avoiding the trap of trying to do everything at once.

The Sins of Agile: Lust (Porneia)

Watch the video

In the annals of ancient Greek thought, Porneia, or Lust, was more than just a passionate desire; it was seen as a form of madness leading to destructive behaviour. It cautioned against being blinded by intense desires, often leading one astray from one’s true path. Translating this to the agile world, Martin highlights how Lust manifests as the intense yearning for quick fixes, shortcuts, and silver bullets without investing genuine effort. Teams might be lured by the promise of rapid transformations or the allure of new tools, often neglecting the foundational principles of agile. This can lead to superficial implementations that lack depth and understanding. True agility requires commitment, understanding, and consistent effort, not just fleeting desires.

The Sins of Agile: Greed (Philargyria)

Watch the video

In the philosophical teachings of ancient Greece, Philargyria, or Greed, was depicted as an excessive desire for wealth and possessions, often at the expense of other virtues. It was a reminder of the dangers of placing material gains above all else. In the agile context, Martin discusses how this greed manifests as overemphasising quick returns and immediate gains. Teams might prioritise short-term profits over long-term value, or focus excessively on resource utilisation without considering genuine value delivery . This can lead to decisions that might provide immediate benefits but harm the project in the long run. The essence of agile is to deliver consistent value over time, and an overbearing focus on immediate gains can detract from this goal.

The Sins of Agile: Sloth (Acedia)

Watch the video

In the ancient Greek ethos, Acedia or Sloth was a warning against a lack of motivation and interest in life. In the agile realm, Martin highlights how Sloth manifests in various forms across teams, organisations, and leadership . A common manifestation is the sheer reluctance or, as he puts it, “not bothering our arse” to do what’s promised. Teams might claim they’re “doing Agile,” yet they don’t deliver a working product at the end of a Sprint, or they might have convoluted deployment processes out of the developers’ control. The absence of an ordered backlog is another telltale sign. This lethargy might stem from a top-down directive to “do agile” in environments not suited for it, perhaps due to legacy systems like mainframes. Martin emphasises the importance of honesty and transparency , urging teams to be forthright about their capabilities and limitations.

The Sins of Agile: Wrath (Thymos)

Watch the video

In the ancient Greek ethos, Thumos, or Wrath, was a caution against unchecked anger and its potential to lead to destruction. It was a reminder of the dangers of letting emotions, especially anger, dictate actions without reason. In the agile context, Martin highlights how wrath manifests in organisations. It’s often seen in the inability to accept mistakes or the reluctance to take accountability. This wrathful behaviour can lead to a blame culture, where individuals or teams are more concerned about deflecting blame instead of addressing the root cause of an issue. For instance, when stakeholders question a decision, they might deflect the blame onto the team instead of the product owner taking responsibility. Such environments stifle innovation and growth as teams become more risk-averse, fearing the repercussions of making mistakes. This lack of accountability and a blame culture is indicative of an organisation’s wrath, preventing it from truly embracing the agile mindset.

A Reflection

In reflecting upon these seven cardinal sins of agile, it becomes evident that the challenges faced in modern software development are not just technical but deeply human. Drawing from this rich tapestry of Greek wisdom and Martin’s insightful videos, this exploration serves as both a cautionary tale and a guide. It’s a journey of introspection, ensuring that as we navigate the agile seas, we remain true to its core principles, fostering innovation, collaboration, and genuine value delivery. 🚀🛤️

These insights serve as a timely reminder that while agile offers powerful tools for success, they require a genuine commitment to values, principles, and continuous introspection. As we navigate the ever-evolving landscape of agile, let’s be mindful of these pitfalls, ensuring that our journey is not just about delivering software but also about fostering a culture of growth, collaboration, and genuine value. Let’s learn from the past, be it ancient Greece or our own missteps, to build a brighter, agile future.

Enjoy these videos? Like and subscribe to our channel: https://www.youtube.com/@nakedAgility

Reference

• 7 Deadly Sins According to Ancient Greek Philosophy - Strange Ago

• Where Did the 7 Deadly Sins Come From? | Psychology Today

NKDAgility can help!

These issues are the kind that lean-agile practitioners are passionate about. If you find it hard to navigate the agile landscape or struggle with certain aspects, my team at NKDAgility can assist.

It’s vital to seek early help if challenges hinder your value delivery. You can request a free consultation or sign up for one of our upcoming professional Scrum classes.

After all, you don’t just need agility; you need Naked Agility.

TLDR;

The Sprint Goal is the heart of Scrum, representing the team’s commitment to the value derived from the Sprint’s outcome. It’s the tactical step towards the objectives of the work in progress towards the Product Goal. A well-crafted Sprint Goal is neither granular nor high-level but strikes a balance to ensure clarity, accountability, and value delivery .

The Core of the Sprint Goal

The Sprint Goal is the commitment made by the Scrum Team to the value derived from the Sprint’s outcome. It’s the next tactical step towards the objectives of the work underway. This goal should be a clear and concise description of the work the team will undertake during the Sprint so that they can collectively manage the emergent Sprint Backlog. It’s not a list of tasks but a unified goal the team strives towards.

When teams find it challenging to craft a Sprint Goal that genuinely represents the contents of the Sprint Backlog, they might be aiming for too much granularity (a local optimisation). The Sprint Goal should be the paramount deliverable for which stakeholders will hold the Scrum Team accountable.

Conversely, a Sprint Goal that’s too high-level can disconnect the work being done from the value being delivered. This can create a chasm between the team and the outcome, diluting accountability.

Sprint Goal videos!

Some folks prefer to watch than to read :), and we have you covered:

• What is a sprint goal? : This video sheds light on the concept of a Sprint goal in the Scrum context. It emphasises the Sprint goal’s tactical nature, which bridges the strategic vision and the intermediate strategic product goal. The Sprint goal should be something stakeholders can review and provide feedback on.

• How does a scrum team create a sprint goal? : Here, the process of crafting a Sprint goal is unravelled. Teams can amalgamate information on the product’s strategic direction, the product owner’s current tactical direction, and ongoing engineering aspects. This synthesis helps in selecting the right items from the product backlog for the Sprint.

• How does a Scrum Team Decide on a Sprint Goal? : Addressing the often-asked question of how a Scrum team decides on a Sprint goal, this video highlights the collaborative effort required. It’s not a spontaneous decision involving developers, the product owner, and stakeholders. The goal should resonate with stakeholder feedback, market insights, and the broader business context.

• How do you know if you’ve got a great sprint goal? : Diving deeper, this video explores the markers of an effective Sprint goal. A well-defined Sprint goal sparks intrigue, questions, and enthusiasm among both stakeholders and developers.

Key things to remember about a Sprint Goal

• The Sprint Goal connects the team and the stakeholders - we commit to the Sprint Goal as a team, and we expect the stakeholders to hold us accountable for achieving it. With the Sprint Goal being achieved as the norm, we build trust for the times when we occasionally don’t make the Sprint Goal.

• The Sprint Goal does not need to represent all of the work in the Sprint - You will also have to plan time in each Sprint for refactoring, refinement, those small changes that are too short for a Sprint, and those ling running pieces of work that take longer.

• Delivering usable product to at least some subset of real users every iteration (including the first) and gathering feedback? - While we strive to have usable value at the end of every Sprint, different sorts of work have different delivery models, and not all delivery can be sliced in the same way as software. For example, a tunnel is not valuable until both ends are open. This needs to be taken into consideration when crafting Goals.

When are Sprint Goals crafted?

While the Sprint Goal is finalised at the Sprint Planning, it is a good idea to think longer term and draft possible Sprint Goals looking out at least the next few Sprints.

While they may change, having some idea of which checkpoints you are thinking of hitting is critical to helping both the team and the stakeholders make better decisions with as much context as makes sense. If you find that you are changing the draft Sprint Goals constantly, then maybe you are looking too far out into the future and need to shorten the forecast.

This forecast should be sufficient to enhance transparency and will depend on the type of work underway.

Examples of Sprint Goals

Here are some examples of Sprint’s Goals for a cloud migration team migrating applications from on-premises to the cloud. These goals may be delivered in this order over the life of the engagement or partnership with a customer and represent vertical slices of work to be delivered that result in some value.

SMART Sprint Goals

These are just example goals, and the specifics will vary based on the organization’s needs, the complexity of the applications, and other factors. One way to ensure the validity of each sprint goal is to use SMART goals; each goal is specific, measurable, achievable, relevant, and time-bound.

1. Environment Setup Sprint Goal - “By the end of this sprint, we will have a fully configured cloud environment, including virtual networks, security groups, and storage, ready for application deployment.”

2. Assessment and Planning Sprint Goal - “By the end of this sprint, we will have identified all dependencies, potential challenges, and the migration strategy for each application.”

3. Proof of Concept (PoC) Sprint Goal - “By the end of this sprint, we will have successfully migrated a non-critical application to the cloud and validated its functionality, serving as a PoC for the larger migration.”

4. Data Migration Sprint Goal - “By the end of this sprint, we will have migrated 50% of the application data to the cloud without any data loss or corruption.”

5. Application Migration Sprint Goal - “By the end of this sprint, we will have migrated and deployed three key applications to the cloud and ensured they are fully operational.”

6. Integration Testing Sprint Goal - “By the end of this sprint, we will have completed integration testing for all migrated applications, ensuring they interact seamlessly with other systems.”

7. Performance Tuning Sprint Goal - “By the end of this sprint, we will have optimized the performance of all migrated applications, ensuring they meet or exceed on-premises benchmarks.”

8. Security and Compliance Sprint Goal - “By the end of this sprint, all migrated applications will be compliant with our security standards, and any vulnerabilities identified will be addressed.”

9. User Training and Documentation Sprint Goal - “By the end of this sprint, we will have provided training to all relevant stakeholders on how to use the migrated applications in the cloud environment and created comprehensive documentation.”

10. Monitoring and Alerting Sprint Goal - “By the end of this sprint, we will have set up monitoring and alerting tools for all migrated applications, ensuring we are immediately notified of any issues.”

11. Final Transition and Decommissioning Sprint Goal - “By the end of this sprint, all remaining applications will be fully migrated to the cloud, and on-premises infrastructure will be decommissioned.”

OKR Sprint Goals

This same list can be written as OKR! OKRs (Objectives and Key Results) are a goal-setting framework that helps organizations define and track objectives and their outcomes. Here’s how the list of Sprint Goals can be converted to OKRs:

Objective: Successfully migrate applications from on-premises to the cloud.

Key Results

1. Environment Setup - KR1: Fully configure the cloud environment, including virtual networks, security groups, and storage.

2. Assessment and Planning - KR2: Identify all dependencies, potential challenges, and migration strategies for each application.

3. Proof of Concept (PoC) - KR3: Migrate and validate a non-critical application to the cloud as a PoC.

4. Data Migration - KR4: Migrate 50% of the application data to the cloud without data loss or corruption.

5. Application Migration - KR5: Migrate and deploy three key applications to the cloud, ensuring full operability.

6. Integration Testing - KR6: Complete integration testing for all migrated applications with successful interactions.

7. Performance Tuning - KR7: Optimize the performance of all migrated applications to meet or exceed on-premises benchmarks.

8. Security and Compliance - KR8: Ensure all migrated applications comply with security standards and address any vulnerabilities.

9. User Training and Documentation - KR9: Provide training to all relevant stakeholders and create comprehensive documentation.

10. Monitoring and Alerting - KR10: Set up monitoring and alerting tools for all migrated applications with immediate notification capabilities.

11. Final Transition and Decommissioning - KR12: Fully migrate all remaining applications to the cloud and decommission on-premises infrastructure.

The Objective sets the overarching goal, while the Key Results break down the specific, measurable outcomes that indicate progress towards achieving that goal.

Other Goal-definition frameworks

In addition to the SMART and OKR goals listed above, there are other frameworks that are also viable in this circumstance:

1. CLEAR Goals:

   • Collaborative: Goals should encourage teamwork.
   • Limited: Goals should be limited in scope and duration.
   • Emotional: Goals should connect to personal and team values or passions.
   • Appreciable: Break larger goals into smaller tasks.
   • Refinable: Be flexible and adjust goals as needed.

2. BHAG (Big Hairy Audacious Goal):

   • A long-term, visionary goal that is more strategic and inspiring than a standard goal.

3. 4DX (The 4 Disciplines of Execution):

   • Focus on the Wildly Important Goals (WIGs).
   • Act on Lead Measures.
   • Keep a Compelling Scoreboard.
   • Create a Cadence of Accountability.

4. FAST Goals:

   • Frequently discussed.
   • Ambitious in scope.
   • Specific and measurable.
   • Transparent and shared with others.

5. GROW Model:

   • Used primarily for coaching and mentoring .
   • Goal: What do you want to achieve?
   • Reality: Where are you now concerning the goal?
   • Options: What could you do to achieve the goal?
   • Will (or Way Forward): What will you do?

6. MBO (Management by Objectives) - A management model where managers and employees work together to set, monitor, and achieve specific objectives.

7. Backward Goal Setting - Start with the end goal and work backwards to determine the steps needed to achieve it.

8. Process vs. Outcome Goals:
   Process Goals: Focus on the actions or strategies needed to reach a goal.
   Outcome Goals: Focus on the desired end result.

Different frameworks and methodologies may be more suitable depending on the context, the nature of the goal, the individual or organization’s preferences, and the desired outcome. Choosing a method that aligns with the specific needs and challenges at hand is essential.

Concluding Thoughts

Mastering the art of crafting a Sprint Goal is pivotal in the Scrum framework. It’s not merely about listing tasks but about setting a clear, concise objective that drives value and aligns with the broader vision. Whether too granular or too high-level, a misaligned Sprint Goal can hinder a team’s progress and diminish stakeholder trust. By understanding its essence and ensuring it’s tactical and relevant, teams can foster better collaboration, clearer communication, and heightened accountability. Remember, it’s not just about completing tasks; it’s about delivering value, every Sprint.

NKDAgility can help!

If you find it hard to craft effective Sprint Goals or struggle to align your team’s objectives with the broader organisational vision, my team at NKDAgility can assist. Lean -agile practitioners thrive on these kinds of challenges, but most teams find daunting.

Don’t let these issues undermine the effectiveness of your value delivery. It’s paramount to seek assistance sooner rather than later!

Take action now. Request a free consultation with my team or enrol in one of our upcoming professional Scrum classes . Because you don’t just need agility, you need Naked Agility.

Why having Acceptance Criteria on the Definition of Done risks the sanctity of the working usable product

The DoD is my touchstone for quality. It’s a measurable and automatable standard that ensures every increment is of a certain quality. Introducing optional or non-executable elements into the DoD can diminish its importance, potentially jeopardising the transparency and empiricism foundational to our work.

The DoD isn’t about guaranteeing functionality but ensuring that what we’ve built works. It’s the bedrock of transparency. If stakeholders are still determining whether the work meets the necessary standards for release, there needs to be more clarity on the additional effort required. Similarly, if Developers are unsure of these standards, they can’t accurately gauge the work needed.

Incorporating elements that might undermine this transparency or minimise these standards is a risk we shouldn’t take. The DoD’s primary purpose is to maintain this clarity.

Why having Acceptance Criteria on the Definition of Done may not risk the sanctity of the working usable product

There are instances where quality measures form part of the acceptance criteria. In such cases, one might be tempted to add “must meet acceptance criteria” to the DoD. However, this can jeopardise the team’s flexibility in determining the Sprint’s contents while upholding the DoD’s sanctity.

Instead, we should scrutinise the acceptance criteria. If specific criteria always need to be true, they should be incorporated into the standards and, by extension, the DoD. For instance, criteria like “all content is spelled correctly and has good grammar” or “all copy meets visual spacing guidelines” can be integrated into the DoD.

If you’re keen on including acceptance criteria in the DoD and wish to maintain the flexibility of value delivery , consider phrasing it as “for all work delivered in the Sprint, quality-based acceptance criteria on each backlog item are fulfilled”. This retains the original intent while allowing the team to adapt based on their learnings.

Conclusion

The DoD aims to ensure transparency, confirming that all showcased work meets our product’s standards. Anything that jeopardises this transparency or the adaptability of Sprint’s contents should be approached with caution. Only adopt such changes if you can guarantee the preservation of adaptability and transparency.

-–

NKDAgility can help!

These are the intricacies that lean -agile aficionados thrive on, but most find daunting. If you find it hard to distinguish between the Definition of Done and Acceptance Criteria, my team at NKDAgility is here to assist. Don’t let these issues undermine your value delivery. Seek help sooner rather than later.

Right now, you can request a free consultation with my team or enrol in one of our upcoming professional Scrum classes . Because you don’t just need agility, you need Naked Agility.

TLDR;

Story Points, while subjective, can be a valuable tool for team discussions and understanding. However, they shouldn’t be the primary metric for comparing teams or predicting future deliverables. Instead, focus on objective metrics like throughput , to gauge and optimise team performance .

These are not the metrics that you are looking for!

First and foremost, Story Points are inherently subjective. They’re influenced by individual perceptions, making them unsuitable for broad comparisons or future projections. While they might offer a vague direction, they’re often misused in planning and measuring.

The essence of agile frameworks like Scrum is value delivery , and the correlation between the subjective nature of story points and their velocity doesn’t necessarily equate to the value delivered. There are better choices for teams aiming to optimise their value delivery than relying solely on Story Points and Velocity.

But is there any value in Story Points?

Aye, there is. In my experience, Story Points can be a great tool during backlog item refinement. They foster discussions, highlighting what’s known and, more importantly, what’s not: Outliers during planning poker often signal gaps in understanding.

Tools like Story Points and Planning Poker can be invaluable in understanding when to dissect items further and spark discussions during refinement. I would expect teams to shift more towards right-sizing, ensuring that backlog items are feasible within a Sprint, as they gain more experience and understanding of the product, its domain, and the technology used.

A Story of Flow and Value

The crux of this discourse lies in two vectors: throughput and value.

• Throughput is a tangible measure of items delivered over time.

• Value, on the other hand, is a more elusive measure of the anticipated benefits from system changes.

It’s straightforward to gauge the throughput of backlog items and their flow. By noting when work enters and exits the system, we can derive the four pivotal flow metrics:

• Throughput

• Cycle Time

• Work Item Age

• Work In Process

Such metrics empower us to make informed decisions rooted in tangible data. They allow us to pinpoint potential issues, identify items needing further breakdown, and employ probabilistic forecasting for future projections.

Simultaneously, to truly maximise team output, we must also focus on the value of the work. Given its subjective nature, defining value can be multifaceted. A practical approach is to examine the four primary value areas from evidence-based management practices:

• Current Value - Evaluating the existing product’s value. Is it meeting customer expectations?

• Unrealised Value - Identifying gaps in your product that could be filled.

• Time to Market - Assessing the speed from ideation to user engagement. Dormant value is essentially no value.

• Ability to Innovate - Determining the balance between maintenance and innovation.

The ultimate goal is to enhance both throughput and value concurrently. Striking a balance is crucial; we neither want sluggish excellence nor a barrage of mediocrity.