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

131–140 of 320 posts

Re: Agile at 20: The Failed Rebellion

#131

Post by pjmlp »

heisenbit wrote: post #109
pjmlp wrote: post #53

Earlier quoted context omitted.

That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause b…

Agile willfully closing eyes to skill mismatch is a wider problem. Complex projects have a need for specialization and I cringe every time when new teams or scrum ‚masters‘ ignore that.

Yep, just pick whatever ticket you feel like working on, for example.

Re: Agile at 20: The Failed Rebellion

#132

Post by dragonwriter »

throw2500 wrote: post #123
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 des…

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

Lean is.

Agile is “It would be nice to do what works for your team in your particular challenges, not some pre-packaged one-size-fits-all processes sold by consultants. Now, here’s a bunch of pre-packaged one-size-fits-all processes, and an army of consultants selling them.”

Re: Agile at 20: The Failed Rebellion

#133

Post by tarsinge »

catmanjan wrote: post #42
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…

I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close

We kind of successfully to that in my shop, the early stage product usually being graphic mock-ups (wireframes may not be enough when the client really lacks product vision) to iterate fast.

Re: Agile at 20: The Failed Rebellion

#134

Post by watwut »

pritambaral wrote: post #112
ipaddr wrote: post #86

Earlier quoted context omitted.

They can turn out fine if you have a strong lead or senior developers.

I ran my company like this (and have recommended to clients a similar approach). It still doesn't work the way you are thinking. The "strong lead or senior developers" you're talking about: I call them TMs. Technical Managers. Because that's what their job becomes when the PM isn't technical enough. In the end, it's not the PM who "turns out fine" when paired with TMs; it's the combo of PM and TM who turn out fine. T…

Thank you! I could not put it into words, but yes this is pretty much what I observed.

They turned out fine if somebody else do that technical management work. Except that if not recognized as such, that someone else is not paid appropriately, does not have official authority nor ctual support of boss nor is he present at higher ups meetings to speak for himself. It makes the leading part much harder and is breathing ground for resentment or simply getting tired and giving up. And then it all starts failing.

It is kind of like saying that senior developer does not have to know all that much, if juniors are very good. Sure, but then your juniors are actually on underpaid senior positions. And it ki d of works, until junior senior figures and finds better place to work at.

Re: Agile at 20: The Failed Rebellion

#135

Post by sorokod »

smokey_circles wrote: post #127
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.

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 becau…

I agree and want to add that sometimes the devs are not very good at, well... "deving".

It is very convenient then to shift attention to inadequacy of others.

Re: Agile at 20: The Failed Rebellion

#136

Post by choeger »

brtkdotse wrote: post #129
yobbo wrote: post #125

Earlier quoted context omitted.

> 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.

Management in turn doesn't pay any attention whatsoever to the technology. They have no idea how quality and productivity is influenced by outdated or poor choices or simply a lack of investment into maintenance.

You need people that care about the how you do it as much about the why and the what. Everything else is going to be disfunctional rather soon.

Re: Agile at 20: The Failed Rebellion

#137

Post by sorokod »

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?

"CV driven development" is a thing. "I am bored with the old framework, let's use the new shiny one" is a thing.

Re: Agile at 20: The Failed Rebellion

#138

Post by Ma8ee »

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’ve seen countless systems built where technology choices where more exciting than economical. Why build something in c# on top of SQL-server in six months when it can be done in three years with micro services, Kotlin, Cassandra, Kafka, mongoDb etc…

Re: Agile at 20: The Failed Rebellion

#139

Post by nicoburns »

Clewza313 wrote: post #56
pjmlp wrote: post #53

Earlier quoted context omitted.

That is the theory, except on the customer side you actually need the people that will use the product. Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be. So the same mismatch is bound to happen anyway. And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause b…

This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this. Of course, this isn't applicable/possible for all types of software (you can't really iter…

One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"

Re: Agile at 20: The Failed Rebellion

#140

Post by austincheney »

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…

> The customer doesn't know what they want

If that were true the customer never drop you for the competition. The customer will drop you in a heartbeat.

The customer cannot express what they want in a language you can articulate which is something amazingly different. As a product manager you need to account for that.

Post reply on HN