[jdsalaro]

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.

At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.

Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.

[baq]

management is very creative, they just sometimes don't realize that agile is not a management process, it's an engineering process. it's an easy mistake to make because they want to measure engineering output somehow and introduce measurements which cause decoherence of the engineering process state if I may use a quantum analogy instead of a car one.

IOW they're trying to do their jobs (manage employees) but engineering is a high trust profession and some managers just don't have the trust (not to say that all engineers have the integrity...)

[hinkley]

That’s because Scrum is so easy to turn into a management process. It makes more sense to them than all the other forms of Agile combined. So like children reaching for candy instead of vegetables, or who will only eat carrots as a vegetable, you have to work to make them reach for something else, otherwise they will be unhealthy.

[robertlagrant]

> agile is not a management process, it's an engineering process

That's interesting - I've always thought of it slightly more broadly as a team-running process. You don't have to be doing engineering to do it; you might be building a website in Wix. You just need to iterate and inspect. What do you think?

[jdsalaro]

> management is very creative

What you described, I wouldn't accept generally under my definition of creativity.

In order for creativity to be such it must ultimately deliver value; managers "doing their job" in ways which hinder instead of supporting engineers is not creative, it's disruptive.

[the_af]

> At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.

I think most commenters on HN understand this.

But then what problem does capital-A Agile solve? It was meant to surface problems faster and empower people in teams, and benefit the customer, avoiding waste and nasty surprises. Yet we've seen enough horror stories in these past decades to understand Agile (Scrum et al) can fail just just as often and is as prone to mismanagement and meddling as the methods it was meant to replace.

It takes a strong team (leadership and stakeholders included) to make Agile work and reap its benefits. But such a strong team will probably work well with whatever methodology -- strong teams are effective regardless.

What about average teams, which Agile was supposed to be helping? In my experience, they'll fail just as often.

A method that works for a team of focused superheroes is not really applicable to the general population of developers.

[zimzam]

Capital-A Agile is for companies that want the benefits of agile (higher velocity) but don’t want to trust their employees or make any meaningful changes in how the management team operates (micromanagement, committing to rigid feature scopes on rigid schedules).

Obviously this doesn’t increase work but companies get to say they are “agile” and the management team gets to keep doing all the counterproductive management they were doing before. No hard conversations about changing how management operates or unpredictable things like giving engineers autonomy.