How Agile Went From Developer Liberation to Meeting Overload

Seventeen developers in a ski lodge

In February 2001, seventeen software developers met at a ski resort in Snowbird, Utah. They were frustrated. The way software was being built at the time was broken. Waterfall processes meant months of documentation before a single line of code was written. Requirements gathered in January were obsolete by the time development started in June. Projects ran years over schedule and delivered software nobody wanted.

These seventeen people, including Kent Beck, Martin Fowler, Ward Cunningham, Robert C. Martin, and others who had spent decades in the trenches, wrote a document that would reshape the entire software industry. They called it the Agile Manifesto.

The manifesto is remarkably short. Four values. Twelve principles. The whole thing fits on a single page. It valued individuals over processes, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The right-side items still mattered, but the left side mattered more.

It was a declaration of independence for developers. Stop drowning us in process. Let us talk to the people we are building for. Let us ship early, get feedback, and iterate. Trust us to organize our own work.

That was the intent. What happened next is one of the great ironies in the history of software.

What the manifesto actually said

It is worth reading the original values carefully, because the gap between what was written and what it became is enormous.

"Individuals and interactions over processes and tools." The developers who wrote this were pushing back against rigid, process-heavy methodologies that treated programmers as interchangeable resources. They wanted small teams that communicated directly, without layers of process mediating every conversation.

"Working software over comprehensive documentation." This was a reaction to projects that spent six months writing specifications before anyone wrote code. The manifesto argued that a working prototype tells you more than a 200-page requirements document. Ship something. See if it works. Adjust.

"Customer collaboration over contract negotiation." Instead of nailing down every requirement in a fixed contract and then arguing about scope for the next eighteen months, work alongside the customer. Show them what you are building. Let them steer.

"Responding to change over following a plan." Plans are useful, but the world changes. Requirements shift. Markets move. A methodology that cannot adapt to new information is not a methodology. It is a cage.

Every one of these values was about reducing overhead and trusting people. Less process. Less documentation. Less rigidity. More communication. More shipping. More flexibility. The manifesto was, at its core, a plea for simplicity.

Then the managers found it

The Agile Manifesto was written by developers for developers. It described how small, self-organizing teams could build better software by cutting through bureaucracy. But by the mid-2000s, something shifted. Management saw the results agile teams were producing and wanted to scale it across entire organizations. The problem was that you cannot scale a philosophy without turning it into a process. And the moment you turn it into a process, you have violated the first value of the manifesto.

Enter Scrum. Enter SAFe (Scaled Agile Framework). Enter the Certified Scrum Master industry, the two-day workshops, the consulting firms selling "agile transformations" to Fortune 500 companies at six-figure price tags. What started as a rebellion against process became the most process-heavy methodology in the history of software development.

The irony is painful. A manifesto that said "individuals and interactions over processes and tools" spawned an entire ecosystem of processes and tools. Jira boards. Story point estimation sessions. Sprint planning meetings. Sprint review meetings. Sprint retrospective meetings. Daily standups. Backlog grooming sessions. PI planning events that last two full days.

A developer working in a "fully agile" organization in 2026 can easily spend 8 to 12 hours per week in Scrum ceremonies. That is 20 to 30 percent of their work week consumed by the process that was supposed to eliminate process overhead.

The ceremony tax

Let us count the meetings in a typical Scrum sprint. A two-week sprint at most organizations includes:

Daily standup: 15 minutes per day, 5 days a week, 10 per sprint. That is 150 minutes, or 2.5 hours. In practice, "15-minute" standups frequently run 25 to 30 minutes because someone always has a blocker that turns into a group discussion.

Sprint planning: 1 to 2 hours at the start of each sprint. Often longer when the backlog is messy or priorities are unclear.

Sprint review / demo: 1 hour at the end of each sprint. Longer when stakeholders ask questions that should have been addressed async.

Sprint retrospective: 45 minutes to 1 hour. Often feels repetitive because the same systemic issues surface every sprint and never get fixed.

Backlog refinement / grooming: 1 to 2 hours per sprint. The session where the team discusses upcoming work, estimates story points, and argues about acceptance criteria.

Add it up. That is roughly 7 to 9 hours per two-week sprint consumed by Scrum ceremonies alone. This does not include ad-hoc meetings, one-on-ones, architecture reviews, or cross-team syncs. A developer's calendar can easily have 12 to 15 hours of meetings per week before they write a single line of code.

The manifesto's authors would not recognize this. They wanted to eliminate the overhead that prevented developers from doing their actual work. Instead, a different kind of overhead replaced it. The documentation burden was traded for a meeting burden. The waterfall status reports were traded for daily standups. The heavyweight process was traded for a different heavyweight process wearing a lightweight label.

Story points as surveillance

One of the most revealing mutations of agile is what happened to story points. In their original conception, story points were a relative sizing tool used by the development team to estimate complexity. They were deliberately abstract, not hours, not days, just a fibonacci-scale number that helped the team forecast how much work they could take on in a sprint.

Management turned them into a performance metric. How many story points did you complete this sprint? Why did you only finish 13 points when the team average is 21? Your velocity is trending down. We need to talk about your productivity.

The moment story points became a measurement of individual output, they stopped being useful for estimation. Developers learned to inflate estimates. A task that was genuinely a 3 became an 8 because completing an 8 looks better in the velocity report. The entire system became a game of numbers that had no connection to the actual work being done.

This is what happens when a tool designed by makers gets optimized for managers. The tool does not break visibly. It just stops measuring what it was supposed to measure and starts measuring something else entirely: compliance with the process.

What the original authors think

Several of the original manifesto signatories have spoken publicly about what agile became. Dave Thomas, one of the seventeen, has been particularly vocal. He has argued that the word "agile" was co-opted by consultants and tool vendors who stripped it of meaning. His recommendation: stop using the noun "Agile" (with a capital A) and go back to the adjective "agile" (lowercase). Be agile. Do not do Agile.

Robert C. Martin (Uncle Bob) has made similar points. The manifesto was about values and principles, not rituals and certifications. You do not need a two-day workshop and a $1,500 certificate to understand "talk to each other more and ship working software faster."

The frustration from the original authors is palpable. They built a manifesto to free developers from process overhead. Twenty-five years later, that manifesto's name is stamped on the most process-heavy methodology most developers have ever experienced.

What this means for your calendar

If you are a developer, designer, or any kind of maker working inside an organization that practices capital-A Agile, your calendar is probably full of ceremonies. If you work across multiple organizations, you are attending multiple sets of ceremonies. Client A's daily standup plus Client B's daily standup plus Client C's sprint planning. The ceremony tax compounds across every engagement.

You cannot single-handedly reform your clients' Scrum processes. But you can manage the impact on your calendar. Batch the ceremonies you can control. Protect focus time between the ones you cannot move. Use conflict detection to catch the overlaps before they become emergencies. And when someone schedules a "quick sync" on top of your only focus block of the day, have the language ready to push back: "I have a conflict at that time. Can I get the notes after?"

The original agile manifesto was right about something fundamental: individuals and interactions matter more than processes. Your calendar should serve you, not the process. If your schedule is 60% ceremonies and 40% actual work, the process has failed, no matter what label it carries.

Read the original manifesto. It is short. It is clear. And it is a useful reminder that the goal was always to spend less time in meetings and more time building things that work.

Try manyCalendars free and start defending your focus time from the ceremony tax.