What does agility mean in the age of AI?

Lately, discussions around agile development have strongly circled one theme: what does agility mean in the age of AI? There have been many different viewpoints, and I won’t comment on individual articles here. Instead, I want to reflect on what agility fundamentally is, and how this core has changed – or may be changing.

I started my career around the turn of the 2000s, and the challenges of the waterfall model were already being discussed back then. Digitalisation was in some ways already more advanced, but in many places we still tried to copy manual processes as they were, without really considering the characteristics of digital services.

The waterfall model is a good example of this. When you build an apartment building, you don’t change the foundations halfway through, and you don’t usually redesign the structures and HVAC installations if you want to complete the project successfully. Plans need to be made thoroughly, and later changes are only possible in a limited way without major impact on schedule and budget. The more precise the upfront planning, the better the outcome. (The analogy is not perfect, of course, but it helps to illustrate the mindset.)

The waterfall model tried to apply this thinking to software projects. Large initiatives were planned for months or even years before any real implementation started. Often the end result did not match the plans or the customer’s real needs: customers did not always know how to express their needs in “engineering language”, the requirements did not truly serve the users, implementation was guided by individual interpretations, and testing came in so late that there was no time or room left for meaningful improvements. Software projects moved slowly, and the outcomes often failed to meet customer expectations.

In process development, people started to realise that, compared to traditional projects, software development can be planned, implemented and shown to customers in smaller pieces. In the 2000s I trained testing processes, and at that time we talked about incremental development models, where work is done in smaller increments.

The important part in this incremental process was that testing was done continuously at lower levels, and for customer demos the pieces were integrated early enough so that compatibility between components could be tested. Customers gave feedback on whether we were heading in the right direction, and the course was adjusted in the next increment. There was a high‑level view of the whole, but the detailed specification was done step by step, in parts.

Around the same time, people were already talking about agile development and how methods like Extreme Programming and similar approaches seemed to completely change the way of working. There were many experiments going on, but for larger development efforts most companies still moved a bit more cautiously.

From my own experience, agile development in many places looked like a more refined form of incremental development. Teams worked in different kinds of cycles depending on their context, but they shared a common pattern: build, test and deliver quickly. At the centre of all this was getting feedback from customers or customer representatives on whether the chain from needs → requirements → specifications was actually producing the right things. Based on that feedback, changes were made when needed.

Gradually, the Agile Manifesto, books, process descriptions, guidelines and Lean/Agile gurus entered the picture. In some organisations, agility had already led to major positive changes, and people wanted to replicate these practices as widely as possible. At this point, something fundamental may have been forgotten.

The focus shifted to principles and to organising the work exactly as described in books or as it had been done successfully somewhere else. In many organisations I’ve worked with or followed closely, smaller companies often adopted agile practices quite successfully, while larger organisations struggled. Software development was going through growing pains. Scaled methods arrived on the scene early enough, but while Scrum was relatively straightforward to adopt at team level, rolling out scaling frameworks often did not go as smoothly as hoped.

It is easy to tell stories about where things have gone well, but to make practices work in your own organisation, you really need to pause, compare different models and think about what actually fits your context. What kind of cadence works best for our product experts and product development? Who really needs to plan together? Where are the real dependencies, and how often do we need to come together because of them? Which tools actually bring real added value?

At that point, the core of agility – continuous learning, experimentation and using feedback – is more important than any single framework or ready‑made model: What needs to be done first, and how do we test it? Who do we show it to, and how do we feed the feedback back into planning?

In the age of AI, this becomes even more important. There are more ready‑made answers and tools available than ever before, but none of them alone solves the question of how our specific team makes better decisions in everyday work, learns faster and delivers the right things to customers.

Many articles ask whether AI means the end of agile development, if we no longer “need” ceremonies and other practices that are associated with agility. For example, some argue that spec‑driven development takes us back to a kind of waterfall model – just a faster one. I would argue that this is not the real issue – we do not want to run software development like large construction projects.

Instead, we may actually be moving back towards the roots of agility: simply focusing on how we get fast feedback on what we have built, how we demo quickly and effectively, and how we feed those observations into the next steps and into the overall picture of the work. Ceremonies, sprints and tools have served teams by giving them a structure for planning together, giving feedback, sharing knowledge and hearing feedback on what has already been delivered. These mechanisms may well change – and that is something I will write more about in a future post.

Agility is not just a process or a set of practices. At its heart, it is about staying humble in front of the fact that we never build alone. There is always a customer somewhere whose voice we want to hear, so that we can offer them the best possible product. The age of AI brings countless interesting possibilities to this.