Live data from Hacker News

Agile at 20: The Failed Rebellion

simplethread.com

71–80 of 320 posts

Re: Agile at 20: The Failed Rebellion

#71

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

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

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

It isn't.

Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.

Re: Agile at 20: The Failed Rebellion

#73
post #16

I never really understood the hype around (f)ragile (as one famous google engineer called it in a small closed circle a few years ago). I think the main problem is that in the past 7-8 years it has become more of an evangelism effort rather than anything. > The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning. Yet here we are: The process just became an endless…

Using story points for evaluating developers goes against the ideals of Agile. It also makes story points useless. See Goodhart’s law.

Indeed, that is why Agile has failed, the OP comment is a typical day on an "Agile" enterprise corporation.

Re: Agile at 20: The Failed Rebellion

#74

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…

"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 plan and plenty of specs. You code accordingly. You deliver.

Time to working software is long and a lot of the effort that goes into specs is wasted, especially for design specs.

Re: Agile at 20: The Failed Rebellion

#75

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

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

Was one of the least soul-crushing and nicest experiences in professional software development.

Re: Agile at 20: The Failed Rebellion

#76
post #29

If nobody does something there is a chance it doesn't work. The most problematic point to me seems to be point 3 'customer collaboration'. Does anybody know how to do that in real life? What does the sales team sell then? And more important how do you prevent feature creep from the customers side wanting more and more things during the process? To me I only see this working if you sell working time instead of a produ…

The sales team sells what has already been delivered. In my experience, the customer collaboration happens through a proxy called the product manager. It is their job to hold meetings with customers to figure out priorities. You don’t “prevent” feature creep ever. It is part and parcel of development. You can, however, manage it by restricting when the goalposts change. In Scrum, that’s at sprint boundaries. The most…

Except most customers only pay when it goes live, or reaches major milestones, and then you are out of budget, struggling to find another parallel project to somehow keep the team in place, before management states it is time to move on.

Re: Agile at 20: The Failed Rebellion

#77
post #13

Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. It's a slippery slope, way to easy to over do. The risk is it starts something to be gamed/incentivized instead of actual progress.

I think the fuss about the daily scrum is a perfect example of what is wrong with many Agile transformations. Often it seems that people talk about the 'micromanagement' and 'wasted time' as if they would not enjoy the daily. To me this is a warning, that something within the setup is not right. In general, micromanagement requires hierarchy, but I don't recall from the Scrum Guide [1] that a manager should be presen…

> negative emotions involved

Because the daily standup can only be X minutes, someone always gets cut off, causing negative emotions.

Re: Agile at 20: The Failed Rebellion

#78
The biggest problem I have with agile is the absoluteness of its proponents. “There is no other truth than agile, and if you don’t agree you’re old/immoral/…”.

It’s the sad combination of not being open to test other approaches and condemnation of people questioning it.

Re: Agile at 20: The Failed Rebellion

#79
post #38
post #13

Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. It's a slippery slope, way to easy to over do. The risk is it starts something to be gamed/incentivized instead of actual progress.

> Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. I would put things differently: micromanagers leveraged the agile and scrum buzzwords to justify and convey an aura of legitimacy to micromanaging. I mean, how many orgs forced daily meetings where workers are forced to enumerate what they did and delivered in a short time frame, but mysteriously left out t…

> workers are forced to enumerate what they did and delivered in a short time frame

This is one example how processes supercede people even though that is against the original agile manifesto.

Re: Agile at 20: The Failed Rebellion

#80
Okay, so agile was a very nice and principled idea.

And what we got from that through corporate senior management involvement is some sort of “scalable agile framework” or a minimal surrogate of “agile scrum”.

Might not be ideal, but it still generously beats the waterfall with quarterly “slave galley-style” weeks of overtime to make it to “the release” and to be able to deploy things that actually already became irrelevant 5 weeks into the release cycle.

Post reply on HN