February 11-13, 2001. Snowbird, Utah. The Lodge at Snowbird ski resort, specifically the Aspen Room.
Seventeen software developers showed up. Not to create a movement. Not to launch a revolution. Just to talk about the fact that the way everyone was building software was completely broken.
They called themselves “lightweight methodologists” because they were trying to escape the nightmare of waterfall. You know waterfall. That Industrial Revolution relic where you spend six months planning, six months documenting, six months building, and then find out the customer needed something completely different.
These seventeen weren’t theorists. They were practitioners. Kent Beck (Extreme Programming). Ken Schwaber and Jeff Sutherland (Scrum). Martin Fowler. Alistair Cockburn. Ward Cunningham. People who were actually in the trenches, shipping software, and figuring out better ways to do it.
And they weren’t even sure they could agree on anything. Alistair Cockburn said later, “I personally didn’t expect that this particular group of agilites to ever agree on anything substantive.”
But they did. In that room, they wordsmithed a 68-word statement to complete unanimity. Four values. Twelve principles.
What emerged was the Manifesto for Agile Software Development.
And then we spent the next 23 years systematically destroying everything it stood for.
What They Actually Said (And What It Actually Meant)
Let’s be clear about what the Manifesto says, because I’m willing to bet most of you haven’t actually read it in years.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:
- Individuals and interactions OVER processes and tools
- Working software OVER comprehensive documentation
- Customer collaboration OVER contract negotiation
- Responding to change OVER following a plan
Then comes the part everyone forgets:
“That is, while there is value in the items on the right, we value the items on the left more.”
Read that again.
They didn’t say processes and tools are bad. They didn’t say documentation is the enemy. They didn’t say planning is useless.
They said we value the things on the left MORE than the things on the right.
It’s not either/or. It’s a priority. It’s where you put your energy.
But that nuance got lost about five minutes after SAFe showed up and companies started slapping “Agile” on their org charts while changing absolutely nothing about how they actually worked.
The Weekend Certification That Killed Scrum
Want to know when Scrum died?
When you could get certified in two days.
“Scrum Master” became a checkbox on a resume instead of someone who actually understood what they were doing.
When companies hired “Agile Coaches” whose entire qualification was binge-watching YouTube videos and attending a weekend workshop.
I’ve watched organizations bring in these certified experts who then implement Scrum by adding more meetings, more process, more overhead, and then wonder why the team moves more slowly than before.
You want to know what killed Agile? We did. We took a philosophy built on trust, autonomy, and empowerment and turned it into a cottage industry of certifications, frameworks, and consultants selling snake oil.
Let’s Talk About The Principles (And Be Honest About Whether You’re Living Them)
The Manifesto has twelve principles. Most teams can remember maybe three.
So let’s go through them. And let’s be brutally honest about whether you’re actually following them or just pretending.
Principle 1: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Is that really your highest priority?
Or is your highest priority hitting some arbitrary date that management set six months ago based on nothing but wishful thinking and a PowerPoint deck?
I bet most of you have a Project Manager (which shouldn’t even exist in Scrum) trying to keep you on some Gantt chart schedule instead of actually trending velocity and delivering value incrementally.
Early and continuous delivery means shipping working software every sprint. Not “feature complete” at the end of Q3. Not “code freeze before the big release.” Working software. Every two weeks.
If you’re not doing that, you’re not Agile. You’re just waterfall with standups.
Principle 2: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Oh, this one’s my favorite.
Because most teams treat changing requirements like a personal attack. The business changes its mind, and the dev team acts like they’ve been asked to rebuild the Titanic out of popsicle sticks.
Agile was built for change. That’s the entire point.
If your process can’t handle the customer saying “actually, we need this instead” two weeks before the release, then you’re not Agile. You’re fragile.
Principle 3: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Preference for the shorter timescale.
Not “let’s do six-week sprints because planning is hard.” Not “we’ll ship when it’s ready.” Two weeks. Maybe a month if the work genuinely demands it.
If you’re running four-week sprints because you can’t be bothered to break down the work properly, you’re lazy.
Principle 4: “Business people and developers must work together daily throughout the project.”
Daily.
Not in a quarterly business review. Not in a steering committee meeting once a month. Daily.
How many of your developers have direct access to actual customers or business stakeholders?
If the people building the thing can’t talk to the people using the thing, you’re not Agile.
Principle 5: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Trust them.
Don’t micromanage them. Not track their every keystroke. Do not make them fill out timesheets and status reports. Trust them.
If you’re measuring productivity by lines of code or hours logged, you’ve completely missed the point.
Give people the environment and support they need. Then get out of their way.
Principle 6: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
This one aged poorly in the remote work era, but the principle still holds.
Real-time conversation beats asynchronous documentation every single time.
If your team is spending more time updating Jira tickets than actually talking to each other, something’s broken.
Principle 7: “Working software is the primary measure of progress.”
Not velocity points. Not burndown charts. Not story completion percentage.
Working software.
Can a user actually use it? Does it solve a real problem? That’s progress.
Everything else is just theater.
Principle 8: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Sustainable pace.
Not crunch mode every sprint. Not “we’ll fix the technical debt later.” Not burning people out to hit some deadline that only existed because someone made a promise without talking to the team first. Not, increase velocity 10% every quarter.
If your team is working 60-hour weeks, you’re not Agile. You’re just abusive.
Principle 9: “Continuous attention to technical excellence and good design enhances agility.”
Technical excellence.
Not “ship it now, fix it later.” Not “we don’t have time for tests.” Not “we’ll refactor someday.”
Good design and technical discipline make you faster. Not slower. Faster.
If your team is constantly fighting fires because the codebase is held together with duct tape and prayer, you’ve failed this principle spectacularly.
Principle 10: “Simplicity, the art of maximizing the amount of work not done, is essential.”
Maximizing the amount of work NOT done.
This might be the most misunderstood principle of all.
It’s not about doing less work. It’s about not doing work that doesn’t matter.
How much of your backlog is actually necessary? How many features are you building that nobody asked for? How much complexity are you adding that solves problems you don’t have?
Simplicity is a discipline. And most teams suck at it.
Principle 11: “The best architectures, requirements, and designs emerge from self-organizing teams.”
Self-organizing teams.
Not teams that get their architecture handed down from some Chief Architect who hasn’t written code in a decade.
Not teams that have to run every design decision through a review board.
Emerge. From the team. Who’s actually doing the work?
If you have architects outside the team making decisions for the team instead of with the team, you’re not Agile.
Principle 12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Retrospectives matter.
But not the performative kind where everyone says “sprint went great!” and nothing changes.
Real reflection. Real adjustment. Real improvement.
If your retros are just a box to check before you sprint plan, you’re wasting everyone’s time.
SAFe Killed The Dream
Let’s talk about SAFe for a second.
Scaled Agile Framework. The thing every enterprise adopted because it promised to make Agile work at scale.
SAFe took the Agile Manifesto and turned it into a 500-page process manual with roles, ceremonies, artifacts, and enough acronyms to make the Department of Defense jealous.
It violates every single principle.
It adds layers of management. It creates dependencies. It enforces rigid planning cycles. It turns “responding to change” into “change management processes.”
SAFe isn’t Agile at scale. It’s waterfall wearing an Agile Halloween costume.
And yet every Fortune 500 company I’ve worked with has adopted it. Because it makes executives comfortable. Because it looks like control. Because it lets them pretend they’re being Agile while changing nothing fundamental about how they operate.
The Problem With Paired Programming
Let’s talk about one more thing while we’re here: paired programming.
The principle is sound. Two people working together produce better code, catch more bugs, and share knowledge.
But organizations look at it and see “two developers burning one hour of productivity.”
So they kill it. Because the math doesn’t work on their spreadsheet.
Never mind that code quality improves. Never mind that knowledge spreads across the team. Never mind that onboarding gets faster and technical debt decreases.
Two people, one keyboard. Looks inefficient. Cut it.
That’s how you know they don’t actually understand Agile. They’re optimizing for the wrong metrics.
What We Lost
The Agile Manifesto wasn’t about standups, story points, or sprint planning.
It was about people. About trust. About empowering teams to make decisions and solve problems.
It was about delivering value early and often, rather than spending months building the wrong thing.
It was about embracing change rather than treating it as failure.
And we turned it into a certification mill, a process framework, and a way for consultants to make money.
We nested it inside PMOs. We hired Scrum Masters who’ve never shipped software. We created Agile Coaches who watched YouTube instead of actually doing the work.
We took something organic and alive and turned it into bureaucracy.
The Practice Still Works (When You Actually Do It)
But you know what? The core idea is still sound.
Self-organizing teams delivering working software in short cycles, staying close to the customer, embracing change, and maintaining technical excellence.
That still works. That’s still the best way to build software.
It’s just that almost nobody’s actually doing it.
They’re doing Scrum theater. Agile cosplay. Process compliance masquerading as empowerment.
So What Now?
If you actually want to be Agile, try this:
Read the Manifesto. Not the blog posts about it. Not the frameworks built on top of it. The actual 68-word statement.
Read the twelve principles.
Then sit with your team and ask yourselves honestly: Which of these are we actually living?
Not which ones do we say we value. Which ones are we actually doing.
Is your highest priority really customer satisfaction through early and continuous delivery? Or is it hitting the schedule?
Are your best architectures really emerging from self-organizing teams? Or is some CAO making decisions for you?
Are you really welcoming changing requirements? Or does the business feel like they’re negotiating a hostage release every time they need something adjusted?
Be honest. Be brutal. Because if you’re not actually practicing these principles, you’re not Agile.
You’re just pretending. And pretending doesn’t ship software.
The Bottom Line
Scrum didn’t fail because the framework was bad.
It failed because we certified people who didn’t understand it, adopted frameworks that violated it, and turned it into a process rather than a philosophy.
Agile isn’t dead because the ideas were wrong. It’s dead because we killed it.
We added the PMOs, layers, certifications, coaches, frameworks, and governance.
We took “individuals and interactions over processes and tools” and built an entire industry of processes and tools.
And now we sit in our three-hour sprint planning meetings, update our Jira tickets, and wonder why everything takes so long.
The Manifesto still works. The principles still hold.
We just stopped following them.
Related:
- The Agile Manifesto
- Twelve Principles of Agile Software
- Mixing Generations Creates Better Solutions
- Why Predictable Leaders Build Better Teams
Which principle does your team violate the most? Drop a comment. Let’s talk about it.
Want more unfiltered insights on leadership? Check out my book, Beyond Management: A Field Manual for Real Leadership.