Ask HN: Does the Scrum Framework Work?

No

If you are are talking about the agile industrial complex, it should all burn in a garbage fire.

Agile (https://agilemanifesto.org/principles.html) is not a formalized process or methodology. It is a set of simple principles:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

These are pretty reasonable principles. Do they work? Better than what they were reacting against, which was the "specify and document everything in detail up front" methodologies.

To begin with, Agile isn't a methodology. It's a way of thinking about development—a philosophy—that's defined at agilemanifesto.org.

There are a bunch of methods that follow the Agile philosophy. Scrum and Extreme Programming are the most well known. Extreme Programming was popular in the early 2000s, but has since been eclipsed by Scrum.

There are a bunch of companies and methods that claim to follow the Agile philosophy, but don't. SAFe ("Scaled Agile Framework") is the most well known. Additionally, because Scrum is so popular, most of the companies who claim to be "Agile" are actually using some cargo cult version of Scrum.

So you'll get a lot of people complaining about Agile, when they're actually complaining about crappy Scrum and SAFe implementations.

Personally, as someone who's been involved with the Agile community for a few decades, I would love to see Scrum replaced with Extreme Programming. My experience is that XP works much better than Scrum in practice, because it emphasizes engineering practices, whereas Scrum puts too much focus on Scrummasters and planning. Although Scrum has some good ideas, they're very nuanced, and tend to be misunderstood in a way that leads to micromanagement.

Edit, since the OP was changed:

Yes, Scrum works when done correctly. But most people don't do it correctly, because it's very bare-bones, which results in people layering their own preconceptions on top of it, most of which are distinctly anti-Agile. Additionally, Scrum pioneered the "Certified Scrummaster" (CSM) and "Certified Scrum Trainer" (CST) certifications, which were so lucrative that they attracted a lot of incompetent people into teaching Scrum. The CSM course is also too short and shallow to really teach people how to lead Scrum teams effectively, but is marketed as a panacea.

The result has been a giant garbage fire.

The problems arise when the "I need agile!" meme becomes reality and leaders adopt it for the sake of showmanship. If your incident responders are able to plan the incidents they'll work over the next sprint, you are clearly managing a team of saboteurs.

IMHO Scrum was a prescription of how to be agile because being agile is a kind if philosophy and it is hard to make it work quickly without huge investment in the growth of each individual.

Its main lets say purpose (not by its creators) was to disrupt Waterfall at scale and it managed to do that no matter if it works or not.

But while Scrum worked well for the innovators adopting it it does not work at scale (nor does Safe or any other framework trying to fix it by adding more processes and roles). Actually most implementations of Scrum at scale are anti-agile, are rigid and products and teams will collapse (productivity wise) if tomorrow someone takes scrum out. Because they are trained to follow Scrum not to be agile.

Agile means thriving in a fragile environment and Scrum does not teach people that.

There are some new frameworks in the making. Solving some of the issues we encounter now but it is hard to predict which one will win if any.

I for example really like Shape Up. I feel it allows teams to be agile while not being so focused on daily work.

There are less than 20 authors in the manifesto, go check what they were up to. Next to the management framework, there is a lot of engeneering techniques and ideas. A sibling comment talked about XP whose technics work well along scrum, but there is also clean code, refactoring, crystal methods, agile as a cooperative game, liberating structures, devops (no, not the job offer),...

They all had blogs (archive. org is your friend for some of them), wrote books and gave talks. I like to get lost on http://wiki.c2.com/ where I found lots of insight about how to make the thing work. So yeah, I think it work pretty well when you learn how to use it.

It's rigid, hierarchical, proscriptive and weirdly bureaucratic. If you follow all the rules they promise you'll end up in a better place. If you dont, it's because you didnt follow the rules precisely enough.

They both believe in all the same sort of wishy washy stuff though.

MVP. I would argue when you bring up agile, most people are thinking of the allure of a small scrappy startup with 2-pizza size teams who by herculean effort create a Minimum Viable Prototype in record time. Nevermind, the MVP was built with little concern for scalability, security, or enterprise integration. Speed to market is the driving force behind startup culture and trying to grab market share. The idea is that once you get market share and more funding, then you can think of documenting and optimizing your code.

Agile Project. In practice, most people are really running "Agile Projects". They invest considerable time upfront to interview, document, and get signoff on project requirements… before they even start coding. Does this sound like waterfall? After they get the requirements, then they develop using scrum practices and ceremonies. (Nitpick, "ceremony" is a terrible word choice as it means those activities have no meat or value [1]). E.g. 18F's Agile based project approach requires "We conduct discovery research before we build anything. Depending on the complexity of your problem space, this can take up to 2 to 3 months." [2]

[1] https://turboscrum.com/the-fascinating-origin-of-the-term-sc... [2] https://agile.18f.gov/18f-agile-approach/