It's only a matter of time till we start having methodology stacks. WoW Stacks? Meth Stacks? That's one way of terming it, I guess. "Hey bro, my team uses XP/Open-souce/Kanban". Alright but seriously, Open-source does sound like a cool idea. But why not just leave this at the behest of the engineers of the team? Just get them to congregate for an hour or two (preferably two), to discuss how the team should work together and collaborate (might require a couple of get-togethers)? "Alright, we've agreed to using SBE, BDD, Collective Code Ownership, Trunk-Based Development, Feature Flagging and GitHub Actions for CI. And a Google Sheet to track our work. Everything else is up to you, you manage your own work, yada yada yada."
Totally, I think that's the way it should be done. I look at these examples as just ideas to get people thinking, but the engineering team should be the ones that decides what to use or not use.
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 think company size has a big influence on trust and processes. In a small company (<50) everyone knows each other and engineers can have fluid interaction with directors etc., so while such companies can still choose scrum, they can easily use an organic process of some sort. But once you start to cross the threshold into ~100 size, there is org pressure to have middle management. At that point the arbitrary process BS starts to kick in unless there is already really good culture and alignment towards maximizing trust.
I feel you have much more to gain if you iron out the anti-patterns of the Spotify Model, compared to if you do so with Scrum. Which is much more simpler and easier to achieve as well, with the Spotify Model (versus Scrum): https://medium.com/@ss-tech/overcoming-the-pitfalls-of-the-spotify-model-8e09edc9583b. Ultimately, there's still a net positive to be had compared to Scrum.
It's only a matter of time till we start having methodology stacks. WoW Stacks? Meth Stacks? That's one way of terming it, I guess. "Hey bro, my team uses XP/Open-souce/Kanban". Alright but seriously, Open-source does sound like a cool idea. But why not just leave this at the behest of the engineers of the team? Just get them to congregate for an hour or two (preferably two), to discuss how the team should work together and collaborate (might require a couple of get-togethers)? "Alright, we've agreed to using SBE, BDD, Collective Code Ownership, Trunk-Based Development, Feature Flagging and GitHub Actions for CI. And a Google Sheet to track our work. Everything else is up to you, you manage your own work, yada yada yada."
Totally, I think that's the way it should be done. I look at these examples as just ideas to get people thinking, but the engineering team should be the ones that decides what to use or not use.
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 think company size has a big influence on trust and processes. In a small company (<50) everyone knows each other and engineers can have fluid interaction with directors etc., so while such companies can still choose scrum, they can easily use an organic process of some sort. But once you start to cross the threshold into ~100 size, there is org pressure to have middle management. At that point the arbitrary process BS starts to kick in unless there is already really good culture and alignment towards maximizing trust.
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/
I feel you have much more to gain if you iron out the anti-patterns of the Spotify Model, compared to if you do so with Scrum. Which is much more simpler and easier to achieve as well, with the Spotify Model (versus Scrum): https://medium.com/@ss-tech/overcoming-the-pitfalls-of-the-spotify-model-8e09edc9583b. Ultimately, there's still a net positive to be had compared to Scrum.