The End of Agile Development: When Two-Week Sprints Meet Two-Hour Solutions
The bottleneck in software development is no longer coding. Often there was a process called agile development on software teams whereby a team would give daily updates on progress and show results every two weeks in what was called a sprint meeting. At this meeting the results of coding would be displayed. Then the first thing the following week would be a planning meeting to start the cycle all over again.
That whole approach is dead. Or in cases where people's jobs depend on that process, slowly dying.
It's hard for me to know what process will replace agile development, but I can guess based on what we're experiencing with VEVE and seeing reflected in software development teams worldwide.
The Three Fundamental Shifts
1. Two weeks is too long. Too long by about two weeks.
Sincerely, what I used to expect of my development team in two weeks can be done in 2 hours by Claude Code.
2. Customer feedback is the new bottleneck.
When they're asked to join a development meeting every two weeks, it's easy to get customers to do as you ask. When you're done with an iteration in a day, then will customers be there on a meeting daily? I don't think so. And that sucks.
3. Product pipelines are as valuable as ever.
Going from idea to production has a few steps in between. All those steps still matter and having them be explicitly defined still matters. The developer in me hates them, but the hate fades whenever my work moves to production.
What Comes Next?
My best guess is that we will need to be rethinking the role of process together as an industry. The ego in all of us who are professionally the best on the team at pressing the buttons will need to be put in check. Just because we can deliver something in 2 hours that used to take 2 weeks doesn't mean we are delivering something useful.
We need customer feedback, we need product thinking, architectural design, usability considerations. I guess if engineers can hold themselves accountable then they can handle all those jobs themselves, and I guess if the people who held those other jobs before can stand the adaptation period and learning period, they can do the software engineering job.
The question isn't whether this change is coming—it's already here. The question is how we adapt our processes, our teams, and our expectations to this new reality where the constraint has shifted from "can we build it?" to "should we build it?"