Beyond agile

If you are a developer, I am sure you have found yourself caught in agile theater. Some teams live in an eternal echo of ceremonies, sessions, dailies, groomings. This can feel lifeless to some. The discipline in which all this theater is played is noteworthy though. Everyone gets their own little spot on the stage. To utilize the theater metaphor one last time: Have you ever wondered what happens if there are no tickets sold anymore? If you play in front of empty seats? If an LLM graduates to be the prompter? Let’s see how it looked before the play was written.

How it used to be

Before Agile, the predominant mode for large-scale software development was the waterfall method. Long planning cycles and detailed documentation helped to establish a definition of done. A waterfall model is easier to oversee in its entirety. There’s one thick book of documentation to read. It should contain the answer if we are able to keep up with our idea for a long period of time, or if we will hit a wall. In contrast, agile methods focus on the short-term risk analysis and make sure that no wall will be hit within the upcoming cycle.

We are dealing with two main planning modes for software: Strategic (waterfall) and tactical (Agile). Either a team aligns up-front on a huge work item. Or they align many times per year on smaller work items. The quality of work items depends on the planning role, be it a project manager or a product owner. Bad planning can be compensated by excellent software developers, and the other way round. A very good plan can be executed by mediocre software developers. This claim is highly context dependent of course. In some environments, you need world-class developers executing an excellent plan to write the required software. Both planning modes give room for the time-consuming practice of writing code by hand. They have a blind spot though, which is called “writing code”.

Distractions

If we look at the massive amount of code that an LLM can produce, it gets even more clear that writing code is not the problem (it never was). Sure, writing code by hand takes patience and focus. What really costs time though are the distractions. Distractions of missing requirements. Distractions of legacy code. Distractions of badly documented APIs. It can be time-consuming and even tiring to navigate obstacles. What we developers failed to do in the past is to draw a clear line between writing code and overcoming distractions. Our work used to be a mix of writing some code, then getting distracted, then writing some more code - we just called all this “writing code”.

Those distractions are not gone in the LLM age, but they are displaced. Those endless blog posts (sometimes heroic, sometimes honest) about developers using coding agents will always contain a sentence like “after some back and forth with the agent” or “after some steering into the right direction”. Those are the same distractions that we had before coding agents! Instead of typing code by hand, then resolving a distraction, we are resolving distractions by typing natural language.

Temporality and Gesture

Beyond Agile means that we need to be much more honest about distractions. As a Principal Software Developer, in my daily work, I can see those mentioned distractions bubbling up in code reviews. Before the wide adoption of coding agents, I’ve seen many more rookie mistakes made by juniors. Those honest mistakes are almost entirely eliminated by LLMs (variable naming, spaghetti constructs, wrong data access patterns, …). Nowadays, the mistakes are in what was not written. A missing sanitization. An architectural pattern that should be there. An unclear security boundary. It is much harder now to put the finger on something that is not there.

A property of successful teams is to reliably complete quality work on time. This is a value companies will not give up on, and it is an embodied value for me as well.

Reliability comes on a timeline. Teams need to rely on their peers. They rely on their tools, which they invest much time to learn and maintain. Reliability is a promise for availability. It contains the discussion when reliability is expected. It even contains the discussion about expectations.

Complete work can be a well-rounded feature. It can be a well-rounded release. It can be a documentation that leaves no questions open. It can be a feature-complete library on a feature freeze. All those need to be discussed on different timelines. Quality work is in the eye of the beholder. Good enough is highly context dependent. What works for an internal experiment will not suffice for aviation or medical devices.

Interestingly, “reliably completing quality work” is a temporal problem to solve. We shifted from long-term waterfall models to short-term agile models. What’s missing is the question what success looks like throughout time. In musical compositions, this is called a “gesture” (German: “Gestus”) - to hold on to a rhythm, hold on to an idea, and not letting go of an intuition and a certain way of expression until the end of the symphony. We can also look at a “gesture” from what it is not: getting distracted.

In times beyond agility, I am convinced we need this “gesture”. We need to hold on to an idea of reliability, completeness and quality. Those are exactly the attributes companies value. We can discuss those attributes systematically. For plan-making, we can optimize reliability, and we can optimize completeness. It needs a team on eye-level to have the back-and-forth of arguments to agree on the best solution, or, if they must, agree on a controversy. Learning from each other, as a team, how reliability, completeness and quality truly looks is the path I propose for developing software in the LLM age.

I see shifting a disciplined theater towards a higher quality of discussion. Where we had a daily, we should speak about quality. Where we had a retrospective, we will ask ourselves how complete the software is, and how complete it should be. Where we do a grooming, we will make sure we can rely on each other’s work. Coding agents should help us to facilitate these discussions, because they reveal distractions. I think it already has become harder to replace senior developers. These individuals carry the unspoken gesture. Articulating these ideas with a whole team is the next step in developing better software, beyond agile.