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

301–310 of 320 posts

Re: Agile at 20: The Failed Rebellion

#301

Post by nerder92 »

I totally love this part:

When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing “Agile”.

I can totally relate with this experience in a previous company I've worked with. They effectively starting the transition to Agile, but the execution was so poor and the general culture was so immature with a lot of chain of command and top-down that it ended up being a total toxic nightmare. I end up blaming Agile for this at first, but now i'm realizing that was not the tool.

Re: Agile at 20: The Failed Rebellion

#302

Post by bosie »

pjmlp wrote: post #62
bosie wrote: post #33

Earlier quoted context omitted.

Any advice on how to calculate the first?

For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. As for how much money it costs me an FTE to play around something out…

> For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month.

No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic.

> For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month.

That is not really what I was asking for or my parent talking about. We were talking about specific salaries. Engineer X wants Y salary. justified or not? You are suggesting revenue/hours.

With that logic, everyone gets the same salary and you would also value the identical work differently depending on the revenue (which might or might not be justified)

Re: Agile at 20: The Failed Rebellion

#303

Post by pjmlp »

bosie wrote: post #302
pjmlp wrote: post #62

Earlier quoted context omitted.

For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month. As for how much money it costs me an FTE to play around something out…

> For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic. > For product development, the price of licenses and support deals per month, correlated to the hourly cost of e…

Value/work is driven by market.

Too many Java devs to chose from? Salaries going down.

Can't get hold of them? Salaries going up.

Whatever engineer wants is driven by market prices in land, and offshoring prices as well.

And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement.

Re: Agile at 20: The Failed Rebellion

#304

Post by pydry »

rramadass wrote: post #294
lrdswrk00 wrote: post #238

Earlier quoted context omitted.

They’re purposely ill defined. The outputs they seek are emergent. You also belittle scrum for becoming too specific. Seems you’re still processing what to make of any of it. Knowledge work is immaterial and should have no prescribed rails or all you get is run of the mill outputs. It’s similar to business; billions have been spent investigating what technology or management style brought the biggest gains. The math…

To apply one of my favourite phrases to your post; "What ineffable twaddle" ! I highly recommend to you the works of David Parnas, Barry Boehm, Fred Brooks, Gerald Weinberg for edification. Start with the paper; "A Rational Design Process: How and Why to Fake It."

Big fan of all of those already. Fred Brooks in particular is seriously underrated.

Re: Agile at 20: The Failed Rebellion

#305

Post by nrvn »

It’s been a long while since I read the manifesto last time.

> Responding to change over following a plan

“Responding to change” is treated as a right to bust WIP at any moment in time. All engineers I have worked with want a roadmap and a plan that has enough room and flexibility to be changed due to some external circumstances (bespoke “change”).

> Working software over comprehensive documentation

This statement puts two characteristics of a software product (be it SDK, library, source code package, binary, whatever) into contradiction. Working software is accompanied with comprehensive documentation.

> Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Late requirements change is what all engineers hate… And as stated in a number of comments here customers want no more than a faster horse. Best products ever made were not made based upon focus group feedback.

> The best architectures, requirements, and designs emerge from self-organizing teams.

Are scrum masters an antipattern then or just a sign that the team in question is not self organized and immature?

Bottom line: any “agile” methodology I’ve come across and experienced myself for the last several years is a mix of cargo cults, religious ceremonies and abusing the word “agile” to justify chaos, incompetence, ignorance and arrogance.

What in essence all the agile methodologies are meant to be is the domain specific extension of the PDCA cycle.

https://en.wikipedia.org/wiki/PDCA

Re: Agile at 20: The Failed Rebellion

#306

Post by zugi »

commandlinefan wrote: post #288
dirkt wrote: post #57

Earlier quoted context omitted.

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

The Agile Manifesto never came out and said so, but it only ever made any sense if you give up the idea of a fixed delivery date. Of course, the idea of a fixed delivery date for a software project never made sense in the first place, but you’ll have to pry that nonsense from their cold dead hands. Big-A “Agile” is an attempt to keep what they (think they) want… so it ends up being useless.

Or you can have a fixed delivery date, but not a fixed feature set. If a feature isn't ready by the release date, it gets pushed to the next release. If you deliver often as agile encourages, this is a fairly short delay.

Re: Agile at 20: The Failed Rebellion

#307

Post by kapad »

kps wrote: post #241
pydry wrote: post #192

Earlier quoted context omitted.

The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are,…

> Scrum (the catholic church to agile's christian sect) At least the Church only had confession once a week in private.

Hahahaha.. this is brilliant!!

And treat this comment as an acknowledgement for all future occasions on which I quote you.

Re: Agile at 20: The Failed Rebellion

#308

Post by wheelinsupial »

rramadass wrote: post #293
pydry wrote: post #192

Earlier quoted context omitted.

The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are,…

>The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. thank you, Thank You, THANK YOU! It is a useless set of vague platitudes which offered nothing but a sense of seeming aphoristic depth. How so many people fell for it is still a mystery to me. Instead of focusing on the core problem of Requirements…

> the core problem of _Requirements gathering and Software Specification_

Where I work there was a huge shift in this.

From Business analysts (BA), who usually had comp sci or engineering degrees, and an expectation to get PMP and CBAP / PMI-PBA / other BA certification to move up, were responsible for requirements.

Now we have product managers and scrum masters with a 1-3 day agile certification and no comp sci or engineering background who are responsible for requirements.

Re: Agile at 20: The Failed Rebellion

#309

Post by bosie »

pjmlp wrote: post #303
bosie wrote: post #302

Earlier quoted context omitted.

> For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month. No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic. > For product development, the price of licenses and support deals per month, correlated to the hourly cost of e…

Value/work is driven by market. Too many Java devs to chose from? Salaries going down. Can't get hold of them? Salaries going up. Whatever engineer wants is driven by market prices in land, and offshoring prices as well. And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement.

> Value/work is driven by market.

i might be missing something but you are still equating value of work with salaries for some reason. this is the context we are discussing, the original quote: "How much of each dollar you make for the company with your hard work do you take home?"

i was asking how you calculate how much you make for the company. you specifically. not 'revenue/hours' or whatever. you and you only. salaries do not factor into this. how could they?

> And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement.

that isn't true though. this might be the case in some countries (please provide a reference) but in europe with strong unions and collective agreements, it is wrong. it sets the minimum standard and companies pay over that agreement all the time.

Re: Agile at 20: The Failed Rebellion

#310

Post by rramadass »

wheelinsupial wrote: post #308
rramadass wrote: post #293

Earlier quoted context omitted.

>The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion. thank you, Thank You, THANK YOU! It is a useless set of vague platitudes which offered nothing but a sense of seeming aphoristic depth. How so many people fell for it is still a mystery to me. Instead of focusing on the core problem of Requirements…

> the core problem of _Requirements gathering and Software Specification_ Where I work there was a huge shift in this. From Business analysts (BA), who usually had comp sci or engineering degrees, and an expectation to get PMP and CBAP / PMI-PBA / other BA certification to move up, were responsible for requirements. Now we have product managers and scrum masters with a 1-3 day agile certification and no comp sci or e…

My sympathies!

Nothing is worse than non-domain knowledgeable, non-technical people lording it over actual Technical Engineers who do the work.

I always recommend Dave Packard's 1960 "Speech to HP Managers" to every "Manager" - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...

Relevant Excerpt:

Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.

This is how great companies were built.

Post reply on HN