Agile, Scrum, Waterfall, and any other methodologies you can think of are like anything else abstract that seems to work: people get so caught up in either adhering to, or rubbing other's faces in, the wording ideas rather than the point and principles behind those ideas. If you take a look at any text that is meant to outline guidelines for something, be it financial guides, software development manifestos, or religious texts, they all follow the same pattern: a few folks take a look at them and go "Hey, this is best. Let's do this." Those few see positive results and a bunch of other people jump on the bandwagon. Human nature gives us an initial reaction to want to better ourselves with the same techniques that others have used to better themselves. Unfortunately, our secondary reaction is either to profit from it, or shove it down other people's throats.
I think any development methodology had good intentions at the start. With Agile, diversity would have helped, but I think considering the main idea behind Agile rather than what the written documentation on it says would help more. Written documents are extremely susceptible to being spun differently depending on who is reading them, or how out of context particular principles are taken when explained to others. But the idea itself of "Release. Get feedback. Improve. Repeat." Is not something that is inherently biased toward 17 white dudes. Anybody can understand that concept. Where we get into trouble, and where diversity comes into play, is when we take the written guidelines of how to accomplish that goal, which were written by white males who couldn't possibly have any first hand experience being anything other than white males and try to apply them as a "one size fits all" solution. Is it the fault of those white guys that others are getting so caught up in the wording that they miss the point? Is it their fault that they couldn't have any personal experience of what it takes for a black man, Muslim woman, or a gay woman of Hispanic descent to succeed in that kind of environment? I can't really say. But to me, it seems like the idea is good. The thought process behind that development method is also good. But implementing it based on what these guys say rather than the team you work with is fundamentally flawed and, dare I say it, a really lazy and stupid way of forcing your team to conform to rules rather than allowing that ideology to guide your team they way they personally need to be guided by it.
Yep you are so right. I think your point about guidelines feels spot on. It is keeping in mind that that is what they are.
On a personal level I hope the team I'm in are never put in that position. I think it helps that there is a mix in the organisation of people who have worked like that for a lot of their careers and people coming to it fresh from different backgrounds.
Im speaking as someone quite early on that journey so dont have strong views on right or wrong just a feeling it works better as a conversation.
The team I'm in have so far had the freedom to learn and adapt how we do things to fit what we need. Both our scrum master and product owner are great at setting the tone of "this is where we need to get to in terms of what the other teams want or need in the way of common process - how do we do that in a way that works for us?"
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.