Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Saying goodbye to Agile

lewiscampbell.tech

Post reply on HN
Print view View original

221–230 of 271 posts

Re: Saying goodbye to Agile

#221

Post by surgical_fire »

latentsea wrote: post #205
surgical_fire wrote: post #198

Earlier quoted context omitted.

I've belonged to numerous teams that followed some form of agile, to varying degrees of success (or failure). The shape of what Agile meant in each of those teams was very different from one another. It would be disingenuous to say "the ones that succeeded were truer to Agile". If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless. A single sentence, as useful a tenet…

Useless as it might seem, I really do think it is actually that basic. Is it useless? Hardly. Take out feedback loops and see what happens.

The tenet was not useless. But it was not bought forth by Agile. It already existed.

And if this tenet is all Agile is, then it contained zero new ideas or contributions.

Re: Saying goodbye to Agile

#222

Post by duxup »

dijit wrote: post #13

There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…

I feel like Agile is just a tool. You adopt it, or parts of it and see if it works. If it does for your org awesome, if not for your org, try something else.

Organizations are all different IMO (even if slightly), and you gotta try things and move on.

Is it the fault of Agile if it doesn't work? I don't know, I'm more interested in finding what works.

Re: Saying goodbye to Agile

#223

Post by mpweiher »

psini wrote: post #181
mpweiher wrote: post #124

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 much to add just wanted to say I share the sentiment and it matches my experience :-) . I'm not smart enough to NOT keep it simple; 90% of stuff I work on at $company is really a CRUDbox and I do NOT want to "astronaut-architect" the whole thing. Comprehensive test-suite, push to prod multiple times a day, feedback, dev. That's it really.

Thanks!

> I'm not smart enough to NOT keep it simple

Yeah, sometimes I feel that most of my "amazing architecture skills" is not understanding what 90% of that stuff is supposed to do or why, and hey, maybe we can just do without it?

For reference: what we did was replace an existing system, which was running over a hundred processes on about a half dozen boxes. We replaced it with a jar.

The jar was around 1000x faster, 100x more reliable, 10x less code while handling around 10x more of the domain.

Re: Saying goodbye to Agile

#224

Post by ghusto »

> and at worst it was commercially unworkable ("Welcome changing requirements, even late in development")

It's been workable for me. We can change the requirements as late as you like, because I'm getting paid by the hour. Scaled up to a company, that translates to not giving a fixed price for anything.

If you need to give a fixed price, either be experienced enough to know by how much your agreement can change and factor that in, or turn it down. You should also turn down demands for a fixed price on novel solutions you can't have experience on.

Re: Saying goodbye to Agile

#225

Post by artemave »

dijit wrote: post #13

There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…

Aren't these just examples of sunk cost fallacy?

Re: Saying goodbye to Agile

#226

Post by latentsea »

surgical_fire wrote: post #221
latentsea wrote: post #205

Earlier quoted context omitted.

Useless as it might seem, I really do think it is actually that basic. Is it useless? Hardly. Take out feedback loops and see what happens.

The tenet was not useless. But it was not bought forth by Agile. It already existed. And if this tenet is all Agile is, then it contained zero new ideas or contributions.

It seems to have successfully popularized it though.

Re: Saying goodbye to Agile

#227

Post by Aurornis »

abrbhat wrote: post #179
dijit wrote: post #13

There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…

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 criticisms about real-world agile; Whenever someone has a complaint about Agile as implemented in the real world, someone will show up and try to defend it by pointing out that The Agile Manifesto doesn’t contain the specific thing they dislike.

The Agile industry moved beyond The Agile Manifesto almost as soon as it was popularized. We can’t keep returning to it as some safe home base that shields Agile from any criticism.

Re: Saying goodbye to Agile

#228

Post by lamasery »

surgical_fire wrote: post #151
azangru wrote: post #142

Earlier quoted context omitted.

> if it fails, it is only considered evidence that you were not doing it enough. Or not doing it properly. And I understand the suspicion, I really do; but in hindsight, if you honestly tried to review how an organisation was operating, would you sincerely be able to say that it was adhering to a certain agile methodology/framework/mindset/strategy/whatever? I have so far not see an organisation that would be followi…

> I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. If that's true, wouldn't it point at the process being impossible to implement? It is a myth. There exists a version of Agil…

It doesn't really fail any worse than other inflexible top-down process mandates from management.

That's where it becomes "impossible to implement"—you can't impose it as a cookie-cutter solution driven and controlled by management, and get much good out of it, yet that's the usual way it manifests in the wild. But that's not so different from anything else management might push in its place.

Re: Saying goodbye to Agile

#229

Post by lamasery »

t43562 wrote: post #37
dijit wrote: post #13

There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere. In that: if it fails, it is only considered evidence that you were not doing it enough . The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty. It's also true for Cloud providers; that they're not suited for certain…

It's usually because your company doesn't fundamentally want it. You cannot have roadmaps with lists of features that you advertise to customers AND have the flexibility to decide to ignore things that turn out to be useless or disporportionately time consuming. If someone handed you a plan for making a jet engine and you messed around with the instructions ... why would you expect it to work? If you have a bug becau…

> It's usually because your company doesn't fundamentally want it.

BINGO. Managers and execs want (or get sold on) "agile" but only want it to affect the structure and processes for the very lowest-level workers. They don't want to change the organization or what they do, and odds are those are really bad and won't let most systems like this, agile or otherwise, function properly.

(The big secret is there's no framework like this that "works" for fixing broken organizations; there are [rare!] well-led well-managed organizations where damn near any halfway-reasonable system they choose will work, so if they decide to do Scrum or whatever in places like that it'll work just fine—and then there's everyone else)

Re: Saying goodbye to Agile

#230

Post by lamasery »

9dev wrote: post #65
endymi0n wrote: post #21

I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams. For reference, here's all the Agile you need, it's 4 sentences: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding t…

> […] when applied to small, excellent teams. Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more…

Yeah, managers adopt agile to try to un-fuck their organization but it doesn't actually do that. You need an un-fucked organization first.

It's not a system of management and it won't work if the way you're managing sucks. Nothing targeted at a similar "level" as the various "agile" systems will either, though.

Post reply on HN