The Myth of Process

How Agile/Scrum drifted from their origins

Agile began as a rebellion.

In 2001, the Agile Manifesto called for something refreshingly simple: small teams working closely with users, delivering working software frequently, adapting as they learned, and valuing collaboration over documentation.

Scrum began in a similar spirit.

It emphasized tight feedback loops, cross-functional teams, and lightweight structure—just enough process to keep a team aligned, not enough to slow them down.

But over the years, something changed.

Process grew faster than products.

As Agile spread into large organizations, a cottage industry emerged around it: certifications, frameworks, tools, consultants, trainers, coaches. What started as an antidote to heavyweight process became, ironically, a new source of process.

Agile in practice often accumulated:

• Layered roles (product owner, scrum master, agile coach)
• Complex tools (Jira boards, workflow states, velocity charts)
• Fixed ceremonies (standups, sprint planning, retros, grooming)
• Heavy artifacts (user story templates, acceptance criteria, epics)

These weren’t part of the original manifesto—they were created to enforce compliance rather than enable momentum.

The result was predictable: Agile became more about managing the process than improving the product.

Sprints replaced continuous learning.

The sprint structure—originally intended as a way to limit scope—became a rigid metronome that teams were expected to obey, regardless of context.

Instead of shipping as soon as something worked, teams shipped when the sprint ended. Instead of learning continuously, they learned every two weeks—if at all. Instead of breaking work down naturally, they did it to fit the sprint.

The sprint became the unit of truth, not the product.

Tickets replaced conversations.

Agile’s founders imagined teams working closely, sharing context freely. But as teams scaled and remote work grew, tools became the intermediary.

User stories, subtasks, acceptance criteria, definition-of-done checklists—these replaced the lightweight collaboration Agile originally championed.

What was meant to reduce documentation created more documentation. What was meant to clarify work often abstracted it into tiny, disconnected pieces.

Velocity replaced value.

Metrics meant to help teams became numbers to hit. Velocity became a KPI. Estimates became commitments. Teams optimized for predictability instead of impact.

This shift prioritized outputs—tickets closed, points burned—over outcomes.

Scrum ossified into ceremony.

Scrum was once an adaptable framework. Over time it became dogma:

• “You must have these events.”
• “You must have these roles.”
• “You must track these metrics.”
• “You must operate in sprints.”

The emphasis on strict adherence overshadowed the original goal:

help small teams deliver great software quickly.

What was lost

• The fluidity
• The speed
• The trust in small teams
• The belief that working software is the measure of progress
• The creativity of iterating directly inside the product

Agile didn’t fail. Scrum didn’t fail. But their real-world implementation drifted far from the mindset that made them powerful.

Build First is, in many ways, a return to the original promise.

• Lightweight
• Pragmatic
• Centered on working software
• Trusting small teams
• Discovering through building
• Valuing momentum over ceremony

Where Agile and Scrum became processes to follow, Build First is a way of thinking—a simple, modern expression of what made Agile great before it became an industry.