Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The whole debating around agile, scrum, kanban etc etc, with seniors hating Scrum yet it being pushed ever and ever again made much more sense when I heard some guy talk about Shu-Ha-Ri (https://martinfowler.com/bliki/ShuHaRi.html).

Having a strict framework à la Scrum is very helpful for new developpers or new teams, where they don't yet have their marks and need to get a feel of what agility feels like. Being explained principles is not enough to know how to apply them: Scrum is not a bad starting point to be in the right-ish track without really knowing what you're doing. As you gain experience, it's natural to want to shake off constraints, that's Ha and Ri



Maybe if you don't fill a team with nine juniors that have no mentors, you don't get this problem?

It's not like FAANG isn't hiring boatloads of new grads every year. Why don't those people need scrum to get on the right track, but half the rest of the industry seems to?


Those companies are very engineering-led. Boatloads of excellent engineers; deadlines are "it'll be ready when it's ready"; marketing is (and thus marketing deadlines are) light, so there's less planning needed; featuresets are largely defined by the engineering teams.

Anything that is reasonably unpredictable in terms of requirements but needs to be reasonably predictable in terms of feature delivery speed is a good candidate.

We use it because we need to release versions of our software a chunk at a time, and it's the closest we can get to continuous delivery given that constraint.


Google Cloud is not at all "it'll be ready when it's ready" with light marketing and feature sets defined by engineers.


FAANG has a lot of metrics and rituals (planning/RFCs/6-pagers, retro, reviews, 360 reviews, some do sprints, some don't), the do their own scrum.


I don't even know if it's a thing with new developers or old developers; I think sometimes you just get people who don't want to play along. Half-hearted participation is as good as no participation. You end up with user stories that are poorly written, poorly estimated, and you can't really reap a lot of the core benefits of Scrum like velocity forecasting. What you end up with is I Can't Believe It's Not Scrum; a shoddy clone of Scrum that never comes near the mark. You're forced to keep going along this way because not everyone agrees that you're failing.

Maybe people are tired of the nonsense that systems like Scrum bring with them? Even the name is a bit silly. And when you start naming roles and inundating people with rituals the eyerolls really get going. Why add abstraction to common sense?

Or maybe Scrum is really just an attempt to turn bad team members into good ones?

Good team members...

- Provide good estimates

- Cooperate to create clarity around requirements

- Work to divide big problems into small chunks

- Keep good track of their work in a shared format

Bad team members shun all of this and expect someone else to do it.


Ah. Nice reference. The fact that Aikido is notoriously ineffective made me chuckle.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: