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

151–160 of 271 posts

Re: Saying goodbye to Agile

#151

Post by surgical_fire »

azangru wrote: post #142
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…

> 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 Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.

It signals to me that the process doesn't work in reality. You are better off doing something else.

Re: Saying goodbye to Agile

#152

Post by kombookcha »

zelphirkalt wrote: post #136
kombookcha wrote: post #101

Earlier quoted context omitted.

Stay hopeful, maybe Nu-Agile will become annoying in new and interesting ways!

Perhaps needing to estimate tasks in cloud credits? That would be a new one. And then of course mapping those credits uselessly to time needed.

Maybe you gotta do daily standups with all your own Agents and then have both you and them do standup with the rest of the team's Agents to touch base, sync up and loop back or whatever.

Re: Saying goodbye to Agile

#153

Post by koonsolo »

Aurornis wrote: post #47
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…

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?

Re: Saying goodbye to Agile

#154

Post by Cthulhu_ »

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…

That's it, "excellent teams" are a needle in a haystack; the mythical 10x developer, if you will.

But at one point you need not one team, but a hundred.

Re: Saying goodbye to Agile

#155

Post by madeofpalk »

strangegecko wrote: post #84
locknitpicker wrote: post #72

Earlier quoted context omitted.

> My favorite Agile-ism is when Agile is defined as “the process that works for the team”. What compels you to believe it isn't? I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently". What leads you to believe Agile implies a fixed set of precise, rigid rule…

The problem is a disconnect between management and those who build. My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts". As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).

This is the problem with 'Agile', and why people refer to it as "Capital-A Agile".

As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you. They want to stay in business, so they need to make sure they have something to sell.

That's the dysfunction - a company that is forcing this laborious process on you, rather than giving teams the autonomy to figure out how they best work.

Agile works best as a toolbox of practices you can adopt, mix, and match to solve whatever problems you have. Do you need to work to a fixed schedule, or provide delivery estimates? You should probably have a way to regularly estimate your work. Are you struggling to actually ship and do things? Maybe it would be useful to plan things on a smaller, more frequent cadence.

Re: Saying goodbye to Agile

#156

Post by tru1ock »

Gather requirements -> Small focused spec -> code -> Validate -> Fix/Adjust -> Remove spec once it is captured in code and tests.

Agile is stronger than ever, spending time on every small detail in a waterfall approach makes you burn human time on work that most probably could have been perfectly fine with a default approach.

Context matter but I fail to see people spending months on planning out a system before building anything.

Re: Saying goodbye to Agile

#157

Post by Cthulhu_ »

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…

Yeah we work agile, just look at this diagram, it's super agile. https://framework.scaledagile.com/safe-6-0-configurations/

It's got loops and infinity markers, AND iconography representing humans!

Re: Saying goodbye to Agile

#158

Post by koonsolo »

tiew9Vii wrote: post #34
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…

> In that: if it fails, it is only considered evidence that you were not doing it enough. Seen this multiple times The problem is agile as in the original manifesto was an ethos, not a process. Everything since the manifesto, called agile, has tried to wrap an ethos up as a process, playing lip service forgetting the ethos. High performing teams are already doing agile, following the ethos without attempting to be ag…

> High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.

This is also my observation. I compare it to McDonalds vs a star restaurant. Put the top chef of a star restaurant in McDonalds and he will perform average. Put a McDonalds member in the star restaurant and he will perform badly.

The amount of process needs to be tweaked to your team. Ideally, you can give your star players more freedom.

Re: Saying goodbye to Agile

#159

Post by 59nadir »

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…

One example of this would be that it's better to go over to your buddy in QA to talk about the feature you just pushed instead of jumping into Jira and activating your overwrought, weirdly scripted kanban flow that requires 3 asynchronous steps to be taken for it to actually be picked up by anyone who can finally give a damn.

Re: Saying goodbye to Agile

#160

Post by Cthulhu_ »

brigandish wrote: post #35
darkhelmet wrote: post #18

Agile, as implemented in every big company that I've worked for, was a lie. It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once…

How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?

That's the neat part of agile / scrum / whatever at larger companies, they don't actually change priorities much from one sprint to the next unless there's a major external factor like an outage. Larger companies like to be able to look ahead, at least a quarter but ideally a year or more.

At my current contract we use "SAFe", "scaled agile framework" which basically revolves around quarterly plannings, but above that is a long term planning of course. (energy industry, scale of hundreds of engineers)

Post reply on HN