DEV Community: Daniel Holt

The Agile Lie

Daniel Holt — Tue, 07 Jul 2026 14:27:26 +0000

Most large organizations did not adopt Agile. They adopted the appearance of Agile.

There is a difference, and it matters enormously — because the engineers sitting in your standups, writing user stories, and estimating in story points can feel it. They feel it every single day. And it is a significant part of why they stop caring.

Here is what actually happened at most large companies that went through an “Agile transformation.”

Leadership decided the organization needed to move faster. Competitors were ahead. Something had to change. The answer, almost universally, was Agile. A consulting firm was brought in. There was a presentation. There was enthusiasm about “ways of working.”

Then came the pilot.

The pilot team was set up carefully — cross-functional, empowered, given an actual problem to solve rather than a list of requirements handed down from a business analyst. They had access to the people they needed. Obstacles were removed in real time.

Of course it worked.

A self-contained team with every skill it needs, empowered to solve a real problem, with obstacles actively removed — that team is going to deliver. That is not a controversial statement. That is just what happens when you create the conditions for good work.

The problem came next. When the pilot succeeded, leadership decided to scale it. But what they chose to scale was not the conditions that made the pilot work.

It was the rituals.

The two-week sprints. The story points. The standups. The retrospectives. Every team in the organization was going to do Scrum — including the teams for whom Scrum made no sense whatsoever.

I watched this happen firsthand at a national bank. The mainframe engineering teams — disciplined, careful teams doing procedural work with quarterly release cycles and months-long testing processes — were told they were going to run two-week sprints.

At the end of each sprint, they were expected to demonstrate “working software” and deliver “value.” But the software was not going to reach production for another two and a half months, minimum. The feedback loop that makes Agile meaningful — build something, ship it, watch it perform, learn, adjust — simply did not exist for these teams.

So what did they do? They did what rational people do when forced to perform in a system that doesn’t fit their reality: they performed. They learned to write stories that demonstrated “value” on paper. They crafted “As a user, I want...” statements for backend infrastructure work that no user would ever directly touch. They held ceremonies that felt meaningless because they were meaningless in that context.

Meanwhile, I was on a team building APIs for the bank’s credit card partners. Two-week sprints made sense for us. We could build quickly. Pipelines existed. The consulting firm’s playbook fit our work.

But we had our own version of the trap.

All of our credit card data lived on the mainframe. Any change touching that data required a deployment from the mainframe team — the team that released quarterly. We could build in two-week sprints. We just couldn’t always release.

What this produced was not a failure of process. It was a new and exhausting form of project management that nobody had planned for. Before anyone could begin a piece of work, the first question was always: does this change touch the mainframe? If yes, it had to be scheduled around a quarterly release window. If no, it could proceed — but carefully, because releasing the wrong thing at the wrong time meant shipping something incomplete or breaking a dependency that hadn’t landed yet.

So the team’s energy — the energy that was supposed to go into building and solving problems — went instead into dependency mapping. Sorting changes into buckets: mainframe or not, ready or waiting, safe to release or hold. The cognitive overhead of managing that inventory was invisible work. It never showed up in a velocity chart. It never surfaced in a retrospective.

It was just the constant background hum of a team doing Agile ceremonies on top of a waterfall dependency structure.

This is what I mean by the Agile lie. Not that Agile is wrong. Not that the consultants were frauds. But that most large organizations import the ceremonies of Agile while preserving the infrastructure of waterfall.

And the most important piece of waterfall infrastructure is the budget.

Finance departments at large companies have not figured out how to budget for true Agile development. They budget for projects. They have deadlines. They have annual planning cycles that define what gets funded, for how long, and with what expected deliverable. These constraints do not disappear because engineering teams start calling their work “sprints” instead of “phases.”

What you end up with is teams working in two-week sprints, running standups, estimating in story points — and implementing projects that were defined by leadership six months ago, with fixed scope and fixed deadlines.

The engineers are doing Scrum. The organization is still doing waterfall. These two things are in direct conflict. And the engineers feel that conflict every single day.

There is a layoff that happened during that first transformation that I think about often.

The Agile rollout happened at the same time as a significant restructuring. Engineers had to bid for their own jobs. There was a day where people sat at their desks and waited. You would watch a colleague get tapped on the shoulder and escorted to HR. By the end of the day, you would find out whether you still had a position.

That day taught every engineer in the building exactly what kind of environment they were now working in.

Stay quiet. Don’t stand out. Do what you’re told and survive.

This is the opposite of ownership. And it happened on the same week everyone was being told to embrace Agile’s values of self-organization, autonomy, and continuous improvement.

The colleagues who were let go were often the ones who had carried the unglamorous work — production support, regulatory maintenance, the labor of keeping systems running. That work did not disappear because the people doing it did. The remaining engineers were expected to deliver new features in two-week sprints and manage the production support burden with reduced headcount.

Retrospectives became performative. Engineers learned that the path of least resistance was to write the story, attend the ceremony, and wait to be told what to build next.

The passivity was not a personality trait. It was a rational adaptation to an irrational system.

One of the consultants from that transformation said something to me that I have never forgotten.

He said: “If your team is doing everything the same way in a year, then we have failed in understanding what Agile’s real benefit is.”

He was right. The real benefit of Agile is not sprints or story points or any ceremony. It is quick feedback loops. Continuous improvement. The discipline of testing things out, watching what happens, and adjusting based on what you learn. It is delivering value to real customers and using their response to guide what you build next.

The organization had looked at his framework and seen a process to install. He had meant it as a mindset to cultivate.

That gap — between Agile as a set of rituals and Agile as a philosophy of learning — is where passive engineers are made.

If you manage engineers inside a large organization and you recognize what I’m describing, the passivity you’re seeing in your team is not a character flaw. It is a message. The system produced the behavior.

The system can be changed — not all of it, but enough. That is what my first post was about, and it is what the book I wrote goes into in depth.

The ceremonies are not the point. The conditions are.

The Passive Engineer Isn't the Problem

Daniel Holt — Tue, 07 Jul 2026 14:25:16 +0000

You've had the meeting.

Smart, well-paid engineers. A refinement session. Nobody saying anything. The scrum master carrying the entire conversation while the engineers watch. A requirement gets read aloud. Silence. Someone offers a point estimate — a 3, maybe a 5 — and everyone nods along. After the meeting, you get a message from one of your engineers: what should I pick up next?

You've tried talking to them about it. You've told them to speak up, to ask questions, to take ownership. They nodded. The next refinement session looked exactly the same.

Here is what most managers conclude at this point: the engineers are the problem. They're disengaged. They don't care. They're not the right people.

Here is what is actually true: the engineers are doing exactly what their environment has taught them to do.

Passivity in engineering teams is not a personality flaw. It is a rational adaptation.

Think about what the organization has been teaching these engineers, often for years. The engineer who speaks up and proposes a solution takes a risk. If the solution is wrong, they own the failure. If the solution is right but wasn't what was specified, they may still own the failure. The engineer who waits to be told exactly what to build, builds exactly that, and asks what to do next — that engineer is never wrong.

Waiting works. And so engineers learn to wait.

Something in their history — a failed initiative, a layoff, a project that got credited to someone else, a solution they proposed that was ignored — taught them that the safest move is to stay in their lane and execute their assignment. That lesson calcified. And now it runs automatically, below the level of conscious decision-making.

This is not laziness. This is learned helplessness — a self-preservation instinct that was once, in some environment, exactly the right response.

The implications for managers are significant.

You cannot talk engineers out of a lesson their environment taught them. Telling them to speak up, to think like owners, to take initiative — these instructions land in an environment that has not changed, delivered by a manager who may or may not still be there in six months. The rational response is to nod and wait to see if anything actually changes.

The manager who understands this does not start with the engineers. They start with the environment.

What would it look like if initiative were rewarded instead of risky? What would it look like if engineers could see the direct connection between what they built and what it caused — if the feedback loop actually closed? What would it look like if the work were framed as a problem to solve rather than a specification to execute?

Those are the conditions that produce a different kind of engineer. Not a different person — the same person, operating inside different conditions, having a different experience of what their work can produce.

The passive engineer is a message, not a verdict.

When you look at a team where nobody speaks in refinement, where every story is a 3 or a 5, where engineers message you to ask what to pick up next — you are not looking at people who cannot do better. You are looking at people who have learned, accurately, that doing better was not what was being asked of them.

The system produced the behavior. The system can be changed.

Not the whole system — you cannot fix how your organization budgets, how leadership sets scope, or how your release process works. But you can change how your team relates to those things. You can create conditions where asking why becomes the natural first response to an unclear situation. Where engineers develop the habit of thinking in problems instead of tasks.

That is the work. It is slow, it is unglamorous, and it is worth doing.

I wrote a book about how to do it.

Getting Engineers to Give a Damn: A Manager's Guide to Building Ownership Inside Broken Systems is a practical guide for engineering managers inside large, constrained organizations — banks, regulated industries, and anywhere that adopted the rituals of Agile while keeping the infrastructure of waterfall.

It covers why passivity happens, what product thinking actually looks like in practice, how to earn the credibility that precedes autonomy, and how to sustain a culture of ownership when the organization is always, in some way, working against it.

It was written by someone still inside the machine.

The Uncertainty Is the Point

Daniel Holt — Tue, 07 Jul 2026 14:14:21 +0000

There is a particular kind of organizational anxiety that doesn’t come from bad news. It comes from no news — from the sense that something is shifting underneath you without anyone saying clearly what it is or where it’s going.

That is where my teams are right now.

New leadership has arrived. There are questions about how a product team fits into the current organization. Lean Six Sigma is being discussed — a methodology that hasn’t been prominent in software engineering conversations for a long time, and one that signals something specific about how the people asking the questions think about engineering work. There are suggestions about getting certified. There is no clear direction.

And my engineers — the ones who show up to refinement having already thought about the problem, who ask why before asking how, who help each other without being asked because they understand the sprint goal belongs to all of them — are afraid.

Not of the work. Not of change in general. Of going back.

What They Are Actually Afraid Of
When I have one-on-ones with my engineers right now, the fear is specific.

They are afraid of not having a backlog. Of losing the product team identity they have built over time and grown into. Of becoming a project team again — receiving requirements, executing tickets, waiting to be told what to build next.

They have been hunters. They know what that feels like. And they can feel the possibility of becoming cogs again, not because they have done anything wrong but because the organization around them is asking different questions than it was before.

That fear is rational. They are not catastrophizing. They have seen enough of how large organizations work to know that the signals matter. When leadership starts talking about Lean Six Sigma and certification programs, they are telling you something about how they think about engineering — as a process to be optimized, not a capability to be developed.

Lean Six Sigma is a serious methodology with real applications. It was built to eliminate waste and reduce variation in repeatable processes. It works well in manufacturing, in supply chains, in contexts where the goal is to do the same thing more efficiently every time.

It is not built for the kind of work a product team does — iterating toward an outcome, forming hypotheses, running experiments, adjusting based on what you learn. Product thinking requires variation. It requires the ability to change direction when the data tells you to. Applying a reduce-variation framework to a learn-and-adapt team is not just a mismatch. It is a direct contradiction.

My engineers can feel that contradiction. They do not have the language for it yet. But they feel it.

What I Am Telling Them
Keep going.

Not as a platitude. Not as false reassurance that everything is going to be fine. But as a strategy.

The work does not stop because the organizational questions are unresolved. The sprint goal is still the sprint goal. The metric we are trying to move is still the metric we are trying to move. The engineer who shows up prepared, asks the right questions, and delivers something measurable is still the most valuable person in the room regardless of what the methodology is called.

And here is the thing that is hard to argue with: positive results.

Numbers do not care about organizational politics. A team that consistently moves the metrics that matter to the business — that reduces fraud losses, increases successful evaluations, improves response times, delivers measurable outcomes sprint after sprint — is a team that is difficult to dismantle. Not impossible. But difficult.

The case for a product team is not made in a meeting about methodology. It is made in every sprint review where a number moved and the team can explain why. It is made in every one-on-one where an engineer surfaces a problem nobody assigned them to find. It is made in the data, accumulated over time, that shows what this way of working actually produces.

That is the evidence that is hard to argue with. And building more of it — right now, in the middle of the uncertainty — is the most important thing the team can do.

What the Uncertainty Is Actually Doing
Uncertainty is not neutral. It teaches people things.

An engineer who watches leadership signal a shift toward process and certification without clear direction learns something. They learn that the environment may be changing. That the things that were valued before may not be valued the same way going forward. That the safest move, until clarity arrives, might be to pull back.

That is the passive engineer being rebuilt in real time. Not because the engineer chose it. Because the environment started teaching the old lesson again.

This is why the manager’s job in a period of uncertainty is not to wait for clarity before acting. It is to keep creating the conditions that produce hunters — to keep naming the outcome before the sprint begins, to keep closing the feedback loop, to keep pressing engineers to lead and playing dumb when they bring problems — so that the team’s identity stays intact while the organizational questions get sorted out.

The culture you built is not a finished thing. It was never a finished thing. It requires ongoing attention and ongoing protection — especially when the organization is shifting underneath it.

The uncertainty is the point. This is exactly when the work matters most.

What Comes Next
I do not know how the reorganization will resolve. I do not know whether Lean Six Sigma will arrive in full, in part, or not at all. I do not know whether my product teams will stay intact or whether engineers will be redistributed to teams that work differently.

What I know is that the results are real. The numbers have moved. The engineers on my teams have become something different than what they were — and that difference is visible in every sprint review, every refinement session, every moment when someone surfaces a problem nobody assigned them to find.

That evidence exists. It is documented. It travels in ways that stories do not.

And when the questions get answered — when the organizational direction becomes clear — a team that kept delivering through the uncertainty is in a much stronger position than one that went quiet and waited.

Keep going. Positive results are hard to argue with.

The fight is worth having.