Agile: Rise, fall and what remains
The first thing a new manager might hear when they start is that they need to “understand Agile.” The phrase becomes so ingrained that it creates a feedback loop where pursuing “Agile” becomes the goal itself. Processes are evangelized, and an entire industry of consultants creates a mysticism around frameworks, selling a version of Agile that is rigid, prescriptive, and dogmatic…
… Which is precisely the opposite of the original idea of Agile.
Why Agile got popular in the first place
The Agile Manifesto was born in an era when shipping software meant checking boxes. The process was dictated by a "Software Requirements Specification" (SRS), a massive document often drafted by people far removed from the actual work. It served as a rigid contract, locking in every detail upfront. This was so much the default way of building software that it is still taught in some colleges nowadays.
For developers, this meant almost zero freedom. When they discovered a better technical approach or the first users felt that the tool wasn't fulfilling their needs, the plan couldn't adapt. The focus was on ticking boxes, not solving problems. This led to a graveyard of failed projects, massive budget overruns, and software that no one wanted.
The Agile manifesto came to change that. It did not come as a complex rulebook, just four headline values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Each line was a direct challenge to the old way:
- Individuals and interactions meant trusting creative people to solve complex problems, not forcing them to follow a rigid, pre-scripted workflow.
- Working software declared that the main measure of progress is a functioning product and customer feedback, not a 40-page document elaborated by a person who purchased the software (many times, not even close to the final user).
- Customer collaboration replaced a one-time contract negotiation with a continuous conversation, ensuring the final product meets the customer's needs.
- Responding to change was the ultimate goal, enabled by the other three values. It embraced the reality that we learn as we build.
Enter the Consultants: The Cargo Cult Era
The manifesto worked. Agile became popular. Then, corporations tried to adopt the practices without the principles. This ushered in the era of "Cargo Cult Agile." Like the islanders in the famous myth who built bamboo runways hoping to attract cargo planes, companies adopted the rituals of Agile, the stand-ups, the sprints, and the story points, believing the process alone would bring them results and make them Agile.
An "Agile Industrial Complex" of consultants and certification bodies commercialized the movement, selling it as a purchasable product. They created "certified" practitioners who knew the Scrum ceremonies but had no idea why they existed.
This is the reality most teams experience today. They perform the rituals without purpose. They have stand-ups, retrospectives, and Jira boards, but no real problems are solved because the team cannot change the system.
Agile is Not Scrum!
It is critical to understand that Agile is a philosophy, Scrum is a prescriptive framework, and the way Scrum is often implemented betrays Agile's core values.
In its worst form, Scrum time boxes work into a rigid sprint where nothing can change. The "Scrum Master" devolves into a ticket administrator. The end-of-sprint retrospective becomes a ceremony for discussing why the team failed at predicting the future.
This rigid implementation directly violates "responding to change." It becomes a game of measuring how good you are at predicting work, not how effective you are at shipping value. This is why many of the world's most effective software companies have moved beyond dogmatic Scrum, dropping roles like "Agile Coach" and rediscovering the core principles.
Reclaiming Agility
So, how do we escape the cargo cult? By returning to the principles. Modern, effective teams often use hybrid approaches that blend elements of Scrum and Kanban—for example, running continuous-flow Kanban boards inside Scrum events or adopting variants like Scrumban—so they keep clear goals while preserving flow-based flexibility.
The way your team does this flow will need to come from the team itself, not from outside consultants who don't even know how you operate. That is why the manager needs to be technical and empowered to change the process.
An ideal Agile process is one where:
- You focus on outcomes, not output. You define a goal: "What is the key customer value we want to deliver in the next two weeks?" The focus is on solving a real problem, not just closing tickets, which are the means.
- You maintain flexibility. The plan serves the team, not the other way around. High-priority work can be pulled in when it makes sense. This truly honors the "responding to change" value.
- Your retrospectives become forward-looking. They are not about assigning blame for a failed estimation. They are about the team identifying real bottlenecks and gaining the power to fix them.
- You invest in technical excellence. This is the foundation. True agility is impossible on a shaky foundation. Practices like automated testing, continuous integration (CI/CD), and proactively paying down technical debt allow a team to move fast and sustainably.
Agility isn't a process you buy. It's a culture you build, founded on trust, communication, and a relentless focus on delivering value.