The Anchor Point Illusion: Why Strong Leaders Don't Need Fixed Milestones

Why Agile Development Is a Mirror, Not a Methodology

There's a seductive idea making the rounds in management circles: that strong leaders need "anchor points"—clear deliverables, milestones with owners and due dates, tollgates—to effectively steer their projects. Without these fixed reference points, the argument goes, leaders are left helplessly watching spillovers accumulate at sprint boundaries, unable to apply corrective measures early enough.

This framing sounds neat and orderly. It appeals to our desire for control and predictability. But it's fundamentally misleading and ultimately dangerous for anyone trying to build successful software products.

The “Agile Methodology” Mistake

Let's start with a critical misconception: treating agile software development as a methodology. This reduction makes it sound like a rigid delivery recipe—a paint-by-numbers approach to building software. What agile development actually offers is a set of principles and practices designed to navigate uncertainty, complexity, and change. The moment we treat it as a methodology, we've already missed the point.

This isn't semantic nitpicking. The distinction matters because it reveals how we think about software development itself. If we believe development is predictable enough to follow a methodology, we'll naturally gravitate toward those comforting "anchor points." But if we understand that software development is an inherently creative and adaptive process, we'll look for different kinds of guidance systems.

The False Promise of Milestones

The anchor point theory assumes that leadership comes from setting milestones and checking whether deliverables hit arbitrary dates. But if leaders are "steering" this way, they aren't demonstrating strength—they're staring at unicorns and chimeras.

Milestones might look like clarity, but in practice they function as lagging indicators at best. By the time they're missed, the damage is already done. At worst, they become theatrical props in a game where teams manipulate dates and deliverables just to keep management happy. That's not leadership—that's project management theatre.

The harsh reality is that a software product is not a straight road with predictable waypoints. It's a complex system shaped by evolving requirements, changing customer needs, emerging technical constraints, new regulations, and shifting market conditions. Pretending we can define clear deliverables upfront and lock them down is pure fantasy. The only place those exist is in the minds of leaders who refuse to confront the reality that plans don't survive contact with the real world.

The Litmus Test of Leadership

Here's the deeper truth: agile software development isn't just about delivery practices—it's a litmus test for leadership capability. The ideas, principles, and values around iterative and incremental development aren't new or exotic. As Craig Larman documents in Agile & Iterative Development, these concepts stretch back decades. Even Winston Royce's infamous "waterfall" paper from 1970 actually described an iterative method that involved customers throughout the process.

We've known about adaptive development approaches for 50-60 years. When they fail in our organisations, the problem is almost certainly not with the methods or frameworks themselves. They're mirrors, reflecting back our own limitations.

Are "strong leaders" unable to support an iterative and incremental approach to complex software product development? Then they should fix that, not blame the mirror.

What Real Anchor Points Look Like

The genuine anchor points in software development aren't tollgates or milestone reviews. They're working software, validated learning, and a steady flow of value to customers. Daily conversations, regular reviews, transparent metrics, and small increments of progress provide leaders with far superior insight than any tollgate review ever could.

Leaders who engage with these real signals aren't left "helpless" at sprint boundaries—they see issues as they emerge and can act immediately. They don't need to wait for a formal milestone to understand where things stand because they're continuously connected to the actual work and its outcomes.

This requires a different kind of leadership strength: the ability to operate in ambiguity, to make decisions with incomplete information, to adjust course based on learning rather than defending a predetermined plan. It's messier than milestone management, but it's also more effective.

Beyond Delivery: The Strategic Foundation

There's another crucial point here. Agile software development, properly understood, doesn't solve everything. It's one piece of a much larger puzzle. Before any iteration kicks off, serious product work needs to happen. Strategic intent must be clear. Tactical objectives need to be defined and aligned with real customer value.

Without this foundation, no delivery practice will rescue us. Expecting agile development to magically fix unclear strategy, poor product thinking, or weak leadership is setting it up as a silver bullet it was never meant to be. The methodology mindset leads us to believe that following the right process will solve our problems. The principles mindset reminds us that good outcomes require good thinking, not just good execution.

The Question That Matters

So the real question isn't whether we have enough anchor points. It's whether the anchor points we're clinging to are real or illusory. If they're just deliverables on a plan, they're giving us a false sense of security while the actual work slips away beneath our feet. If they're grounded in continuous learning, working outcomes, and genuine adaptability, they actually help us navigate toward results.

Strong leaders don't need the theatre of fixed milestones and tollgate reviews. They need the courage to engage with uncertainty, the wisdom to recognise what's actually working, and the skill to help their teams adapt and improve continuously.

That's the difference between strong leadership and the illusion of control. The anchor points that matter aren't the ones we draw on our project plans—they're the ones we discover by doing the work, learning from the results, and staying closely connected to the real value we're trying to create.

The choice is ours: we can keep chasing the comfortable fiction of predictable milestones, or we can develop the leadership capabilities that complex software products actually require. The mirror of agile development will reflect back whichever path we choose.