Hacker News

While there are plenty of non-anecdotal reasons to criticise scrum, I am so very, very, very bored of the armchair criticism of scrum that comes entirely from very narrow personal experiences and second-through-seventh hand anecdotes that emphasise the negative and leave broad gaps in the story telling - story telling that frequently relieves engineers of any wrongdoing and even elevates them to pure machines of 100% efficiency being restrained or tethered by the shackle of scrum.

It was tiring 20 years ago when I started to hear them and it's no less tiring now. Show me a thousand scrum/agile critics and I'll show you zero better methodologies given back in return.

I think the bigger question might be: "Why is so much effort being made to 'manage' developers and their work?" Do other departments have so many different process theories on how best to manage themselves?

From my experience, it's because most dev teams I've been on are completely disfunctional. Most devs I've worked with won't invest in learning the apps and the business. They want to effectively "color by number". So, when they are given work, they are starting from zero every time. So, they can't estimate. They can't meet deadlines. They can't communicate. They are slow. They are practically begging to be "managed".

When I've been fortunate enough to work with good developers, we don't get "managed" like this guy describes.

This is just commentary on blindly following a process and taking it to the extreme. Plenty of people use scrum successfully. Plenty of people also do what this person did and follow process for process sake. That’s the issue. Agile and scrum are simply a set of tools that you can use to iterate. If you cannot intelligently look across the tools in the Agile tool box and pick the ones that you really need, you ARE doing it wrong.

I mean for goodness sake, he’s complaining about planning poker and story points. I used to play planning poker with my team every other Friday for an hour. The team would talk design or whatever they needed to on Friday afternoon and we’d estimate 3-5 things in our backlog. It was a great time to teach junior devs. They would independently think about what needed to be done and then that would be validated through planning poker. It also allowed less familiar devs to learn enough to pick up new tasks in the upcoming sprint.

It’s possible to over index on this and take it way too far. That sounds like what this guy’s team is doing. Blindly following Agile processes without questioning how they best apply to your business and team is absolutely doing it wrong.

What scrum.