AI Agile: X Modification

Figure 1: Photo by Nguyen Dang Hoang Nhu on Unsplash

One year ago we ran a common Agile workflow. Teams, sprints, a release every Wednesday. Today the teams are gone, we still run sprints and ship every week — but neither means what it used to. That’s not because we read modern posts or books about a new framework, but because AI broke the assumptions the whole thing rested on. Below is my experience of what was broken and what we changed. I can’t promise a happy final: some of it works, some of it is still in progress.

What Actually Happens

When someone says “AI speeds up development”, they mean the code is created faster. That’s true but it’s not the main thing.

The main thing is that AI changed the ratio between writing code and everything else. Before, the bottleneck was implementation: an engineer got a task, created code for two weeks, and moved the work into QA. Currently, implementation takes a few days, sometimes hours and the bottleneck became everything around it: understanding the task, designing it, testing it, and making sure you didn’t break other parts.

If you speed up code creation, you don’t speed up delivery. You just push more work onto everyone downstream.

It happened to us.

One Engineer — One Project

The first thing we changed is the unit of work.

Figure 2: Photo by Ben Kolde on Unsplash

At the beginning we had teams of five to seven people, the team had a backlog, the features were broken down and shared inside the team. As Agile says — Groom it baby, Groom it! And we did it, everyone understood the whole feature and could see their part too. Ownership happened naturally: sometimes the team was responsible for a feature, sometimes someone took the lead and ran it. Both worked — when they worked. The challenge here is that this isn’t a system, it is luck because collective responsibility fades away on its own, and voluntary ownership is a lottery. For one feature it was easy to find who could take it, on another it wasn’t. While implementation was the bottleneck, the cost of this was low: a few engineers writing code in parallel were faster than one, and the gains from parallelism outweighed the blurred ownership.

Right now it is not true. One engineer with an AI agent can close the amount of work that used to need a team. But AI still can’t think for you: why do we need the feature, edge cases and what it can break. That’s why we flipped the model: each engineer has their own feature — we call it a project — from technical design through development, tests, release and monitoring. If an incident happens in production, it goes to that engineer.

The side effect is that this became the main point of growth for an engineer: Instead of “learn a new framework”, the goal turned into “deliver one project end to end”. It stopped making sense to measure lines of code and what I need to see is how much uncertainty an engineer can take on.

Not everyone accepted it. Some people feel lost: early you can see your value in the code, and now code is not fully yours, so you have to show a different kind of ability.

Why the Weekly Release Stopped Working

We did releases every week and for a long time thought it was sign of a mature company. Small releases, frequent shipping, everything by the book.

As you can guess, the problem showed up when the speed of coding increased while the release cycle stayed the same. Here is what we hit every week:

• A lot of changes went into the release and they overlapped each other. Merging branches isn’t a problem, AI can help with conflicts. The problem is that after those merges you have to be sure everything still works as expected. In a weekly release we simply didn’t have time for that.
• QA got everything in the last two days. They couldn’t check everything. They checked what they could.
• After the release we got issues. Our hotfixes broke the plans for the next week.
• The following week began with leftovers from the previous one, and so it went in circles.

A separate story about self-hosted customers. The customers provided feedback which meant more than any metrics: defects from the previous version still weren’t fixed, and we were already sending a new one. For them each release meant “check everything again” and not “new features”.

So we were delivering more often, but there was less and less trust.

The first idea was obvious and wrong one: let’s release everyday! And we discussed it seriously. But that treated the symptom. The real issue was not the number of releases, it was that nobody had time to properly check what was in them.

New Rhythm

What we did instead.

Figure 3: Photo by Quilia on Unsplash

Week A — feature week. We deploy new functionality. Everything as usual: projects close, the release goes out.

Week B — stability week. No new features in the build. None at all. This week goes to bug fixes, performance, tests, any improvements for the last build.

A few things that are more important that someone can imagine.

The type of week has to be visible
We have a release calendar where we clearly set the week type: Feature or Stability. It is not just a verbal agreement, If it says Stability, there are no new features and no arguments.

People will argue anyway
In the first cycle we ran into exactly this situation, when someone wanted to deliver a large feature during a stability week. Thanks to the mark in the calendar, the engineers pushed back easily.

A rule that has never been tested under pressure isn’t a rule

The stabilization week isn’t a buffer for overdue tasks
As soon as you say “let’s finish what we didn’t finish last time” the stability week loses its meaning. This week exists for the work that always has lower priority: a slow page, weird UX, flaky tests, architecture changes that we postponed a week ago.

Engineers now have an answer to “when will we fix it?“
There used to be a dilemma during reviews: the feature works, but the implementation isn’t ideal. Deliver it or rebuild it? Now there’s a third option: we can ship it as is and take the rework into the next stability week.

Feature flags: release and launch are two different events
Separately I should mention about thing without which this rhythm wouldn’t work at all. We started actively using feature flags.

In the general approach, “released” and “available to users” it is one event. That’s why release was risky: the code went to production and immediately became available to everyone. That’s where the stress around release day comes from, along with the attempt to verify everything over the final two days.

With feature flags these are two separate events, and you can put as much time between them as you need:

• feature is shipped on production
• it used internally for a few days
• we open the feature to a limited set of customers
• we open the feature to everyone
• at any step we can switch the flag back off

For the rhythm this means a lot: the stability week is not idle time for development. Code still ships to production even in Week B, but behind a feature flag.

One more side effect I noticed: it reduces arguments about dates. A question like “Can it be done by the release?” transformed into “Can we open the flag for us?”. The second one is a reversible decision, and that conversation is much calmer.

QA also changed their flow. The stability week for them is a week when they can investigate anything they never had time for, and write more automated tests.

What Can Be Taken

1. AI doesn’t speed up deliver. AI speeds up code creation. The bottleneck just moves: before, we couldn’t code fast enough, now, we can’t verify fast enough.
2. The unit of work has to grow. Give people a whole project!
3. The stabilization week should have its own slot in the calendar. Otherwise you keep doing exactly what you did before.

The problems that we got with AI are not new ones. AI just made everything several times faster, including the accumulation of problems. We changed the process not because AI became available to everyone, but because the old approach relied on spare time — and we don’t have that time anymore.