Positive: The alternative to sprints is frequently no process at all, not the strawman waterfall. If you can't plan two weeks of work there is no way you can plan six months work of work. Sprints mean that conflicts get surfaced regularly and not "kicked down the can" for eight months. Teams that don't release regularly don't know how to release. so they'll plan to spend six months developing something and think they…
^^^ This here everybody! The much bemoaned waterfall is not a development methodology, it's a project management methodology. The developers had no process at all. That's an important point missed by developers who've never known anything other than agile development. From a developer's perspective it's not agile or waterfall, it's agile or nothing at all (typically). Agile, with its warts and all, is far better than…
Agile, with its warts and all, is far better than nothing at all.
Yeah. You see criticism of agile, all of which is generally totally valid, but I never see alternatives mentioned short of "have a team of top X% developers with a clear shared understanding of all objectives and essentially no interference from management and no unreasonable deadlines."Which, well... I mean, great if you can get yourself into a situation like that. That sure is better than agile. It is the ideal I yearn for as an engineer.
I just don't think that's realistic for most engineering endeavors. At some point, engineers need to recognize that interfacing with the rest of the company (product owners, etc) is a big part of the job and really embrace it. It's also typically the only part of our job that is not easily outsourceable, so it is in our best interest to embrace this.