The Process That Punishes the Behaviour You’re Building
Or: Why Your Engineers Stopped Taking Initiative — and Scrum Helped
Ownership Series, Part 2 of 4
It was 11:20 on a Thursday morning, and the sprint review had been going for six minutes before the energy in the room shifted. Not dramatically — just the subtle recalibration that happens when everyone simultaneously realises where a conversation is heading. Namfon had pulled two days out of the sprint to fix a performance issue that had been silently degrading the page they’d spent the last three sprints building — interaction times creeping up, the kind of thing users feel before they can name it, the kind of thing that makes a Product Owner’s carefully planned feature land softer than it should have. She hadn’t asked. She’d seen it, understood it, and fixed it. The work was good. The fix was right. The page hadn’t dragged since.
The sprint, however, was two points short of its commitment. And the Jira burndown on the big monitor on the wall made sure everyone in the room knew it.
In the last post, we looked at the problem: engineers who default to waiting, who ticket small fixable problems instead of fixing them, who treat ownership like a school assignment rather than something they’ve genuinely claimed. We traced the instinct back to where it comes from — twelve-plus years of education that rewards execution within defined parameters and never once asks you to define the parameters yourself.
This post is about something harder to fix. Because the waiting instinct, at least, is just conditioning. You can interrupt conditioning with enough repetition and enough visible demonstration of the alternative.
What you can’t interrupt as easily is a process that’s actively working against you.
The Scrum Trap
Here’s the structural irony at the centre of most engineering organisations: the behaviour that defines Station 3 ownership — stopping to fix something important that nobody asked you to fix — is precisely the behaviour that most Scrum implementations are designed to punish.
Not intentionally. Not maliciously. But effectively.
Sprint completion rate is a standard health metric in virtually every Scrum team I’ve encountered. When an engineer decides mid-sprint to address unplanned work, the committed scope doesn’t get delivered. The burndown chart goes red. In many teams, the whole team is accountable for the miss — velocity drops, and someone in a management review asks why the team keeps not hitting its commitments. The message lands on everyone, not just the person who acted. One engineer does something. The whole platoon does push-ups.
As W. Edwards Deming observed: “A bad system will beat a good person every time.”
Deming was talking about manufacturing — the assembly line worker blamed for defects that the production system itself was generating. But the mechanism is identical here. You can hire engineers with excellent instincts for ownership, put them in an environment where exercising those instincts makes their team miss its sprint, and watch those instincts get quietly trained out of them inside six months. It’s not a character failure. It’s a rational adaptation to the incentive structure they’re operating in.
Namfon did the right thing. The system told her she didn’t.
What the Manifesto Actually Says
Here’s the part that should make every certified Scrum Master slightly uncomfortable.
The Agile Manifesto — the document that Scrum claims as its foundational text — contains twelve principles, not four values. And principle number nine reads: “Continuous attention to technical excellence and good design enhances agility.”
Not “when the backlog allows for it.” Not “subject to Product Owner prioritisation.” Continuous attention.
The manifesto’s authors understood that agility and technical health aren’t in tension — they’re the same thing. A team that stops to fix something important isn’t deviating from the spirit of Agile. They’re living it. The sprint commitment model, applied rigidly, has managed to produce the opposite of what the document intended: a process where the most agile response to a discovered problem — fixing it immediately, before it gets worse — is classified as a sprint failure.
We took a manifesto that explicitly values responding to change over following a plan, and built an industry around following the plan.
The Velocity Illusion
The deeper problem with sprint completion metrics is what they measure and what they don’t.
Velocity measures output. It counts points delivered, features shipped, tasks completed. It has nothing to say about the quality of what was delivered, the health of the system it was delivered into, or the compounding cost of the things that were deferred to keep the number looking good.
A team that ships every sprint on schedule while ignoring a quietly growing reliability problem has excellent velocity and deteriorating capacity. Those two facts don’t appear on the same dashboard. By the time the capacity deterioration becomes visible — slower delivery, more bugs, longer debugging sessions, engineers spending half their time working around problems rather than solving them — the connection to the sprint metrics that enabled it has become almost impossible to make.
John Wooden, who won ten NCAA basketball championships at UCLA, used to tell his players: “Never mistake activity for achievement.” He wasn’t talking about sprint planning, but he might as well have been. A team that’s busy isn’t necessarily a team that’s improving. And a team that occasionally pauses to fix something important is doing more for its long-term velocity than any number of fully-committed sprints.
The teams that understand this shift their definition of a successful sprint away from scope delivered and toward outcomes achieved. Did the system get more reliable? Did the deployment get faster? Did the thing we were worried about last quarter get less worrying? Those questions have answers too — they just require different metrics, and a willingness to accept that some of the most valuable work a sprint can contain is work that wasn’t on the board when it started.
The Product Alignment Problem
Even if you fix the process — build in the slack, shift the metrics, create explicit permission for mid-sprint course correction — there’s a second structural trap waiting.
The misaligned product person.
An engineer starts taking initiative. They fix things without being asked. They stop a sprint to address something they own. Their engineering manager is giving them positive signals — “good call, that needed doing.” Then a PM pushes back. “Why wasn’t this in the sprint plan?” “We agreed on scope.” “I need to be able to predict what this team delivers.”
The engineer is now caught between two authority figures sending directly contradictory signals about what good looks like. No single person is the villain. The engineering manager is correctly rewarding ownership. Product is correctly managing predictability. The engineer — who was just making the leap from Station 2 to Station 3 — quietly concludes that initiative is conditionally safe at best, and goes back to waiting.
This failure mode is more common than the manager who actively punishes initiative, because it doesn’t feel like punishment from either side. It feels like a process disagreement. But to the engineer watching it play out, the signal is identical: acting without clearance has a cost.
The fix requires a conversation that happens before an engineer gets caught in the crossfire. Engineering and product need to be aligned on a few non-negotiable principles: sub-day fixes are never sprint failures, they’re engineering hygiene; an engineer stopping to fix something they own is categorically different from scope creep; and the goal of sprint planning is outcomes, not exhaustive pre-commitment of every available hour. Without that alignment, you’re asking engineers to take initiative inside a system that will occasionally, unpredictably, penalise them for it. That’s not ownership culture. That’s a minefield.
The Flex You Need to Build
None of this means abandoning sprint planning or throwing predictability out the window. It means building enough flex into the process to absorb initiative without classifying it as failure.
In practice, this looks like a few specific decisions:
Explicit capacity slack. Some teams reserve a percentage of sprint capacity — call it ten or fifteen percent — that’s understood to be available for unplanned good work. Not technical debt in the abstract, not “innovation time” that mysteriously vanishes when commitments get tight, but a deliberate buffer that signals: we expect to find things worth fixing, and we’ve made room for that.
A team norm about quality stops. The explicit, stated understanding that stopping to fix something important is never a sprint failure — it’s a data point. The debrief question isn’t “why didn’t you finish the committed scope?” It’s “what did we find, and was fixing it the right call?” Usually the answer is yes. Occasionally it’s a useful conversation about prioritisation. Either way, nobody gets push-ups.
Outcome metrics alongside output metrics. Deployment frequency. Lead time for changes. The number of times the team had to work around a known problem this sprint rather than through it. These sit alongside velocity on the dashboard rather than replacing it — and they make visible the things that velocity alone is hiding.
The goal is a process that can absorb a Namfon moment — an engineer who sees something important and fixes it before asking — without the burndown chart becoming an accusation.
What’s Actually in the Way
So if you’re an engineering leader reading this and recognising your own team in the waiting pattern from the last post, the honest question isn’t “how do I change my engineers?” It’s “what is the process telling them?”
Because your engineers are not ignoring their instincts. They’re following them. They’ve learned, through observation, that the environment rewards completion of assigned work and occasionally penalises deviation from it. They’ve watched what happens when someone acts without clearing it first. They’ve felt the implicit weight of a sprint that went red because someone did the right thing at the wrong time.
The instinct to wait isn’t irrational. In most Scrum environments, it’s the correct adaptation.
That’s the trap. And it’s one that no amount of “we want engineers who take ownership” messaging will fix, because the message and the system are saying different things — and the system always wins.
In the next post, we get to the fix. There’s a specific story about a CEO in a room full of people watching him respond to three consecutive quarters of failure, and it’s the clearest illustration I’ve found of how culture actually changes — not through what leaders say when things go well, but through what they do when everyone’s watching and things have gone badly.
The fix, it turns out, isn’t a process change. It’s four words.