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

141–150 of 320 posts

Re: Agile at 20: The Failed Rebellion

#141

Post by pjmlp »

nicoburns wrote: post #139
Clewza313 wrote: post #56

Earlier quoted context omitted.

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"

Because that isn't something their management levels will even consider a possibility, given security concerns, politics, and whatever might come up if the project goes south and a lawsuit is bound to happen.

These agile ideas only work in an ideal world of "we are all friends here".

Re: Agile at 20: The Failed Rebellion

#142

Post by brtkdotse »

Ma8ee wrote: post #138
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’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…

For real. That why I’ve focused my consulting on pure Microsoft stack at insurance companies. My knowledge _acumulates_ for each assignment, rather than having to start over with the tech du jour.

Re: Agile at 20: The Failed Rebellion

#143

Post by yobbo »

I don't think there is an understanding of why agile works, and why it is (essentially) impossible to implement in most places.

One subtle, but necessary, effect of the original scrum sprint planning is that it splits accountability between product owner, team, and master.

The effect is that, upon failures, there is a way that developers can rightfully blame the product owner or master. Part of the point of time-boxing increments is checkpoints of accountability, so that once the "contract" of a sprint has been fulfilled, the devs can not be held accountable for its product value.

If this mechanism is not in place, it means the product owner/master (or whatever title) is just another name for plain old manager with mandate to overrule anything, and in the worst cases with influence over careers of the devs. This is the high entropy state most organizations converge to. In these cases, all product failures will be blamed on the devs (in effect, if not verbally.)

In an effective agile organization, there can't exist mechanisms where blame/consequences for failures can be shifted downwards postfact. But this is also the basis for most old organizations. Hence, implementing agile in older organizations will never work.

Re: Agile at 20: The Failed Rebellion

#144

Post by mytailorisrich »

eesmith wrote: post #94
mytailorisrich wrote: post #74

Earlier quoted context omitted.

"Customers don't know what they want": this is something Agile specifically tries to address by releasing often and adapting to change. This is a quick feedback loop: the customer can quickly see a product and the development can quickly adapt. What was the 'standard' way to develop systems when the Agile Manifesto was written: the same as for building a bridge. You gather and freeze requirements. You write a massive…

Your characterization is not true. The reality was quite the opposite. Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1: > The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date. > When the time came…

The 'standard' method is the waterfall model, which proceeds like you would for a bridge (of course this is just an approximate analogy) from specs, to architecture, detailed specs, implementation, and tests.

Of course the shortcomings of this model have been known for a long time to anyone building software and so a number of other models appeared.

Re: Agile at 20: The Failed Rebellion

#145

Post by tchalla »

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?

It’s a constant daily struggle to explain technology experts that inferior technology with superior business/customer/product results can be prioritised over superior technology with inferior business/customer/product results.

Re: Agile at 20: The Failed Rebellion

#146

Post by denton-scratch »

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…

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

I beg to differ.

A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint.

You need this team lader role to keep the suits off your back, and to ensure the demands are achievable.

Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.)

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

I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.

Re: Agile at 20: The Failed Rebellion

#147

Post by gonzo41 »

habitue wrote: post #19

I think the big divide here is between tech companies and non tech companies. Tech companies can look at the agile manifesto and use it as a heuristic guide, because engineers are already kind of on the same page about it. You don't need heavyweight process etc. Non tech-companies need the window dressing of tech companies to retain their best engineers, but ultimately agile is kinda telling them to turn everything u…

I totally agree, and I think another big reason Agile fails to cut through in companies is because anyone who wants to be Agile in a non tech company is fighting a crushing bureaucracy. So rather than innovating and climbing higher on innovation they leave due to the massive inertia that is encountered trying to change company culture.

Re: Agile at 20: The Failed Rebellion

#148

Post by avereveard »

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?

The whole JavaScript ecosystem

Re: Agile at 20: The Failed Rebellion

#149

Post by sorokod »

choeger wrote: post #136
brtkdotse wrote: post #129

Earlier quoted context omitted.

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.

I would argue that technology is in general not management's responsibility, but resource allocation is.

If you care about quality and productivity, please quantify those and present your findings in terms of tradeoffs.

Post reply on HN