[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?

[mcmcmc]

Maybe it would be more accurate to say agile is a way of doing things, not a way of managing people.

[baq]

yeah I completely agree, well put; I also like the sibling's 'process of making/doing things'.

[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.

[mwigdahl]

This sounds cynical on its face but it is my experience as well. Management does not actually trust engineers to provide value without close oversight (sometimes with good reason!), so any framework that purports to give engineers more autonomy will eventually be subverted by the management. And since management always has more power than line engineering, they always win.

The only way for "true" agile to really take root would be for management to trust engineering to add more value on their own than when being micromanaged. That's a tall order, and gets much taller in larger organizations.

[seadan83]

Agile is not there for higher velocity! It is sold to management that way often, but intrinsically - no.

Agile though is meant to reduce waste. In other words, you don't march faster, but are supposed to spend more time marching in the right direction. (I personally loathe agile and find it intrinsically broken.. I just find it kind of funny that a process oriented around dynamic environments is supposed to give predictability and speed, when it gives neither. If anything, a lack of predictability since direction can change)