Saying goodbye to Agile

Not the op, but you only commit to what you already did in this sprint.

So this sprint shows what you delivered 2 sprints ago, next sprint will be the work you just finished.

I watched a video a few years ago where one of Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber, I don't remember who exactly, explained what they wanted to do with the Agile Manifesto, what screwed up. He explained that they wanted to give guidelines, not a strict rules. They wanted flexibility. But people started selling this as courses, business, rules. Some Agile practitioners become fanatics on the topic. And this created misunderstanding and chaos :D

For 20 years, I have seen it working and not working, and the reasons are a lot. It can be affected of level of expertise, quality of documentation, pressure from management, engagement of the clients, etc.

Simple example of failing, and how one of my team overcome it. There is no specification. Option 1: team complains that the specification is bad, and this makes the code quality bad. Option 2: the team pro-actively prepared the specifications, gave them to the client for approval. Writing the specification was, a kind of, added flexibility, that was introduced in the sprints.

Another example, why should the sprints be fixed at 2 weeks. Sometimes, people try to finish for two weeks and they produce bad quality code, because they are time pressured. Be flexible and make them 3 weeks, if the sprint includes things like, preparing specifications, or if the sprint includes pauses for bug fixing. :)

So it is not the Agile that makes the project successful, it is the people. Agile just help for tracking where you are , and what you need to do ;)

Now with AI, you can use Agile again, there are agentic frameworks that support it and they give good results, in my opinion. If the people use it wisely, think what they do, and try to do things better, it will work. Of people are lazy, don't know what they are doing, don't have expertise on software development, it will fail :)

> […] when applied to small, excellent teams.

Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.

That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers.

I don't really have a better answer, though…

Still though, that cycle can be iterated many times in a single day. Write a spec, let the agent build it, use the software, evaluate results, repeat.

A requirement specification is how you prompt software engineers. One-shotting it doesn't work (waterfall). You need to put the SEs in planning mode. They will ask you questions and refine the plan. And you end up with a better plan. But if you make it too complicated the plan will go off the rails. So, you need to make them assign Fibonacci tokens to their planned tasks. Now you have a better plan and you can assign your SEs to tasks and get them working on it. Fibonacci tokens are not time units. This is very important. But you will run out of tokens after two weeks. So you need to buy some extra pizza tokens and make them work until midnight (crunch time!). That's how you get the job done. Every time. Sort of.

I bet some jerk is going to organize a multi agent scrum process at some point and burn some tokens on this nonsense.