It's easy to criticize. What specifically are you proposing as an alternative that will allow software organizations to reliably deliver value to customers?
Criticize all you like. But if you want to actually effect positive change then you'll have a lot more success with proposing specific improvements. Otherwise your co-workers will tend to perceive you as a whiner.
There is no single easy answer, and I'm not a management consultant so I have no interested in trying to sell one. You simply have to do the hard work of understanding the constraints you are operating under and exercising good judgement on how to work in that environment.
And, now I eagerly await the dozens of replies I'm going to get telling me that exercising good judgement and common sense could only mean that I am in fact following the True Agile (unless it doesn't work, then it was obviously No True Agile process).
Clients and other stakeholders often need status updates and estimates to conduct their business. It may even be worth sacrificing some speed and value in order to have better insight into when it is likely to be delivered, so plans and coordination can happen accordingly. This is still hard to do, and perhaps the agile-branded methodologies aren’t the best way to achieve that objective, but that doesn’t mean that predictability is meaningless as a goal and shouldn’t be attempted. ”Hire competent people and when they’re done, they’re done” doesn’t necessarily produce the best outcome for an organization.
That's the thing, though. Agile tries to accurately measure the progress as well as predict the time cost of the immediate future. It doesn't propose to predict the full time cost of an entire project.
Lots of methodologies do promise that, but they all seem to end up even worse. I know I don't want to go back to the waterfall days of requirements gathering for weeks, then being held to a schedule that was built entirely on hypotheticals.
What works is to have a competent team that cares and aren't hindered by bureaucracy. Agile is one such obstacle that prevents people from getting things done.
Agile might be a good way to deliver value if you have sub par teams, I'm not sure, but I'm pretty sure it hurts competent teams since now you made it their job to deliver reports rather than improving the product.
> I know I don't want to go back to the waterfall days of requirements gathering for weeks, then being held to a schedule that was built entirely on hypotheticals.
Removing constant scheduled reports and meetings all the time does not necessarily mean waterfall where you frontload all those meetings and reports. You could just have meetings and reports that fits the project as needed instead of forcing a one size fits all solution to everything.
Agile and waterfall are both examples of the same corporate inflexibility.
Okay but that's not really actionable. There are only a small number of highly competent people available in the labor market at any price. Occasionally you can get lucky and hire enough of them to assemble an entire team, and the results can be extraordinary (at least until the ego conflicts destroy it). But since no large organization can rely on that strategy they have to find ways to deliver value using average people who might be incompetent in certain areas. That usually means some kind of agile methodology to provide a level of predictability and prevent things from going totally off the rails.
