In practice, and despite what they sell it as, Scrum is a superior exploitation framework, not a superior engineering framework. As brutal management sees it, the pain inflicted on engineers is the point.
The listed options are engineering frameworks, some of which like Open Source and Kanban are really good, but they don't optimize for exploitation, so they are not used so much in the corporate world.
I know that this might seem horridly "disorganised" - but what's wrong with the traditionally successful method of just picking people you think can do the job, who agree they can do the job, and just letting them do it?
Without anything even vaguely resembling any kind of 'methodology' at all?
I know this gives Project Managers conniption fits - but good PMs, with experience of what works and what doesn't, can often cope well and work well with herding that kind of assemblage of cats.
Upper management might hate the thought - but who says they have to know? The right kind of PM can feed them whatever BS they need, while concealing what's really happening below. The last few (very successful) projects I've worked on have been like that.
(Full disclosure and fair call, though, these have not been software development projects: they've been mainly "infrastructure with a bit of code re-writing". But I have previously worked on mostly-new-code projects that work - and worked! - like that too.)
In practice, and despite what they sell it as, Scrum is a superior exploitation framework, not a superior engineering framework. As brutal management sees it, the pain inflicted on engineers is the point.
The listed options are engineering frameworks, some of which like Open Source and Kanban are really good, but they don't optimize for exploitation, so they are not used so much in the corporate world.
I know that this might seem horridly "disorganised" - but what's wrong with the traditionally successful method of just picking people you think can do the job, who agree they can do the job, and just letting them do it?
Without anything even vaguely resembling any kind of 'methodology' at all?
I know this gives Project Managers conniption fits - but good PMs, with experience of what works and what doesn't, can often cope well and work well with herding that kind of assemblage of cats.
Upper management might hate the thought - but who says they have to know? The right kind of PM can feed them whatever BS they need, while concealing what's really happening below. The last few (very successful) projects I've worked on have been like that.
(Full disclosure and fair call, though, these have not been software development projects: they've been mainly "infrastructure with a bit of code re-writing". But I have previously worked on mostly-new-code projects that work - and worked! - like that too.)
The spotify model is a classic trap. They don't use it and people keep pointing at it like some ideal. Learn from their mistakes:
https://www.jeremiahlee.com/posts/failed-squad-goals/