Scrum is a cancer

I think it's a mistake to think in black-and-white terms about management approaches. It's a mistake to adopt scrum rigidly, and it's a mistake to reject it in full.

Instead, we should look at what works and what doesn't, and consider their merits on a per-project basis.

So at the risk of being a contrarian, here are the ideas that I personally think are valuable from scrum:

(1) Break down bigger projects into smaller ones. I'm not sure it's beneficial to rigidly define a spring as 2 weeks. But the opposite of this is endless scope creep, where there's no clearly defined finishing line. By my definition, some springs might take a day. Others, several months. It really depends on what we're trying to accomplish. The smaller the period of the sprint can be, the less risk there is of losing focus. To paraphrase Einstein: Sprints should be as short as possible, but no shorter.

(2) Sprint planning may have too narrow of a focus, since it's entirely focused on the upcoming sprint, rather than the big picture. But I prefer it to going into detailed monolithic plans (i.e. waterfalls). No plan survives contact with reality, and the further out you plan, the more fictional your plans become.

(3) While I don't like fixed meetings that repeat with a specific rhythm (i.e. what scrum calls "ceremonies"), there is value in at least considering them on a per-sprint basis. Not every sprint justifies a daily stand-up, iteration review, or retrospective. But they do have merit. I just think they should be evaluated on a case-by-case basis rather than applied across the board.

(4) I have mixed feelings about product backlogs. On the one hand, they spare you from trying to plan out how to implement every request under the sun. On the other hand, they encourage you to simply go to the backlog and pick things you feel like doing for the upcoming sprint, rather than being focused on the next most important things. Important things don't need backlogs to be remembered. Important things will keep coming up, over and over. You're not going to forget them.

(5) The term "scrum master" is icky for many reasons. But I do believe someone should be in charge. Search all the parks of the world and you won't find statues to committees. Leadership matters.

My wish is for HN to ban all links from there. It would be better to HN anyways if the discussions got contained within the forum instead.

It would be nice if it became normal for HN users to flag and or at least refrain from upvoting twitter links, since my belief is that they are bound to influence HN negatively.

Failing that I suppose I'll have to mess around with an extension so that my browser removes them automatically instead.

Management decided that the company needed to implement the 5S workspace management system company wide. In short, one focus of the system is to help you put tools and materials back in the right spot to keep the workspace organized for the next person that needs to use it.

This is helpful for organizing the manufacturing workspaces where different employees would be coming in on different shifts and using the same space.

They had engineering (software, mechanical, electrical) doing the same thing. They sent up rolls of different colors of tape so we could mark all the stuff on our desks and asked us to write documentation about our workspaces. We were all marking off with tape "Keyboard", "Mouse" and "Stapler". It was truly asinine. I left the company shortly after that.

That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile.

You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs.

A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc.

More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.