So true. 90% of Agile practitioners give the rest a bad reputation.

Mostly agree, but process is a way to tame the incompetence, if incompetence wins process has failed

Well, yes, but - it clearly doesn't work well to only come up with a good idea like that. After initial momentum, people often took it elsewhere, or abandoned.

Which tells you a lot about people out there. Maybe one can't force a shiny cool shoe on a feet incapable of using it well, even if it would be great in many aspects. Maybe we need something that is easier adaptable by real people making up real teams and organizations out there, not just cool books and trainings.

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

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.

Agile was introduced as a way for coders to empower themselves, and make changes to the software process for themselves.

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.

I like it too, but was always a problem for me:

> Customer collaboration -- over contract negotiation

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

> Individuals and interactions -- over processes and tools

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.

Agile is like communism - it sounds like a great idea. Except it never seems to work anywhere, and everywhere that it turns into a train wreck consisting of 45 minute daily stand-ups and 3 hour meetings arguing about T-shirt sizes or whether points are equivalent to time or not, the only explanation anyone ever proffers is, "well, you weren't doing Agile right".

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.

I think we need to reverse the roles or how they play out in companies in day to day life. We need other people than engineers to _ask_ for certain changes or _make suggestions_. Not a product manager, who takes ideas from other departments as law and _makes demands_ out of that for the engineers, and then by the might of their management position push the changes through.

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.

Absolutely, I love working with great designers / markets / etc.

"The 5 Laws of Holistic Development" at the bottom reeks of being written by someone who is bitter and falling into the "us vs them" trap.

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.

To a lot of folk, that's a feature! Capital A "Agile" is just sort of a pointer to "ayyy you've heard of other companies doing this" in a lot of people's minds.

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!

Not all that counts can be counted. Not all that can be counted counts.

I hate Agile and I'm not going to try and sugar coat that. "We're drowning under the weight of clueless product leads, managers, and owners who've never written a line of code" That's why this still exists though not performant, because it some peoples entire entire careers now.

Agile is dead long live (fr)agile.

Same. I agree with most of what is said, but this is terrible way to deliver it.

I mean, that works if you give them ownership of the budget and revenue targets.

That means if the product does not meet the revenue targets, the development team decreases and the development team has to decide which of their developers are losing their jobs.

That way, when the dev wants to burn it down, they are playing with their own consequences. Autonomy comes with consequences.

No satire

Moved on to ... what?