Scrum (and similar processes) are usually better than the absence of process. Sure, occasionally you have lightning in a bottle and have 5 proactive self-organi

Scrum (and similar processes) are usually better than the absence of process. Sure, occasionally you have lightning in a bottle and have 5 proactive self-organizing engineers that are pro coordinators and communicators, or you have a team with a tech lead that just magically makes everything run smoothly without anyone really noticing. But even teams with the best engineers often struggle with scheduling and communicating large projects to executives. Scrum is a fine default for any software engineering team working on app/website-style engineering projects. But if their process never veers away from default Scrum, they're probably not a very good team. I've discovered that good teams are fearless about retros. They take suggestions seriously If they're unwilling to try new things, they're always going to underperform teams that experiment with process, and keep the good and reject the bad. Scrum (and similar processes) makes every engineering team move at roughly the same speed. This is good news if you have a poor-to-medium quality team and is frustrating if your team would be speedy without the process. Teams that don't adapt the process to themselves and their companies are always gonna feel like they're stuck in the mud.