Live data from Hacker News

Saying goodbye to Agile

lewiscampbell.tech

251–260 of 271 posts

Re: Saying goodbye to Agile

#251
post #249

Earlier quoted context omitted.

> this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. Counterpoint: I learned a variant of agile in exactly this type of environment, long before any of this was publicized. Which is another point: agile wasn't something new, certainly not at the time of the manifesto, which was a compromise document. But not even before the manifesto. XP,…

Not to take away from your point, but that sure does sound competent, aligned, and motivated to me!

Yeah: as a result of doing small-a-agile for a while.

Not at the start.

I guess if the point is that agile doesn't work for incompetent teams because teams become much more competent through agile, then I'll concede the point.

Re: Saying goodbye to Agile

#252

Earlier quoted context omitted.

> always the poor specs But that is fundamentally what agile is about. It's not about coding faster, it's the recognition that the specs are incomplete or wrong because fundamentally, a lot of customers cannot tell you what the want until they see it. That's why "build something simple and iterate on it" works. Regardless of how good your spec is, once the coding is done the customer is going to realise that that's n…

This is a weird backwards logic to justify terrible analysis

No this is literally in the agile manifesto. It's not logic at all, it's the written word of what agile is.

What that means is that Agile and agile are not the same thing. Most companies practice Agile, very few are agile.

Re: Saying goodbye to Agile

#253

Earlier quoted context omitted.

I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles( https://agilemanifesto.org/ ). Values are not right or wrong, they are just values you agree to or don't. The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called pro…

I think it’s long past the time where we can pretend that The Agile Manifesto is representative of what the word “Agile” means in tech companies. The manifesto is a minimal set of principles but every real world Agile shop I’ve interacted with has subscribed to a set of processes that everyone in tech would recognize as “Agile”. The manifesto has become a safe retreat that agile fans bring out whenever someone has cr…

At this point I equate the Agile Manifesto to the Communist Manifesto. Sounds nice when you read it; in practice it is an absurd endless source of suffering.

Re: Saying goodbye to Agile

#254
post #250

Earlier quoted context omitted.

Author here. So one of the main points in this massive, 700 word Treatise (which I do hope you will find the time to read) was that nothing Agile practitioners slapped their label onto was actually novel. Why re-invent agile, when agile itself was just a reinvention by "the kids" (your words, not mine) of things people in the 1970s already knew? One might as well go straight to the 1970s directly.

Yeah I read it and didn't get the point. So agile is dead? And we are now doing waterfall due to Ai needing unambiguous specifications? But also agile was nothing new because they knew that waterfall didn't work in the 70s. But now it works? Or are we still doing iterative development but the term agile is banned as unoriginal?

I am not Kent Beck; I don't have all the answers.

All AI has shown us is that we should probably write specs before we code. That was true before AI, but LLMs have just shone a light on this, and it will remain true if agentic coding falls out of fashion again.

Never once did I advocate waterfall...

Read the Royce paper, seriously. It's short, he's a much better writer than I am, and if nothing else it's a fascinating looking at the old state of the art.

Re: Saying goodbye to Agile

#255
post #145

Earlier quoted context omitted.

Venting is important. When you don't, tension builds and then explodes. It's necessary to give people a way to air complaints and be heard. And if your team has people with some organizational and social skills, you can channel that into action.

> Venting is important. Of course. But you shouldn't run retros that are focused on it.

Sure, but if people are using the retro as a vent session, maybe it's because they need an outlet. Perhaps a separate meeting titled "vent session" is what you want. Although it's important to have action come out of that meeting as well, don't want to just channels peoples' real concerns into a meeting that is intended to hear them out and then do nothing. Manipulating peoples' concerns into a channel where they are made unobstructive and ineffective, so they can be easier ignored is a pattern of bad-faith bosses. Conflict avoidance is toxic. You and the team building skills in conflict resolution can help.

Re: Saying goodbye to Agile

#256

Earlier quoted context omitted.

My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

My definition of agile is that process is a knob that you can turn. You don't like how the process is working out for your team? Adjust the process. Find the sweet spot for your team. As your team changes size and/or members, keep adjusting. "We're going to do agile by following this rigid process" is an oxymoron.

Wow I guess we were actually agile all along, by virtue of being a team that defines our own processes. Yet I don’t think we’ve ever used the word agile once in any of our meetings.

Re: Saying goodbye to Agile

#257
Here is one experience I did not maybe consider enough:

the teams that behave the closest to what the Agile manifesto seems to define as agility had three things in common, two of them were inside the team:

1. emotionally mature team members

2. competent team members that were able to deliver and knew their strenght and acknolwedge their unknowns

and the one item outside the team:

3. Trust and respect for them from the business leadership

Of course having these 3 things makes any SDLC work

Re: Saying goodbye to Agile

#258
post #59

Earlier quoted context omitted.

when it comes to some diets, some only work if you follow them wholeheartedly, like meat only diet, one speck of peppar might be enough to cause an inflammation. But generally you can't take a process that worked well for another person or company and apply it on you or your company. Like for example a training program, you can't just take a training program from a professional athlete and reuse it on your kid and ex…

I'm pretty sure a religiously followed meat only diet can't succeed at anything other than achieving scurvy.

Meat have all vitamins. But if you plan to stay on the diet forever you should eat all parts, not just the steak.

Re: Saying goodbye to Agile

#259
post #128

Earlier quoted context omitted.

My favorite Agile-ism is when Agile is defined as “the process that works for the team”. If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!

Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof). Regardless of success or failure you can say to what degree this is true, and to me this is really that only part of "agile" that is worth locking in.

In the team's power to determine a working process but in the scrum master's responsibility.

Re: Saying goodbye to Agile

#260

I've written something similar https://blog.dochia.dev/blog/waterfall-returning/ As code is less expensive, specs are the new bottleneck.

Getting the requirements right was always the hard part. Hence agile.

Yes, exactly. We move cost in another place. When you look holistically at a (complex) project, efficiencies are not that big.
Post reply on HN