The Evolution of Agile Project Management: From Trend to Practice

Starting in a large enterprise

My career started at SAP, and you could not ask for a better place to learn what agile was reacting against. A traditional enterprise with decades of process in its bones: release trains measured in quarters, documents signed before code was written, and a hierarchy for every decision. In that world, simply running Scrum (actual standups, actual sprints, an actual board) felt genuinely revolutionary. It was the buzzword era everywhere, but inside a company like that, the ceremonies were not theater yet; they were rebellion. (If you're new to these concepts, I've written a that covers the fundamentals.)

The appeal was obvious. Waterfall felt rigid and slow, often delivering products that were outdated by the time they launched. Agile promised flexibility, faster iterations, and better alignment with customer needs, and against a backdrop of quarterly release trains, a two-week sprint felt like teleportation.

But even then I noticed the failure mode that would follow me for years: teams adopting the rituals without the principles. Standups that ran for 30 minutes as status reports to a project manager. Sprint planning that felt like a commitment ceremony rather than collaborative planning. Retrospectives that were complaint sessions with no action items. Story points quietly becoming deadline commitments; velocity becoming a scoreboard; the backlog becoming a wishlist nobody dared to prune. In a company that size, agile theater is almost gravitational: the org chart pulls every new practice back into the shape of the old ones.

From a six-person startup to a scale-up

Then I joined Beamery as an early-stage startup, and the contrast was total. We were six people. Six. And we still did sprints, planning, standups, the whole rhythm. It sounds excessive for a team that could hold most of its coordination in one conversation over coffee, but it worked. At that size the ceremonies were nearly weightless, and the rhythm itself was useful: a cadence for deciding, a moment for demoing, a habit of asking what we learned.

As the company scaled, we leaned into Scrum harder rather than lighter. We brought in a Scrum coach, formalized the retros, tightened the ceremonies. And for a while that was right: each layer of process was absorbing a real coordination cost that growth had created. It suited what our teams needed then.

As we kept scaling, I saw some of the same drift I'd seen at SAP: retros held because the calendar said so, planning performed for the process rather than the plan. The harder bottleneck had moved. How did the company's bets become priorities for Engineering, Product, and Design? How did those priorities become coherent work across dozens of teams? Improving a team's ceremonies wasn't enough to resolve competing priorities and dependencies across the organization.

The AI Team: Planning in the Era of Uncertainty

The break came when I started the AI team at Beamery. Half the backlog was questions: “Can this model even do this?” A Tuesday experiment could invalidate the work we'd selected on Monday. When we judged the sprint by how much of that selection we'd completed, useful research could look like failure.

That was a problem with how we were using Scrum. The Scrum Guide explicitly addresses complex work and allows scope to be clarified and renegotiated as people learn, while preserving the Sprint Goal. It doesn't require a frozen list of tasks, and it doesn't require story points. We had been asking our estimates and plans to carry more certainty than the work justified. ¹

We kept the demo cadence and retrospectives, and ran the day-to-day as a WIP-limited Kanban flow where research spikes moved through explicit states. We still had to plan: choose a question, decide what evidence would be useful, and limit how many investigations we opened at once. The shorter horizon suited us better. That experience taught me to ask, for every ceremony: what feedback does this create, and how quickly can we act on it?

Discovering Improvement Kata: A Different Lens

Then I stumbled upon improvement kata, and it fundamentally changed how I thought about continuous improvement and project management. It's a practice Mike Rother distilled from Toyota's management culture, built around a simple four-step pattern of scientific thinking: understand the direction, grasp the current condition, set the next target condition, and experiment your way toward it. I've since written a , so I'll keep this to what it changed for me.

What struck me was how concrete it made learning. What condition are we trying to reach? What happens now? What do we expect the next small experiment to show? The accompanying Coaching Kata gives a coach and learner a routine for examining those questions. After checking the current condition, they look back at the previous prediction, what happened, and what they learned. The question card is a starting point for practicing that conversation. ²

I found that more useful than another abstract instruction to “continuously improve.” It gave us something to do with an obstacle before turning it into a process change for everyone.

Back to building a startup

Now I've started , and I'm doing the startup-from-the-ground-up thing again. This time we don't run Scrum. The work changes quickly enough that we plan over a shorter horizon: choose the next priority, make room for it, and reconsider as we learn. There is still planning involved, even when it doesn't look like a sprint planning meeting.

What keeps earning its place is a lightweight Kanban flow, with explicit states and WIP limits, alongside for working on how we operate. We're a small team again, which makes the comparison with early Beamery interesting. Sprints helped us then; a lighter flow suits us here. I don't think the difference is that we've graduated beyond Scrum. The work, uncertainty, and coordination needs are different.

What I keep coming back to

I want to understand where work waits, what we're trying to improve, and how we'll notice whether a change helped. A board can make the waiting visible. A regular demo can expose a misunderstanding. A small experiment can test an assumption. Each needs a clear purpose; none earns its place just by being familiar.

Target conditions help me be more specific about improvement work. For example, if deployment is the problem, I would describe how routine changes should move through automated checks and reach production without an unnecessary manual handoff, then set a date and measures for that condition. A test-coverage percentage alone wouldn't tell me whether the critical paths were protected or whether deployment had become easier. This also doesn't replace a product backlog: deciding what to build and improving how we build it are related jobs, with different questions.

I also want to separate customer outcomes from delivery capability. Customer satisfaction asks whether we're helping people. Deployment frequency, recovery after a failed deployment, and lead time tell us about aspects of our delivery system. They can support a conversation about value; they don't establish value by themselves. The current DORA measures are useful here, alongside the broader view of developer productivity in SPACE. Neither is a reason to rank individual engineers by activity. ³⁴

Finally, I need people to be able to tell me that a plan no longer makes sense. If admitting uncertainty is punished, we'll get tidy updates and hidden problems. That is a management responsibility I can't delegate to a framework. I've explored the same tension in .

I still find plenty to use in Scrum. I also know that the process that helped us at one stage can become expensive at another. The question I want to keep asking is simple: what is this practice helping this team learn or do today?

Reading that helps with the next questions

• looks beyond team ceremonies to team boundaries, cognitive load, and how teams interact. It's relevant to the coordination problems I ran into as Beamery grew.
• goes deeper into queues, batch sizes, and the economics of managing work in progress.
• The practical companion posts cover , , and .