The Age of Agile
We live in the agile age in the tech world. It traces back to the Agile Manifesto in 2001 - almost 24 years ago. In those formative years, startups used agile techniques to ship products quickly, fail fast, and fail forward. That’s how you build good software. Revolutionary in the age of waterfall where companies would take years to develop some fully fledged program before going to market.
By reducing the time between idea inception to the idea being in people’s hands, the feedback loop could start quicker. Only focus on core critical functionality and see whether the market even fucking wants what you’re selling. Less capital required, so it makes sense for startups. It’s still used today as a guiding light for any aspiring startup founder: be AGILE! Fail fast and fail often, intending to fail into a winning product with market fit.
Who wouldn’t want that?! It got us Google, Uber, Amazon, and a host of other unicorn companies. WHO DOESN’T WANT TO BE A UNICORN?
The agile methodology is outlined in 4 key tenets articulated in the manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Embodying these 4 tenets will make you agile.

But when you look closely not all agile is made the same. When large corporations saw Google’s success, they wanted in. But here’s the problem: the Agile Manifesto is just a website with 4 tenets and 12 principles. That’s not enough for a corporate procurement committee. They need frameworks, training programs, certifications, consultants, and a roadmap they can present to the board.
Enter SAFe.
The SAFe Corporate Solution
What SAFe Promises
Picture this: You’re a VP at a Fortune 500 company. Your board is breathing down your neck asking “How are we Agile in this modern age?” You can’t just point at a manifesto and say “we’re doing it.” You need proof. You need metrics. You need someone to blame when it doesn’t work.
SAFe (Scaled Agile Framework) promises to be your salvation. It’s packaged, it’s professional, it’s got whitepapers and case studies. Most importantly, it can scale across your entire enterprise. Finally, an agile framework that can handle your 5,000-person engineering org!
The consultants arrive, fresh from their $995 SAFe certification courses. They’ll transform your company from an ancient lumbering monolith of waterfall to a nimble agile… puma? Rawr? They’ve got frameworks within frameworks. Agile Release Trains! Value Streams! Solution Trains! Program Increment Planning! It’s agile, but SCALED!
And for the shareholders, they’ve created beautiful new roles: Release Train Engineers, Solution Train Engineers, Epic Owners, Value Stream Coordinators. Look at all this structure! This must be professional. This must work.
Let’s huff some hopium and get into that shareholder mindset.
Building Blocks of SAFe
Story Points - The atomic unit. Teams estimate effort in points (could be hours, days, or how many fucks to give). Some teams use planning poker, others let one engineer guess. I use the binary system: 69 for quick tickets, 420 for the existential mindfuck variety.
Sprints - Two-week chunks where teams deliver work. Daily standups keep everyone “aligned.” In theory, this creates focus. In SAFe, it creates coordination overhead.
Program Increments (PI) - Here’s where SAFe really shows its hand. Every 8-12 weeks, you have PI Planning: a two-day ceremony where everyone involved in the Agile Release Train (teams, product owners, architects, managers, the guy who fixes the coffee machine) sits together to plan the next quarter.
Two. Full. Days.
Not working. Planning.
Every three months.
But wait, there’s more! Between PIs you have:
- Scrum of Scrums (weekly sync across teams)
- PO Sync (product owners coordinating)
- ART Sync (the whole train aligning)
- System Demos (showing work every two weeks)
- Inspect & Adapt workshops (at the end of each PI)
SAFe has taken the agile idea of “coordinate when needed” and turned it into “coordinate constantly whether you need to or not.”
Let me be clear: this isn’t just regular corporate meeting bloat. This is prescribed by the framework itself. SAFe doesn’t just allow this bureaucracy - it requires it.
The Reality: Death by a Thousand Ceremonies
Time for some pedantic minute counting! We have 8 work hours a day. 40 work hours every week, ~80 work hours per sprint, and ~480 work hours per Program Increment (12 weeks).
Let’s add up the SAFe ceremonies:
Daily:
- Standup: 15 minutes (but actually 30 because Timmy talks about his dog)
- Random “alignment” conversations spawned from standup: 15 minutes
Weekly:
- Backlog refinement: 1.5 hours
- Scrum of Scrums: 1 hour (if you’re the scrum master)
- Team sync with PO: 30 minutes
Every Sprint (2 weeks):
- Sprint Planning: 2 hours
- Sprint Review: 1 hour
- Sprint Retrospective: 1 hour
- System Demo: 1 hour
Every PI (12 weeks):
- PI Planning: 16 hours (2 full days)
- Inspect & Adapt: 4 hours
Let’s do the weekly average:
Daily ceremonies: (45 min × 5 days) = 225 min = 3.75 hours
Weekly ceremonies: 180 min = 3 hours
Sprint ceremonies per week: (5 hours / 2 weeks) = 2.5 hours
PI ceremonies per week: (20 hours / 12 weeks) = 1.67 hours
Total per week: 10.92 hours
(40 hours) - (10.92 hours) = 29 hours left
And I’m being generous. This doesn’t include:
- The mandatory training workshops on SAFe itself
- Architecture discussions
- Dependency management meetings (because SAFe creates dependencies)
- The impromptu “quick syncs” to clarify what was discussed in the last meeting
- That one-on-one where your manager asks why velocity is down
But here’s where it gets worse. As an international team, standup isn’t at 9am - it’s at 10am to accommodate everyone across time zones. That leaves a one-hour window before lunch where you can’t sink your teeth into any real problem. You finish standup at 10:30, grab coffee, chat with colleagues, and suddenly it’s 11. Lunch is at 12.
That “essential” standup just killed your entire morning. You’re left with 20 hours of afternoon time.
You get back from the Thai place that absolutely slaps (but also slaps you with that food coma). Now you’ve got 1pm-5pm. Four glorious hours to code, right?
Wrong.
That Scrum of Scrums meeting is Wednesday at 2pm. PI Planning prep is Thursday afternoon. The System Demo is Friday at 3pm. Your actual coding time gets fragmented into 1-2 hour chunks scattered throughout the week.
According to Cal Newport’s research on deep work, engineers need 2-4 hour uninterrupted blocks to accomplish anything meaningful. When you fragment your week into hour-long chunks between meetings, you’re lucky to get two solid deep work sessions per week.
That’s 8 hours out of 40. A 20% efficiency rate.
And we wonder why engineers sandbag estimates.

The Great Betrayal: How SAFe Violates Every Agile Principle
Remember those 4 tenets from the Agile Manifesto? Let’s see how SAFe measures up:
Individuals and interactions over processes and tools
SAFe says: Follow the framework. We have defined roles (Epic Owner, Release Train Engineer, Solution Train Engineer, Product Owner, Product Manager, System Architect, Business Owner), defined ceremonies (listed above), and defined artifacts (PI Objectives, Features, Enablers, Architectural Runway).
When you raise a concern, people don’t ask “what do you need?” They ask “what does the framework say?” Want to adjust how your team works? Sorry, that’s not aligned with the SAFe model.
The framework becomes scripture. Individuals and their interactions are secondary to following the process correctly. SAFe has literally created a process fetish while claiming to be Agile.
Verdict: SAFe chooses processes over people. Complete violation.
Working software over comprehensive documentation
SAFe says: Every PI needs:
- PI Objectives (written, estimated, scored)
- Program Board (physical or digital, showing all dependencies)
- Risk Register (documented)
- Team Breakout sessions (documented)
- Architecture Runway documentation
- Solution Context documentation
- Weighted Shortest Job First (WSJF) scores for everything
Before the PI even starts, you’ve spent two days in a conference room with whiteboards, sticky notes, and documentation. You’ve planned three months of work in excruciating detail. You’ve identified dependencies, risks, and mitigation strategies.
This is waterfall. This is exactly what Agile was supposed to replace.
Sure, you still ship software every sprint. But the ratio of planning-to-doing has flipped. In true Agile, you plan just enough to start, then adjust. In SAFe, you plan everything, then scramble to adjust when reality doesn’t match the plan (which it never does).
Verdict: SAFe demands comprehensive documentation before and during delivery.
Customer collaboration over contract negotiation
SAFe says: Here’s the fun part. In SAFe, your “customers” are often:
- Business Owners (internal executives who fund the train)
- Product Management (who write epics and features)
- Other teams in your value stream (who need your APIs)
PI Planning becomes contract negotiation. Teams commit to PI Objectives and give them confidence scores. Business Owners assign business value. At the end of the PI, your “actual” is measured against your “committed.” If you miss your commitments, it’s tracked. If you miss too many, it affects planning for the next PI.
This isn’t collaboration. This is a quarterly commitment ceremony where teams are pressured to commit to more than they can deliver (because that’s what the business owners want), then judged on their ability to meet unrealistic goals.
The real customer, the person using your software, is so many layers removed from this process they might as well not exist. You’re building features because they scored high on WSJF and fit into the PI plan, not because users are begging for them.
Verdict: SAFe prioritizes internal commitments over customer collaboration.
Responding to change over following a plan
SAFe says: You plan 12 weeks of work in advance. Every team, every dependency, every risk. Then you commit to it publicly in front of business owners.
What happens when priorities change in week 3? “That’s a great idea, let’s discuss it in PI Planning for next quarter.” What happens when a customer emergency comes up? “We’ll have to descope something else to maintain our PI commitments.”
The whole point of Agile is to embrace change. Ship small, get feedback, adjust course. SAFe’s quarterly planning cycles make course correction expensive and politically fraught. You can’t just pivot - you have to renegotiate with other teams, update dependencies, revise PI Objectives, and explain to business owners why you’re breaking commitments.
In practice, teams become prisoners of the plan. They spend more energy defending their PI commitments than they do responding to actual user needs or market changes.
Verdict: SAFe prioritizes following the plan over responding to change.
Four for four. SAFe violates every single core principle of the Agile Manifesto. It has taken the word “Agile” and used it to sell the exact opposite: a heavyweight, process-driven, documentation-heavy, commitment-based, change-resistant framework.
It’s not Agile. It’s waterfall with standups.
The Business Model: Why SAFe Exists
Here’s the uncomfortable truth: SAFe exists because it’s profitable, not because it works.
The Certification Industrial Complex:
- SAFe Agilist (SA): $995
- SAFe Practitioner (SP): $795
- SAFe Scrum Master (SSM): $995
- SAFe Advanced Scrum Master (SASM): $1,295
- SAFe Product Owner/Product Manager (POPM): $995
- SAFe Release Train Engineer (RTE): $1,295
- SAFe DevOps Practitioner (SDP): $995
And that’s just the certifications. Want to actually implement SAFe? That’ll require:
- Consultants to guide the transformation ($200-$400/hour)
- Training for your entire organization (hundreds of thousands of dollars)
- Tools and software to support SAFe practices
- Ongoing coaching and support
Scaled Agile, Inc. has productized Agile and created a business model that depends on complexity. The more complex the framework, the more training you need. The more roles they create, the more certifications they can sell. The more ceremonies they prescribe, the more consultants you need to help you “do it right.”
They’ve sold corporations comfort. Executives can point to their SAFe implementation and say “See? We’re Agile!” They have metrics, burndown charts, and velocity reports. They have certified professionals and a roadmap.
They don’t have working software shipping faster. They don’t have happier engineers. They don’t have better products.
But they have the appearance of Agility, and sometimes that’s enough to satisfy a board of directors who wouldn’t know real agility if it shipped working software in their lap.
Conclusion: Reclaim Your Craft
SAFe isn’t just inefficient - it’s insulting.
It treats engineers like assembly line workers who need daily check-ins to stay on task. It treats software development like manufacturing, where you can plan every step three months in advance and execute flawlessly.
But software isn’t manufacturing. It’s creative problem-solving. It’s battling with complexity, uncertainty, and the fundamental unknowability of how long something will actually take until you’ve done it. And creative work dies under micromanagement.
Here’s the truth SAFe doesn’t want you to know: the best software in history was built by small teams with minimal process. Unix. The first web browser. AWS. WhatsApp (55 employees at their $19B acquisition). None of them used SAFe. None of them had PI Planning. None of them had Release Train Engineers.
They had smart people, clear problems, and the space to fucking think.
SAFe has taken the Agile Manifesto - a beautiful, simple set of principles that revolutionized software development - and turned it into a bloated, bureaucratic, certified, expensive framework that violates every principle it claims to uphold. It exists not because it makes software better, but because it makes executives comfortable and consultants wealthy.
It’s theater. Performance art where the performance is “look how Agile we are.”
What Actually Works
So what’s the alternative? Here’s what I’ve seen work in the real world:
Small, autonomous teams (Amazon’s two-pizza rule) - If you can’t feed a team with two pizzas, it’s too big. Amazon runs on thousands of these micro-teams. Each owns their services, their APIs, their decisions. No cross-team standups. No dependency management ceremonies. Just clear ownership and well-defined interfaces. When you need to coordinate, you talk to the other team. When you don’t, you don’t.
Minimal coordination overhead (Spotify’s model) - Spotify rejected SAFe and built their own approach: Squads, Tribes, Chapters, Guilds. They fucked up parts of it (even they’ll admit that), but they got the core right: teams sync when they need to, not because it’s Tuesday. If you find yourself in constant coordination meetings, you don’t have a process problem - you have an architecture problem.
Ship constantly (Etsy’s approach) - Etsy deploys 50+ times per day. Small changes, fast feedback, rapid iteration. When you ship daily, each change is tiny. Tiny changes don’t need PI Planning. They don’t need 16 hours of ceremony. They need a pull request and a deploy button.
Trust your engineers (Basecamp’s Shape Up) - Six-week cycles. No daily standups. No estimates. No sprints. Just “here’s the problem, here’s six weeks, show us what you got.” Basecamp has 60 employees and ships multiple products. Their secret isn’t more meetings - it’s fewer meetings and more trust.
Protect focused time (Microsoft’s maker schedule) - Microsoft Research found that it takes 23 minutes to get back into flow after an interruption. If you have meetings scattered throughout the day, you never reach flow. Block out 4-hour chunks. Make them sacred. No meetings, no “quick questions,” no drive-bys. This is where the actual work happens.
Measure outcomes, not activity (GitHub’s approach) - GitHub doesn’t track velocity or story points. They measure deployment frequency, lead time, and mean time to recovery. These metrics tell you if you’re actually being agile - shipping fast, getting feedback, and fixing issues quickly. Everything else is vanity metrics.
The key insight: if you can’t be agile at scale, scale less. Break your problem down until you can have small teams working independently. If you can’t do that, you have an architecture problem, not a process problem. No amount of SAFe ceremonies will fix bad architecture.
SAFe Survival Guide
If you’re an engineer in a SAFe organization, you have two choices: fight for your time or find a company that already values it.
If you choose to fight, here’s your tactical playbook:
Defend your time ruthlessly. Every Sunday night, block out 2pm-5pm Monday, Wednesday, and Friday on your calendar as “Deep Work - Do Not Schedule.” Mark it as busy. When someone tries to book over it, reply: “I have a conflict during that time. Here are my other availabilities.” You don’t owe them an explanation. Your conflict is doing the job they hired you for.
Underpromise systematically. PI Planning wants you to commit to 80 points? Commit to 40. When you deliver 45, you’re a hero. When you commit to 80 and deliver 60, you’re a failure. The game is rigged, so rig it back. Build in buffer. Sandbag estimates. When leadership asks why velocity is low, point at the 11 hours of weekly ceremonies.
Make the dysfunction visible. Track your actual coding hours per week in a spreadsheet. Every week, log it. After a month, you’ll have data. Book a one-on-one with your manager. Show them the numbers: “I had 8 hours of focus time this week. That’s 20% efficiency. The other 80% was ceremonies and coordination. What are we going to do about this?” Make it uncomfortable. Make it their problem.
Master the art of “no.” When someone asks for “just 15 minutes,” ask what it’s about first. Half the time, it can be an email. When you’re invited to a meeting without an agenda, decline and ask for the agenda. When you’re invited to a meeting where you’re not speaking or deciding anything, decline and ask for the notes after. Your time is your most valuable asset. Protect it.
Document the insanity. Keep a log of the dumbest moments. The 3-hour PI Planning session that could’ve been an email. The dependency that blocked you for 2 weeks because another team was in a different sprint cadence. The “urgent” feature that sat in backlog refinement for a month. When you interview elsewhere, you’ll have stories. When you talk to leadership, you’ll have evidence.
Find your allies. Other engineers feel this too. They’re just afraid to say it out loud. Start conversations. “Hey, did we really need 2 hours for that planning session?” You’ll find your people. Build a coalition. When enough voices push back, things change. Or they don’t, and you all leave together.
Notes for Managers and Leaders
You have the power to change this. You might not be able to kill SAFe entirely - there are too many sunk costs, too many stakeholders, too much momentum. But you can protect your team and if you’re already doing this your team should be buying you the beers.
Give your engineers time. Not over training, not more tools, not more process. Time. Uninterrupted, protected, sacred time to actually build the thing you hired them to build.
Question every ceremony. Before you invite someone to a meeting, ask: “Will this person speak? Will they make a decision? Will they learn something they can’t get from notes?” If the answer is no to all three, don’t invite them.
Measure what matters. Stop tracking velocity and story points. Start tracking: How fast do we ship? How quickly do we fix issues? Are customers happier? Everything else is theater.
Protect focus time. No meetings before 12pm or after 3pm. No meetings on Fridays. Core collaboration hours are 12pm-3pm. Everything else is focus time. Yes, this is radical. Yes, it works.
Trust your people. If you hired someone competent enough to solve complex technical problems, they’re competent enough to manage their own time. If they’re stuck, they’ll ask for help. You don’t need a daily ceremony to babysit them.
The best thing you can do as a leader is get out of your team’s way. SAFe does the opposite - it gets in everyone’s way and calls it “coordination.”
Final Thoughts
SAFe promises to scale Agile. What it actually scales is the distance between engineers and the problems they’re trying to solve.
Every ceremony is another layer of abstraction. Every role is another game of telephone. Every commitment is another opportunity to measure the wrong thing. Every PI Planning session is another two days not shipping software.
The Agile Manifesto fit on one webpage. SAFe requires a $995 certification course.
That should tell you everything you need to know.
If your organization just spent $500K implementing SAFe and you’re reading this thinking “fuck, he’s right,” don’t despair. That money’s already gone. The question is: how much more time are you willing to waste pretending it works?
Engineers: defend your craft. Your focus time is where the magic happens. Everything else is just noise.
Thanks for reading this far. To you, I wish health, wealth, and a waterfall of puppies. Now I’m going to touch some grass - I need to wipe this shit off my hands.
