The fundamental assumptions behind Agile are as valid as they were 25 years ago. The problem(s) are control freak managers who are incapable of coaching their teams into taking charge at the local level, devs "who just want to code" and not think for themselves about the larger context of the work, and bullshit "life coaches" using Agile coaching as a way to "break into tech" with no tech skills.

This is fundamentally a crisis of incompetence, where people are failing to implement what at its roots is a better way of working, in certain contexts anyway, because they fear giving power and control to the rank and file.

---

Individuals and interactions -- over processes and tools

Working software -- over comprehensive documentation

Customer collaboration -- over contract negotiation

Responding to change -- over following a plan

---

I still like it. The problem is not the lack of a good manifesto, is that people don't get it.

Anyway, I like that someone else apart from me is thinking about these things! I don't know, maybe we do need a new manifesto to shake things up.

Maybe the only thing I feel iffy about here. Just feels a bit naïve, I've worked together with some really talented designers. Also worked with some really talented product owners. Can't say I've agreed with every marketer/PR person I've worked with but they've saved our ass a few times. While I do think developers have a major role to play, I don't think a company past a certain size would benefit from only devs making all decisions. A little specialization is OK when there is actually a useful task at hand.

There's innovation to be made on design or business side stuff as well. Maybe sort of lame to you, but it's helped me make stuff in the past.

Nothing to do with Agile btw, hopefully this doesn't sound like I'm pitching the tech world's private definition of capital A "Agile" with a different lens. Just a plea to appreciate that engineers aren't multitasking super gods.

The response that "you're not practicing Real Agile" may be true, but is unhelpful, as this is the norm rather than the exception. A consistent failure of any plan to succeed in its purpose after 25 years is a failure of that plan, not of the world, at least when the plan promises improvement on a shorter-than-generational timeline.

The only time I've ever seen Agile work is when the technical lead who practiced it was incredibly charismatic and forceful, and the team wanted to do what he said. Like magic. It worked great, and then the guy left, and the whole thing fell apart within months. But, I don't think what worked about that team was Agile per se, I think it was a unique individual leader that made it work, and it would have been just as successful without Agile.

I'm skeptical about methodologies. The force of the team and the company they're embedded in is so strong, it will overcome a generic system in most cases. I think you probably have to make an ad hoc solution that continually evolves, and have someone with rare abilities prune it and champion it. That is so harder. In all likelihood, muddling along is probably the realistic solution for most companies.

I recently stumbled across a blog post from 2006 explaining all the problems commonly heard today about capital-A agile. That means we've spent at least 18 years faffing about letting conmen steamroll us that it can't be a con because there's a nugget of a good idea burred somewhere in there. Good ideas don't need branding. Branding is never a good idea.

My first thought was: I would never want to work with someone who writes a rant like this. Because to me it shows a lack of empathy and self-awareness, I miss any sense or the slightest hint of humility.

Maybe the same can be said of this remark, that’s for you to decide.

The problem now is people use "agile" to mean anything from the 2001 agile manifesto meaning of the term to the 2024 F500 meaning and that's too long a span of time so the word has lost all communicative value. You can either engage in a fool's errand trying to drag the word back to the original meaning or accepting reality and letting people have it and come up with some new term like "katana development" or some bullshit that means essentially the same thing.

The "Observability" crew are good at this, I feel like every 10 years, there's a new coat of paint on essentially the same basic SRE concepts. Like how we went from Oriental to Asian American to AAPI, the mental burden of keeping up with these language changes serves as a basic shibboleth to who is paying attention enough to developments in the field.

(But really, small-a agile has been ascendant, better, and preferred in many places for at least a decade. That or related takes on agility like Shape Up.)

Some teams don´t need Agile. In many products it doesn't make even sense to use it.

I think we like to gather and discuss how to fix the world, but we know shit. The people that want to get the things done just need the resources (time, tools, money, etc). Facilitators, that should be the role of PMs.

We’ve been through that, you leave coders alone without management and the create a new game engine with custom scripting language and state-of-the-art rendering pipeline and no games to go with it and then they get sad

(I’m only half joking to illustrate the point that extreme points of view are often silly)

Which really, gives a good balanced view of the practices and the hype.

Reading, is what removed the veil in my eyes.

Are we really? The whole industry has moved on a good 10 years ago.

If you feel stuck with agile, you should probably change job.

And by ownership I mean they come back to it on every revision of the software. They add the new features, they fix its bugs ... they can burn it to the ground if they like for reasons of technical debt (or because they feel like it).

"But what if that engineer leaves and no one else understands the code?" I hear you ask.

So what. We're smart. Put someone smart on it and they'll have it figured out soon enough. Chesterton’s Fence be damned, if the new dev wants to burn it down, let them.

You have to accept some risk in this field. But also you have to allow other's the responsibility. And in my experience, they'll rise to the occasion.

The groups I was in that claimed to be Agile rotated devs around the project like, um, cogs.

Scaled Agile for Enterprise (SAFE), SCRUM, etc., generally don't accomplish this. Any methods that take waterfall and relabel it and add roles until executives are bamboozled into thinking it's Agile™, don't.

This is where waterfall probably came from:

- Royce, 1970: https://www.praxisframework.org/files/royce1970.pdf

While it's where "waterfall" came from, seems to be because someone stopped reading when they saw Figure 2.

Figure 2 is what not to do, he says it doesn't work. By contrast, he already understands principles such as prototype what works then document it, then build it again (Fig 7 Step 3 says make one to throw away) or ski with your customer (Fig. 9 Step 5 says keep tight with the customer), etc. Myth has it the DOD got excited about Figure 2 and ran with it. Most damagingly misunderstood software development paper ever?

- Spiral model: https://en.wikipedia.org/wiki/Spiral_model

Prototypes with iterative scope and rigor until it's good enough. Sound familiar?

- DSDM: https://en.wikipedia.org/wiki/Dynamic_systems_development_me...

Look at the 8 principles and especially the core techniques...

- XP: https://en.wikipedia.org/wiki/Extreme_programming

"Pairing" is why LLM code copilots "work".

* Easy to say.

If it is satire, it's quite subtle and well done. It references the old reasons why "Agile" was invented (current software development processes being bureaucratic and meeting-intensive, the new one will be lightweight and engineer-led).

If it is not satire, the juxtaposition is striking.

I think that is the problem though. It's still a system for human beings, if the majority of human beings aren't getting it, not sure it works.

I can etch my commandments on stone tablets and show some people, but unless they both understand what I'm trying to say AND actually believe it, I don't think my stone tablets are really doing anything.

But management came in and started mucking it up. They added more bureaucracy, added silly requirements such as mandatory velocity increases every sprint (numbers go up!). And added even more ceremony than was required with things like "Big Room Planning."

At one F500 company we were mandated to do retrospectives at the end of every sprint. The problems hampering the team's development were all external. 50% of the work was coding. The other 50% was chasing signatures, chasing information and requirements from other teams, dealing with security and inter-management politics, while stand-ups became hour long gab fests as coders tried on a daily basis to impress the attending management. We had no control over it the externals, and management didn't give a fuck.

> Customer collaboration -- over contract negotiation

Customer is often too busy with his own work to collaborate meaningfully.

That's why I proposed having a "build team" where you ask an individual to run your compiles for you, rather than dealing with an impersonal CI system. More Agile.

The old Manifesto sounds nice, but it's more a reaction (overreaction?) to some pathologies of the time than something that will get you very far without otherwise knowing what you should be doing.

No fucking shit. Nobody can do Agile right. I would argue that if something is so hard to get right, then it is effectively worthless.

We could be better off with for example a designer talking directly to the engineers and asking them "Can you achieve XYZ?" then the engineers thinks for a bit and then reply "We can do XY, but Z would be way more effort and not worth it at this time.". Then they decide, whether to do XY even without Z. I don't see why designers or engineers should not be capable of sitting together to come to a decision, and I don't see, how there necessarily someone needs to be involved trying to force something down the throat of engineers.

Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.", instead of sales and marketing running off selling things that don't even exist yet. Then there needs to be acceptance and trust in the engineering team's competence. If that trust does not exist, we need to ask ourselves what the company is doing with such a team.

How I have come to loath the view, that engineers are like a band of little children, who will run off and go all crazy, if there is no manager ordering them around.

Some kind of overarching goals will need to be known or thought of. Those we can extract from having contact with the actual users, and from having great ideas, that we test out and get user feedback for.

In reality most engineers never have contact with the actual user in their daily job and as such, it is of course very far removed from being agile.

I get it, I used to get really upset when business "overruled" engineering advise and decided to adopt a subpar solution, such as reaching for a 3rd party vendor or telling me what library they want me to use.

Then I realized that the job of a really good senior engineer is to offer options, be able to discuss the tradeoffs of each and to empower the business to make informed decisions that take ALL of the context into account: budgets, timelines, market pressures, planned shelf-life of the application, what "quality" means to end users etc.

It is the business' role to do cost benefit analysis. Engineers tend to get into the mindset of "there is one, 'right', way to do something." The reality is that there are many possible solutions to a given problem, each with their own tradeoffs. The business hired you to be able to provide solutions that align with business goals, objectives and budgets.

If a manager is telling you that they like a particular tool and would like you to consider it, that's a sign that you have failed at communicating. You have not communicated the fact that you have already explored various options, you have not communicated the fact that you understand that there are tradeoffs to be found among various options, you have not communicated that there are options at all. Most likely you did what engineers are inclined to do: you told them what you think is the 'right' way to do it, and they don't like that because it is too expensive and you didn't give them a single "out" so they are looking for them themselves (even though that was your job).

"Synergy: Value genuine, purpose-driven communication over forced meetings and rigid processes."

That's no different than "people over processes" from the original Agile manifesto.

"Adaptability"

What do you think 'agile' means?

"Courage: Foster an environment where taking risks and learning from failures lead to breakthrough solutions."

Courage is a value that companies either hold or they don't. At my current employer we embody this as "Normal sucks" in our core values. This tends to be a culture problem when companies don't value courage. I don't object to this one, but it suggests that the author is bitter having worked at companies that don't value this and want to maintain status-quo.

"Mastery: Cultivate engineers who combine deep technical proficiency with a clear understanding of the product vision."

Here's the catch-22 when it comes to business:

You want to hire a team of super experienced and talented engineers who can develop your application to an incredibly high standard in a very fast time.

Your first problem is that the labour pool for software is already tiny. That's why wages are high. So you have a hard time just finding these engineers in the first place. Once you've invested weeks into trying to recruit them, some Fintech company with a bigger budget snatches them up from under you.

Now say you did manage to hire a few. These are middle-aged individuals with families who cost a small fortune and have very low tolerances for bullshit. They will not work weekends. They may be willing to work the occasional overtime but only if that's a rare occurrence, they participated in getting the team into the weeds and the overtime is guaranteed to get the team back on track.

This senior engineer isn't looking to get promoted, they are already earning enough comp that more money no longer motivates them. Some of them are approaching retirement while others are looking to move into leadership positions.

Whereas you have less difficulty hiring someone with 5 years experience. This is a young person in their mid-twenties who has something to prove. They want to get promoted so they want to impress you. They are not married with children and so they are way more willing to give up weekends and churn out mediocre pull requests like it's no ones' business.

What the younger engineer needs is guidance and mentorship. They need the people that you want writing the code teaching them how to write the code that you want.

That's another culture issue. But hiring is difficult especially if the person doing the hiring is not an expert in the domain they're hiring for. This will be the case for virtually ALL tech startups that aren't being co-founded by an engineer ... you need to trust that the top engineering talent you are hiring is competent to do the tech hiring for you.

I think we'd end up doing this no matter what. If it wasn't "agile" it would be "brisk methodology" or "go-minded development" or something. The reality is people sort of just like having hand-wavy terms that they definitely know other people have heard before, but have been given an ever shifting definition for.

To that point, I've started hearing people say "kanban" or "iterative planning", explicitly as opposition to agile. Yet, there are no actual changes to the process. All the people are still here, doing the same jobs with newly renamed meetings of the same length. But we are "fighting the agile lie" because we don't say agile!

IMO, teams figure out what works for them. Totally agree that methodologies are worth being skeptical about. If you hire sharp smart folks, they figure out a stable way of working. Muddling along isn't that bad if you have smart people muddling!