[nineteen999]

It's about whatever some commentator thinks its about this week in order to get blog hits, sell more books, or to appear influential or as a thought leader etc etc etc.

Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest.

The rest just parrot on the same talking points with a different angle every week.

[wpietri]

I think your contempt here is not a bad default position, but I think you misapply it here.

I was involved in the movement before the term "Agile" existed. I agree it is now on average horseshit, and have been saying so a long time. [1] But I think that one of the things that hasn't been broadly incorporated what is mentioned here: vigorously pursuing faster feedback loops.

So many places are so top-down and plan driven that their corporate structures and corporate cultures just don't let them take advantage of release-early, release-often approaches. Done right, it is hugely powerful because you get to learn ASAP when you are wrong. But in so many places people essentially don't want to know that. They would rather lose months or years to bad plans and bad practices than seek out the kind of real-world feedback that lets them know when something is wrong. People would rather feel smart and look smart than take the hit and learn from enough mistakes that they become actually smart.

Indeed, I think the reason that so much "Agile" is horseshit is that people reject the most important Agile changes such that they can keep on believing they're doing just great. They just don't want their process rub their noses in the fact that however fast they're going, it's not in the right direction.

[1] e.g., from 2011: https://williampietri.com/writing/2011/agiles-second-chasm-a...

[cassianoleal]

The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.

Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out.

Good managers are willing to listen. Most other engineers either already understand what's wrong or dislike the current processes anyway so are open to trying a bit less of them.

When all else fails or when something feels off, get back to first principles.

[simplotek]

> The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.

I feel we need to take a step back and look at the organizational problem. Is your job to get things done in a team environment or waste time and effort reinventing the wheel of how to organize work in software development projects? If you're there to ship software then you adopt pre-established organizational methods and adapt them to better suit your team and org's needs.

It turns out that planning projects with high levels of uncertainty and frequent changes in goals and requirements is hard, and thus a JIT/dead reckoning approach to planning with all the stakeholders involved provides acceptable results while minimizing uncertainty.

So what are you going to do, if your goal is to get stuff out of the door? Are you going to reinvent the wheel or are you going to get stuff done with standard approaches?

[cassianoleal]

If the so called "standard approaches" are in the way of my delivering quality software, I'm absolutely going to call it out and do my best to change it. Most times, if that's impossible, the correct course of action is to leave rather than delivering poor quality.

[majormajor]

It's a similar version of "build vs buy" discussions that happen at every level, from "do we even build an engineering team vs outsource to contractors" to "do we include leftpad or write our own method," and everything in between.

There are people out there with high amounts of resistance to using something someone else hasn't recommended or appeared to vet, at every level.

It's often about trying to manage downside risk vs trying to maximize upside. Orgs where people are more afraid of having someone they can blame than they are motivated to truly excel are going to lean towards things they can pay other people to decide for them.

[cassianoleal]

https://www.forbes.com/sites/duenablomstrom1/2018/11/30/nobo...