My LinkedIn feed was flooded with anniversary posts from people who built the Agile industry — co-founders of the Scrum Alliance, the CEO of PMI, certified coaches, SAFe practitioners. The pattern across almost every post was striking: they acknowledge what went wrong, then continue doing the thing they just criticized. Direct quotes from today's posts by certified Agile professionals:

"We turned agile into a certification ladder" "Ceremony without intent" "Packaged mediocrity" One person called it "the unforgivable sin: taking a manifesto that is 68 words long and turning it into a multibillion-dollar certification industry"

These aren't critics. These are people with CSM, SAFe SPC, PMP, and RTE after their names. They sell certifications and coaching for a living. The self-awareness is there. The business model hasn't changed. Some numbers that stood out to me:

The original manifesto: 68 words, 4 values Scrum Alliance certifications issued: 1.4 million+ Average CSM certification cost: ~$1,000 SAFe full framework documentation: 800+ pages PMI stat shared today: 85% of executives say agility is critical, only 32% satisfied with implementation

That last one is interesting. A 53-point gap between "we need this" and "this works." PMI's response: they're releasing a new Manifesto for Enterprise Agility on March 3rd. More framework to solve a framework problem. The CEO of PMI actually replied to a comment I left questioning this approach. His response was that the new manifesto "is NOT about software development" — even though his own post opened by celebrating the Agile Software Development manifesto. In fairness, some counter-arguments I want to acknowledge:

Agile genuinely helped some organizations move away from rigid waterfall. The pre-Agile world was often worse. The comparison shouldn't be Agile vs. perfection, it should be Agile vs. what came before. Certifications, flawed as the model is, did spread ideas that many teams benefited from. The 2-day CSM course is shallow, but it introduced concepts that some people built on meaningfully. The manifesto authors didn't create the certification industry. Scrum predates the manifesto, and the commercial ecosystem grew around it somewhat independently. Some Scrum Masters and Agile coaches are genuinely good at their jobs. The criticism is about the systemic incentives, not every individual.

That said, I keep coming back to a structural question: when the organizations that define, certify, and sell a framework also measure its adoption, is there a realistic path to honest assessment of whether it works? Curious about HN's experience. Has anyone here worked in an organization where Agile (specifically the framework, not just "being adaptive") produced meaningfully better outcomes than what came before? What made it work vs. the common failure modes?

Comments URL: https://news.ycombinator.com/item?id=47014773

Points: 3

# Comments: 1

The Certified Scrum Master pipeline works roughly like this: a 2-day course, approximately $1,000, pass rates above 95%, and no engineering background required. The Scrum Alliance has certified over 1.4 million people through this process.

After certification, many of these folks land roles paying $90K-$130K facilitating sprints, standups, and retros for teams of senior engineers.I'v e worked with good Scrum Masters who genuinely helped teams. I want to be clear about that. But the structural model seems odd to me:

The certification requires zero technical knowledge, yet the role involves managing a technical team's workflow daily. A mid-level engineer with 5 years of experience writing production code often earns a comparable salary to the person facilitating their meetings.

The certification body has a direct financial incentive to expand the perceived necessity of the role. More essential the role seems, more certs sold. At $1K per cert and 1.4M certified, that's $1.4B in certification revenue alone.

In most teams I've observed, removing the SM role would redistribute about 30 minutes of weekly facilitation across people who already understand the work better than the SM does.

The counter-arguments I can think of:

Not every team has a tech lead who wants to handle process. Fair point. But that's an argument for better leadership, not a separate process role.

SMs handle organizational impediments. True in some orgs. But in practice, most impediment removal I've seen is a management function that existed before Scrum.

The role protects the team from outside interference. Valid, but you don't need a certification for that. You need someone with organizational authority, which the SM role often lacks anyway.

I'm not arguing that every SM is useless. I'm questioning whether a 2-day certification with no technical prerequisites is a sound foundation for a six-figure role managing engineering teams.

Has anyone here worked in an organization that genuinely benefited from having a dedicated Scrum Master? What made it work vs. the cases where it didn't?

That set the pattern for two years. Every technical problem got redirected to a process conversation because process was the only thing he understood.

Database migration from Oracle to Postgres? "Let's timebox this and take it offline." Microservice boundaries for payment processing? "What's the user story?" Deployment pipeline failing intermittently? "Sounds like we need a retro."

His retrospectives were textbook perfect. Clean facilitation, sticky notes, dot voting, action items in Confluence within the hour. But six months of action items and every single one was a process change. Not once did we commit to fixing the service causing 60% of our production incidents. He couldn't evaluate whether a refactoring proposal was valid so he defaulted to what he could judge: process.

The moment that crystallized everything was a 14 hour production incident. Connection pool exhaustion in a payment service that had been patched without proper refactoring for years. Team knew it was a ticking bomb. Had been raising it in retros for months.

Next day he facilitates a blameless postmortem. Engineers explain the root cause in detail. He nods, then steers toward "how can we improve our incident response process" and summarizes the tech debt as "legacy system challenges." Six weeks later same service, different symptom, same root cause.

For $150k we could have hired a senior engineer who could actually look at the code, unblock developers, pair with juniors on real problems, and catch architectural mistakes in pull requests instead of process deviations in sprint boards.

He had every certification. CSM, SAFe SPC, ICF-ACC, ICP-ATF. None required writing a single line of code. Two day courses and multiple choice exams that qualified him to coach teams of senior engineers on effectiveness.

He was a good person genuinely trying to help. The role itself is broken when it puts non-technical people in charge of making technical teams effective. How do you coach a team when you can't evaluate their technical decisions? You default to process. Every time.

Anyone else seen this pattern? Curious whether anyone has found a version of this role that actually works.

Team sits down for sprint planning. Takes forever. Probably 4 hours by the time we're done arguing about story points and breaking shit down and mapping who needs what from who.

Everyone leaves knowing what they're doing for two weeks. Board looks great. All organized.

Couple days later something breaks. Or priorities shift. Or we find out another team needed something we didn't know about. Plan falls apart.

Next sprint? Same thing. Four hours. New plan. Dies in a few days.

Tracked this once because it was making me insane. Out of 20 sprints maybe 3 actually ended close to what we planned at the start. The rest just completely different by the end.

So what are we even doing? It's not planning if nothing survives. More like... I don't know. Making management feel better? Having something to point at?

Teams I saw shipping well never did this. They'd just grab what looked important and start. Things changed? Cool, adjust. Keep moving.

Anyway. Been watching this happen for years and nobody ever questions it. Starting to wonder if it's just me or if everyone knows this is bullshit but we all just go along with it anyway.

Your sprints actually go according to plan?

Comments URL: https://news.ycombinator.com/item?id=46860663

Points: 2

# Comments: 2

That's when it stops being team member helping out and becomes process person from outside.

Smart defensive move.

Devs were building features. We were on track. Then month 2 hit and management started hiring. A bunch of managers showed up. Then they brought in a Scrum Master. First week this guy wants to implement full Agile ceremonies.

Daily standups, sprint planning, retrospectives, backlog refinement. The whole package. His reasoning: "You need process to scale." We had 8 weeks left.

We weren't trying to scale. We were trying to finish. I've seen this same pattern play out multiple times now. Small team shipping. Management gets uncomfortable with lack of visibility, they hire process people. Process people need to justify their existence, ceremonies get implemented and everything slows down.

The thing that kills me is the timing. We were working. Why fix what isn't broken when you're 8 weeks from deadline? I'm genuinely curious, why can't management just leave working teams alone? Is it actual concern about sustainability or is it just discomfort with not having control mechanisms in place?

What's your experience with this?

Comments URL: https://news.ycombinator.com/item?id=46828358

Points: 5

# Comments: 5

That contrast you described, pharma-sales-rep energy vs the guy people yell at mid-meeting got me thinking about the actual ROI. I've been tracking salary data and trying to see if SM presence correlates with delivery metrics (deployment frequency, lead time, that kind of thing). Looked at around 40 teams. Couldn't find any meaningful difference.

Wrote up the whole thing here: https://agilelie.com/blog/scrum-master-salary-data-2026-wort...

Would love to know if I'm missing something in the analysis.

One thing I keep wondering: that good SM you had, would she have been just as effective as a tech lead who spends 10% of her time on facilitation? Or does the dedicated role actually matter when you find the right person?

I've been looking at what differentiates the good ones, and it seems to come down to:

1. Actually removing blockers (not just logging them in Jira)

2. Taking admin work off the team vs creating more process overhead

3. Protecting the team's time vs adding more ceremonies

The SAFe certification thing you mentioned... I tracked certification-to-effectiveness correlation and couldn't find one. Plenty of certified SMs who don't understand the work, and great facilitators with zero certs.

What did that one good SM do that the others didn't? Trying to identify the pattern.

I analyzed time allocation data from Scrum Masters and found they spend ~60% of their time in meetings about meetings. The actual "servant leadership" part averages 4.2 hours per week according to an Agile Alliance study.

The teams that work best seem to be the ones that either: 1. Rotate facilitation duties among senior devs (~10% time) 2. Have tech leads who code 80% and facilitate 10%

Curious if that matches what you've seen when those responsibilities got reassigned to teams?

Comments URL: https://news.ycombinator.com/item?id=46683508

Points: 1

# Comments: 6

Comments URL: https://news.ycombinator.com/item?id=46422894

Points: 1

# Comments: 0