The Early Days: When Agile Was the New Cool

When I first started exploring agile project management, it was the buzzword that everyone was throwing around. Scrum was king, and if you weren't doing daily standups, sprint planning, and retrospectives, you weren't "doing agile right." (If you're new to these concepts, I've written a that covers the fundamentals.) The industry was flooded with certifications, agile coaches, and frameworks that promised to revolutionize how teams worked.

The appeal was obvious. Traditional waterfall methodologies 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. Teams were excited about the prospect of working in sprints, having more autonomy, and being able to pivot quickly.

But here's what I noticed: many teams were following the rituals without understanding the principles. We had standups that ran for 30 minutes where people gave status updates to the project manager instead of coordinating with each other. We had sprint planning sessions that felt like commitment ceremonies rather than collaborative planning. Retrospectives became complaint sessions with no real action items.

The tools and ceremonies were there, but the mindset shift hadn't happened. We were doing agile theater - performing the rituals without internalizing the values. Story points became a deadline commitment mechanism. Velocity became a productivity metric to compare teams. The backlog became a wishlist that nobody dared to prune.

What was supposed to be a lightweight, adaptive approach had become another rigid framework with its own set of rules and dogma. The irony wasn't lost on me: we had created a new orthodoxy in our attempt to escape the old one.

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. For those unfamiliar, improvement kata is a practice developed by Mike Rother that focuses on developing a scientific thinking pattern for improvement work.

The beauty of improvement kata lies in its simplicity:

1. Understand the direction - What's the target condition we're trying to achieve?
2. Grasp the current condition - Where are we now? What's actually happening?
3. Establish the next target condition - What's the next step that will move us toward our goal?
4. Experiment toward the target condition - Run small experiments (PDCA cycles) to learn our way forward

What struck me about improvement kata was its emphasis on learning through experimentation rather than following a prescribed process. It wasn't about doing sprints or standups or any specific ceremony. It was about developing a systematic approach to problem-solving and improvement.

This felt refreshingly different from the agile frameworks I had been practicing. Instead of asking "Are we following the Scrum guide correctly?", we started asking "What are we trying to achieve, and what experiment can we run to learn more?"

The coaching kata that accompanies it was equally powerful. Rather than telling people what to do, coaches would ask five questions:

1. What is the target condition?
2. What is the actual condition now?
3. What obstacles are preventing you from reaching the target condition?
4. What is your next step?
5. When can we go and see what we have learned?

These questions created a culture of scientific thinking. People learned to see obstacles as learning opportunities rather than blockers. Teams became more comfortable with uncertainty and experimentation.

Where I Am Now: A Synthesis of Practices

Today, my approach to project management is a synthesis of agile principles, improvement kata thinking, and hard-won pragmatism. I've moved away from religious adherence to any single framework and toward a more adaptive, context-sensitive approach.

Here's what this looks like in practice:

Focus on Flow, Not Ceremonies

I care less about whether we're doing sprints "correctly" and more about whether work is flowing smoothly through our system. We identify bottlenecks, measure cycle time, and optimize for reducing work-in-progress. Some teams use sprints, some use continuous flow. The choice depends on the context, team maturity, and the nature of the work.

Experiments Over Plans

Inspired by improvement kata, we frame everything as experiments. We might hypothesize that pairing developers will reduce bugs, so we run a time-boxed experiment and measure the results. We might think that smaller user stories lead to faster delivery, so we test it. This mindset shift from "implementing best practices" to "running experiments" has made teams more engaged and reduced the defensiveness that often comes with process changes.

Target Conditions Over Backlogs

Rather than maintaining massive backlogs that nobody looks at, we define clear target conditions for what we want to achieve. This could be "reduce deployment time to under 10 minutes" or "achieve 90% test coverage in the authentication module." The work we do is in service of moving toward these target conditions, and we're ruthless about saying no to anything that doesn't clearly contribute.

Regular Reflection, Flexible Format

We've kept the retrospective spirit but made the format flexible. Sometimes it's a structured retro, sometimes it's a group problem-solving session, sometimes it's a celebration of wins. The key is that we regularly pause to reflect and adjust. The improvement kata coaching questions often guide these sessions.

Metrics That Matter

We've stopped tracking vanity metrics like velocity or story points completed. Instead, we focus on outcomes: customer satisfaction, deployment frequency, mean time to recovery, and cycle time. These metrics tell us whether we're actually improving our ability to deliver value, not just whether we're "busy."

Psychological Safety as Foundation

None of this works without psychological safety. Teams need to feel safe experimenting, admitting uncertainty, and discussing obstacles openly. Building this safety has become a primary focus, more important than any process or tool.

The Journey Continues

The evolution of my project management approach reflects a broader maturity in how I think about process and improvement. Early in my career, I was looking for the "right way" to do things. I wanted a framework that would solve all problems if only we followed it correctly.

Now I understand that there is no "right way" - only practices that work better or worse in specific contexts. The goal isn't to follow a methodology perfectly, but to build teams that can continuously learn and adapt. Agile gave us permission to iterate quickly. Improvement kata gave us a systematic way to learn from those iterations. What I do now is an ongoing experiment in combining these ideas with the realities of the teams and contexts I work in.

The only constant is the commitment to keep learning, keep experimenting, and keep adapting. That, perhaps, is the most agile thing of all.