[vpeters25]

Every time I see an "agile sucks" post, I take the time to read it and every time (so far) I have found they blame the process for some key part of agile they missed. Quote from the article:

“Way too much of Agile has been not about technology, but about people and about managing things and about getting stuff done — not necessarily getting the right stuff done.”

This is the whole point of agile: progress on iterations, inspect and adapt at the end of each iteration.

Your team might build the "wrong stuff" for an iteration, realize it (inspect), then make a course correction (adapt). If you end up delivering the "wrong stuff" is because you didn't follow this very core principle of agile.

I find it hard to believe these so called "Agile Early Evangelists" can make such a statement. Their background in lean development should have made the familiar with empirical process controls, from where lean and agile come from.

My guess the author quoted them selectively to fit the "agile sucks" narrative of the article.

Edit: expanded last 2 paragraphs.

[ebiester]

So, it gets complex.

I have been privileged to work in a company that really thought about and worked to prioritize the four values on the left. I would follow those agile coaches to any place they wanted. I have been a staunch defender in real life and online, because I've seen it work very well. I also have been on teams with other processes and seen how much worse it can be.

I will take the values of agile and push for those, and I'll take the lessons learned such as quick feedback loops, continuous integration, relative estimation, automated tests (which came from people like Kent Beck and Robert Martin pushing them so hard alongside agile), and the good stuff.

However, after seeing how badly it can be weaponized against developers, I'm certainly ready to throw out the bathwater, and I think this is what they're talking about. I've seen far too much cargo cult agile and far too much command and control with a light layer of SCRUM.

We have agile "coaches" who have never learned to code! They take a set of color-by-number technical practices but don't understand how or why they matter! I had to correct someone's slide that got the four values wrong, and their consulting group apparently had been copying and pasting them incorrectly from presentation to presentation!

The values and principles of agile are great. The current implementation has some serious debt.

(And while we're at it, we could update it. Too many people misunderstood the documentation part. Continuous attention to technical excellence needs to be upgraded to a value. Delivering frequently today means days instead of weeks.)

[vpeters25]

> However, after seeing how badly it can be weaponized against developers, I'm certainly ready to throw out the bathwater, and I think this is what they're talking about.

Poor management is a separate issue from agile. Even so, I would rather stay on a poorly managed agile shop than go back to a waterfall shop.

As far as the "values on the left", I like to explain them as a 55/45 split (and adjustable depending on your reality): we still deal with processes and tools, we just take a second to think whether a process is actually needed when we can just talk to someone instead.

Example: on a small team, you might just ask "can someone please approve my changes?" instead of having a whole jira workflow with code reviews and approvals.

[arduinomancer]

Every time I see a comment on an "agile sucks" post I see people saying "well that's not true agile".

Which sounds a bit like the "no true scotsman" fallacy.

If so many people have trouble implementing agile maybe it just doesn't work?

[vpeters25]

> If so many people have trouble implementing agile maybe it just doesn't work?

The problem with agile and other empirical processes of project control is that it goes against the OCD tendencies of scientifically minded people. They assume that, since programming is all math and logic, software development projects should be as well.

They add micromanaging processes in a futile effort to control what they perceive as chaos and end up trying to fit a square peg in a round hole.

[jillesvangurp]

I.e. the old "you are doing it wrong" argument. My experience is that there is no right way that you can blindly apply on any project. There is no set of magical agile dogmas that works everywhere. And there is no substitute for decent engineers doing what needs doing.

Agile was a neat idea 20 years ago and it changed the engineering practices. However, unlike the methodology, engineering practices continued to change and modern software development practices automate away a lot of what agile processes tried to orchestrate.

If you are doing continuous delivery and lean development, you should be conceiving of and shipping software features in time units smaller than a sprint (i.e. continuously). That was very rare 2 decades ago and has become the norm for a lot of tech companies. It requires asynchronous processes and practices. It's enabled by having automated builds, automated tests, and automated deployments. These tools barely existed 2 decades ago and have had a far larger impact on software development then any form of agile.

Lots of large OSS projects and software companies have made the shift from doing feature based software delivery to time based software delivery. E.g. MS famously kept missing its own deadlines with windows vista, windows 7, etc. and shifted to having a more predictable release schedule. Ubuntu's LTS releases appear regular as clockwork in April of every second year. Linux ships a kernel every 2-3 months. Mozilla ships Firefox every month.

Time based releases are basically about releasing an unknown quantity of software at specific intervals and with a high level of quality. It involves having multiple asynchronous tracks of development and instead of planning which of them need to be ready they simply use quality gates to determine which of them are actually ready to ship. It's a shift from what to when and it emphasizes quality (i.e. good engineering) over schedule.

Most agile methodologies are still stuck trying to do feature based planning. It's the project mentality from the nineties where things get commissioned and have to be delivered on a particular schedule. Worse, these things are often under specified and then blow right by their planned deadlines. Just like in the nineties. I've seen a lot of agile projects shipping low quality software doing the wrong things right on time.

[interactivecode]

With these things the reality of agile is within corporate constraints. The Big managers will want to steer the company and dictate deadlines or goals. While the pure form of agile might work the reality of agile causes a lot of friction.

Keep in mind though problems also show up with waterfall or young small startups. Its just which flavor of friction/pain project issue you are willing to deal with