[alganet]

The old manifesto is fine, isn't it?

---

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.

[graypegg]

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

[bumby]

This is somewhat ironic, considering the first point. If the process is not intelligible to most humans, maybe we should focus on refining/clarifying the process a bit?

[bb88]

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.

[alganet]

Exactly.

Velocity was supposed to reach an equilibrium and then remain constant. Not over taxing the team is essential. If the meetings are a drag, there's something wrong. If people are burning out, there's something wrong. Those are very old lessons.

[JodieBenitez]

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.

[Rotundo]

If the customer doesn't think their project is important, why should I?

[JodieBenitez]

hence why a contract is still important.

[jrs235]

Correct. "while there is value in the items on the right, we value the items on the left more.

[jrs235]

As stated in the manifesto "while there is value in the items on the right, we value the items on the left more."

That doesn't mean there isn't room or need for contracts. A contract can and should exist with clear expectations of the customer's involvement and availability with customer response and turn around times and what the consequences are if the customer doesn't fulfill their end of the "bargain".

[zelphirkalt]

If you go to the customer and the customer doesn't answer your questions, that is obviously a huge problem. Then that customer is not ready to work agile. Maybe the situation can be salvaged, maybe not. If not, then apparently it is not the customer you would want as an agile team.

[skeeter2020]

The manifesto intended that your customer can (and often will) be a proxy. You need a PM who gets out of the office, empathizes and understands clients, talks to customers. A big part of what's wrong with "agile" today is BS product managers.

[dllthomas]

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

[alganet]

Fair enough.

The original reaction for that pathology is "The Mythical Man-Month", it's what started everything. From my point of view, we're still man-monthin'.

The Agile folks just translated a personal reflection from Fred Brooks into a culture (then some companies made it into a cult).

Anyway. In your opinion, what the pathologies for _this_ time would be?

[drewcoo]

> The original reaction for that pathology is "The Mythical Man-Month", it's what started everything.

In software, Gerald Weinberg was writing about how to organize and optimize this stuff at least a decade before Brooks.

And Edwards Deming's work led to a lot of agile ideas. That strain of thinking is traceable at least back to the Napoleonic-era's Prussian artillery. The mythical man month isn't really a software problem; it's a human organization problem.

[dllthomas]

I very much agree that Brooks didn't "start everything" but I think he brought value to the discussion of those human organization problems in the context of software. Weinberg got there earlier but I feel like I personally got more of value from Brooks. Obviously YMMV.

[dllthomas]

I think there's some space between MMM and agile and the former (as problem statement more than proposed solutions) holds up better. It's been a while since I last read it, though.

> Anyway. In your opinion, what the pathologies for _this_ time would be?

That's certainly an interesting question; I don't have a ready answer.

[ryandvm]

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.

[bluGill]

Agile works very well for small projects. When you have less than 10 developers it gets rid of a lot of overhead. However those are situations where project management isn't really hard and so they didn't need it. Companies doing projects with hundreds of thousands of developers are hurting because nobody can do project management. Agile seemed to help and so they jumped in. However painful experience with agile has shown there really was a good reason for all those processes agile go rid of! They are back to waterfall because at the end of the day they have real problems and all solutions end up pushing them to do a lot of pre-work planning to have a chance. Not that waterfall is good - it isn't - but everything else is worse as painful experience keeps showing.

Note that while we call what they are doing waterfall, in fact it isn't. All (nearly all?) projects are doing releases. They do go back and change things made in the past, just that the timeline is very long. They do discover things are not working and stop - sometimes they don't realize this in time to stop early, but they do stop.

What the world needs is a process for large numbers of people to develop software without stepping on each other. I do not have an answer to this problem - I'm not even sure if it exists.

[josephg]

The people who “do agile right” are out there. Just, like the agile manifesto says, they’re authoring their own processes. And because of that, they don’t have to call it agile - or really call it anything. They just go into work, figure out what needs doing, and take responsibility and do it.

I’ve worked in plenty of teams that did this sort of thing. All different. And at different scales - startups to big tech to game jams.

[jjmarr]

Nobody can do Agile right because there's no one-size fits-all process. There are Agile approaches you can use and see if they work for your team.

The motto is "individuals and interactions over processes and tools" because if a process or tool isn't working for you, you're not supposed to use it.

It's like communism in the sense that it's defined with all the good quantities you'd want in a society or workforce and has several conflicting methods to get there. It's a set of principles that invites people to argue about how their approaches fit into them. Maybe that's the point.

[alganet]

Sounds like you expected it to be a silver bullet. Is there something in the agile manifesto that implies that?

[reverendsteveii]

My team spends half an hour per week on standups and about 2 hours every 3 weeks pointing stories. Any interaction beyond that is on an as-needed basis and mostly I'm just trusted to figure out what needs doing and do it. Agile is like communism - problematic, but mostly maligned by people who don't understand it using examples that are either made up whole-cloth or cherry-picked and then badly distorted in the retelling.

[computerdork]

Yeah, kind of disagree with this. Compared to waterfall, agile is definitely an improvement.

And most teams get the core ideas right in my opinion: small, tight knit teams working closely together, with a "reduced amount" of process (yeah, think the number of meetings in agile is bad, in waterfall, meetings seem like crush you like a tsunami).

[skeeter2020]

it's a lot less like communism and much more like a co-op or member-owned/lead organization - which can and totally do work. Think a bunch of farmers banding together to start a credit union vs. a big centrally planned org.

[cholantesh]

Co-operatives and worker self-management can and have existed under communism.

[psunavy03]

Bullshit. That's like claiming no one can play good football because the Cleveland Browns suck.

https://ronjeffries.com/xprog/articles/jatbaseball/

[SomeCallMeTim]

No, and Jeffries' analogy suffers the same strawman fallacy.

The proper analogy would be if no one knew the rules of football/baseball and everyone ended up playing Calvinball instead, then you could say that football/baseball was broken. If following the rules of football produced a product of its own if the rules were followed, it shouldn't matter that other people can follow those rules better.

Or you can point at Monopoly and the fact that so many people destroy the game by playing the "Free Parking gets the kitty" rule and use that as an excuse that Monopoly is a terrible game. Well, Monopoly is a terrible game, even as designed, so that one works.

It's not about how well people follow the "rules" of agile. It's that most everyone who tries doesn't understand the intent of agile.

I would argue that most of the attempts at codifying agile, from Extreme Programming through whatever the latest fad is, are all also wrong. That if you codify agile at all, you're missing the point.

In my experience, the OP article is correct: You need good developers on the team. That's it. That's the secret to success. The methodology you use is nearly irrelevant, though some methodologies do more harm than good.

The fact that XP's flagship project (C3) was an abject failure should have been a clue that maybe it wasn't as good as people want to believe it is. Maybe Kent Beck wasn't "doing agile right" either?

[tomxor]

You are likening American football to communism? So which regime is Cleveland Browns, and which are the functional ones?

[drewcoo]

< Agile is like communism - it sounds like a great idea. Except it never seems to work anywhere

Agile always fails because it's undermined from the inside.

Communism always fails because it's undermined from the outside.

[alganet]

Agile is like communism. Lots of people like to hang external ideas to it. Some valid, some not.

Points, t-shirt sizes, figmas, etc... these are _tools_ and _processes_. Why the hell are you complaining about it when it says very clearly that you should focus on people and interactions?

[bluGill]

Because I have real problems. People and interactions as a focus shows me where those problems are, and now I need solutions to solve them. Those tools and processes that agile often uses are the type of things I need to make my people and interactions work. (or at least that is their promise) I should not be developing my own tools when someone else already has some that works.

[ryandvm]

Oh, well if Agile is just a vibe then count me in.

[skeeter2020]

it's more than a vibe, the challenge is it's "Here's a bunch of things that can help; pick and use what works but don't be dogmatic about it". This is impossible to scale, as by definition it's anti-scale, which is why companies run into massive problems and pervert agile into whatever they have now.

[alganet]

If that's the problem, then it's easy.

Do not think about the tools. Think about small improvements that can move the team in a more productive and sustainable (agile) way.

Simple things. Like putting a timer on long meetings until people get used to not extending it. Or putting a limit on the work pipeline between the developer and the tester to avoid overwhelming testing sessions.

In my opinion, you are not supposed to start from scratch. The chaos often comes from this "let's blank slate everything and adopt all agile things we can find". Once again, the same mistake of focusing on tools instead of interactions between people.

C'mon, it's not that hard. Doesn't need to have strict rules.

[bluGill]

> Think about small improvements that can move the team

Which team? My team of 5 people or the entire project of several hundred? Focusing on the small teams finds a lot of local maximums that are very bad for the entire project. Many of the small changes small teams want to make are not possible because they would impact some of those several hundred other developers. Often small pain for us is much better than the pain our change would force on those others.