At some point in the last twenty years, Agile became almost impossible to escape in software development.
There are standups. Sprint planning. Backlog refinement. Sprint reviews. Retrospectives. Story points. Velocity. Burndown charts. Jira boards.
This vocabulary is found everywhere.
And yet, after years of working in software organizations, I sometimes wonder whether we have confused being Agile with doing Agile. These are not the same.
Agile was never really about having more meetings. It was never about putting colored cards on a board, estimating every piece of work with a number, or making sure every team completes the same ceremonies every two weeks.
The original Agile Manifesto was remarkably simple. It placed individuals and interactions above processes and tools, working software above comprehensive documentation, customer collaboration above contract negotiation, and responding to change above following a plan.
Those ideas are still surprisingly relevant.
The problem is what happens when those ideas are translated into organizational processes. A principle becomes a ceremony. A ceremony becomes a checklist. The checklist becomes a policy.
And eventually, someone asks why the team isn't following the process correctly. This is where Agile can become strange.
Every morning, a group of engineers may stand in front of a board and answer three questions they have answered hundreds of times before.
Every two weeks, the same group may enter a retrospective and discuss what went well, what didn't, and how they feel about the last sprint.
Every sprint, they may estimate work using points and then watch their velocity as if it were a measurement of the team's productivity.
On paper, everything looks incredibly Agile. In practice, the team may still be struggling with communication, unclear priorities, technical debt, organizational politics, slow decision-making. So, what happened?
The interesting question is whether we are actually using these practices for the reasons they were created or whether we have turned them into organizational rituals.
A retrospective, for example, is supposed to help a team inspect how it worked and identify meaningful changes that can improve its effectiveness. That's a good practice.
But what happens when the retrospective becomes a meeting where everyone shares their frustrations, agrees that communication should improve, creates three action items, and then repeats exactly the same conversation two weeks later?
At what point does continuous improvement become continuous discussion?
And what about the daily standup?
Is it a short coordination mechanism that helps a team move work forward? Or is it a daily status report where engineers explain themselves to a manager?
What about story points?
Are they helping engineers communicate uncertainty and complexity? Or have they quietly become a productivity metric?
And Jira?
Is it helping the organization make better decisions?
Or have we simply created a very sophisticated database of everything the organization has ever wanted to do?
These are the questions I want to explore in this series.
Not “Is Agile good or bad?”
But instead: At point does an agile practice create value, and at what point does it just become a ritual?
There is a difference between a team using a process because it helps them and a team following a process because the organization expects them to. There is also a difference between criticizing a practice and understanding why it exists in the first place. The goal isn't to throw Agile away. The goal is to go back to the problem each practice was supposed to solve and ask whether it is still solving that problem for us.
Because sometimes the answer is yes. Sometimes the answer is no. And sometimes the most Agile thing a team can do is stop doing something simply because someone once decided it was Agile.
Dive Deeper: Read the full, unabridged article on Agile: The Theory, the Ritual, and the Reality.
