Formal development processes exist BECAUSE so many developers are poor developers. For good developers, most formal processes only act as a hindrance. This is exactly why you're observing what you observe. As is the traditional 80/20 rule, 20% of your developers do 80% of the work. Which leaves us with what to do with the remaining 80% of the team. Yes, they can contribute, but they require some type of process to follow otherwise they'll get lost in the weeds every time. Sapping even more time away from the 20%. Management sees this as good because you get better utilization of the 80%. It may well result in a net win, if implemented correctly. But, of course, that's not how the 20% want to spend their time - mostly.
Agile is really about neutering the 20% to make the 80% appear and/or be more productive. It's a bridal to force the 20% to drag the 80% into the solution domain. For body count houses, this is great stuff. For good developers, it's a nightmare.
Let's face it, good PMs are harder to find than good developers. And good developers are as rare as unicorns. The result is that most projects get stuck in suckage-land, whereby the 20% are stuck fixing the issues caused by leadership, management, the PM, and the rest of the team. Which is usually compounded by the fact that everyone wants to work reactively rather than pro-actively. After all, who can possibly foresee that if you implement your solution with highly specialized patterns and that if the requirements change at all, it's going to mandate massive refactoring. But, hey, there's a reactive process for that, so it's all good.
Excuse me, I have to go finishing butting my head into the wall for another couple of hours.
Formal development processes exist BECAUSE so many developers are poor developers. For good developers, most formal processes only act as a hindrance. This is exactly why you're observing what you observe. As is the traditional 80/20 rule, 20% of your developers do 80% of the work. Which leaves us with what to do with the remaining 80% of the team. Yes, they can contribute, but they require some type of process to follow otherwise they'll get lost in the weeds every time. Sapping even more time away from the 20%. Management sees this as good because you get better utilization of the 80%. It may well result in a net win, if implemented correctly. But, of course, that's not how the 20% want to spend their time - mostly.
Agile is really about neutering the 20% to make the 80% appear and/or be more productive. It's a bridal to force the 20% to drag the 80% into the solution domain. For body count houses, this is great stuff. For good developers, it's a nightmare.
Let's face it, good PMs are harder to find than good developers. And good developers are as rare as unicorns. The result is that most projects get stuck in suckage-land, whereby the 20% are stuck fixing the issues caused by leadership, management, the PM, and the rest of the team. Which is usually compounded by the fact that everyone wants to work reactively rather than pro-actively. After all, who can possibly foresee that if you implement your solution with highly specialized patterns and that if the requirements change at all, it's going to mandate massive refactoring. But, hey, there's a reactive process for that, so it's all good.
Excuse me, I have to go finishing butting my head into the wall for another couple of hours.