The Agile Manifesto

Why do so many teams fail to achieve real agile development?

Because agile places very high demands on people.

• “Individuals and interactions over processes and tools” means the team needs aligned language and aligned understanding. Ideally, I only say half a sentence and you already know the other half.
• “Working software over comprehensive documentation” means the team must know the codebase well enough that the lack of documents does not make everyone nervous.
• “Customer collaboration over contract negotiation” means the team must understand the requirement, know what the customer says, and also know what they really want behind those words.
• “Responding to change over following a plan” means the team must be able to execute quickly without falling apart in an unknown space.

At bottom, all of these statements mean the same thing: team members need a relatively consistent level of business capability, technical capability, and collaboration capability. Ideally, one look is enough and I already know whether you want to create an interface, refactor an implementation, cut scope, or change the design.

That is a very high bar.

Agile engineering practices

If you look at the signatories of the Agile Manifesto, that makes sense. They probably did have that level of capability and shared understanding.

But the reality is that you cannot hire Martin Fowler or Kent Beck from the open market, and you definitely cannot clone yourself to build a team that shares the same brain waves.

That is why we need all kinds of agile ceremonies: Standup, IPM, Sprint Review, Retrospective, Backlog Refinement. We also need technical practices: Pair Programming, TDD, refactoring, and Code Review.

Of course, these ceremonies are also what people often criticize when they talk about “fake agile”: standups become status recitals, reviews become management shows, retros become complaint sessions, pairing becomes staged performance, and code review turns into group nitpicking.

That is because, in essence, all of these activities exist to achieve the high requirement inside the Agile Manifesto: shared understanding and shared capability.

• Lower the upper bound of task complexity. Backlog Refinement and IPM do requirement analysis and task decomposition first. Then all kinds of meetings synchronize information and pass context around, so people do not fill the gaps with their own imagination and end up producing five different versions.
• Raise the lower bound of team capability. Pairing, mentoring, sharing, and Code Review are basically talent-system work. They help new teammates get close to the team's average capability faster instead of forcing a few veterans to carry everything.

Only after pulling both ends toward the middle can you talk about the next layer: iterative delivery, estimation, free card picking, Trunk-Based Development, and using automated testing to replace part of Code Review.

Agent as colleague

The capability of an Agent still depends on the capability and skill of the person using it. Whether you ask clearly, decompose well, and write constraints explicitly makes a huge difference.

Just like with people, you need to train it, cultivate it, and even manage it. You need to let it know what counts as a good result and what counts as a bad result. You need to let it know which behaviors are encouraged and which are forbidden. You need to let it know which goals matter most and which matter less.

Agents also have two characteristics that human colleagues do not.

One is that their capability can be replicated at scale. Multi-Agent and Sub-Agent setups can run in parallel. You are not just getting one more assistant. You are getting a small squad that can be assembled on demand.

The other is that their capability can be acquired almost instantly. Skills are plug-and-play. You do not need to wait through onboarding. Add a Frontend Skill, and it can immediately help write React components.

If you look at Agents as team members, you start to notice that they are naturally close to what agile needs: shared understanding and shared capability, plus horizontal scaling and vertical upgrades.

• “Individuals and interactions over processes and tools” — in a sense, this really does become chat with agent.
• “Working software over comprehensive documentation” — the agent will read your code, and usually read it very carefully.
• “Customer collaboration over contract negotiation” — you do not need contract negotiation. You are the demand side yourself.
• “Responding to change over following a plan” — you can change your mind at any time, and it can rerun with you.

200x??

Last month, I used Agents to rewrite an internal tool. In the final estimate, a team composition of 1 human + 3~5 Agents produced an efficiency gain close to 200x.

That number looks exaggerated in isolation. It sounds like clickbait from a course-selling account.

But if you treat those Agents as real teammates you can collaborate with, it becomes less mystical. It is basically a six-person full-function team: one PO/BA plus five developers/testers.

Once you break it down that way, the average is around 30x.

Then there is still a lot of time that used to be consumed by default and is now saved: meetings, training, context synchronization, waiting for people, finding people, rest, lunch. Silicon-based life forms only eat electricity, not takeout.

Average it again, and maybe it is closer to 10x — a level top engineers can reach.

So Agents are not just fast code writers. More importantly, they work in a team-shaped way. Their efficiency gain comes from amplifying human capability across multiple dimensions: execution, collaboration, and learning.

If you are interested in the rewrite process, you can also read my earlier post From Months to One Week: The Governance Loop for Agent Coding.

ThoughtWorks

ThoughtWorks is an excellent company. In many ways, it feels more like a university.

Looking back now, the typical growth path inside ThoughtWorks was to become a “Thought Worker”: analyze first, think second, and only then write code.

Back then we cared a lot about agile and the training that came with Pair, TDD, and DDD. Every day involved modeling, analysis, evaluation, and many frameworks and methods.

For a period of time, I also wondered: why spend so much time on things that do not look directly related to writing code? Wouldn't straightforward CRUD be enough?

Now I see it differently. Those capabilities determine the size and quality of the Agent team you can lead.

As a Tech Lead, even if your individual capability is very strong, that still does not mean you can stably deliver 10x more than others by yourself.

Whether you can define the problem clearly, break it down well, identify boundaries and risks, and turn fuzzy requirements into stable constraints — those things determine whether you can lead a 10x team.

• Pair, TDD, and DDD train communication and collaboration, boundary recognition, and abstraction modeling. Agile trains feedback and adjustment.
• Even the old “blog competition,” in hindsight, trained more than writing. It trained expression: the ability to explain what is in your head clearly. Today, that is a required skill for communicating accurately with Agents.

In a sense, “one person leading eight” has now been realized in a different dimension.