Well, it's more than that though - otherwise you'd just assign each developer 80 "points" worth of work for each two-week sprint.

> If nothing is going to be cut from the requirement docs, all the castle about poibts priority and speed just falls down (or you have a ridicolously lax deadline, of the likes I’ve never seen in practice)

Adding stories to an iteration in progress is also (I'm pretty certain) explicitly discouraged.

If your manager is doing that, you've already kinda lost the Agile battle.

I think that's sorta what people mean when they say people are doing Agile wrong - they do these things that are explicitly discouraged.

Whether there's any way to reconcile that, I can't say.

Usually how it goes. It's like critics of communism. Or libertarianism. Maybe--just maybe--it's a shit ideology that is totally unworkable.

I think my current place is on their, what, 8th "reset" now? Where they try to correct their process because it's "not working." Despite not listening at all to the developers who are telling them week after week exactly what is wrong: management forcing unreasonable deadlines on developers and throwing all process out the window.

It would be more amusing if I wasn't one of those caught in this demented whirlwind.

I think I'll start a new fad. Instead of Waterfall, I'll propose we call it: Typhoon Development. It's where management focuses all their attention on a single project for a short period of time, stressing the developers to the breaking point and eventually moving on. But not before completely destroying the code base in their wake.

Could be. Much like communism, it's something that seems to work remarkably well for small groups of people but seems to have problems with large, entrenched groups.

There are enough agile success stories though that I don't think the ideology is completely silly.

> I think my current place is on their, what, 8th "reset" now? Where they try to correct their process because it's "not working."

It's highly unlikely that any methodology would have any effect on your current place, regardless of how brilliant or revolutionary it is.

I think it's tempting to dismiss Agile as stupid or unworkable because it's failed to produce any results at organizations like this (and often just made things worse).

The truth is really that your organization is highly dysfunctional and the problem is management. There's no development methodology that will fix that, and indeed it won't get better until those people see the light of day (unlikely) or leave/are replaced.

For more functional organizations, or even organizations where management is willing to admit they might be wrong, Agile can be a nice set of guiding principles for development work that makes life easier.

Any lonk to read one account of such written by devs themselves, as opposed to the vast majority that are written by consultants selling agile packages?

In both cases management was on board with scrum and knew what that meant. Everything was estimated by devs, not managers. If there was an external deadline, scope was adjusted to meet it.

I think of scrum as training wheels to get started for organisations that aren't used to operating in an agile fashion.

There are agile techniques that don't have sprints.