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

Agile at 20: The Failed Rebellion

simplethread.com

Post reply on HN
Print view View original

121–130 of 320 posts

Re: Agile at 20: The Failed Rebellion

#121

Post by pritambaral »

ipaddr wrote: post #39
emptysongglass wrote: post #23

Earlier quoted context omitted.

> And that's why things like "Agile", "DevOps", etc will fail. I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about. If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement…

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

That's an elitist approach thinking a PM knows more just because they're a PM and and must be listened to irrespective of their competence.

In the end if you are difficult you become easy to ignore. Or worse, worked-around.

Re: Agile at 20: The Failed Rebellion

#122

Post by shsbdncudx »

Here we are 20 years later and we still can’t agree what agile even means. That is where it failed. It’s not concrete enough, and maybe it was never meant to be.

I feel like they had a great idea, gave birth to something, but then failed to nurture it and we are still evolving a solution. Ok we got scrum but we all know that’s a complete shit show.

What agile is really missing is that it doesn’t touch on leadership. We like to blame management and say they should let us do what we know, but we don’t lead. Decentralised control only works when everyone leads.

Let’s add a line to the manifesto and fix it:

“Lead from the bottom over centralised control”

Re: Agile at 20: The Failed Rebellion

#123

Post by throw2500 »

AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

Isn't Agile more or less gradient descent (well, approximating the gradient for an undifferentiable function), applied to software development?

The objective function is some function of the quality of the product, as measured by the customer, and the work put in. The gradient evaluation is then the process of determining which feature gives the most bang for the buck, implementing it, and repeating.

But gradient descent has problems with local minima. So if that's what Agile is, no surprise it doesn't do surprising projects - even if the customer does know what they want. If the programmers are too inexperienced and it's not just a CRUD, then you'll end up with something like Jeffries' TDD Sudoku solver.

Re: Agile at 20: The Failed Rebellion

#124

Post by pritambaral »

ipaddr wrote: post #89
emptysongglass wrote: post #55

Earlier quoted context omitted.

My PM does know more than me. And he's good at directing where the team should invest it's efforts. That's why he's my PM. You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.

I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product. That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.

> I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product.

No, that is not the point your parent seems to be making. Your parent talks about "earning respect by learning on the job", but you are stuck at "having respect because of background".

Your parent leaves open the possibility that a PM without technical background can still become a good PM, and even lays out what they think is required for that to happen. You're stuck at "you don't respect them, got it".

----

I'd like to remind you of this point from the HN guidelines: Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

Re: Agile at 20: The Failed Rebellion

#125

Post by yobbo »

brtkdotse wrote: post #113
outsomnia wrote: post #100

Earlier quoted context omitted.

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.

> As much as devs try to disagree, technology is not a goal in of itself

Can you find one dev that has ever disagreed with this?

Re: Agile at 20: The Failed Rebellion

#126

Post by happyweasel »

A lot of time, especially with Scrum, team communication is now formalized and non-team members participate and evaluate "the process" (indirectly). This can extinguish direct,non-formal-communication and can lead to CYA attitudes in teams... "A Process" can never be about "the people". Let's say someone would implement Scrum for football teams. Every team could follow the process to the T, n times training, 2 times weight lifting per week, daily meetings, n times cardio work, mobility training, strategy planning/training etc etc.. At the end, in the game there would still be good or bad teams. And the good team would probably be p*** off because they have to do so much formal stuffs just to "do the process right" and ensure "every checkbox in the process list has been ticked off". So yeah, I guess it is up to agile teams .. let's deliver in increments and let's ensure it is what the customer needs. Everything else is secondary.

Re: Agile at 20: The Failed Rebellion

#127

Post by smokey_circles »

outsomnia wrote: post #100
baxtr wrote: post #97

Earlier quoted context omitted.

It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.

You know why it's "easy" to blame "management"? Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

The air quotes sell it.

It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does.

Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners.

Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.

I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea".

Docker had the philosophy.

Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is...

>but insist to intercept every decision

Yes, because left to our own devices, developers will not contribute meaningful business value.

There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me).

WE as engineers need to find a better way to engage management.

But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please

Re: Agile at 20: The Failed Rebellion

#128

Post by username90 »

underdeserver wrote: post #82
TedDoesntTalk wrote: post #58

Earlier quoted context omitted.

This sounds soul-crushing and I hope never to work in such an environment.

It's not. The time spent in those retrospectives and planning sessions are about the technical aspects - how talks should be broken down, how overall design of interacting components should look like. It's 100% actual work. I'd take these over another bs "status sync" any day.

Some developers might love just mindlessly doing trivial tickets week after week, since it means they don't have to worry about anything since the job is so easy. But others will view that as soul crushing, you can't say it isn't soul crushing for them.

Re: Agile at 20: The Failed Rebellion

#129

Post by brtkdotse »

yobbo wrote: post #125
brtkdotse wrote: post #113

Earlier quoted context omitted.

You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.

> As much as devs try to disagree, technology is not a goal in of itself Can you find one dev that has ever disagreed with this?

I can find a ton of devs paying lip service disagreeing, but the second they utter “we need to rewrite this in…” the facade falls apart.

Re: Agile at 20: The Failed Rebellion

#130

Post by eitland »

TedDoesntTalk wrote: post #67
koonsolo wrote: post #34

Earlier quoted context omitted.

Agile should include retrospectives, and retrospectives should allow your team to change anything within the process as you need. In fact, all agile needs is good retrospectives, and all the rest you can decide there.

IN my experience, the same two or three people speak up in retrospectives… and no one else, ever.

I guess you are one of those?

In that case get the two others with you and decide a new rule: nobody leaves the retrospective before they've spoken.

Warning: might backfire, one team I worked with scheduled meetings right before lunch so they wouldn't stretch out.

It backfired: these meetings continued into our lunch every single time until I think I or someone else started just walking out as lunch started.

Post reply on HN