Agile is alive. The bottleneck is moving.

Every now and then, I come across another declaration that agile is dead. Recently, AI has become the explanation. When software can be written in hours instead of weeks, the argument goes, the processes built around developing it have outlived their usefulness.

I understand some of the frustration. I also think we are mixing up several different things.

There are teams for whom the familiar setup of two-week sprints, daily standups, planning poker and detailed estimates deserves a serious rethink. If the work has changed, the way we organise it should change too.

But I struggle with the leap from there to declaring agile thinking obsolete. AI has given us new ways to build things. It has hardly made customers, markets or organisations predictable.

The reason I keep coming back to agile thinking is its usefulness when we do not yet know enough to make a reliable plan. We take a manageable step, observe what happens, and use what we learn to decide what to do next.

I have yet to see AI remove the need for that.

The ceremonies deserve scrutiny

For many people, agile has become synonymous with Scrum. And Scrum, in turn, has become synonymous with a calendar full of meetings and a backlog full of estimated tickets.

That deserves a little fairness. The Scrum Guide does not prescribe two-week sprints or planning poker. It also explicitly allows delivery before a sprint ends. A team waiting until Friday's review to release something useful may be following a local habit rather than a requirement of the framework.

Still, understanding the guide correctly does not mean Scrum is the right choice for every team.

A meeting that helps people resolve dependencies or make a decision has a purpose. An estimation exercise that informs a meaningful investment decision may have one too. A meeting everyone attends because it is Tuesday deserves more scrutiny.

Faster coding alone cannot tell us which of those activities to remove. We need to understand what each activity contributes and whether a simpler approach would serve the same purpose.

Some teams may retain Scrum. Others may find a continuous flow of work, fewer simultaneous initiatives and frequent reviews more useful. Changing the method is a reasonable response to changing circumstances.

A working feature still leaves questions unanswered

AI can dramatically shorten some implementation tasks. That does not mean software engineering as a whole has become effortless. Reviewing, integrating, securing and maintaining a system still matter.

But even where implementation becomes much faster, a working feature leaves several questions unanswered.

Did we solve a problem customers actually have? Will they change their behaviour? Does that change help the business? Was this the most useful thing we could have worked on?

Imagine a SaaS company whose new customers struggle to get started. A team can now build an onboarding assistant in an afternoon. That makes the idea easier to test. It does not establish that missing guidance was the problem.

Perhaps customers cannot access the data they need. Perhaps the person who bought the product is different from the person expected to use it. Perhaps the sales promise created expectations the product cannot meet.

The implementation may be finished before the team understands which of those explanations matters.

That is where I think the bottleneck can move: towards choosing, understanding and validating the work. A shorter development cycle gives us an opportunity to learn sooner, provided we actually follow through and observe what happens.

Customer behaviour still needs time to emerge. Trust takes time to earn. An experiment needs enough evidence to support a decision. None of those clocks automatically speeds up because code generation does.

Cheap code does not make every bet cheap

I have little interest in returning to a model where we specify everything upfront and assume reality will cooperate until delivery. Planning is useful. Treating uncertain assumptions as settled facts is where the trouble starts.

But the other extreme is no more convincing: build whatever comes to mind because implementation is cheap, and hope something works.

A quick prototype can be an excellent way to investigate an idea. Once an experiment reaches customers or becomes part of a live product, however, its cost extends beyond writing the code. It consumes attention, creates expectations, adds complexity and may need support long after the initial enthusiasm has passed.

If we try ten things without deciding what we hope to learn, we can end up with ten new features and very little understanding of why anything changed.

I would rather make the bet explicit: here is the problem, here is what we believe might help, and here is the evidence that would make us continue, change direction or stop.

That leaves plenty of room for experimentation. It also gives us a way to recognise when an experiment has taught us enough.

Developers need access to the business problem

As implementation becomes faster, I expect product and business understanding to become even more important in engineering work. Developers need enough context to challenge a request, recognise a trade-off and suggest a simpler way to achieve the intended result.

That requires organisational change as well as individual curiosity.

We cannot ask engineers to take greater responsibility for outcomes while giving them only tickets, keeping them away from customers and measuring them primarily by how much they deliver. They need access to the reasoning, the evidence and the people involved. They also need the authority to act on what they learn.

In the onboarding example, the useful group might include engineering, product, design, sales and customer success. Together, they can investigate the journey from the sales conversation to the customer's first useful result. The eventual improvement might involve software, a different sales promise, better guidance, or a combination of all three.

AI does not automatically create that collaboration. Leadership has to make room for it.

Agile thinking needs to reach beyond the development team

The principles behind the Agile Manifesto already emphasise close cooperation between business people and developers, adaptation as requirements change, and regular reflection on how to work more effectively.

I think those ideas deserve a wider application across the company.

A development team can learn quickly and still be constrained by priorities that nobody revisits, commitments made without its involvement, or departmental targets that pull in different directions.

The company needs a lightweight way to connect its direction to the problems people are working on. Teams need to understand what improvement they are trying to achieve, see how their work contributes, and bring learning back into decisions about priorities.

That does not require every department to adopt the same workflow. Sales, finance and engineering have different daily work. They can still share a direction and a regular opportunity to assess whether their combined efforts are helping.

This is the part of agile thinking I want to carry forward: enough shared structure to make decisions together, and enough freedom to change the approach when we learn something new.

I am quite happy to retire ceremonies that no longer help. I am much less convinced that we should retire the discipline of learning our way through uncertainty.

AI gives us more opportunities to act. The question is whether we are building organisations that can make sense of the results.

When we can build almost anything, knowing what is worth building becomes a greater responsibility.