Giles Bowkett: Why Scrum Should Basically Just Die in a Fire | Hacker News Reader

Giles Bowkett: Why Scrum Should Basically Just Die in a Fire

gilesbowkett.blogspot.com

Your post could be called "Why the company culture where I experienced scrum should die in a fire"

It is all about the implementation. Just today I had a manager, remind the developers who were talking too much that the meeting needed to be over in 15 mins. Horrible long meetings is a culture thing.

Blaming someone for something because they left early is a culture thing.

Managers sitting everyone standing is a culture thing.

Scrum is a tool. You can use it badly, and horrible cultures will use it badly.

When we went Scrum, I can say that my favourite bit was the free E-meter at every desk. The Kool-Aid tasted a bit funny, though.

Your logical fallacy is: No True Scotsman. http://rationalwiki.org/wiki/No_True_Scotsman

Having worked at Google, I can say that there are definitely large chunks of the company that do not do agile. Currently working at Spotify, I can say that while the company definitely does agile, most of the teams AFAIK don't do Scrum. There's a publicly available Spotify Culture video that explains this and other things.

To quote my actual post:

> the Agile methodology allegedly favored by Google and Spotify

That's why I put that "allegedly" in there, along with links to where the claims were made.

I see these claims in the business press from time to time, but I rarely believe them.

BS reporting is a catch-22. Since I repeated the claims, I get well-informed debunking. If I'd ignored the claims, I'd be getting poorly-informed debunking from people who saw it and believed it.

I'm pretty happy to get well-informed debunking, rather than poorly-informed debunking.

I'll happily help debunk a teensy bit more - I just left Spotify where I was an Agile Coach for 3 years. At least by the time I left, there weren't any teams in the company really "using scrum", some teams may have kept some pieces that worked well for them (regular development intervals for instance) but I don't think any of them were falling into the traps or anti-patterns mentioned here. There are 80-something product development teams, each one gets to choose and evolve the practices best suited for them, etc.

Reply on news.ycombinator.com