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

161–170 of 271 posts

Re: Saying goodbye to Agile

#161

Post by tome »

dijit wrote: post #105
chrchr wrote: post #97

Earlier quoted context omitted.

Yes, but on the other hand, there's https://www.reddit.com/r/ididnthaveeggs/ , which collects cases of home cooks making inadvisable recipe substitutions and then complaining to the recipe creators that the resulting dish tasted bad. Sometimes there are essential ingredients and skipping them or replacing them with something else makes success impossible.

An appealing analogy but recipes have defined testable outcomes. You know what a Victoria sponge is supposed to look like (there's probably even a picture of one in the book). You can perfectly evaluate when a substitute has ruined it. Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly". What does "Agile" adoption look like? Faster delivery? Happier Developers? Mor…

> Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly".

That's not true for the way I understand agile. The way I understand it, the testable outcome is whether the principles of the agile manifesto are satisfied

For example, is your highest priority to satisfy the customer through early and continuous delivery of valuable software? If not then you're not agile.

https://agilemanifesto.org/principles.html

Re: Saying goodbye to Agile

#162

Post by mytailorisrich »

globular-toast wrote: post #112
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…

I never really got the "Individuals and interactions over processes and tools" one. What processes and tools is it talking about? Surely it's not saying I should talk to a colleague to track a change rather than use version control? I feel like I'm missing some context of what "tools and processes" it is talking about. The others I get, but only after having already spent years in software. I guess like many things y…

It is the usual and old advice that instead of, for instance, doing back and forth over emails, Jira, whatever it is more effective to just go discuss with the relevant person directly.

Re: Saying goodbye to Agile

#163

Post by sanbor »

koonsolo wrote: post #153
Aurornis wrote: post #47

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!

> Agile is defined as the process that works Can you show a reference of where it is defined like this?

    At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.
https://agilemanifesto.org/principles.html

Re: Saying goodbye to Agile

#164

Post by oersted »

dannyobrien wrote: post #44

I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not". Lewis is right that most of these principles were described before the manifesto, but I can vouch for the near-impossibility in many contexts of convincing anyone who wasn't a coder (and a lot of coders too) why these might be sensible defaults. For e…

https://agilemanifesto.org/

Re: Saying goodbye to Agile

#165

Post by qwertytyyuu »

yc-kraln wrote: post #143
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…

> Working software over comprehensive documentation this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.

If it’s good enough for a space program it’s good enough for pretty much anything

Re: Saying goodbye to Agile

#166

Post by moring »

Balinares wrote: post #91
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 mean, Switzerland and North Korea both call themselves democracies but the specifics matter. The specifics matter! These discussions are always fascinating in a sort of baffling way to me because I've only had great experiences with what I call agile. Like, you bring it into the team and within months everyone is gushing about how much better life is now. Yet threads like this one are full of people reporting awful…

> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?

Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.

Re: Saying goodbye to Agile

#167

Post by t43562 »

magicalhippo wrote: post #115
t43562 wrote: post #43

Earlier quoted context omitted.

Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th." "Oh, feature no 32 is going to take months and we realised that users can just...." "No"

> "You're going to do agile .... and this list of features will be ready on September 20th." Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then. We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.

What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect.

When there's a time constraint one has to be able to winnow out the real must-haves from everything else.

Re: Saying goodbye to Agile

#168

Post by phba »

yc-kraln wrote: post #143
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…

> Working software over comprehensive documentation this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.

Yeah, I don't understand why it has to be agile XOR waterfall. Agile development simply doesn't work in projects that have so many externally imposed constraints that there is barely any flexibility left.

Re: Saying goodbye to Agile

#169

Post by BobaFloutist »

z3t4 wrote: post #59
patcon wrote: post #30

Earlier quoted context omitted.

I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion. I'm not religious is any traditional sense, but I'd argue that it's not always the hallmark of a bad dynamic when a system always asks of you to do inner work when failures happen in contact with the real world. Sometimes that's a healthier mode than the alternative -- externalizing…

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.

Re: Saying goodbye to Agile

#170

Post by pif »

protocolture wrote: post #40
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 I see it all the time. Sometimes its justified. Like "This is only satisfied when x, y and z are correct" But then you get "We will do x and y as a compromise but not z" And then you have to explain that, the compromise is actually worse.

> "We will do x and y as a compromise but not z"

This reminds a lot of this: "I'm going to try this extremely difficult pastry recipe at home, but I'll use margarin insted of butter because and a teasponn of stevia instead of the prescribed 200 g of sugar for ."

Post reply on HN