Articles on Martin Hinshelwood on Engineering Leadership

Don’t Manage Dependencies, Remove Them

Martin Hinshelwood — Mon, 29 Sep 2025 09:00:00 +0000

Answering the question: How do you manage dependencies?

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.

Is Agile Really Just a Mindset?

Martin Hinshelwood — Mon, 11 Aug 2025 09:00:00 +0000

Let’s get one thing straight: Agile is not a mindset. And it’s certainly not just about behaviour. That lazy framing dilutes the discipline, ignores the engineering reality, and gives cover to incompetence.

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.

Stop Building Silos. Start Building Systems

Martin Hinshelwood — Mon, 07 Jul 2025 09:00:00 +0000

You can’t deliver quality at speed when your automation is duct-taped together. If your pipelines are stitched across multiple systems, your deployments depend on human rituals, and your tests run in the shadows, you don’t have a delivery system, you have a liability.

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.

Telling People What to Do Is Not Leadership. It’s a Failure of System Design

Martin Hinshelwood — Mon, 04 Aug 2025 09:00:00 +0000

If your organisation still measures leadership by how many decisions a manager makes, you are not leading. You are leaking value.

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 to Build for Business Resilience and Continuity

Martin Hinshelwood — Mon, 26 May 2025 09:00:00 +0000

Business resilience is not an accident. It is the deliberate outcome of intelligent systems design, pragmatic decision-making, and organisational discipline. If you want resilience, you must build for it, upfront, consistently, and aggressively.

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.

Resilience is Part of the Product, Not an Afterthought

Martin Hinshelwood — Mon, 09 Jun 2025 09:00:00 +0000

Resilience is not a nice-to-have. It is not a department. It is not something you bolt on later if you get around to it. Resilience is part of the product. If you are serious about delivering value, you design resilience deliberately from day one. Any other approach is just gambling with your business, and is adding to your technical debt.

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.

Release planning and predictable delivery

Martin Hinshelwood — Tue, 24 Nov 2020 13:00:01 +0000

Many organisations wrestle with the seeming incompatibility between agile and release management, and they struggle with release planning and predictable delivery.

Updated to reflect the 2020 Scrum Guide!

TL;DR;

Without working software, you can’t build trust and you don’t know when you will get the next piece of working software.

Any software that you create is an organisational asset and decisions to cut quality need to be reflected in your company accounts and as such those decisions need to made by your executive leadership and should not be made by Developers. Once you accept this, and quality becomes non-negotiable, your Dev e lopers can focus on creating usable increments of working software. Once you have usable increments of working software, you can then start to look with interest at the progress being made on features and goals.

Without a regular cadence of delivery of working software any belief that you will get a usable increment is misguided at best. Professional Developers create working software.

Release planning and predictable delivery

The incompatibility between predictable delivery and agility is fictitious (tweet this ) and while usually created by an organisation and structure that is unwilling to let go of the old ways and embrace the tenants of agile it can also be the result of a Scrum Teams fervour to divest themselves of all things that smack of prior planning. There is a lack of understanding that agile and the path to agility is far more than just a change in the way that you build software, it is a fundamental shift in the way that you run your business. Much like the lean movement in manufacturing, companies that embraced it wholeheartedly were the ones that ultimately see the competitive edge that it provides. If one is unwilling to let go of the old ways, then one can’t attain the value of the new. This change will take hard work and courage as the fundamental transparency required to inspect and adapt effectively is at odds with the measures of the past. The lack of predictability of software development is the key to understanding the new model.

Why is software so unpredictable

All software development is product development. In lean manufacturing, we can optimise the production of pre-developed products through the nature of its predictable production. Each unit of work takes the same amount of materials and time to produce so any changes that we make to the process, time, or materials can easily be qualified and the benefit demonstrated. Manufacturing lives in the predictive world.

With software everything that we create takes its own amount of time: You can really only know how long something took after it has been completed. Even in manufacturing if you asked an engineer how long it would take to develop a new type of unit of work they would not be able to tell you with any certainty. Once they have developed it however they can tell you exactly how long it will take to make each one, and then systematically optimise the process that you use to make it. In software development we are always doing new product design, therefore, we have no certainty…and this often results in chaos. Software lives in the empirical world.

All is not lost however as we can, by looking at our history of delivery for similar things, make a pretty good forecast…

The best thing we can then do is to expend effort to make that forecast as accurate as possible while accepting that more time spent planning does not necessarily affect the accuracy of that forecast.

Figure: Diminishing returns from Agile Estimating – Estimation Approaches

Ultimately Software Development is a creative endeavour and has the same lack of predictability that painting a picture, writing a book or making a movie has. Yet movies get made all of the time. How can that possibly be! Well, they have a Director (Product Owner) that has a bunch of money and a delivery plan, a Producer (Scrum Master) to make sure that everyone has the skills, knowledge and assets available at the right time and place and one or more Units (Scrum Teams) that have all of the skills necessary to turn the Directors ideas into a working movie. They create Storyboards of what they expect to create so that they can run it past the stakeholders and get feedback. They take those storyboards to the Units who collaboratively work together with the stunt, prop, lighting, camera, sound and wardrobe crews to get estimates and costs and ultimately coordinating to create the movie. Sometimes they don’t know how to do stuff and have to have a go and see what they get.

Making a movie is just like building software, you need a budget, you need a plan, and you are trying to reach a ship date. And just like making a movie, you have to make money at the end of the day so that you can do it all over again.

Accept the lack of predictability

While I hope by now you understand that the lack of predictability is part of the nature of building software, there are many things that we can do to lessen the impact of that chaos. Indeed if you were to estimate all of the discreet things that you need to do to achieve a goal (let us call them backlog items) in Small, Medium and Large what would your standard deviation of actual hours be? I would wager that it is fairly large. So large in fact that at least half of all mediums would be more accurately classified as Large. But that reclassification can only be done with hindsight. This is indeed one of the tenants of the No-Estimates movement, as really there are only three classifications of size: small, fits in a Sprint, or too big to fit in a Sprint.

This difficulty in estimation is normal for organisations that move towards agility as the transparency that it brings uncovers these sorts of problems. In order to increase the accuracies of our forecasts, there are a number of simple activities that we can perform. These activities, while easy to understand, are very hard to do as they require a culture shift within your organisation as well as the courage of the participants to make them work.

Focus on continuous quality

Most software lacks quality for the simple reason that you can not easily see the quality in software like you could with a table or a painting. I am not talking about the quality of the User Interface, but the quality under the covers; the quality of the code.

If you put developers under pressure to deliver they will continuously and increasingly cut quality to meet deadlines.-Unknown (Tweet this )

A lack of quality of the code results in an increase in Technical Debt (or more accurately an unhedged fund) which in turn results in two nasties. The first is the teams increasingly have to spend more time struggling with the complexity of your software rather than on new features. If you are still pushing your teams to deliver the same feature level every year you are only encouraging them to cut more quality and thus incurring more technical debt which becomes a vicious cycle. The second is an increasing number of bugs found in production. Bugs found in production also directly impact on the number of features that the team can deliver and any bug, no matter how small, costs ten times and much to fix in production than it does in development.

The only way to handle technical debt is to stop creating it, and then pay a little back each iteration. If however, you are so drowning in technical debt that you cant create working software at the end of the iteration then:

Create a short measurable checklist that mirrors minimum releasable product (Defenition of Done)
Stop adding new features and make your product meet that checklist and release your product
While you have an increment of working software (Sprint)
1. Work to create something of value (Increment)
  1. Work towards a new goal while meeting the DOD (Sprint Goal)
  2. Leave things better than you found them (Engineering Excellence)
2. Review that thing of value with your stakeholders (Sprint Review, Backlog Adaption)
  1. Get feedback on at least one new thing for stakeholders
  2. Update the Backlog to reflect this new information
3. Reflect on how you worked with your entire team (Sprint Retrospective, Kaizen)
  1. Is quality increasing?
  2. Is the DOD increasing?
  3. What can we change to make things better?
Go to #1

You can call the activity that results from dropping out of the while loop of working software to be a Scrumble; You need to stop piling more features on top of the features that don’t work and fix things so that you can make new things. Ultimately professional teams build software that works.

There are a number of strategies that can help you both stop creating and start paying back technical-debt:

Sufficient requirements – If your backlog has things in it that are too big or too vague then your team will not really be able to understand them and this, in turn, creates a multiplier for uncertainty. Follow the INVEST (Independent, Negotiable, Valued, Estimable, Small, Testable ) model for every single thing that you ask the team to deliver. If you invest in you backlog in this way you will find it much easier to deliver the contents and thus predict that delivery. This will require you to spend a significant amount of time in refinement. Backlog refinement is key to facilitating a flow of actionable Backlog Items to your team.
The Developers choose what they can deliver – this implies that the Developers can reject any item on the backlog that they do not understand. If we accept that every Developer is trying to do their best to deliver for their Product Owner then the only reason to reject anything would be if an item is too big or does not have enough detail to understand. These Backlog Items can be put on the queue for refinement and refined over the next Sprint. Remember that there is no such thing as a rejected backlog item, only actionable feedback and continuous improvement.
Definition of Done (DoD) – Along with having sufficient requirements the single biggest blocker to predictability is a lack of common understanding of DONE. Done for Developers should equal what it means to complete an item with no further work required to ship it. If you cant ship working software then you need to stop sprinting, Scrumble, and focus on getting your software into a shape that can be delivered in a Sprint.
Test First - Focus on Test First practices like TDD or ATDD to help you make sure that not only did your engineers build what they expect, but that you ultimately built what the customer expects.
Fixed length iterations – If you have variable length iterations you can’t be sure what you can do in a particular timeframe. How much decomposition do you need to do to the backlog? How much can the team deliver in a single iteration? You can’t be sure unless you have fixed length iteration, and you reject the idea of staggered iterations.
No separate teams – This means no separate test teams, configuration management teams and definitely no separate maintenance teams. It’s hard for folks to grasp, especially with the recent focus on DevOps but if you have separate teams then why would your Developers, those best placed to fix any problems, care about the problems of other teams. The most successful organisations at creating software have development teams that own the entire application lifecycle (Amazon AWS | Visual Studio | Azure DevOps.)
Manage dependencies - Managing dependencies is a hard task and my advice would always be to minimise the number of dependencies that you have. Developers should have all of the skills required to deliver what you want at the quality level that you want. So if you need to have productionised databases or scripting for production delivery then you might need a DBA or an Operations administrator or two. This can be hard for many teams or organisations but you will have far less success creating silos like Configuration Management or DevOps. Rather add those individuals that you need to the team. However, if you have a dependency on a separate team, maybe you have an application upon which all of your other applications depend, then you may need another way. This is not a silo of types of individual skills, but of a domain and that team just has something in their backlog upon which you are dependent. It is up to the team’s respective Product Owners to fight negotiate over when these things get done.
Use a modern source control system - A modern source control system is more than just code management, it should include all of the goodies talked about in DevOps practices and beyond.

If you can, do them all, and many more…

Work can flow across the Sprint boundary

Martin Hinshelwood — Tue, 30 Jan 2018 20:12:00 +0000

There is nothing in the Scrum Guide that explicitly prevents work from flowing across the Sprint boundary. In fact, allowing flow across Sprints, without compromising the Sprint Goal, is a pragmatic strategy that enhances delivery, throughput, and responsiveness to customer feedback.

For practical guidance, explore the Kanban Guide for Scrum Teams, and consider attending a Professional Scrum with Kanban class.

TL;DR

The Definition of Done ensures transparency and quality and is non-negotiable. The Sprint Goal must articulate clear, measurable business outcomes or customer benefits. Effective flow requires reducing batch sizes, allowing unfinished work to cross Sprint boundaries strategically. Professional Scrum Teams adept at consistently delivering Done increments significantly enhance their throughput by embracing flow principles and rapid feedback cycles.

A Sprint serves primarily as a container for planning, not always for delivery. Just as Continuous Delivery integrates seamlessly with Scrum, incorporating flow through Kanban complements and strengthens Scrum practices. All teams can benefit from this approach, provided they consistently achieve clear, outcome-focused Sprint Goals and maintain transparent, Done increments.

Managing Work Across Sprint Boundaries

Allowing work to flow across Sprint boundaries is an advanced yet beneficial technique. Initially, many teams struggle as they rarely achieve truly Working Software or fully meet their Sprint Goals by Sprint’s end. Transitioning to a mindset of flow and continuous validation is crucial for agile maturity.

My early scepticism around flowing work across Sprints shifted through deeper discussions with colleagues like Steve and Daniel. The critical insight was distinguishing the necessity of a Done Increment from the expectation that all Product Backlog Items (PBIs) must be completed by Sprint’s end.

Teams practicing Continuous Delivery (CD) inherently create working software incrementally and continuously. Such teams typically automate every aspect of their Definition of Done. Thus, by the Sprint Review, presenting completed increments is straightforward and predictable.

For a professional Scrum Team, adopting CD is foundational, not optional.

Strategic Sprint Goals and Continuous Value

Good Sprint Goals clearly articulate measurable outcomes or customer benefits rather than listing features or technical tasks. These goals act as strategic stepping stones toward your broader product or business roadmap, enhancing the clarity and alignment of your team’s efforts. Poorly constructed Sprint Goals, focused merely on delivering bundles of functionality or technology, often fail to communicate explicit and measurable benefits.

Aim to deliver multiple increments within a single Sprint, frequently gathering user feedback to continuously inspect and adapt progress toward your Sprint Goal. Regular increments and rapid feedback loops foster empirical control, allowing the team to pivot swiftly based on emerging insights or market changes.

Minimal Sunk Costs and Strategic Investment

Organisations invest in products or services one Sprint at a time. Each Sprint represents a potential decision point: assessing product-market fit and deciding whether continued investment is justified. The ultimate aim is to minimize sunk costs, banking created value incrementally and evaluating whether the product should continue development, transition to maintenance, or be marked end-of-life. Effective Sprint Goals and transparent increments support informed strategic decisions, ensuring resources align with business outcomes.

Shipping Software with Unfinished PBIs

Flow necessitates disciplined engineering practices ensuring early, frequent validation through automation. Key practices significantly enhancing CD include:

Feature Toggles – Enable controlled exposure, A/B testing, and experimentation. Temporary toggles must be systematically removed through refactoring upon feature completion.
Refactoring – Regularly restructure code for clarity, maintainability, and responsiveness to customer feedback.
Test Driven Development (TDD) – Validate code functionality continuously, supporting confident incremental changes and refactoring.

While complementary, these practices are fundamental to robust CD frameworks. Experimentation and iterative improvements tailor their application effectively to your context.

Aligning Flow with Scrum Principles

The Scrum Guide mandates a Done increment each Sprint for transparency. Without transparent increments, empirical control suffers, undermining Scrum itself.

Unfinished Backlog Items differ fundamentally from incomplete (“undone”) work.

Flowing work between Sprints is permissible within Scrum if aligned with clear Sprint Goals and delivering usable increments:

Sprint Review – Teams collaboratively inspect completed increments, openly discuss incomplete work, and revise the Product Backlog based on stakeholder insights and measurable outcomes.
Sprint Planning – Establishes clear goals and forecasts achievable work items, ensuring alignment with delivering increments and measurable Sprint Goals.
Sprint Goal – Provides strategic focus. Teams can integrate additional work provided primary Sprint Goals remain achievable, enabling strategic decision-making based on ongoing feedback.

Regularly revisiting the Scrum Guide, emphasizing empirical control, and maintaining Scrum Values ensures successful flow integration within Scrum. Consistently verify increments against the Definition of Done and fulfil measurable Sprint Goals.

For further insights, review the Kanban Guide for Scrum Teams and consider participating in a Professional Scrum with Kanban course.

Rethinking Capacity Planning

Martin Hinshelwood — Mon, 21 Jul 2025 09:00:00 +0000

Capacity planning is not about filling calendars or counting resource hours. It is about flow, system constraints, and predictability. And importantly, what we are talking about here applies even within environments of strict budgets, immovable deadlines, and rigorous accountabilities. Lean approaches do not discard discipline; they reframe how we achieve predictability, accountability, and sustainable delivery by focusing on the system, not just the parts. These ideas align directly with the Scrum ethos of empirical process control and the Kanban strategy of observing and managing work-in-progress limits to enhance value delivery.

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.

Should You Use One Project to Rule Them All in Azure DevOps?

Martin Hinshelwood — Mon, 25 Aug 2025 09:00:00 +0000

Most organisations still believe that managing multiple projects means a better organisation. It doesn’t. It could just be hiding your problems or even creating them.

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.

⚠️ Warning

This is going to get confusing since “Team” can mean “team of people” or the Azure DevOps construct of “Team”. Im going to try and explicetly say “Azure DevOps Team” to refer to the construct and “team” to refer to a group of people. These people could be a “portfolio team”, “feature team”, or “delivery team”.

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.

MyProject
 ├── Product A
 │    ├── Team 1
 │    └── Team 2
 ├── Product B
 │    ├── Team X
 │    └── Team Y
 └── Platform
      └── 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.

💡 Tip

Use Area Paths deliberately. They are your primary tool for scoping permissions, isolating test plans, assigning build policies, and targeting dashboards. Keep them stable. Don’t reorganise on a whim.

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.

💡 Tip

A work item should never appear on two boards. If it does, your setup will confuse stakeholders and erode trust.

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.

⚠️ Warning

When teams have different cadences within the same funding structure, it can cause friction and delays.

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.

💡 Tip

Choose a cadence for review and delivery that aligns with the business needs, stakeholder engagement cadence, and the effective planning horizon. Regardless of the delivery team’s chosen process, everyone inspects and adapts at least on that cadence.

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.

💡 Tip

Use Azure DevOps Groups that contain Enta ID groups to maintain flexability and clarity

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.

💡 Tip

Reporting doesn’t just inform, it aligns. A unified project gives you shared truth. Every extra project boundary erodes that.

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

Testing in Production Maximises Quality and Value

Martin Hinshelwood — Thu, 13 Feb 2025 09:00:00 +0000

Testing in production, is about structured, observable releases that allow for fast feedback, controlled exposure, and rapid course correction, ensuring quality without sacrificing speed.

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:

Incremental feature releases with real-time telemetry analysis.
Production-first mindset, shifting quality assurance left.
Automated stops to rollouts triggered by observed failures.
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:

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.
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.
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:

Feature Flags & Toggles – Control feature exposure dynamically without redeploying code.
Progressive Delivery – Gradually expand releases based on telemetry and user feedback.
Real-Time Observability – Use logging, metrics, and tracing to detect issues immediately.
Automated Rollout Halts – Deployments should automatically pause if telemetry detects anomalies or performance degradations, ensuring issues are caught before they escalate.
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?

Why Topic Branches Drive High-Quality Delivery

Martin Hinshelwood — Mon, 14 Jul 2025 09:00:00 +0000

In modern software development the idea of the topic branch is an essecial one. It is your gatekeeper to preventing Conway’s Law and an engineering structure that mirrors your organisational boundaries. Frequent integration through topic branches helps break down silos, encouraging cross-team collaboration and reducing the tendency for the software architecture to reflect the organisation’s communication paths.

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.

Stop Promoting Branches

Martin Hinshelwood — Thu, 06 Feb 2025 09:00:00 +0000

The traditional Dev → Test → Staging → Production model is flawed, leading to unnecessary complexity and reinforcing outdated software delivery patterns. This breakdown explains why branch promotion is a failure mode, why GitHub Flow and Release Flow are reasonable alternatives, and why Git Flow belongs in the bin.

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:

Code is committed to a Dev branch.
It moves to a Test branch for QA.
It advances to a Staging branch for approval.
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:

Every change merges into main as soon as it is ready.
Deployment is decoupled from release using feature flags.
Testing happens in production-like environments without blocking releases.
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:

Developers work in short-lived feature branches.
They open a pull request against main.
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.

The Definition of Done is a Commitment to Quality

Martin Hinshelwood — Mon, 28 Jul 2025 09:00:00 +0000

Every Scrum Team must explicitly define what “Done” means. Without it, you are not doing Scrum. Let’s be clear: if your product increment cannot be shipped, tested, and validated at least every 30 days, you’re missing the point. Scrum is a social technology for adaptive solutions, and the Definition of Done (DoD) is the core commitment to quality that enables reliable, transparent, and releasable increments.

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:

Organisational DoD – minimum standards to protect reputation and compliance.
Practice DoD – engineering or discipline-specific standards (e.g., security, performance).
Customer DoD – any client-specific requirements.
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

Run a DoD Workshop , include Developers, Product Owner, stakeholders, and relevant experts.
Document and Share , make the DoD visible, accessible, and owned by the team.
Automate , reduce human error by automating checks wherever feasible.
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.

A better way than staggered iterations for delivery

Martin Hinshelwood — Thu, 10 Dec 2020 09:00:00 +0000

There is a better way than staggered iterations for delivery that will keep you on the path to agility. Staggered iterations lead to more technical debt and lower quality software.

Updated to reflect the 2020 Scrum Guide!

TL;DR;

The expected result of staggered iterations would be an increase in rework and in technical debt. If you are moving from a 4-year iterative process to a 4-month one you will see the value, but your process will be opaque and will only reduce your ability to deliver working software.

Yes, your cycle time will be reduced, but you can do so much better. Move all requirements for shipping your software into your Sprint. If you need testing then it needs to be inside of the Sprint. A general rule is that: If you need to validate something outside of the Sprint; User Acceptance, Security audit, regulatory approval; Then you need to make sure that all of the work required to pass that outside validation is doing inside of the Sprint, with no further work required from the development team.

-Martin Hinshelwood

For example, this means that if you have 6 weeks of animal trials, followed by 6 weeks of human trials to validate that your pacemaker firmware is good, you can’t have those things happen inside of every 2 weeks Sprint. Instead, focus on what you can do to make those things pass. If they don’t pass then do a full route-cause-analysis and bring that new information to your Sprint Retrospective and make sure you put measures in place to make sure it does not happen again.

A better way than staggered iterations for delivery

I have seen many companies that are trying to move towards greater agility get trapped in the past by creating artificial silos based on skills. They believe that by creating a timbox for planning, development and testing that we can get closer to agility and move away from our traditional models. Unfortunately, the actual result is to enshrine that traditional staged model and step sideways on the path to agility, not forwards. In many cases, it can be a significant step backwards that will take many painful years to rectify.

staggered-iterations-for-delivery

I have heard this called many things. Water-Scrum-fall or maybe Scrummerfall but whatever you call it the reality is that this is just small waterfalls and in the case above not really that small at all. This is often how organisations respond when they are told to “do agile” and they end up figuring out how to not really change, and do the same thing that they have always done.

This is not the action of a Professional Scrum Team, but that of, at best amateurs and at worst cowboys.

The problem with staggered iterations for delivery

In the diagram above we have an 18-week cycle from inception to delivery. That’s more than 4 months between ideation and delivery with a lag of 2 months to even get feedback with a 2 month lag for all subsequent feedback. Worse this is the most expensive kind of feedback as the Coding and Testing teams have already moved on from the thing that is getting feedback and the result of that feedback will be more expensive to implement. Indeed worse yet if QA finds something that needs fixed we have maximised not only the cost to fix but the meantime to repair as the developers have moved on. And what do they do with that feedback? How is it prioritised? Do they quit what they are doing immediately and fix the previous iteration or do they wait until after they deliver this one? What if they are blocking QA? Does QA sit around till the end of the iteration after the one they reported the problem in?

The solutions to staggered iterations for delivery

We need to foster teams over individuals and make those teams responsible for the delivery of working software. To get that we need cross-functional teams that can turn ideas into that working software. And we need to do it often.

Cross-functional teams – We need to have everyone on the Developers that is required to turn the Backlog Item into working software. If you were a property developer you would have access to joiners, plumbers, plasterers and electricians. You would create a team of individuals that was sufficient to complete the daily work on-site with experts on hand as needed. This is the same process for Developers . You should have all of the skills that you require on each team to turn the forecast backlog items into working software each and every iteration. Have experts on hand for those tricky items but minimise the dependency that you have on them.
Asynchronous development - Ideally you want all of the disciplines that you need to complete each backlog item to work together to deliver the software. This is more than handing off between disciplines but moving towards everyone always working at any point in time. This is a hard one to achieve but is the responsibility of the team to figure out how; To achieve asynchronous development you will need a modern source control system .
Test first – Test first is about not doing any work unless there is a measurable test that elicits that work. Creating tests from acceptance criteria will make sure that your team is working on and understands the next most relevant thing to be worked on and that you have built what the customer wants. Additionally, creating unit tests before code will make sure that your coders are working on the most relevant problem, and that each line of code that they complete does exactly what they intended. The long term benefit of this is that we now have an executable specification that will result in an error if a future change breaks existing functionality. You are doing it wrong if you are not using test first.
Working software each iteration – If you don’t create working software at the end of each iteration you have no way of knowing what really needs to be done to create a working increment. If you do four iterations of two weeks before you think about creating a working increment, how much work (re-work really) is left that you need to complete to really be done? To really have shippable quality? If you don’t have working software at the end of each iteration you are making sure that your business can’t ship out of band, no matter how much it wants to; Professional Scrum Teams build software that works .
Quality Assurance requires no testing – If you consider that all testing is done as part of the sprint, then the only thing that needs to be done as part of the QA gate is to review the test results and coverage and determine the sufficiency of those results and coverage. If you are taking more than four hours to QA two weeks of development then I would suggest that the Developers work is not sufficient.

These things will all individually help and if you are doing all of them together your value delivery and quality should start to increase over time. Make sure that you focus on automating everything from the moment a Software Engineer checks in code, to it being continuously delivered to production . In the age of agility giving you a competitive advantage in whatever marketplace you are in, any manual work is a risk.

Stop Hiding Behind Complexity and Start Delivering Continuously

Martin Hinshelwood — Mon, 24 Feb 2025 09:00:00 +0000

Every organisation says their software is ’too complex’ for continuous delivery. That’s nonsense. Complexity is an excuse, not a blocker. Azure DevOps, Starbucks, and countless others proved it wrong. The only real obstacle is the resistance to invest in fixing what’s broken. Complexity is an excuse, not a blocker. Microsoft proved it. Starbucks proved it. You can too; if you’re willing to put in the time, effort, and money.

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:

Current Value (CV): Measures the value delivered to customers or stakeholders today, reflecting satisfaction and success based on the current product.
Unrealized Value (UV): Identifies potential future value by highlighting gaps between what customers have and what they need or desire.
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.
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.

Your Evolving Definition of Done

Martin Hinshelwood — Mon, 31 Mar 2025 09:00:00 +0100

The Definition of Done (DoD) is not a static artefact; it evolves over time as a Scrum Team gains experience and capability. While the Scrum Guide acknowledges that teams may refine their DoD to improve product quality, there’s an often overlooked piece: Organisations should also provide an organisational Definition of Done that reflects their needs. This organisational perspective ensures that Scrum Teams build on a solid foundation, aligning technical execution with strategic goals.

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.

“Live an in production” - done here mean that it is in the hands of real users
“gathering telemetry” - done here mean that the Developers must add code that collects relevant information from usage, performance, and such…
“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:

Start at a minimal viable level (e.g., basic testing, peer reviews).
Expand to include automated testing, security checks, and CI/CD.
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

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.
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.
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.
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.

Fragile by Design: The Cost of Pretending to Be Resilient

Martin Hinshelwood — Mon, 12 May 2025 09:00:00 +0000

Most systems are not resilient. They are fragile by design, propped up by a fantasy of “continuity” that vanishes the moment real pressure hits.

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.

Professional Scrum teams build software that works

Martin Hinshelwood — Thu, 03 Dec 2020 00:00:00 +0000

I am always surprised at the number of teams that release undone work to production. I understand that one may need a few sprints, or many if you inherited something nasty, to pay back that debt, but if it’s more then you are not a Professional Scrum Team. The sheer amount of software that I have that is buggy, slow, or just not finished makes me think that there are few professional Scrum Teams out there!

TL;DR;

Every organisation has the right to hold their Developers accountable for the quality, but never quantity, of the software that they build. Every Developer should pursue engineering excellence through DevOps practices, automation, and rigorous attention to detail for every release. Working software builds trust with your users and promotes your brand, faulty software encourages distrust and hurts your reputation. Defective software and technical debt are the causes of the current death grip that organisations have to traditional Taylorism based management techniques.

Ultimately if your organisation will not let you build software any way you please its because of the shit that you have been trying to get away with delivering in the past. You have work to do to build trust again.

Treat your team to a Professional Scrum Developer class to get them up to speed.

Scrum teams build quality software that works

Working software is software that is free from fault or defect. Developers are primarily accountable for the quality and delivering a usable increment. While they are also responsible for value delivery, the accountability for that lies with the Product Owner. That means that if there is a choice between delivering value that lacks quality or providing less value that is of higher quality, Developers should always choose quality.

Since “rules are for the guidance of wise people, and the obedience of fools” I am going to caveat that statement for those that like to latch onto absolutes. Since any software that you build is an organisational asset, and all assets are attributed to the value of your company then that software must exist on a balance sheet somewhere. If you as the Developers decide to cut quality to make a delivery do you immediately speak to the CFO so that they can accurately reflect that loss of value on the companies balance sheet? Because if you don’t, then knowing or not there is a danger that your organisation is committing fraud by inaccurately reflecting the value of your software! Ultimately the decision to cut quality should only be taken with the full consent and understanding of your executive leadership team.

The decision to cut quality is not one that the Developers , the Product Owner , or IT management are able to take, it is reserved for executive leadership alone.

Quality software is not about expectations!

Working software is software that is free from fault or defect, but it does not necessarily meet the Product Owner’s or stakeholders expectations.

It is just not possible for everyone’s expectations to be understood let alone met, and thus it is unrealistic to expect the Developers to deliver on them. At the end of every Sprint we have a Sprint Review where we invite stakeholders, and the Scrum Team, to pause and reflect on the Product Backlog based on that which was delivered. There you can explore the difference between expectation and delivery and then update the Product Backlog to reflect that difference. The Scrum Team should continuously be investigating the difference between what they delivered and stakeholders expectations so that they can close that gap as much as possible, so while they are responsible for meeting expectations, they can’t be held accountable.

The Development Team consists of professional Developers that are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work.

-The 2020 Scrum Guide

The Scrum Guide very deliberately does not tell you how to build working software. It only states that its delivery is the accountability and accountability, and responsibility of the Developers If you don’t have working software, then you are not yet doing Scrum, although you might be working towards it.

So, to define working software we have to look at what working software is not:

Known errors or exceptions - if you find a bug then fix it. If it’s too big, then raise it with the Product Owner , and get it on the Product Backlog. To much time is spent managing rather than fixing bugs. Just fix them.
Manual Tests - if you have manual tests then you are already working towards software that does not work, or that you struggle to deliver. It is unsustainable to have any manual testing, so get automating.
Manual pipelines - in 2017 no-one should be building production code on their local computer, never mind shipping it to production from there. Even if all your build does is package up some files, and push them to an FTP location. Automate your build process… If you have a person that has to do something more than approving between code and production, then you should look to automate that process away. Humans make mistakes, and humans miss stuff. At least with an automated process if not continuous delivery, you get consistency, and you can increase the complexity over time for consistency. Make sure that you automate both your build and release pipelines.
No Source Control – Yes, I still meat organisation with no Source Control, or no control over it. I wrote Getting started with modern source control and DevOps for just that reason. If you don’t even have source control, whatever you are developing, then you need to get help and quick. The business risks that are exposed by not having it are just too big.
Lack of feature flags – It is a fundamental fallacy of the rejected backlog item, and your engineering team is going to have to figure out how to release at the end of every sprint (or every commit) regardless of the quality of the PBI’s being worked on. Hide features that are not completed behind feature flags so that they are not visible to end-users, but your code can still be shipped.

The other name for the things that make it difficult to get to working software; Technical Debt. All of the things listed above are forms of Technical Debt, but the biggest form is just poor quality code. Code that is not tested or would not meet even a cursory code review by another software engineer.

What happens if Developers are not accountable for Quality?

If the Developers are not held accountable for quality why do you believe that you have it? Quality is one of those hidden measures in software that can be there or not, and you would not know unless you were using that product in anger. If you put pressure to deliver on a Developers , they will consistently and increasingly cut quality to meet whatever ridiculous deadline you give them.

Use Scrum to Inspect and Adapt empirically

Every organisation needs to focus on delivering quality working software that is of use to its customers. The entire Scrum Team is accountable and then works together over many iterations, experimenting and continuously improving, to deliver the best possible outcome in the circumstances. So instead of being an amateur team, be a team of Professionals that deliver working software because that is what your organisation and your customers deserve. If you are having a hard time delivering then discuss your options anytime, but especially at your Sprint Retrospective, and figure out what actionable improvement you can make that will help you pay back some of your technical debt and move forward. Once such step could be making sure that your Developers at least understand this with a Professional Scrum Developer course.

Use empiricism to Inspect and Adapt with Scrum.

Why Most Companies Operating Models Fail in Dynamic Markets

Martin Hinshelwood — Thu, 04 Dec 2025 00:00:00 +0000

Most organisations today operate under a Predictive Operating Model while competing in dynamic markets. This fundamental mismatch creates enormous waste, missed opportunities, and frustrated teams. Understanding why this model fails, and how an Adaptive Operating Model can replace it, is essential for any organisation seeking to deliver value effectively in the 21st century and beyond.

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:

The Essential Drucker by Peter Drucker (2001) - collection including “The Theory of the Business” essay ↩︎
The Principles of Scientific Management by Frederick Winslow Taylor (1911) - foundational work on industrial management ↩︎
The Scrum Guide by Ken Schwaber and Jeff Sutherland ↩︎
Mary Parker Follett’s work on organisational democracy and distributed authority ↩︎
The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka ↩︎
Continuous Delivery by Jez Humble and David Farley ↩︎
Organize for Complexity: How to Get Life Back Into Work to Build the High-Performance Organization by Niels Pflaeging and Pia Steinmann ↩︎
Management: Tasks, Responsibilities, Practices by Peter Drucker (1973) - comprehensive framework for management functions and organizational design ↩︎
This Is Beyond Budgeting: A Guide to More Adaptive and Human Organizations by Bjarte Bogsnes ↩︎
The Practice of Management by Peter Drucker (1954) - introduces Management by Objectives and the theory of the business ↩︎
High Output Management by Andy Grove (1983) - on system thinking and management leverage ↩︎
OpenSpace Agility by Daniel Mezick, Harold Shinsato, and others - a framework for organizational change through self-organization, Open Space events, and rapid experimentation ↩︎ ↩︎

Can the Definition of Done change per Sprint?

Martin Hinshelwood — Mon, 14 Oct 2019 13:55:00 +0000

I was asked this question today and I think there is a clear answer, however it may change depending on the context of the question.

“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.” -Scrum guide

[Question] Can the Definition of Done change per Sprint?

Yes; you can and are expected to make improvements to the Definition of Done at the Sprint Review. Your Development Team should always be asking themselves:

Do we have the quality level that we need to release?
Is our quality improving?
What can we add to the Definition of Done to improve quality.

Every bug found in work that was done in a previous Sprint is a possible quality issue that should result in a stronger Definition of Done to make sure it never happens again. However I am a little concerned that the brevity of the question could result in enabling activity in a way that can be used to suborn the process. There is a distinct lack of context to this question that could change my answer from a yes, to a no.

[Question] Can the Definition of Done change per Sprint so that we can reduce quality and deliver more features?

The resounding answer here is no. You should never reduce quality as its not within the authority of a Scrum Team to reduce quality. The quality of the product equates to the value added to that product through capital investment. If one chooses to reduce quality then that change in the ROI of the capital investment needs to be reflected in your financial statements. If you are a private company, then I would think that your Shareholders would be unhappy if the value of an organisational asset is misrepresented! What about if its a public company? Now we are in the realm of fraud!It is a board-level responsibility to actively reduce quality and the ramifications of that reduction should be presented to your board. A Development Team does not have the authority to lower quality, the Product Owner likely does not have that authority, and your IT Management definitely does not. When I am approached with this question by teams, I always say: “Let’s go have a chat with the CFO and make sure he understands the ramifications of a deduction of quality on his capital investments.“I’ve never had anyone take me up on that offer.

[Question] Can the Definition of Done change per Sprint because we have different DoD for each backlog item?

No, you should have a consistent DoD that is applied to all of the work that you do, and that represents a usable increment. Sometimes I see some confusion between DoD and Acceptance Criteria. DoD is about how we do things and covers engineering practices, Development Team standards, coding standards, architectural standards, and other Development Team standards. It should reflect both product and engineering qualities. Acceptance Criteria is about the notes that we have to take when we are discussing what we are going to deliver. This is the bit that is different for every Backlog Item.

[Question] Can the Definition of Done change per Sprint because we just like mixing it up?

No; The purpose of the Defenition of Done is to maintain transparency of the past by allowing everyone to understand what a “usable increment” means.

If we keep changing the goal posts how can:

Does the development team determine if a Backlog Item fits in a Sprint if we don’t know what we will do for it?
Does the development team create a Sprint Backlog that contains the about of work that they believe that they can reasonably achieve?
How does the Product Owner or the Stakeholders understand what they are looking at at the Sprint Review?
Do your stakeholders understand their return on investment?

On a brownfield project that moves to Scrum, I would expect your DoD to start week, and not reflect releasable. Each Sprint Retrospective, your Scrum Team, should review your DoD and get it closer to releasable. As you make the changes, you will discover more technical debt, and it may take some time to pay it off. Keep improving until your definition of Done mirrors shippable. On a Greenfield project, you should always start with a definition of Done that mirrors shippable and have shippable product every Sprint, including the first one.

There are no right answers, only things that you try to discover if they are right for your Team.

Definition of Done - Objective vs Subjective

Martin Hinshelwood — Fri, 03 Jan 2025 00:00:00 +0000

In countless teams, there’s a recurring mix-up between “what” we’re building, “how” it aligns with business objectives, and the objective quality criteria by which it should be measured. The result? Chaos masquerading as agility. To clear the air: in Scrum, the “what” and “how” are driven by Product and Sprint Goals. These provide directional clarity but remain inherently subjective, a north star guiding your path, not a litmus test of quality.

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:

Objective and Measurable: Avoid vague criteria and instead focus on things that you can measure.
Comprehensive: What are all the things that need to be true for a production deployment of your product to be deployed to production?
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:

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.
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.
Train Teams: Ensure every team member understands the DoD and its importance in delivering professional-grade Increments.
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!

Avoid the pick-n-mix branching anti-pattern

Martin Hinshelwood — Mon, 14 Jul 2014 15:35:35 +0000

For the last few days I have been working with a customer in the UK on a grass roots engagement to help them solve their source control issues. They have ended up with a pick-n-mix branching anti-pattern and could not see the way out.

The pick-n-mix branching anti-pattern is something I encounter quite often and on the surface it looks like it should work and give the business flexibility. However the real result is lost code, failed releases, technical debt, unhappy customers, and an erosion of trust with the business.

For the last few release they had noticed that they had been missing things from the release and this had resulted in some major bugs and egg of the face of IT. This is obviously not acceptable and they were looking for advice on how to move forward. There current source code management model was not working for them.

In their current model they were doing something that I like to call pick-n-mix branching. In the diagram above you can see the pick-n-mix branching anti-pattern where in scenario #1 we are leaving behind some of the changeless. However in scenario #2 we are taking a couple of changeless that are dependant on some things that were left behind. This may result in a compile time error, or worse in the case of a website or some asset types. What if these were SQL changes… How hard would it be to debug why the development code line works and Test does not. Worse again when you compound the result and this happens over many years it may work out for a while but even just a year down the line how much code is there in development that was never pushed to test. And how to you know which is which when you are adding new features to development?

The pick-n-mix branching anti-pattern is a symptom of poor planning and almost always results in a code promotion model. In a code promotion model you are promoting source code from Development->Test->Production. This has the unfortunate consequence of complicating your quality assurance. You do not test code, you test the binaries that are a result of the compilation process. You might have clever packaging but ultimately you are releasing those binaries. However the reality is that if you create new binaries you are going to need to test them all over again to get any kind of assurance. Even without pick-n-mix code promotion is not the best of ideas but with! Now we are easily in a world of hurt.

On small projects with few developer this can work. I even had a customer that create a software tool around this so that they could scale. However this is dysfunctional behaviour and results in a number of issues:

Technical Debt (or an un-hedged fund) - More and more code will ley unfinished in the Development branch which results in an inability to have 100% working software every build.
Merge Chaos - Over time the difference between development and production will increase leaving developers with less and less idea of what dependencies they can take. This results in total chaos at merge time, and it will only get worse as time goes on.
Retest required - if you are creating new binaries then you have to re-execute all of your tests even if you think nothing has changed. You have just created a brand new version of your application.
Business Trust - As your software erodes you will more often have failed rollouts and more major bugs in production. The result is a total lack of trust in your ability to deliver by your business. This often results in a crazy and convoluted gated model for deployments with loads of ass-covering paperwork.

The pick-n-mix branching anti-pattern is used as a crutch for poor planning. The solution for this is a single branch line and using feature flippers (toggles) to determine what code is run. However this requires engineering work and cannot be turned on with a switch. It will take some time, often a considerable amount of time, to engineer into the product. The only way to mitigate this in the short term is to switch to a Feature branching model.

In a Feature branching model we have single main (or trunk) line with multiple branches for each feature. Features are one or more things that will ship together. There will be no pick-n-mix and everything on that feature line will merge to the ‘main’ line at the same time. This will require a little more planning as you need to separate your features early. And a little more coordination from your management to make features distinct. This however gives you the capability to continue to release some features and not others without changing your code too much.

There are still a few downsides:

Multiple instances - we need an instance of our application per feature branch. This can be expensive and time consuming.
Break in binary pipeline - as we are still on a separate branch and promoting code we can’t have a seamless binary promotion model. We can however have one per feature and then an end-to-end one pipeline for Integration

In an ideal world you need to change your code, using agile engineering practices, to allow you to be able to turn any feature off at any point in the release cycle. This would allow you to not ship a new feature as late as the day of release (or later) without having to rebuild, change a single line of code, or run your full regression again. When you are able to do this then you can move to a more advanced branching model where you maintain either a single source line, or for business reasons you may have a step structure for major releases.

In the step model you go back and fix bugs on the oldest version that you support that has the bug. You can then push forward from parent to child in the clear safety of never having to choose between bugs and new features.

When you are in the zone with the need for withholding features between major versions for marketing reasons then you may need to work on separate branch lines. This is most effectively solved by using a step, or branch by release, model. This is not a branch for every bug fix or small change but instead is relegated only for the major changes. This allows your branch line to move through various states at different times depending on the criteria that you set. You may still have the idea of ‘dev’, ’test’, and ‘prod’. However the difference between the states is likely only one of rules-of-engagement.

However this is still just feature branching except we are looking at major releases. As you organisation realises the power of continuous delivery and the speed with which it can get function to market they will start to change and accept the reality. When that happens you can move to the most optimal branching model of all. The single line.

Conclusion

If you are currently in a pick-n-mix branching model you need to move immediately to a Feature branching model to reduce risk and promote stability. It may take a while to get to this point but it will make your life easier and allow you to start building more trust with your business as you are more likely to be successful with releasing. At this point you can move to binary promotion on your main line to reduce your test matrix.

Once you are there you should look at implementing the engineering necessary in your product to implement Feature flippers to whatever level of granularity makes sense in your application. This may be by feature, user, or account and should provide you with the flexibility that your business require and is willing to pay for. Now we can move towards true binary promotion from our development phase all the way through to production.

Even while in a single branching model with binary promotion you may find the need to have a stepped model where you need to support multiple versions of your product. This can be achieved without crippling your teams by having your branching flow forward from parent to child as you move through major releases of your software.

Ultimately there is no excuse for using the pick-n-mix branching anti-pattern for branching. Step up, be professional, and fix this one for good.

I do continuous deliver, why should I Sprint?

Martin Hinshelwood — Mon, 13 Jul 2020 18:42:03 +0000

Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous delivery pipeline and say to themselves; “Why would I limit myself to shipping only once every two weeks?”

UPDATE: Scrum.org just posted my Scrum Tapas - Scrum and Continuous Delivery which is posted inline below.

[embed]https://www.youtube.com/watch?v=3XOorzoubYU[/embed]

To that I say: “Where in the Scrum Guide does it say that you can’t release every day?”

You will not find it, I know as I have looked. I work with many teams that release software on a continuous delivery model of everything from a few hours, to a few days, and often on-demand. Can you say that they are not doing Scrum? Of course not.

So why would you want a Sprint at all?

A Sprint enshrines your empirical process by providing a maximum delivery cadence
It increases communication and alignment
It Adds some predictability to the unpredictable nature of software by evening the batch sizes.
A Sprint is a container for planning!

As far as the Scrum Guide is concerned you must deliver working software at least every 30 days, but there is nothing to stop you doing it more frequently than that. Indeed continuous delivery and Scrum go together quite well in my experience.

A Sprint enshrines inspect and adapt by containing your other feedback loops:

Sprint Planning - Inspect the Backlog and Adapt the plan for the next Sprint
Daily Scrum - Inspect progress and adapt the plan for the next 24hours.
Sprint Review - Inspect the Increment and adapt the Backlog
Sprint Retrospective - Inspect the Sprint and adapt the process.

Without a Sprint when would you bring all this together? The Sprint makes the effort required to pull your work together and create a Done increment of software mandatory. It is absolutely crucial to understand that if you don’t at least have working software that meets your definition of done by the end of the Sprint then you are not doing Scrum.

If you are an awesome disciplined team then by all means do something that looks a little more like Kanban, but if you don’t have the discipline to follow the rules of Scrum, how would you expect Kanban to work.

Communication & Alignment

An additional benefit of Sprinting is that it gives a cadence that your management, and other dependant teams, can follow easily. If you are coordinating work, then having a common frame of reference, Sprint 231, will aid in communication.

Creates Predictability

Software is inherently unpredictable. The standard deviation between the amount of work required for seemingly similar tasks is so big that it is very difficult to gain predictability. A Sprint creates an artificial batch of a fixed size (or at least less varied) with a time boxed Sprint so that you can create that cadence of predictability.

Conclusion

A Sprint is a container for planning rather than releasing and while Scrum requires that you have a working increment of software at least every Sprint, there is nothing to stop you doing it more often. Indeed the recommendation from Scrum.org is that you not only ship your software at least every 30 days, you should endeavour to do so more often.

Scrum.org recently changed its mantra from “Improve the profession of software development” to “Improve the profession of software delivery” to start to enshrine the idea that delivery, to your customers, is no longer optional to get significant actionable feedback that you can reflect on.

In short, while the Scrum Guide does not explicitly state it, it is no longer optional to ship your software to production at least every 30 days if you want to stay competitive and build the software that your users deserve.

Getting started with a modern source control system and DevOps

Martin Hinshelwood — Mon, 13 Jul 2020 18:41:59 +0000

There are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code, but modern source control systems are about way more than code. They are about your entire application lifecycle and supporting DevOps practices, they are about the metadata that you use to understand and manage your development processes and deliver great software. The tools you choose should compliment the professional people and practices that you use.

DevOps is the union of people, processes, and practices to enable continious delivery of value to your end users

Donovan Brown

TL;DR

I have been teaching the Professional Scrum Developer (PSD) training and working with software teams for 7 years. I have never encountered a better platform than Visual Studio Team Services (VSTS) for managing the metadata required to facilitate the building of professional software on a regular cadence in any technology that is deployed to any platform. I have seen Java, .NET, Web, Android, iOS, and Mainframe teams all working together in VSTS with a shared vision and access to the same metadata. If you have many teams I did a webcast for Scrum.org on Scaling Professional Scrum with VSTS.

Let’s get some things out the way first

If you are writing code then it SHOULD be in Source Control. More specifically, if you are writing code for your company then it MUST be in Source Control. Every line of code that you write or change is an asset of your organisation and should be reflected on a balance sheet somewhere. Any value you add is capital expenditure, of which your shareholders/owners should care, and any maintenance is operational expenditure, which your accountants can write off.

Put your code in source control… and yes, I still meet organisations that DON’T use source control. No, not only small sweatshops but banks as well. Would you want your real-time transactional banking system under source control? Coz I would!

Another thing to get out of the way is that deploying directly to production is a BAD IDEA! If you are deploying from your local workstation then you are introducing significant risk to your business and reducing the quality of the organisational asset. Any reduction of quality is a decision that needs to be taken by your executive board on advice from your accountant. Again, organisational asses sitting on a balance sheet. Its fraud to incorrectly represent the value of an asset, ignorance is not an excuse. Even if you have automated builds; if you ship irregularly, or with a lot of time between releases, then you likely have a way to bug-fix production quickly. Bypassing your usual checks and balances for shipping software reduces quality and shows an inherent lack of engineering excellence in your organisation.

Deploy software through an automated release pipeline… and yes, I have met companies that deploy directly to production from workstations. I even worked with one company that had operations using trial and error mixing and matching DLL’s to get the software working in production. One customer required to do 9000+ hours of manual testing to validate that

Modern source control is more than just code… in the past, just like operating systems used to be simple things, you could stick your code in source control and call it good. In the past, you used VSS, Subversion, or Perforce and it was good enough. Not anymore. Just as you expect a browser to ship with your OS, you now expect a build engine, release management, and planning tools to ship with your source control system and for them all to be integrated. So don’t base your choice on that one thing, think of the integration and other tools that you need to support your modern software development pipeline.

I would expect my release tools to understand exactly; what changes have been made to the code, which features of the system are affected, and what the resulting impact of that release had on both the user experience and system performance through telemetry. I would expect my work tracking tools to understand exactly; what branches are related to this work, which build include the changes, and who approved the pull requests that brought that code into the system. This is the type of metadata, regardless of the implementation technology, that I would expect to be available to Engineering and Management to help them understand their process and how things are going.

That all said it is important to remember to focus on becoming a professional Scrum team rather than an amateur one. While you need to focus on the Scrum Guide, you also need Engineering Excellence and a set of Values and Principles.

Recommended good practices for a modern software team

I almost never use the term “best practices”, especially for software delivery and anyone that gives you a best practice is generally talking out their ass. There are only good practices that fit the current needs of the business or the situation at hand. In the modern software development world, you need to accept that any process or practice that you adopt is imperfectly defined and will need to be adapted to meet your needs. That said, having source control and an automated release pipeline is not optional if you want to continue to be competitive. You need to be able to monitor both your Lead Time and your Cycle Time.

Some general guidelines you should consider:

Never code without Source Control - Ultimately the tool does not matter but if you are building Open Source Software (OSS) then you need to be on GitHub. GitHub has cornered the OSS market and has not near competitor. If however, you are building closed source software then there is no better platform than Visual Studio Team Services (VSTS). You get unlimited private repositories and if you have MSDN licences, as most organisations building on the Microsoft stack does, then it is already included in your licence. If you are not on the Microsoft Stack then I would still recommend VSTS as the cheapest and most featureful platform available that supports any platform and any environment.
Use feature flags to minimise branches - Branches introduce waste with merging and often introduce quality issues. Bypass the whole issue by using Feature flags and other software patterns to avoid it. If you are using a distributed source control system (DVCS) only ever release from MASTER with fully tested code, but you can have an unlimited number of topic and personal branches, as long as they are short lived. If you are using a server-based source control system (SVCS) then you should completely avoid branches where possible, and work to move towards a DVCS. Maybe you need only [trunk/master/main] and [dev/work] branches but focus on a zero branch policy.
Move to Git - Regardless of the scale of the software that you are building, you should be developing on Git. If you are clinging to your SVCS (TFVC, Perforce, SVN, whatever) then you are merely clinging to the past and relying on outmoded technology. Even the Windows team at Microsoft has moved to Git, as has Bing, Xbox, & the entire Developer Division.
Meet your Definition of Done at least every 30 days - Create a definition of done that represents the minimum bar of quality for everything your develop. Make sure that definition reflects everything that you need to do to ship your software to production, and get there at least every 30 days. If you can get there more regularly that better, and if you can practice continuous delivery inside of your planning Sprints then that’s even better.
Get feedback from your users at least every 30 days - Part of the trick of delivering awesome software is building just what your customers need, just as they need it. The only way to do this is to get what you have just built into your customer’s hands so they can tell you is it is right, then pivot as soon as they give you feedback. Continuous delivery to production is the best way to achieve this.
Create tests first so you build what was asked the first time - You should always work towards test-first practices. While for many this means Test Driven Development (TDD) I like to look it as any form of test-first. How can your coders ever hope to pass the quality gates when the testers build the test cases separately and only show the coders after they are finished. Get your test cases written first and have the coders make them pass. I also recommend that coders use TDD and pair programming. Following Test First will help you move from testing quality in at the end to building quality in from the start.
Automate every test you can - Automation is key to a successful delivery because you can’t run all your tests every 30 days. Every 30 days you add more tests and without automation, you can’t keep up. Ideally, all of your tests are automated from the start. An interesting example is that Microsoft moved all of its testing efforts into the Development Teams around 3 years ago, and got rid of their last external test team about 2 years ago. Make your Development Team(s) accountable for Quality and give them the tools to make it happen.
Create automated release pipeline - Creating an automated release pipeline is hard but the benefits are numerable. From quality to resilience you just must have one to support modern development practices. You should focus on delivering to production (start with as close as you can get) at least every 30 days, but expect to need to ship many times a day. Automation will make your process quick and easy an lets you focus on improving the pipeline over time as you his issues. This is where lean practices and focusing on flow can really help minimise the waste and improve the process.

In order to support these things, I use VSTS as my software development platform. With the move by Microsoft to distance its platform from execution and focus on orchestration we get a system that can support any team developing with any technology for any platform. This allows us to have a single unified organisational vision and tool for our orchestration of portfolio, planning, execution, coding, build, test management, and release while leaving the execution of these tasks and the technologies used in and to build our software up to the team. You might have one team that used Nuget and another than uses NPM, or one using Maven and another on Gulp. Regardless of your implementation choice, VSTS can support your teams doing Scrum and deploying anything on a regular cadence to anywhere. When I am teaching a Professional Scrum Developer (PSD) class I always use VSTS regardless of the technology that the students are working on.

Don’t get locked into a limited set of technologies, VSTS supports every technology on every platform.

Find out more on Visual Studio Team Services from naked Agility - Martin Hinshelwood .

The Insufficiency of Scrum is a fallacy

Martin Hinshelwood — Sat, 23 Mar 2013 17:37:31 +0000

The insufficiency of Scrum is a fallacy perpetrated by teams that don’t step up their practices in concert with their planning and don’t really want to make it work anyway. You can fail doing Kanban, XP, Merise and SSADM just as easily unless you have good engineering practices as well.

The goal of Agile it to have you fail sooner and for it to cost less. So what happens when you try to make your management practices more agile but forget about your engineers practices?

Well José Manuel Nieto contacted me on twitter after joining a team that was suffering from what he called The Insufficiency of Scrum and asked for thoughts and after a conversation some advice.

@mrhinsh Hi What do you think about the thoughts I published? "The Insufficiency of SCRUM" wp.me/p33ULi-5k
, José Manuel Nieto (@SuperJMN) March 23, 2013

When we fail at something it is only human to look for something to blame other than ourselves as the implementers and the things that we did not take care of.

We have to accept the fact that no process is perfect and that we will need to work hard at anything to make it work. Unfortunately we worked at traditional software development for over 40 years to prove that it did not work. But that is not really true…. it works in the small scale or if we are building something simple. I can’t think of any modern software that is either of those things. However Agile is not a silver bullet. I will say that again… Agile is not a silver bullet and you should read Scrum is hard to adopt and disruptive to your organisation .

@mrhinsh It WAS agile until bugs started to riddle the app. SCRUM only has short-term planning.
, José Manuel Nieto (@SuperJMN) March 23, 2013

Most of the Agile Frameworks only cater for planning the ‘what’ and tells you to let the team decide on ‘how’ to build the software. Scrum, Kanban & Scaled Agile all focus on the Management process not the engineering practices. This does not mean that you don’t also need good engineering practices, and in fact the Scrum Guide explicitly tells you that your team needs “good engineering practices’ in order to succeed.

Figure: Testing is core to inspecting and adapting your engineering practices

If you don’t have those good engineering practices then you will spend more time sprint on sprint struggling with the technical debt that is built up and you will end up down an engineering blind ally.

@mrhinsh Right. It lacks all of those -able adjectives. But, how to recover from the mess. How to refactor?
, José Manuel Nieto (@SuperJMN) March 23, 2013

But now I am hosed, how to I get out of this?

Step 1: Hold effective retrospectives to prevent the insufficiency of scrum

On of the reasons our team gets into this position is that they did not know that they was in a broken state until it is too late. If our organisation fails to understand the purpose of the retrospective as an inspect and adapt moment for ‘how’ we worked during our Sprint then one will fail to improve.

@mrhinsh it was as soon as I entered the team. 6th sprint.
, José Manuel Nieto (@SuperJMN) March 23, 2013

The accountable and responsible party here is the Scrum Master. Without an effective Scrum Master to guide the team you WILL fail. If you do not have an effective Scrum Master then you or they don’t fully understand the 42 Tasks for a Scrum Master’s Job .

According to the Scrum Guide the Development Team can ‘choose’ their Scrum Master to make sure that they get some one as effective as possible.

Yes, this also means that they can ‘un-choose’ their current one.

Step 2: Stop creating technical debt to prevent the insufficiency of scrum

You need to first stop creating technical debt. To do this you only need to focus on one thing; Working software at lease every 30 days. If you are not able to create working software every sprint then you need to stop and look at why that is.

Note I prefer ‘working software on every checkin’ and ‘continuous delivery’. That way I can ship working software at any time.

Now I am not talking about that flaccid rendition of working software that lead you to this place of horror and despair. But instead take ‘working software’ at face value and have it mean ‘everything that I have delivered works with no further work required’. Does that mean that it meets the customers expectations? No it does not; unless their only expectation is for what you show them to work with no errors and that if they say ‘ship-it’ you can deploy what you have. If you have to reply with… “Well, maybe next sprint as we still have some bugs.” then you have failed as a professional and as a team to deliver the minimum bar.

@mrhinsh The core is basically wrong. Now, nobody can fix that. No time for redesigns in a sprint
, José Manuel Nieto (@SuperJMN) March 23, 2013

But if we do get into that state then you are in the very same ‘brownfield’ situation as software that have been built over years with no unit tests. So if the primary goal now is working software that meets our customers expectations and we augment our Definition of Done to reflect that then we will be delivering less features of higher quality.

Figure: There is 1000% return of investment for every test written in TDD

While we are still paying back our excessive build up of technical debt, using those engineering practices that will prevent future build up, we will be delivering less value to the customer.

Conclusion

Remember that the software that you are building is an organisational asset and decisions to cut quality affect the value of that asset and thus must be reflected in your organisations financial statements .Cutting quality in your software without first gaining the approval to do so from your financial executives is unprofessional at best and fraud at worst and always incompetence.

Don’t be incompetent. Don’t commit fraud.

Be a professional…

The Sprint is a container for Planning and not necessarily for Delivery

Martin Hinshelwood — Tue, 29 Nov 2011 04:36:22 +0000

I have been told time and again in the office that Scrum is an inflexible platform for developing software as it is way too prescriptive. This is far from reality and represents an invalid interpretation in the rules of the game. This fault lies not with those that have been turned away from the light, but with the fanatics that have brandished the burning torch and pitchfork at your door chanting “that is not Scrum because…”.

Figure: Please ignore these guys

Many of us in the community have a vision of making Scrum more accessible to all and to that end, one of the goals of the entire Scrum community should be to help the misguided back to the light and re-educate the Scrum Coaches ( read Inquisitors here ) that have corrupted them.

Let me ask you a question;

If the Scrum Guide is the rules by which the game of Scrum is played, then where is it written that your delivery schedule must match up with your planning schedule?

It does say that you should be meeting your definition of done for each PBI and at least each Sprint. As your definition of done is the quality bar set by the Development Team and negotiated with the Product Owner, what is to stop you having the following DoD:

Acceptance Tests have been turned into Test Cases
Functional Tests have been turned into Test Cases
Code coverage percentage is the same or better than the last build
All Tests Cases pass
All Test Cases have been turned into Coded UI Tests
Deployed to QA and full automated test suit run
Deployed to Production

If you are deploying to production every Sprint and even for every PBI then you are one step away from doing it for every build, which is Continuous Deployment. Does Scrum say that you can’t do this? Hell no, it encourages it without mandating it. As long as you meet a simple measurable checklist , you can say that you are doing Scrum.

“Businesses rely on getting valuable new software into the hands of users as fast as possible, while making sure that they keep their production environments stable. Continuous Delivery is a revolutionary and scalable agile methodology that enables any team, including teams within enterprise IT organizations, to achieve rapid, reliable releases through better collaboration between developers, testers, DBAs and operations, and automation of the build, deploy, test and release process.”
-Jez Humble

Even if you are not practicing Continuous Delivery, I would encourage you to deploy more regularly than just once a Sprint. I am not saying that it is easy, because it is not.

You can’t do this with immature software either. I see customers fail time and again with institutional technical debt and software teams that are highly tuned to create it. In order to achieve Continuous Delivery your organisation must be committed to minimizing technical debt and to maximizing the value delivered to your business. Apart from technical debt there are a quandary of things that need to be in place in order to achieve Continuous Delivery. Think about the ability to have different versions of the same code running in production at the same time while maintaining the contracts and separation of concerns that go to make that possible.

There are only a few organisations that have mastered Continuous Delivery, but the benefit that they achieve in being able to get features into production almost as fast as the business can think of it.

But if you do want to get there, or at least take a journey down that road and see how far you want to go then there are things that must happen. There are waypoints along the road and provide a simple guide to your maturity in this area:

Automated Build
Build Verification Tests
Automated Acceptance Tests
Automated Functional Tests
Automated Unit Tests
Automated Deployment

Only once you have all of these thing should you then be thinking of what more do you need for your software in your environment to be able to successfully deploy your software to production and be happy that you have met the correct quality level to achieve this.

I never tell teams that you MUST do a thing but instead encourage them to do the right thing for their organisation in a journey to build better software.

Now, that is something that we can all aspire to.

Great Scrum Masters Need Technical, Business, and Organisational Mastery

Martin Hinshelwood — Mon, 24 Mar 2025 09:00:00 +0000

Scrum Masters don’t need to be subject-matter experts in the way traditional management once required. We’re no longer in an era where managers direct unskilled labour; modern teams are intelligent, capable, and cross-functional. The Scrum Master’s responsibility is not to do the work, but to enable others to do it better. They are leaders.

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.

The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery

Martin Hinshelwood — Mon, 22 Sep 2025 09:00:00 +0000

In many software organisations, estimation accuracy is mistaken for predictability and control. Leadership asks teams to compare original estimates to actuals in hopes of improving forecasts. But this creates a false sense of certainty , one that undermines trust, distorts priorities, and derails delivery.

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:

Instead of…	Try…
Estimate vs Actual	End-to-end lead time from commitment to usable customer delivery (Time to Market)
Story points completed	Customer satisfaction (Current Value)
On-time delivery rate	Quality Trends, or % of effort on new vs sustaining work (Ability to Innovate)
Headcount-based planning	Opportunity backlog delta (Unrealised Value)

⚠️ Warning

Time-based metrics must be contextualised. Without insight into value, complexity, and customer outcomes, they risk becoming another distorted proxy.

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

Why Handoffs Are Killing Your Agility

Martin Hinshelwood — Mon, 13 Jan 2025 00:00:00 +0000

Many organisations attempt to adopt Lean practices without fully understanding their implications in software development. This often leads to excessive handoffs, which fragment communication and reduce agility.

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.

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.
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.
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.
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:

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.
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.

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 .
Minimise Work in Progress (WIP) - Limit WIP to reduce context switching and improve focus. A lower WIP means fewer handoffs and faster delivery cycles.
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 .
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

Daniel Pink, Drive: The Surprising Truth About What Motivates Us
The 2020 Scrum Guide - Scrum.org
Martin Hinshelwood, You are doing it wrong if you are not using test first - NKD Agility
Martin Hinshelwood, If your backlog is not refined then you are doing it wrong - NKD Agility
The Agile Manifesto - AgileManifesto.org
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!

Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?

Martin Hinshelwood — Mon, 15 Sep 2025 09:00:00 +0000

Flow of value vs. flow of work: misnomer or useful shorthand?

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.

Hiring a Professional Scrum Master

Martin Hinshelwood — Mon, 15 Mar 2021 14:11:00 +0000

One of my customers is hiring for the Scrum Master Role and asked if I had a handy-dandy Scrum Master Job Spec that they could use. I did not, but there have been a few good ones floating around in the ether so I thought that pulling one together would be a good idea anyway. Here is my best effort to use the existing job postings, and combine them with the latest version of the Scrum Guide.

![](images/Wide-screen-scrum-master-1280x720-2-2.jpg) { .post-img }

[Professional Scrum](/tags/professional-scrum/) Master

Hiring a Professional Scrum Master

The Scrum Master is a challenging position to hire for and finding the right person is even more difficult. Ultimately the Scrum Master is accountable for the effectiveness of the Scrum Team. That means that they need to have some level of knowledge of both the relevant business domain to help the Product Owner, as well as enough technical knowledge to help the Scrum Team.

Are technical skills required to be a Scrum Master?

While there is no need for a Scrum Master to be technical, they do need to understand what effective looks like within the product and the technical domain within which you are creating the product. Ultimately it’s worth remembering that certification is not an indication of competence, but may be used as a simple bar to reduce the load on interviews and assert a minimum level of knowledge. At $200 for a PSM I assessment and $250 for the PSM II assessment, and with a reputation in the industry of not being totally easy, these are a no-brainer for any aspiring or experienced Scrum Master. At the time of writing there are more than 350k people with PSM I and 11k people with PSM II .

A Scrum Master Job Spec

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework. Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

Role Summary

This Scrum Master position is a leadership role that is accountable for the effectiveness of the Scrum Team by:

Leading, training, and coaching the organization in its Scrum adoption;
Helping establish empirical product planning for a complex environment;
Helping find techniques for effective Product Goal definition and Product Backlog management;
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;
Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand and enact an empirical approach for complex work;
Removing barriers between stakeholders and Scrum Teams.

Should work to build a trusting and safe environment where problems can be raised without fear of blame, retribution, or being judged, with an emphasis of healing and problem-solving.

Role Requirements

The successful candidate must have the following attributes:

First level Scrum Master certification (PSM I, CSM, RSM)
Excellent Leadership skills; with a proven track record of assessing the Scrum Maturity of the team and organization and coaching the team to higher levels of maturity, at a pace that is sustainable and comfortable for the team and organization
Personify Scrum and Agile; Providing all support to the team using a servant leadership style and leading by example.
Facilitation skills; Facilitating getting the work done without coercion, assigning, or dictating the work; Facilitating discussion, decision making, and conflict resolution
Excellent communication skills; Assisting with internal and external communication, improving transparency, and radiating information
Diverse knowledge of agile mindsets; an ability to guide and coach the Scrum Team in self-management to fill the intentional gaps of the Agile/Scrum frameworks.

In addition, the successful candidate will have some or all of the following attributes:

Second level Scrum Master certification (PSM II, CSP)
Experience playing the Scrum Master role for at least two years for a product development team that was diligently applying Scrum principles, practices, and theory.
Knowledge of other Agile approaches: XP, Kanban, Crystal, FDD, Less, Nexus, etc
[If Software Team] Knowledge and/or experience with widely successful Agile techniques: User Stories, ATDD, TDD, Continuous Integration, Continuous Testing, Pairing, Automated Testing, Agile Games
[Applicable knowledge of the Business used by the team] <– Add your Business Domain Here
[Applicable knowledge of the technologies used by the team] <– Add your Technical Domain Here

Role Sucess

If the Scrum Master is successful then the Scrum Team will have the following characteristics:

Reliable delivery of the quality valuable product.
Solid understanding of Scrum framework, theory, & values
Continuous improvement and learning
Happyness
Self-sustaining

I would love to get your feedback and discussion on this job specification so that we can make it better!

Sources:

Stop Writing Business Logic in Stored Procedures

Martin Hinshelwood — Mon, 23 Jun 2025 09:00:00 +0000

Over the years, I’ve encountered many companies that have maintained their business logic in stored procedures, but the practice of doing so has died out, for good reasons ill hilight below. However, many codebases have been around for 10+ years, and may still have large amounts of business logic in them.

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.

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.
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.
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!
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.
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.
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.
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.

Are technical skills required to be a Scrum Master?

Martin Hinshelwood — Sun, 01 Sep 2019 15:37:41 +0000

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.

In case you missed it, here is the recording of yesterday’s Ask a Professional Scrum Trainer webinar with Martin Hinshelwood! Watch here: http://ow.ly/ijiM50vwEkD

[Question] Are technical skills required to be a Scrum Master?

As per the Scrum Guide there is no requirement for a Scrum Master to have technical skills.

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

-The Scrum Master, Scrum Guide

When I discuss the Scrum Master in class and with customers I talk about them as being someone that can be a Teacher, Mentor, Coach, & Facilitator for your Scrum Team. So let’s ask a question: If you were the Scrum Master for a Scrum Team building some financial software for a bank, how would you expect to guide and mentor the Product Owner without some understanding of what their challenges are? Oh, you can coach them, one does not need expert knowledge of the problem to coach a subject. The Product Owner is the one that knows the answer, the Scrum Master just needs to facilitate their own discovery. That is only part of the Scrum Master role, I also need to teach & mentor the Product Owner to become better at realising value; for that, I need to have an understanding of the context within which they operate.

I think that while you can be a non-technical Scrum Master, you can be a better Scrum Master with more knowledge of the context for each of the roles; you need more than technical skills! In order to be an awesome Scrum Master you are going to need 3 main masteries that you can leverage to help each of the roles, as well as the wider organisation:

Technical Mastery – While I would not expect a Scrum Master to have to be able to do everything that the Engineering team members can, they need to understand what the mastery of that profession looks like as well as the context within which the engineering team are practising. For example, they should be able to tell if TDD is appropriate for this team, what does it look like, and if so, are they doing it well. There are a wide range of engineering practices that I would expect a Scrum Master to guide the team towards which include, but is not limited to: Pair programming, (A)TDD, Refactoring, UI testing, Functional testing, Continuous Integration (unit, deployment, build, integration, regression, … tests), Performance testing. How would they change their approach if the technical team was at Boeing, or if it was a call centre line-of-business app?
Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:
- Coaching the Development Team in self-organization and cross-functionality;
- Helping the Development Team to create high-value products;
- Removing impediments to the Development Team’s progress;
- Facilitating Scrum events as requested or needed; and,
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
-The Scrum Master, Scrum Guide Without technical mastery, I think it would be very difficult to help the development team build high-value products.
Business Mastery – The Scrum Team, and especially the Product Owner need to understand the business, and how they can optimise the product they are delivering to best support it. Does everyone understand the product qualities that are required within their context? Do you have Quality code base (clean, readable, naming conventions), Valuable functionality only, Architectural conventions respected, According to design/style guide, According to usability standards, Documented, Service levels guaranteed (uptime, performance, response time)? How would you help the Scrum Team get better at meeting the business goals without a keen understanding of what those are?
Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:
- Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
- Finding techniques for effective Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Understanding product planning in an empirical environment;
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
- Understanding and practicing agility; and,
- Facilitating Scrum events as requested or needed.
-The Scrum Master, Scrum Guide Without business mastery how could the Scrum Master ensure that the backlog maximizes value; without the context of the business how can they ensure that everyone understands the goals, scope, and domain?
Organisational Transformational Mastery – Have you ever tried to change an organization without really understanding the structure, people, and history that led to the current culture and organisation? This is why so many organisational transformations fail. If the Scrum Master really understands the organisation, the people, and the key players that need to come together to effect real change then they can make a difference. Without that knowledge, they have little hope of success.
Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:
- Leading and coaching the organization in its Scrum adoption;
- Planning Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact Scrum and empirical product development;
- Causing change that increases the productivity of the Scrum Team; and,
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
-The Scrum Master, Scrum Guide Without organisational transformational mastery, and the context of the organisation there is very little likelihood of real lasting change.

These masteries for me mean that a Scrum Master needs to be fully familiar with the Technical, Business, and Organisational context within which they are operating and how and when to encourage the Scrum Team to particular practices based on the Scrum Teams and the Organisational maturity.

Does it sound to you as if the Scrum Master can be awesome if they don’t have technical, business, and organisational change skills?

While there are no right answers there are some answers that are better than others. For your given situation select the most right answer and iteration to the best version of it.

You are doing Scrum but the Scrum Master tells the team what to do!

Martin Hinshelwood — Tue, 13 Sep 2011 20:40:07 +0000

If you are doing Scrum but the Scrum Master tells the team what to do then you may be missing the point.

Ultimately the Scrum Master should never tell the Development Team what to do and they should make sure that the Development Team has both the knowledge and the skills to work things out for themselves. This is critical to the teams ability to self organise going forward because we all learn by the mistakes we make.

A Scrum Master does NOT equal Project Manager. In Scrum, project management is the responsibility of the entire Scrum Team (Scrum Master, Product Owner and Development Team) and is distributed as such, with the Scrum Master keeping an eye on the mechanics of Scrum to make sure it is working. The top-down management model traditionally used for project execution is rejected in favour of self-organization and shared accountability. While this is alien to many organisations it has been proven time and time again to increase the accountability, efficiency and quality of the software delivered by the Scrum Team.

In Scrum the responsibilities between the Scrum Master and the Development Team are very explicit. The Scrum Master is there to serve the Development Team, not to manage them.

Scrum Master
- Scrum Mechanics
- Individual & Team Training
- etc.
Development Team
- Conflict Resolution
- Engineering Practices
- Grooming the Backlog (with Product Owner)
- etc.

All implementation, whither centred around working together, working to build software or working on the backlog, is the purview of the Development Team. This, however, does not mean that the Development Team are left to flounder. I mentioned that the Scrum Master is responsible for making sure that the Development Team has the Knowledge and Skills necessary to allow that Development Team to resolve things themselves.

In order to allow the Scrum Master to provide the knowledge necessary to resolve conflicts they could ask questions of the team to illicit knowledge and learning.

The term Socratic questioning is used to describe a kind of questioning in which an original question is responded to as though it were an answer. This in turn forces the first questioner to reformulate a new question in light of the progress of the discourse.
-Socratic method

Using this method a Scrum Master can “guide” a Development Team through the muddy waters of finding solutions to problems without enforcing their views or restricting the creativity of the Development Team.

Groups that defer to a person of higher status will miss many good ideas, and fail to tap and develop the talents of the entire group.
-Esther Derby: Why Group Dynamics and Interpersonal Skills Matter

In addition the Scrum Master should never provide the team with options, unless they are specifically asked by the team for their opinion or their assistance. This removes the responsibility of the Development Team to make decisions and may limit the options that the Development Team creates. If they are provided with options they are unlikely to try to formulate their own and if that option fails they can claim it is the responsibility of the person who provided that option and not of the Development Team.

You will have to have, learn, or improve requirements gathering and presentation techniques; quality techniques; refactoring; customer engagement; collaboration; teaming; conflict resolution techniques; and other practices, as well. But the Scrum framework will help you by providing continual feedback on your progress and success.
-Ken Schwaber: Scrum As A Framework

The Development Team must be empowered to come up with resolutions to the problems that they have without interference.

References

Engineering as a Leadership System: Moving Beyond Frameworks

Martin Hinshelwood — Wed, 19 Aug 2026 00:00:00 +0000

Most of the engineering leaders I work with have already done the work. Scrum is in place. Teams are cross functional and mostly stable. There is a platform team, a pipeline that builds and deploys, a dashboard with four metrics on it, and now an AI assistant on every desk. The practices are not missing. The people are not weak.

And yet delivery is still slower than anyone expects, less predictable than anyone will admit in a board meeting, and more expensive to change than it was three years ago.

That gap is what this is about. My argument is easy to state and uncomfortable to act on. The frameworks and practices your teams adopt cannot overcome the operating model your organisation runs them inside. Engineering is not a set of team practices. It is a leadership system.

Your operating model is a theory of the business

Every organisation runs on what Peter Drucker called a theory of the business: a set of assumptions about the environment, about who the customer is, about what that customer values, and about what the organisation has to be good at in order to win. Most of those assumptions were never written down, and almost none of them are revisited. They were correct once. That is usually why nobody questions them.

Two things make this worse than it sounds. First, a theory of the business does not become obsolete because it failed. It becomes obsolete because it worked, and success is what stops it being questioned. Second, and sharper: for many organisations the theory never matched the realities of their environment at all. But when every company in your competitive arc makes the same mistake, it is not noticeable. Nothing in the market punishes an error everyone shares. The mistake becomes institutional.

There is one exception worth naming. A personality, or a group, can through sheer force of will make an organisation override the implications of its theory of the business. But it is almost always departmentally local, and it rarely outlives the person. Heroics are not a structure, and this piece is about what persists.

An operating model is that theory made structural. It is the assumptions converted into governance, funding, measurement, decision rights, and accountability, so that they no longer have to be argued. They become the way things are done here.

Drucker’s requirement was never just that the theory exists. It was that the theory be tested constantly, because it is a hypothesis, not scripture. That dashed return arrow is the piece almost nobody builds, and it cannot build itself: a theory made structural has no sensor. Nothing inside the structure can detect that its founding assumptions have lapsed, because the structure exists precisely so those assumptions no longer get argued. Detection is a job, and in most organisations it is an unowned job.

This is why operating models are simultaneously so powerful and so hard to see. A framework is something you adopt, and you can point at it. A theory of the business is something you inherit, and it points at you. Scrum can be installed in a quarter. The assumption that work can be specified up front, approved centrally, and then executed to plan is installed in your budget cycle, your capitalisation rules, your job architecture, and your promotion criteria. One of those two things is going to win, and it is not the framework.

The distinction between a predictive operating model and an adaptive one is not a moral one, and it is not modern against traditional. Predictive structures work extremely well when their assumptions hold: stable demand, knowable work, long product lifecycles, advantage from efficiency and consistency. They fail when the environment changes faster than the planning cadence that governs it. Most organisations I see are not badly run. They are running a theory of the business that stopped matching their environment some years ago, and nobody was accountable for noticing. I have written about that distinction at length elsewhere.

The two theories are mutually exclusive. They make contradictory claims about the same environment, so at most one is true of yours. That does not make organisations pure: an adaptive theory of the business freely uses predictive practices wherever the work is knowable, in payroll, in regulated execution, in any known-good procedure. The practices serve; the theory governs. If you believe your organisation holds both theories, look at what your budget process does when the two collide. That is your theory.

When this is not your problem

I should say this plainly, because the argument reads as universal and it is not.

If your demand really is stable, your work really is knowable in advance, and your product lifecycle is measured in years, a predictive operating model is not your constraint. It is the correct design, and changing it would cost you the advantage you have.

If your teams genuinely cannot do the work, structure will not save you. Genuine means absent: nobody in the system has the skill yet, and the work would fail even with every gate removed. That is fixed by hiring, training, and time. But if skilled people keep leaving, or mastery never gets funded time, that is not a capability gap. That is the funding surface wearing a skills costume, and you are back in this article. My claim is narrower than it sounds. When the practices are present and the people are capable, the operating model is the explanation you have least examined, and it is the only one this piece gives you a way to test.

And if you can answer the five questions at the end of this piece with evidence rather than opinion, you are not the reader I wrote this for.

Where the theory is actually written down

If you want to find an organisation’s real theory of the business, do not read the strategy deck. Read five things instead. These are the surfaces where the theory stops being an idea and starts governing behaviour.

Governance: what requires permission

Governance answers one question: what may a person do without asking. Every approval gate is a recorded statement that the organisation does not trust the information held at the point of work, and would rather pay delay than accept variance. That is sometimes a sound trade. It is rarely a conscious one, because approval gates are added one incident at a time and removed almost never.

The cost is not the meeting. The cost is that a decision cannot be tested until it has been approved, and by then it has usually also been committed. The property being destroyed here is what I call decision testability: the ability to validate a decision against reality before the commitment becomes irreversible. Every gate lowers it.

Funding: what you buy, and for how long

Funding decides what an organisation is structurally able to change its mind about. Fund a project and you have bought a scope, a date, and a team that disbands at the end, which means learning that arrives late has nowhere to go and no one to carry it. Fund a product, or a long-lived team that owns an outcome, and you have bought a capability that can absorb what it learns.

There is a third rung. Fund an outcome, and the money is attached to the result rather than the plan, so learning redirects the work instead of being defended against. A project buys a plan. A product buys a capability. An outcome buys a direction. The chain should run downward from the vision: the vision defines the outcomes, outcomes drive the products, each product hosts a capability, and projects, if you use them at all, are batches of work inside a product, never the unit of funding.

Annual funding cycles in a market that moves monthly do not just slow the organisation down. They make it structurally rational for everyone in it to defend a plan they know is wrong, because the plan is the thing the money was attached to. The book calls this surface economic ownership.

Measurement: what you count

Measurement determines what leaders are able to see, and therefore what they are able to decide. When the measures are outputs, and the people being measured cannot change the system that produces those outputs, the measures stop describing reality and start describing what people need reported. Signal integrity, the degree to which the signals reaching leadership reflect operational reality, degrades quietly, and it degrades first in exactly the places where you most need the truth.

The diagnostic is not whether your metrics are good. It is what happens when a metric reveals a structural problem rather than an execution one. Organisations that change the metric have told you where their accountability actually sits.

Decision rights: who may decide without asking

Context does not survive travel. Every layer it crosses on the way to a decision maker strips detail and adds interpretation. When authority sits several layers above where the information is generated, the organisation has designed decision latency into itself, the time between recognising a need for change and having the authority to act, and the delay is not a behaviour anyone can be coached out of.

The compounding cost is not slowness. It is that by the time a decision reaches the person entitled to make it, the option to reverse it cheaply has usually already expired.

Accountability: who carries the consequence

The most common structural defect I find is accountability without authority. A team is held to an outcome it does not control the conditions for. Engineers are asked for quality by an organisation whose funding, deadlines, and measurement all penalise the behaviour that produces it. Nobody in that arrangement is behaving badly. They are behaving rationally, given the system they have been handed.

Where accountability and authority sit apart, no amount of intent closes the gap. It is a structural property, and it is fixed structurally or not at all.

Why frameworks, coaching, training and AI change so little

Once you see those five surfaces, the disappointing return on transformation investment stops being mysterious.

Frameworks, coaching, training, and tooling all operate inside the constraint. The operating model is not a layer above the work. It wraps it. They can make a team better at working within the system. They cannot change the system, because the levers that define it (budget, structure, policy, decision rights) are outside everything they touch. This is why improvement arrives, holds for a while, and then regresses. The operating model reasserts its constraints, and everyone concludes the framework did not work.

AI is the sharpest current example, and it is worth being precise about why. AI does not create a new operating-model requirement. It accelerates execution, and in doing so it removes the technical effort that used to disguise where the real constraint was. When writing the code was the slow part, governance delay and context decay were hidden inside the estimate. When writing the code is fast, they are all that is left. The queue does not disappear. It just becomes visible.

There is a second effect that is easier to miss. AI output arrives quickly and looks precise, which means an invalid assumption can survive longer under AI than it did under manual work, because nothing about the output signals that it was built on the wrong premise. Where context quality is poor, AI does not compensate. It multiplies. This is why I treat AI as a diagnostic rather than an intervention: it will tell you, faster and more expensively than anything else you could buy, exactly what your operating model was already doing.

The tell: stated intent against the operating model

Almost every organisation I work with has a stated intent that is genuinely held and an operating model that contradicts it. The contradiction is not hypocrisy. It is usually that the intent was updated and the structure was not.

The tells are consistent, and you can look for them this week:

You have asked for empowered teams, and every decision above a fixed value goes to a forum that meets fortnightly.
You have asked for faster feedback, and you fund in annual cycles against fixed scope.
You have asked for quality, and the only measure with consequences attached is date adherence.
You have asked people to surface problems early, and the last person who did is still explaining it.
You have asked for experiments, and there is no mechanism to stop one, so every experiment quietly becomes a commitment.

Where stated intent and structure conflict, structure wins, because structure is the thing with consequences attached. It wins without a meeting. People are reading the system, not the memo, and they are reading it correctly.

This is also why culture change programmes fail. Culture is the shadow the structure casts on the wall, cast by the structure, which was formed from the theory of the business. You cannot change a shadow. You can only move the thing that casts it. Culture is a read-out, not a lever: read it, because it is excellent diagnostics about your structure, and stop pulling on it.

Move, wait, learn, decay

The most useful diagnostic I know is not a maturity model. It is four questions about what your system does with work, and you can answer all four this week from things you already have.

Does work move? Take ten items you shipped last quarter. For each, write down the date work started and the date a customer could use it, then subtract the days anyone actually touched it. What is left is waiting. In the organisations I look at, the waiting is usually the larger number.

Does work wait? Walk your board and find everything that is done but not released, or decided but not authorised. Count them, and note what each one is waiting for. If most are waiting for a person rather than for work, you have found where authority sits relative to information.

Does your organisation learn? Look at the last five problems that reached your desk and ask what changed afterwards. A new rule, a new report, a new dashboard, or a new approval is a reaction. A removed approval, a moved decision, or a changed budget line is learning. Count the two. Most people are surprised by the ratio.

Does the system decay? Find one approval, one report, and one recurring meeting that exist because of an incident nobody in the room can now date. Then ask who is accountable for removing them. If the answer is nobody, this is not entropy and it is not the market. It is an unowned job.

Five questions worth answering honestly

If you take one thing into your next leadership meeting, take these. They are diagnostic, not rhetorical, and the answers are usually already known by someone who has not been asked.

The four questions above tell you what your system does with work. These five tell you where that behaviour is written, one per surface. The order matters: run the four yourself, this week, on the span you control. No permission needed. Take the five to your next leadership meeting once you have the numbers, and leave that meeting with one name and one date per question, or the meeting produced nothing.

Governance. What decisions currently require permission, and what evidence would tell us that permission is buying us more than the delay costs?
Funding. What are we funding that we would not start today, and what is our standing mechanism for stopping it? Drucker asked the first half of that question in 1954, and his version was not a question but a calendar entry. Most organisations still cannot answer the second half.
Measurement. When a measure last revealed a structural problem, did we change the structure or the measure?
Decision rights. Where is the largest gap between where information first appears and where the decision about it is made, and what is that gap costing us in reversibility?
Accountability. Who is currently accountable for an outcome whose determining conditions they do not control?

Not one of these questions is about your teams. That is the point.

This work does not finish

The uncomfortable part of treating engineering as a leadership system is that it removes the possibility of completion. There is no target state. Operating models degrade through accumulation and through decay, continuously, and the work of removing obsolete commitments, realigning decision rights, and refreshing the assumptions the model rests on is permanent executive work. It cannot be delegated to a transformation office, because the levers are not there.

What changes when leaders take this on is not that delivery becomes fast. It is that problems arrive while they are still cheap, decisions get tested before they become irreversible, and leadership attention stops being consumed by crisis response and retrospective justification. That capacity is the real return, and it is structural rather than heroic.

If your organisation has adopted the practices and is still disappointed by the results, the constraint is very unlikely to be your engineers. Start with the five surfaces. The theory of your business is written there, and so is the reason your work moves, waits, learns, or decays.

Engineering as a leadership system means two things, and I mean both. Engineering, the function, is a leadership system: its performance is produced by structures leaders own. And the leadership system is what needs engineering: your operating model is an engineered artefact, designed once, by someone, under assumptions that were true at the time. It deserves what any engineered system deserves. Instrumentation. Testing against reality. Maintenance. Refactoring when its assumptions expire.

The engineering problem in your organisation was never the code. It is the company. Go engineer it.

Everything above is diagnosis. It will let you recognise your own organisation and tell you where to look, but it deliberately stops short of two things. It does not give you the mechanism by which each of these structures produces its outcome, and it does not tell you what evidence would prove the argument wrong. Both matter, because a diagnosis you cannot falsify is only a strongly held opinion. That is the work the book does.

I wrote this alongside my session for The Future of Work in Scotland, on engineering as a leadership system and what lies past framework adoption. You can watch the session recording.

Read Engineering as a Leadership System on Leanpub , where the ebook comes with free updates for life and you set the price. Paperback and Kindle are on Amazon .

Big Scrum: All you need and not enough

Martin Hinshelwood — Wed, 01 Jul 2015 16:33:00 +0000

I was in Norway for NDC Oslo 2015 and I was there to talk about “Big Scrum: All you need and not enough” which is a kind of oxymoron as it really is enough, you just need to apply the values and principals at scale. I tried to cover what for me is a total 100% requirement for Scale.

[embed]https://vimeo.com/131642789[/embed]

In order to scale you first need Professional Team and not Amateur Teams. In the Scrum world that means that you need to embody the values and principals of agile, have awesome engineering practices, and know the mechanics . Its really not enough to simply pay lip service to your process. Dig in and really do it.

The second thing that I covered is why a cookie cutter process will not work. Your companies change is a unique fingerprint and the idea that you can buy and off-the-shelf process that will suit your culture and your journey is ludicrous.

To support scaling Scrum you need to have many Professional Scrum Teams working together, and for that we need a few extra communication lines that are not new, but that need enshrined in the model to make sure that it works. Check out the video below to get a walk-through of the new events and their significance and value.

At the end of the session I highlighted a small number of additional, but optional, practices that make scaling a lot easier. These practices only scratch the surface of what is presented in Scrum.org’s new Scaled Professional Scrum course, but they are representative of practices that we know, from experience, you need to build software big.

Big Scrum: All you need and not enough

The proliferation of scaling frameworks shows there are real challenges in scaling agility, and the solutions don’t seem to involve inventing yet more frameworks or formal processes. So then, why is it so hard to find success in agility at scale? Large scale agility can be found in exploiting Scrum’s simplicity while emerging and sustaining technical excellence. Something that sounds so easy shouldn’t be so hard, and for some it isn’t. This session highlights successes in growing large scale agility using Big Scrum while maintaining technical excellence to deliver value faster.

Delivery is the only Measure of Progress in Scrum

Martin Hinshelwood — Mon, 03 Feb 2025 09:00:00 +0000

As a social technology, Scrum has remained steadfast in its ethos for over 32 years, enabling teams to generate value through adaptive solutions to complex problems. Yet, a subtle distinction in its guidance often trips up practitioners - Scrum explicitly mandates a Done Increment but implicitly mandates Delivery. This distinction, though subtle, holds profound implications in a modern context where DevOps has reshaped the landscape of software delivery.

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:

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.
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.
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?
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.
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?”

Getting started with a Definition of Done (DoD)

Martin Hinshelwood — Mon, 14 Dec 2020 13:03:00 +0000

In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining what “Free from fault or defect” means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD).

Updated to reflect the 2020 Scrum Guide!

TL;DR;

Your Developers are ultimately responsible for creating done increments of working software. Done Increments. Done.

Developers needs to decide what Done means within the organisational context and the product domain. They need to sit down and create a list of things that must be true for every Increment of software that they deliver. Working Software is not specific to a PBI; it’s applied regardless of PBI to the entire delivery. Not just for each PBI.

“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. Instead, it returns to the Product Backlog for future consideration.”

-The 2020 Scrum Guide

If you can’t ship working software at least every 30 days then by its very definition, you are not yet doing Scrum. Since Professional Scrum Teams build software that works, stop, create a working increment of software that meets your definition of done (DoD), and then start Sprinting, and review what you mean by “working” continuously, and at least on a regular cadence.

What is a Definition of Done (DoD)

You need to start somewhere, and most often we don’t have a greenfield product. Either we are handed an existing product, or we are the team that built it and are switching to Scrum. Wherever your product originated, the code, and thus the product, will not currently be working software. How can it be when you don’t have a definition of what working means? So what do you do?

Before you cut a single line of code, you need to decide what done means for your product and your company. It will be defined very differently if you are building firmware for pacemakers or if you are creating an e-commerce portal. Here are some characteristics of a Definition of Done:

A short, measurable checklist - try and have things on your DoD that can be measured, that you can test the outcome, preferably in an automated fashion.
Mirrors shippable - While you might not have shipped your product, although we recommended it , you should have that choice. Your Product Owner should be able to say, at the Sprint Review : “That’s Awesome… lets ship it.”.
No further work - There should be no further work required from the Developers to ship your product to production. Any additional work means that you were not Done, and it takes away from the Product Owner capacity for the next iteration. Ideally, you have a fully automated process for delivering software, and never use staggered iterations for delivery .

Your short, measurable checklist that mirrors usable and results in no further work required to ship your product needs to be defined. I find the best way to do this is to get the Scrum Team (the Product Owner plus the Developers and any relevant Stakeholders ) into a facilitated DoD Workshop . Without a Defenition of Done we don’t understand what working software means, and without working software we cant have predictable delivery . Your Product Owner can’t reject a Backlog Item , only whether the Increment is working or not.

My first Definition of Done (DoD)

Your Definition of Done does not just magically appear, and your software does not magically comply. Making your Software comply with your definition of done is hard work, and while your definition of done should organically grow, you need to create the seed that you can build on.

I recommend that you run a workshop with the entire Scrum Team , and likely some other domain experts. If there are Stage Gates that your software has to pass after Developers are Done, then you need representatives from those Gates to participate in the workshop. Regardless of your product you likely need representatives with the following expertise; Code, Test, Security, UX, UI, Architecture, etc. You may have this expertise on your team, or you may need to bring in an expert from your organisation, or even external to your organisation.

Some examples of things to put on your definition of done:

Increment Passes SonarCube checks with no Critical errors - You will be increasing over time, so maybe you need to say “Code Passes SonarCube checks with no more than 50 Critical errors” then work on it over time.
Increment’s Code Coverage stays the same or gets higher - Looking at a specific measure, like 90%, of code coverage is a read hearing and tells you nothing of code quality. However, it might be advantageous to monitor and measure for adverse change in code coverage, and we always advocate for TDD practices .
Increment meets agreed engineering standards - You should decide rules for naming of methods, tests, variables and everything in-between. Start small and add over time. Link to your agreed standards on a Wiki and continuously improve and expand your rules. Automate if possible.
Acceptance Criteria for Increment pass - Making sure you at least meet the prescribed criteria is a laudable goal and automating them with ATDD practices is even better.
Acceptance Tests for Increment are Automated - Make sure that you automate all of your tests. If you think something will break, then you should have a test for it.
Security Checks Pass on Increment - Use an automated tool as part of your build and check for known security vulnerabilities. You will not find all of your security issues, but at least don’t do things we know to be reflective of poor Security.
Increment meets agreed UX standards - Again, have a Wiki page and make sure that you check it twice. If you are not using an automated DoD entry, then you need to agree as a Team that you have met the criteria.
Increment meets agreed Architectural Guidelines - Wiki’s are fantastic for this, but automate what you can.

Whatever Definition of Done you come up with it is unlikely that your entire Product currently meets the criteria. You are not yet doing Scrum. Before you start Sprinting, you need to focus on making sure that your current Increment meets your new Definition of Done. Focus on Quality, which is what the Developers are accountable for, and make sure that your Increment meets that new quality bar before you start. The next Increment can only reach the quality bar of all those that came before do, but you can and should add to that quality bar .

The Definition of Done is the commitment to quality for the Increment !

Create a usable increment that meets your definition of done and then start sprinting. Keeping your software in a working state will require a modern source control system that provides you with the facility to implement good DevOps practices.

Growing your Definition of Done (DoD)

It’s super important that quality is always increasing, and that means that you will need to at least reflect on your Definition of Done on a regular cadence. In Scrum, this cadence is defined by your Sprint length, and you have a Kaizen moment at the Sprint Retrospective. That does not mean that you don’t reflect on your DOD all the time, you do. You reflect continuously on whether your increment currently meets your DoD, and what you need to do to get it there. You should always be reflecting on whether your DoD fits your needs. If your Developers finds that something is missing from the DoD halfway through the Sprint, then they should go ahead and add it, making sure that they are not endangering the Sprint Goal.

You may discover that you have a performance problem with your product as David Corbin pointed out in my previous post. How do we make sure that we fix that issue? As I see it there are two pieces to this once you are in flight. You can Scrumble (stop Sprinting because of poor quality), and fix it, or you can integrate this new knowledge into your product cycle.

If it is a significant issue that results in you not having working software, then you need to stop and fix. In Scrum, this is called a Scrumble, as a reflection that the Developers stumbled because something is missing. You should stop adding new features and create a usable increment before you continue Sprinting and adding new features. Once you have repaired the issue, you can increase your Definition of Done to make sure that all future Increments meet the new requirements.

If it is less significant, you might want to keep working and add what you need to your Product Backlog. You can then deliver improvements over the next few Sprints that mitigate and then resolve the identified issue. Once you have resolved it, you can then pin the outcome by adding something to your DoD.

Always look for ways that you can increase your quality. What does your definition of done look like today?

Metrics that matter with evidence-based management

Martin Hinshelwood — Tue, 25 Feb 2014 13:29:14 +0000

I was recently asked to speak at ALM Days in Dusseldorf and more specifically to create a talk on Metrics and KPI’s for Quality. As I have been working a lot recently with evidence-based management. I am pretty sure that my session title translates as “Test management and reporting – KIP’s for better decisions” so I am going to concentrate on reporting and KPI’s as the session before mine is on Agile Testing.

slideshare Metrics that matter with evidence-based management @ ALM Days in Dusseldorf
slideshare The pursuit of Agility @ Agile into Finance in London

Figure: Testmanagement und Recording - KPIs für schnellere Entscheidungen

There are really two levels of metrics that I want to talk about, the first being at the team level and the second being the organisation level. If we are making decisions on the metrics that are being presented then we had better have the right metrics. I have recently been learning a lot about Evidence based Management and I think that it holds somewhat of the answer to which metrics we should be looking at and that we can consistently trend over time.

Evidence-based Management (EBM) comes out of Evidence Based Practices that have been used extensively in medical fields. Where we have life and death being the result of our decisions we want to make very sure that our metrics are being accurate. What I think that we forget is that while not strictly life threatening the executive leadership of an organisation is making critical decisions based on the information that they get from their subordinates. If these metrics are not the right ones or totally the wrong ones then you could find a company plunged into a critical state. So what is EBM all about?

In order to be using EBM we need to be:

Evaluate the current outcomes in the organisation
Carefully analyse the most likely contributors to these outcomes
Implement improvements in short cycles
Evaluate outcomes based on solid evidence.

If we were to apply these principals to organisations that deliver software what might these metrics look like?

Figure: Overview of Organisational Metrics

Out of these metrics there are really only three that I can hope to calculate at the team level and the rest are organisational or product based. The three for the team are Cycle Time, Innovation Rate and Defects which are all data points that I can get from Team Foundation Server. There is also a whole host of circumstantial evidence that we can get from TFS.

Data, Data, Everywhere

Circumstantial evidence is data that we use to support our analysis and with Team Foundation Server we get a plethora of options. We still need to make sure that we are not looking at the wrong metrics and at least TFS metrics are much more difficult to game as they come from an auditable system. However…

…always check the data with the source.

Figure: Data relationships in Visual Studio ALM

There tends to be so much data in TFS that it can be difficult to sort out the information that can be useful from a project managers wet dream of exceptionally bad metrics. I bet every developer has seen metric used for the wrong results. Have you ever been measured on the number of lines of code that you have written? Or a tester by the number of bugs found? The result is people gaming the system.

Figure: Reports in Visual Studio ALM

There is so much data available that it can be difficult to know where to start and indeed this is the reason that there are only a few reports out of the box with TFS. Not only can it be dangerous to provide to many reports that “generically” apply, you would invariable be wrong and have angry teams at your door with pitchforks and torches. And above all we need to avoid vanity metrics…

I worked at Meryl Lynch back in the day as a developer we had to provide some data in a spread sheet up the chain. It amazed me that my box, the Lead Developer for my Team, would massage the statistics a little to make them slightly more favourable. Turning the KPI’s from just a little to many red to a little more green and orange. Not only that but his boss would take those massaged figures, merge it with all his lead developers, and then proceed to massage them himself… Can you imagine the total fiction that the person at the top of the chain gets? And what decisions are they making based on that fiction?

Figure: Project Estimate Overview from the Project Overview Report

At one of my customers I was presented with the “Project Overview Report” that consisted of a ring bound book of data that was viewed all the way at the 3C’s level. The keystone report was the “Project Estimate Overview” report with which the lead BA and owner of the report was very proud. The report showed the original estimate versus the actual time taken to deliver a project. I looked at the report for all of 30 seconds before I turned to him and said:

“Two of these projects have original estimates that are within 20%, one is within 10% and the other two are exact or almost exact matches. I call bull shit.” -MrHinsh on being presented with the report above

The answer I got was interesting to say the least. He said:

“Well Martin, we were so far off with our estimates that we had to come up with a solution. We created a system that allowed the a project manager to submit a change to the original estimate. Its all recorded and above board.” -Customer

Wait what? Where in the graph above is that reflected… well of course it is not. The whole purpose is to legalize a fake report and cover their asses should someone challenge them on it, which no one did until an external consultant came along. I just hope that no one made any decisions at the executive level that resulted in the loss of jobs based on this fiction.

SO what data can we look at?

Figure: Stories Overview report

One of the key reports in TFS for quality indicators is the overview report. The overview report comes in different flavours depending on the process template that you choose. You get the Requirements Overview, Backlog Overview, and the Stories overview pictured above. Whatever the format you get to see the maturity of each of the pieces of work that your team currently has underway. You can see the number of Tests that are passing and failing as well as he outstanding bugs.

You should generally see more completeness at the top as these are displayed in backlog priority. I would also expect to see more passing tests the more ‘complete’ the feature. If you see something that is marked as very complete but has lots of outstanding bugs, few successful test results, or no test then you can be sure that the quality will not be high.

Figure: Build Quality Indicators

The automated build that you all obviously have on your software is another point of inspect and adaption for your code. You cant look at all of your codebase so trending some key build metrics will help us gain some general insight into the trends of your quality.

Active Bugs – This is the number of bugs that are active at the time of the build
Code Churn – The cumulative number of lines of code that have been touched between the last build and this one.
Code Coverage – The total percentage of your codebase that is covered by the tests that are executed as part of the build
Test Status – The number of unit tests and their status

When pulled together the representation of the Build Quality above shows that while code churn has been increasing the coverage has been dropping. While circumstantial, this would likely result in a reduction in quality and technical debt that will need to be paid back later. Indeed couple that with the reduction in bug count and increase in tests passing and you could construe that the wrong tests might also be being written. This signifies something to look into…

Figure: Build Success over Time

If however I have many build I may not want to monitor each one in that level of detail. I can use the Build Success Over Time reports to figure out which ones I might want to delve into. Having some form of KPI’s for my builds allows me to see at a glance something that I might want to investigate and you can see above that both the Code Coverage and the Main Nightly Build are having issues. However the Continuous Integration build was doing poorly and now now improving.

Figure: Martin’s Fitbit Status

It is important to be less concerned with individual values and instead be more focused on trends. You need to know when the team has fallen off the waggon.

Creating custom reports

Being able to create custom reports is a mixed blessing. It is incredibly powerful however you then have to create custom reports…

With TFS you get a complete Data Warehouse and Cube. The Data Warehouse is updated every 5 minutes and the cube once every few hours. This data has everything described above and more. It has data on Source Code, Work Item Tracking, Build, and Tests that is all related.

Figure: Report Builder & Excel

You can use Report Build to create reports in Reporting Services that you can render in the web and schedule. You can also just simply create reports in Excel and either run them locally or put them on Excel Services.

Figure: Stories Released vs Unreleased

I am no Excel reporting expert so I asked my colleague Steven Borg from Northwest Cadence for a few Excel TFS reports and he sent me this…

Figure: Test Case Automation

…And this…

Figure: Defect by Severity and Cumulative Defect Detection Trend

…mmmm data… and this one…

However we do need to remember one thing….

Figure: Team Metrics only

These may not be the metrics that you are looking for!

Beyond the team, metrics that really matter

If we look beyond the team we need metrics that scale a little better. The team metrics of code, code coverage, test coverage, and velocity are fine for a single team, however they do not work well for multiple teams.

What about that division you want to measure and create KPI’s for?

There are two things to note before we get started on which KIP’s I am going to propose that we look at…

First is some extensive Forrester analysis on metrics that saw that we often use the wrong metrics or focus on the wrong goal, also resulting in the wrong metrics. Effectively that metrics should match the goal and the goal, if we are going to be measuring an organisation, should be the delivery of value.

The second is that The Sandish Group while re-examining the 50k some projects that they have listed in their analysis data base found an inverse relationship between projects deemed a success under PMI, and value delivered. So your goal should be delivering value and you better not use PMI to measure success…

Figure: Organisational Metrics from Agility Index

There are few metrics that follow the evidence-based approaches described in “The Leaders Guide to Radical Management by Steven Denning” but one such emerging dataset is the Agility Index from Scrum.org. It looks at a number of areas shown above and concentrates on Value, Lead Time, and Quality.

Within each area we have a number of data points that we collect. Each one brings a specific balance to the equation of wither we are providing value and how quickly that value can be implemented. And very specifically, each one is a leading metric. They are metrics that are directly related to the outcome and can often precede any negative results that we are trying to avoided.

Figure: Direct Evidence is Consolidated into one indicator

The dataset that is the outcome of collecting the previous stats are then rolled up into a single indicator called the Agility Index. Scrum.org provides a tool for capturing the data and calculating the Agility Index in a consistent manor.

Figure: Relating outcome to value creation

There are really two types of evidence available to us:

Evidence, broadly construed, is anything presented in support of an assertion:

Strongest type of evidence is that which provides direct proof of the validity of the assertion.

Weakest type of evidence is that which is merely consistent with the assertion, but doesn’t rule out contradictory assertions, as in circumstantial evidence.

This is Evidence-based Management (EBM) and while new in the world of software delivery it has been round for quite a while in the medical world.

While we have the direct, strong, type of evidence from the left we still need to look at the softer evidence of the right. These are the more circumstantial pieces that may or may not provide us with an assertion of affect on the strong evidence.

If we look at the Skills, Knowledge, and understanding of the participants and the Practices, Tools, Architectures, and Standards that they have implemented to try and gain some insight into what might be limiting the direct evidence that we have on the value delivery. We can then take a look at things that we might change. Just as a doctor would gather some data before making a diagnosis.

So what sorts of things might we want to take a look at?

Figure: Practice domains of Agility Index

Out of these broad domains above Scrum.org have identified over 300 practices that have been ordered and provide an organisation with a deeper, if circumstantial, understanding of where they might want to spend some investment.

What would you want to do? Try something random or that is hot in the market? Or use Evidence-based Management to observe and analyse how work is done, asses the capabilities of the people doing the work and identify the most likely improvements to add value.

Figure: Trend analysis of evidence

If we go around that cycle of measure, diagnose, and then improve multiple times we can build up a picture of the trends within the organisation and a relationship between activates to improve and measureable results will emerge. This allows us to not only direct activity but to see the value derived for euros spent to implement improvements.

Have you ever been asked to justify continued spending on activities that are designed to improve your processes?

Figure: Patterns within practices

We should then be able to delve into each of the domains and identify which practice areas are improving and which are not to more explicitly diagnose additional improvements.

Figure: The Agility Index Calculator

The Agility Index calculator rolls all of the gathered evidence up and aggregates the values across all three dimensions into a single KPI to allow us to track trends and ROI.

Conclusion

This is a game changer for the software industry at large and create a credible set of metrics for the first time that can be used to guide process improvement initiatives regardless of the framework used to deliver that improvement. Agility Path, SAFe, or Kanban can be measured equally.

Do you want to use Evidence-based Management to improve your processes?

Building a release pipeline with Release Management with Visual Studio 2013

Martin Hinshelwood — Tue, 18 Feb 2014 16:30:59 +0000

With the release of Visual Studio 2013 we now have release management built right into the product that we can use to build a scalable release pipeline. It’s not perfect but it does hit the spot.

Unlike the other Application Lifecycle Management (ALM) tools on the market Visual Studio ALM actually lives up to the name. Most tools out there tend to concentrate on a single angle. Specialising in work item tracking, source control or build. Then there are tools like HP ALM or Rational that have many integrated tools within the Application Development Lifecycle Management (ADLM) world. They in effect concentrate on the development side of the process and don’t look at deployment or operations. This i think is a critical gap as we bring DevOps into the fold and integrate the developers and operational work to provide better products. Indeed many of the most successful products out there were developed by the same folk that support it. Why do they continue to be successful? When there is no one else to blame for the mess you end up just cleaning it up.

Figure: Introduction to Release Management in TFS 2013

Visual Studio ALM has implemented the next level of delivery by incorporating continuous release right into the product. Notice that I said “Continuous Release” and not simply “Continuous Deployment”. I was asked recently be a colleague if I had meant deployment, and if not, why release. Well, here was my answer:

Deployment is for those folks that can’t get it into Production. Releasing continuously with high quality is the real goal.

Today’s world of software delivery is very different from that of even a few years ago. Lean-agile thinkers have been pushing continuous quality, feedback and delivery for quite some time as the only way to really deliver acceptable quality. Now, with the modern application lifecycle even large enterprises are using cloud and delivering to mobile. We are all moving towards that ideal on continuous delivery and for many companies it is already a reality. Even if your organisation is not ready for continuous release you should be releasing continuously even if the only folks that use that environment are within your team.

Figure: Application lifecycle trends

In the past it has only been the smaller development shops that have been able to deliver continuously, however as larger organisations see those smaller organisations taking their business they also need to change, if only to keep up. This is what happened to the Visual Studio ALM team with the 2010 release, they were behind the curve and they had to aggressively innovate to get ahead of it. With a modern development platform there really is no excuse to not delivering continuously. If your organisation wants any sort of business agility then they will need to be looking at agility in their supporting departments as they can only move at the pace of their slowest part.

One of the most important supporting processes to both your development and operations teams when it comes to your software is something called a release pipeline. Even if you don’t know you have one, you do, you just may not have formalised it. A release pipeline is the process by which you get code from its text based from all the way through all of your environments to production. How long that takes can mean success or failure in the long run for your business. In a typical release pipeline we first compile our code and run unit tests before packaging it for deployment. This package would typically take the form of one or more binaries and this is what we are going to promote through our release pipeline.

Teams have tried for many years to work within a source code promotion model and it just does not scale to agility and indeed is one of the many any-patterns that can make agility harder than it should be. Why should test, QA or even operations need to wait for you to merge and retest your code before they get a copy? More to the point, why are you changing it after it has been tested? Did you run all of your tests again? Your full regression? Really?

Most teams, under pressure to deliver not only cherry-pick the changes that will be promoted between branch lines but almost always cherry-pick the tests that are run again. Your code coverage is only as good as the coverage attained since the last code change.

To combat these many issues you need a solid binary promotion model for your release pipeline.

Figure: Release Pipeline in Visual Studio ALM

Your release pipeline is usually made up of a number of instances of your application that you need to update between your build and your production systems. I have tended towards call these environments ‘Feedback’ rather than the traditional Dev, QA, and UAT as the old form pigeonholes them a little to specifically for what I want. All of these intermediary environments have one purpose and one purpose only, to provide the Development Team with feedback. Who the intended target is that you want to retrieve that feedback from is the only thing that really changes between instances.

In the Release Pipeline for Visual Studio 2013 graphic above I have depicted four environments, the first two of which are owned and managed traditionally by the development team. The one constant we have through the flow is the tooling for deployment. We are using Release Management for Visual Studio 2013 for all of our environments however we are using different tooling to gather data from these environments. Feedback comes in many forms and while feedback from people provides the most value we sometimes need feedback from systems as well.

Development Realm

When we are within the realm of the Development Teams I am looking for feedback that will help the development team understand defects and usability issues. The team needs to understand if they have met the business requirements . They need data that tells them things about their test coverage as well as which tests are most impacted by the changes that my team had delivered since the last change. I want to know how much and often the code is changing as rapidly changing areas of my code may be problem areas as well as identifying where I my need my team to spend time refactoring.

Here under the gaze of the Development Team we are mostly interested in functionality and quality:

Test Impact - Looking at how the changes that are being made to your system affect your tests is key to reducing the number of tests that you need to run and increasing your agility.
Unit Test Coverage - As a key quality indicator test coverage still needs to be taken with a pinch of salt. Look at test courage in conjunction with other metrics like code churn.
Code Churn - Code churn helps us understand how much or codebase is changing over time. Greater change is greater risk but again it is only an indicator.
Acceptance Coverage - Based on my acceptance criteria that I have pre-agreed with the business I need to know how good I am at meeting those criteria and when I am not how important it is to the product owner.

These are all things that we need to look at as our software travels down our release pipeline. We need to be seeing an increase in maturity as our software makes it further towards production. The more often your push an increment of your software through the pipeline the more data points that you get. The more data points you get the more accurate your measure.

While in the development realm we should be using Lab Management environments configured to execute our tests. The deployment capabilities of Lab Management were never that mature with the team that created it focusing more on vitalization than deployment. To relive this deficiency we can create dual environments so that we can execute test automation as part of our release pipeline with the new Release Management tools.

Operational Realm

As we get closer to production we start to need a different set of data we need operational data. This data is about what matters to those that are going to support your application even if it is the same folks as those that built it. Here we need to look at scalability and stability rather than meeting functional requirements. We need to monitor server performance, perhaps under load, and look at where there are gaps between support and action. All of this needs fed back to the Product Owner so that they can prioritise as needed to achieve the desired level of quality that meets the business needs.

In the world of Operations and DevOps we need information on performance and stability:

Performance Counters - Within your operating system there are a plethora of capture able metrics that allow you to identify where you might have problems. Getting access to this data in a way that you can slice it across multiple servers will allow you to scale quickly.
Load Test Results - to really get good metrics we need to be able to exercise our applications. While it is hard to scale UI testing it is easy to scale up the calls that are a result of that testing. You can create recordings from scratch or intercept examples using Fiddler and turn them into parameterised and scalable tests that you can use to exercise your application to the brink.
Incidents - how many incidents are required to be responded to by the team

Hopefully you are in the process of merging your operations and development teams but that does not mean that terms like operations and devops go away. It only means that they become more designations of types of work rather than of who will perform that work.

Conclusion

When you put these together, sometimes with a little overlap depending on how progressive your teams are, you get a release pipeline that is, and should be, a challenging gauntlet for your software. Software that makes it through the trial by fire should be stable, and scalable as well as functional.

In other words… Quality.

Quality enablement to achieve predictable delivery

Martin Hinshelwood — Wed, 24 Jul 2013 09:46:22 +0000

You need quality enablement to achieve predictable delivery for your organisation which takes effort to achieve.

I do a lot of ALM Assessments for companies and almost every customer that I speak to has unpredictable quality in the software delivery that they receive from their teams. This is not always the Development Teams fault and is often the result of an organisation that is finely tuned to minimise the ability to have a defined and predictable level of quality. In most cases this is due to a lack of a bar that quantifies the minimum things that need to be completed in order for and organisation to understand what i involved in each delivery.

If you have no bar for delivery and thus no idea what needs to be completed for each thing to be delivered then how can you expect to make accurate (or at least as good as we can get) prediction on when things are going to be delivered? You would effectively have no empirical evidence to rely on for predictability of delivery. In addition, the varied quality level results in more bugs in production, which then puts those individuals’ responsible for adding features under more pressure. If you put developers under pressure they will consistently and increasingly cut quality to meet the same deliverable.

Figure: The Iron Triangle

In addition many product backlogs lack acceptance criteria leaving the Development Team to guess at the basis by which the customer will accept that something is complete. Indeed because if this lack of acceptance criteria backlog items can often be deceptively large which puts the development team under greater pleasure for delivery and thus the cut quality.

Fix quality for improved predictability

The only way to successfully create predictable software delivery is to fix 3 of the 4 points of the Iron Triangle. In traditional software development quality is the hidden value and if you fix everything else it is Quality that suffers. Quality should be anchored with an explicit definition.

Definition of Done – Your DoD is the fixed measure or explicit definition of quality for your software development process. It is a short measurable checklist which mirrors shippable that can and is applied to every unit of work delivered. It can be hard to define but without it we don’t know how much work needs to be done in order to ship any backlog item. Apply it at least to the output of the iteration and ideally to every backlog item that you complete.
Acceptance Criteria – While the DoD is applied equally to every backlog item acceptance criteria only applies to an individual item. All conversations between the Development Team, Product Owner and the Business should be reflected in the acceptance criteria so that things that are discussed are mot missed. This also serves to understand scale and encourages breaking down backlog items into smaller units of work. Once you understand what needs to be done to complete an item, overly large items become transparently obvious.
Automated Builds – Having automated builds that can measure the quality of your software is paramount to minimising the amount of work that the team needs to do to verify the software and creating automated acceptance tests and unit tests increase the validity of those builds. Ideally you should have an automated test (UI or Unit) for every acceptance criteria that was added to the backlog item.
Automated Deployment – Having automated deployment will force the team to create working software and allow you to build and maintain something that will minimize the cost of delivery. If the Development Team knows that the business can choose to ship at any time they are then under pressure to maintain that ship-ability and thus quality.

Doing all of these things will serve to make quality the goal not the lack of it.

Conclusion

The way that we have traditionally measured our development teams have finely tuned them to fluctuate quality in order to meet aggressive delivery schedules. However this fluctuating quality only serves to reduce our ability to deliver and annoy our customers when they find the resulting bugs.

The goal is to increase quality not reduce it but first we need to be able to measure that quality and enforce it.

Storms of Neglect The Perils of Not Delivering Usable Products in Agile Iterations

Martin Hinshelwood — Thu, 27 Jul 2023 09:00:00 +0000

In light of the importance professional teams place on delivering usable, working products, I find myself compelled to address the woes that befall teams that need to adhere to this crucial tenet. We understand the need for working products; now, let us dissect the perils of straying from this righteous path.

TL;DR;

Neglecting to deliver a usable product at the end of each iteration breeds an ecosystem of compounding issues. From eroding trust to technical debt and from sluggish adaptability to misaligned expectations, the outcomes go from bad to worse. Inspection and adaption should be our guide, helping us navigate towards professionalism and quality.

What happens when we ignore usable working product?

Erosion of Trust with Stakeholders: Imagine walking into a store to purchase a laptop, only to be handed the bits and pieces with a pat on the back for your ‘future’ computer. The retailer can’t fathom why your faith dwindles. Similarly, with each iteration bereft of a usable product, the trust vested in you by stakeholders wears thin. Like sand slipping through fingers, trust is painfully hard to regain once lost.

Tsunami of Technical Debt: With each iteration that lacks a tangible product, you’re essentially signing IOUs against your future. This accrues as Technical Debt – a mammoth wave looming on the horizon. The resources required to address this increase exponentially as the interest piles on. Continuing down this road with abandon results in nothing but pain and suffering for everyone involved.

Sluggish Adaptability – The Quicksand: In the ever-changing landscape of customer needs, adaptability is key. Delivering usable increments is akin to the agile footing on uncertain terrain. When teams neglect this, it is like walking in quicksand – the more they struggle without clear direction, the deeper they sink. The lethargy in adaptation will drag them down as the world moves on; without them.

Misaligned Expectations – A Compass Gone Haywire: A usable product at the end of iterations acts as the compass, keeping stakeholders and the team aligned. Without this neither you nor your stakeholders have any transparency of what is going on and where we have arrived. The stakeholders expected one thing but got another, and the chasm between them widens with every iteration that the expectations are not validated. We often get so far apart that we can’t see how we bridge that gap!

Decreased Morale – The Fading Flame: Morale is the lifeblood of creativity and productivity. Delivering a working product is the kindling that keeps this fire alive in the team. Being able to see how the stakeholders use the product, are engaged by what we are creating, and care about the outcomes are the foundation of team morale. If we can’t see the stakeholders care about what we are creating, Im not sure why we would care…

Feedback Drought – direction-lessness: How do we know that we are heading in the right direction without feedback. When we encounter an obstacle and have to go around, how to we reorientate on the direction to go? Our usable working product is like our compass, allowing us to orienteer as effectively as we can towards our destination. Without it, you’re navigating blind, guessing the direction based on our assumptions.

Usable working product, every iteration, including the first, is the bedrock upon which we build the pillars of trust, alignment, adaptability, and quality. It is the very foundation of inspection and adaptation. Without it, we have no transparency, inspection, or adaptation!

Without it, we are not agile.

Stop normalizing unprofessional behaviour in the name of agility

Martin Hinshelwood — Mon, 19 Apr 2021 14:04:00 +0000

In Scrum Events across the world, I hear repeated the phrase “that’s how agile works” when describing behaviours that are both unprofessional and the very opposite of an agile mindset. These behaviours will inhibit agility and are a result of a lack of understanding of the underlying principles.

We need to stop normalising unprofessional behaviour and call it out whenever we hear it.

In order for agility to function, we need professionalism; a focus on doing things right so that we don’t end up with our beards caught in the mailbox (Norwegian saying). Agility requires more planning, more knowledge, more diligence, more discipline, and more competence… not less! It’s harder to use agile practices as we are expected to have a usable product at all times, well, at least every iteration of a few weeks. We are most definitely not agile if:

We don’t have a usable increment at the end of every iteration -
We constantly take on work that we don’t understand enough to have a reasonable degree of certainty that it will be completed within the timebox
Our team members don’t understand how their daily work contributes to the goals and vision of the product
We have a Tactical Goal that reflects a list of work to be completed
We assign work to individuals and hold them accountable as such
We create and organize ability-based groups within our team; programmers, testers, operations
You have a deployment process that is not within the control of the Scrum Team or is linear and bureaucratic.
You have a fixed set of requirements that cant be changed based on feedback

In the traditional world these behaviours were still present, however they were mitigated by time… lots and lots of time.

Think about the lead software engineer at Volkswagen that got a 3-year prison sentence for following orders and writing code that disabled the catalytic convertor when under emissions tests.

Think about the engineers at Boeing that dont yet know their fate over the 737 Max.

When you don’t know that these behaviours have a negative impact on our ability to deliver its ignorance, once you know and do it anyway, it’s incompetence. We have a moral and ethical responsibility to do the right thing, to protect our customer, our company, and ourselves.

Big Scrum: Are you doing mechanical Scrum

Martin Hinshelwood — Wed, 24 Jun 2015 13:43:00 +0000

Last month I created an article for NDC Magazine on Scaling Scrum. The guys at NDC must have liked it as they decided to put it on the cover. This article is a discussion and investigation into what it means to be a Professional Scrum Team, why we need it, and how we can scale it.

[Download NDC Magazine 2015.1 as a PDF ]

Excerpt from the article

Many organisations move towards Scrum and Agile for the allure of hyper-productivity. This is the promise that led them to Scrum in the first place and they are, more often than not, sorely disappointed when they don’t achieve it. The easiest way to make Scrum as ineffective as possible, is to pay lip service to it. Forgetting about the values, principles, and technical excellence that are the underpinning of its effectiveness.

It’s just fine to start with mechanical Scrum and work from there. Just don’t expect to get the effectiveness that you desire without the other two pillars. You need all three of the pillars to be able to ship twice the features in half the time.

The desire: Twice the features in half the time

No really! You can ship twice the features in half the time, but only with Professional Scrum. In Professional Scrum we not only follow the framework, but enact the values and principles. In Professional Scrum we strive for technical excellence and really focus on doing the right thing and minimising technical debt (yes, I know that unhedged fund is technically more accurate.)

Jeff Sutherland talks often of using Scrum to make money as a venture capitalist. His company buys struggling software companies and turning them around. Jeff does this by implementing Professional Scrum and turning that struggling software organisation into a highly tuned, effective team that turns ideas into customer value. He can then sell that company for many time that which he bought it for; professionals are worth far more than cowboys.

It beggars belief that so many organisations only practice flaccid Scrum and waste their investors’ money. That’s bad when it is private investment, but down right criminal in a public company. And let’s not get started with the public sector.

Is your organisation paying lip service to the values and principals? Does it feel more like ‘yeeha’, or a group of professionals?

Mechanical Scrum is only the start [read more… ]

The Scrum Master is accountable for Delivery

Martin Hinshelwood — Thu, 30 Jan 2025 00:00:00 +0000

Ultimately, the Scrum Master is accountable for the Scrum Team’s success. This includes product delivery, product success, Sprint outcomes, the team’s ability, and ensuring the team has the resources, skills, and ethos needed to succeed. While the entire Scrum Team shares accountability for delivery, the Scrum Master’s role is to create the conditions for effective delivery and continuous improvement. Delivery is the minimum bar for effectiveness, without it, the team cannot measure or realise value. Without delivery, there is no increment, no feedback, and no way to empirically assess value. A Scrum Team that delivers without value is ineffective but still functional. A Scrum Team that fails to deliver anything cannot be considered effective under any measure.

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:

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.
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.
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.
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.
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!

If your backlog is not refined then you are doing it wrong

Martin Hinshelwood — Thu, 17 Dec 2020 09:00:00 +0000

Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly. However, if you get to the Sprint Planning event and your backlog is not ready, then you are doing it wrong. If what you build is not of good quality then you should read about Defenition of Done.

Updated to reflect the 2020 Scrum Guide!

TL;DR

If you get to the Sprint Planning event and your Product Backlog Items for the next Sprint are not already of a size that can fit into the Sprint and fully understood by the Developers, then you are doing it wrong. You are heading for the rocks from the start, and you have no map of the shallows to prevent it.

Although the Scrum Guide does not define Refinement as an event, you should be doing it. You can come up with your Refinement event(s), or refine ad-hoc. Whatever you chose there is a simple measure of success. If your Developers looks at something within the next 2 Sprints on the backlog and they don’t understand it, then you have work to do.

If you find that you can’t quite get things to fit and have to stagger iterations, or you are just not able to deliver at all, then a lack of refinement is usually at fault.

What does ready mean for a Product Backlog?

If the Developers does not understand the things that they are being asked to do how could they possibly agree that the items can fit in a Sprint? You will often find teams that don’t do refinement confused as to why they can’t get everything done in a Sprint. While we accept that in an empirical process like Scrum that we, know less upfront than we discover as we go, merely taking a guess and hoping for the best is decidedly unprofessional.

“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.”
-ScrumGuides.org

While we don’t need a definition of ready, we do need a working agreement between the Product Owner and the Developers. In Scrum, the Developers are the ones selecting work for the Sprint, and they are the only ones that can decide what they can do. Developers should be empowered to refuse to take items from the backlog that either they do not understand, or are too big to be completed in a single sprint. In general, I would expect that a team take many items into their Sprint, so they need to be sized appropriately.

Ready Backlog just means that the Developers can select it with confidence.

How do you refine your backlog?

Refinement is not an explicit event in the Scrum Guide because it is something that can be different depending on the Product, Domain, or Technology. If you were to ask how much refinement you should do then the answer is “as much as you need and no more”. Too much refinement is waste, as it too little.

“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.”

-The 2020 Scrum Guide

The amount of time that Developers spend on refinement is based on the need. However, this need for refinement will vary over the life of the product and you should be spending as much time as your need while maximizing focus on the realisation of value. I have found that many teams that were not doing refinement in the past may need considerably more time to get their backlog into some semblance of order. Once it is in order, you are generally only maintaining a rolling Sprint projection, based on your effective planning horizon, of what you might achieve.

I usually run at least the first refinement as a guided workshop. By running one before a Sprint Planning most teams will see the value of it by the end of the next Sprint. For the workshop, I get the Scrum Team (Product Owner, Developers, & Scrum Master) into a room with any necessary subject matter experts and we merely open the existing backlog and review it. Start at the top and ask the Product Owner if this is the next most important thing? If not, find something that is. Then have the Product Owner read and explain it, then discuss and add details.

Any time the Product Owner deviates from the text that is in the Backlog Item, or adds more information, stop and have someone add that info to the Backlog Item. Ask the Developers to estimate the item, “Does this look like it can fit with many other friends into a single Sprint?”. If the answer is no, then you get to work breaking it down, reordering in the Product Backlog, and start refining again. You continue this process until the Developers agrees that there is enough backlog refined for the next 2 Sprints.

This enables your Product Owner to be able to plan future releases and your Developers to create an implementation plan for the current one.

During the Sprint Planning event, your Developers should be able to quickly select many Product Backlog Items that go towards the chosen Sprint Goal and agree that they fit. If you can do this, and most of the time you get most (not all) of the Items delivered, then you are probably doing enough refinement. If you can’t, then you need to focus a little more on Refinement and making your Product Backlog ready.

If at your Sprint Review the Product Owner is always wanting to reject that Backlog Items are complete then there is unlikely to be enough refinement for the Development Team to understand what they are expected to do.

Kalabule or a Professional at Agile in Africa

Martin Hinshelwood — Thu, 27 Oct 2016 18:01:00 +0000

I have been honoured by being asked to speak at Agile in Africa today on the topic of Kalabule or a Professional at Agile in Africa . I was a little disappointed when Nana asked me, as I had already booked a customer on those dates in Houston, Texas. Nana asked if I could do remote, so I could attend anyway :). This is my second presentation at Agile In Africa, and it sounds like this years event is just as awesome as the last.

Download the Presentation: Kalabule or Professional @ Agile In Africa

I have been covering the topic of Professionalism in software ever since I started doing the Scrum thing and finding that most companies, big and small, really have no idea what Scrum is beyond doing “Stand Ups” and “Demos”… neither of which are really part of Scrum…

Most teams working on software are kalabule (cowboys) who use excuses of poor management to try to seek forgiveness for their terrible software. Software that more often than not does not do what the customer asked for, was not delivered when they needed it, and cost far more than what they were expecting. That, my friends, is the experience of working with kalabule and con men…not professionals. The customers of these teams need to demand professionalism from the teams and vendors with the result being working software delivered on a regular cadence that meets their needs.

There is no excuse any more for kalabule. None…

Its was the last session in the day so I was expecting only a few people, but it looks like there was some turnout. Nana introduced the audience and I had Bankers, Farmers, and Software folks in the room. A good mix of Customers and Providers is always good when your message affects them both.

I talked a lot about why we are kalabule in the software industry and that neither mechanical Scrum, nor mere Engineering Practices alone can prevent the fear, disrespect, hidden rocks, and overall lack of commitment in the software industry. We also need some guiding values that we can use to make sure that we always do the right thing.

Courage
Focus
Commitment
Respect
Openness

If these values are not something that you want, not just building software, but simply interacting with others on a daily bases, then you have no business interacting with them.

As an industry we need to step up and refuse to be kalabule (cowboys) and instead strive to be Professionals and embody the Values that we want to be known for. Its time to clean the unprofessional muck from our industry and reinvent ourselves…

Constructing a framework for the TFS Automation Platform

Martin Hinshelwood — Sun, 12 Jun 2011 04:44:02 +0000

As Lead developer for the TFS Iteration Automation my goal this weekend is to provide a framework for the developers to give both architectural and development guidance for the tools and methods we are going to be using to construct the Platform.

I have been working on a framework that will allow the developers to get started building for the TFS Automation Platform and specifically to meet the goals for Release 1. I should note that I am not writing any code at this time I am putting together the jigsaw and selecting some technologies.

I have gone with two solutions. One to constrain all of the platform bits and another for the Automation that we will be building. The main reason for this is to dogfood the developer experience as we really want folks to start building Automations in the wild. If it is hard in any way then they will not.

This method also allows us to both version and release the Automations separately from the platform and reduces our dependency on code changes in the core. The idea is that, just as everyone else will be doing, we build the Automations against the latest “released” bits. In our case, that will mean the latest “alfa” at the start, but needs must.

TfsAutomationPlatform

While I intend to keep the Automation Platform as simple as possible, that does not mean that it actually is simple. There are really three parts to the Platform that need to be installed separately, but Mike’s help we should be able to have a unified installer.

Figure: The Platform needs to be very structured

If you are eagle eyed you will see that we are going to be using WIX, Silverlight and the new Architectural tooling in Visual Studio 2010 Ultimate.

Store

The Store is like a big database of assets. In this case the assets are the Plugins that are available for TFS Administrators to install on their servers. This will be written in Silverlight 5 and can be hosted in IIS or Azure. Hopefully we will be providing a hosted version on Azure, but those with extreme security concerns may install it locally in IIS.

Figure: A simple model

Hopefully as we move forward with new versions we can implement more to provide a culture and ecosystem around the store, but our initial goal is to deliver something that works. Lets worry about gold plating later.

Admin

This handles all of the grunt work of downloading, installing, Deploying, retracting and configuring plugins. Must be installed on the Application Tier.

Figure: Very Similar to the Store for now

The Admin section handles all of the magic of configuring and auctioning all of the Plugins.

Client

A hook to provide deep Visual Studio integration. Is optional, but lets you quickly link thorough to the Admin application. Will also provide dynamic Check-In Policies in the future. I am not really thinking a lot around this as it will probably not make R1.

TfsAutomationPlugins

As we will be building a number of OOB (Out Of the Box) Automations it makes sense for us to build them as part of a single solution. This is just for ease of development and if we do have a separation of teams then we may end up with separate solutions. But for now it is easier with just one. We will however need to be careful not to reference between them as one could be deployed without the other.

Figure: Where do the files go?

I will be looking more at the Plugins layout later, and how you can start building Plugins now. I will be upgrading my TFS Event Handler project code to this platform soon.

I am trying very hard to make it easy to develop for this platform. I don’t think it will be something that anyone can do as there will be a learning curve for what goes where, and especially how you can debug against TFS in process.

Now that everything is checked in, I will be encouraging my team mates to explore the solution.

Figure: Lots of lovely places to put code

Let me know what improvements you can observe as noting is perfect, especially not if it was done by me.

Guidance - Branching for each Sprint

Martin Hinshelwood — Thu, 08 Apr 2010 16:34:03 +0000

There are a lot of developers using version control these days, but a feature of version control called branching is very poorly understood and remains unused by most developers in favour of Labels. Most developers think that branching is hard and complicated. Its not!

What is hard and complicated is a bad branching strategy. Just like a bad software architecture a bad branch architecture, or one that is not adhered to can prove fatal to a project. We I was at Aggreko we had a fairly successful Feature branching strategy (although the developers hated it) that meant that we could have multiple feature teams working at the same time without impacting each other. Now, this had to be carefully orchestrated as it was a Business Intelligence team and many of the BI artefacts do not lend themselves to merging.

Today at SSW I am working on a Scrum team delivering a product that will be used by many hundreds of developers. SSW SQL Deploy takes much of the pain out of upgrading production databases when you are not using the Database projects in Visual Studio.

With Scrum each Scrum Team works for a fixed period of time on a single sprint. You can have one or more Scrum Teams involved in delivering a product, but all the work must be merged and tested, ready to be shown to the Product Owner at the the Sprint Review meeting at the end of the current Sprint.

So, what does this mean for a branching strategy?

We have been using a “Main” (sometimes called “Trunk”) line and doing a branch for each sprint. It’s like Feature Branching, but with only ONE feature in operation at any one time, so no conflicts

Figure: DEV folder containing the Development branches.

I know that some folks advocate applying a Label at the start of each Sprint and then rolling back if you need to, but I have always preferred the security of a branch.

Like:

being able to create a release from Main that has Sprint3 code even while Sprint4 is being worked on.
being sure I can always create a stable build on request.
Being able to guarantee a version (labels are not auditable)
Be able to abandon the sprint without having to delete the code (rare I know, but would be a mess if it happened)
Being able to see the flow of change sets through to a safe release
It helps you find invalid dependencies when merging to Main as there may be some file that is in everyone’s Sprint branch, but never got checked in. (We had this at the merge of Sprint2)
If you are always operating in this way as a standard it makes it easier to then add more scrum teams in the future. Muscle memory of this way of working.

Don’t Like:

Additional DB space for the branches
Baseless merging between sprint branches when changes are directly ported
Note: I do not think we will ever attempt this!
Maybe a bit tougher to see the history between sprint branches since the changes go up through Main and down to another sprint branch
Note: What you would have to do is see which Sprint the changes were made in and then check the history he same file in that Sprint. A little bit of added complexity that you would have to do anyway with multiple teams.
Over time, you can end up with a lot of old unused sprint branches. Perhaps destroy with /keephistory can help in this case.
Note: We ALWAYS delete the Sprint branch after it has been merged into Main. That is the theory anyway, and as you can see from the images Sprint2 has already been deleted.

Why take the chance of having a problem rolling back or wanting to keep some of the code, when you can just abandon a branch and start a new one?

It just seems easier and less painful to use a branch to me! What do you think?

Technorati Tags: Scrum SSW TFS 2008 TFS 2010 ALM Branching Version Control