Agile at 20: The Failed Rebellion • Hacker News Board

Re: Agile at 20: The Failed Rebellion

#151

Post by axegon_ » Sun, Jul 25, 2021, 9:43 AM UTC

TameAntelope wrote: post #120

axegon_ wrote: post #95

Earlier quoted context omitted.

No, I mean using story points for evaluating the complexity of a task (a lot of companies/teams use them this way at least).

I think spending too much time in a large company is damaging, possibly permanently, to a developer's ability to connect value to work. On a basic level, Story Points are there because if you can't tell me how long something will take, I don't want to give you money to go do it. Everyone has to deal with this, at every level. CEOs think about this, janitors think about this, literally everyone is constantly calculati…

I spent around 11 years in large companies(anywhere between 300 and 6000 employees). It highly depend on what you work on and what's your work ethic. In all honesty beyond circumstances which were outside my control, I ended up in a small company and just now I realize how much the idiotic bureaucracy truly bothered me. And I'm acknowledging that precisely agile facilitated this hell.

I think you are looking at it from an r&d (still evangelistic) prospective, but now picture rewriting a truly ancient system still operating on mainframes(and the original developers and maintainers are no longer among the living) in a modern language where it's not a question if something is worth doing or who will do it-it has to be done. Figuring out how the old system works is a combination of reverse engineering and brute forcing. I've been there and trust me, in those circumstances story point is a synonym for a random number. This is a real life example and in those conditions agile doesn't only crack, it collapses and it mentally crushes on top of you cause you are still forced to stick to everything agile.

What I'm saying is that agile and by implications sorry points work in some extremely specific circumstances but in the vast majority of cases it only adds multiple layers of complexity which does nothing but waste valuable time.

Re: Agile at 20: The Failed Rebellion

#152

Post by Robin_Message » Sun, Jul 25, 2021, 9:44 AM UTC

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'm not sure if Agile ever claimed to be a good process for coming up with unicorn startups though.

It's a way to meeting actual business software needs, much more suited to custom development for one customer than product development, which necessarily requires some additional insight into what the market wants.

Re: Agile at 20: The Failed Rebellion

#153

Post by ako » Sun, Jul 25, 2021, 9:44 AM UTC

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…

Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go.

Agile tries to turn software development into a product design process rather than a product manufacturing process. Together with the client, iteratively you try to find the right solution and design for the customer problem.

By being easy to adopt, software lends itself to an iterative design process, where you adopt it multiple times based on the iterative feedback of the customer. But this means that at the end of the design process, you can skip the manufacturing part, as you've already built the software during design.

Alternatively you could argue that this is too expensive, inefficient and slow, and you need some design before you begin to manufacture software. Modeling tools could help here, e.g, low code tooling like CAD tools in fysical product design.

Re: Agile at 20: The Failed Rebellion

#154

Post by mmarq » Sun, Jul 25, 2021, 9:46 AM UTC

baxtr wrote: post #97

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…

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

The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup.

I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “improvement” we will get is millions of dead and injured. But for whatever reason we allow freshly minted certified scrum masters to lecture seasoned professionals on process, to organise 19 meetings a day to discuss the differences between scrum and agile and, in general, to unleash havoc and destruction.

Re: Agile at 20: The Failed Rebellion

#155

Post by draw_down » Sun, Jul 25, 2021, 9:48 AM UTC

TedDoesntTalk wrote: post #58

forgotmypw17 wrote: post #52

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.

I dunno if it’s quite soul crushing, but entire days of planning and retro certainly are not fun. Pass.

Re: Agile at 20: The Failed Rebellion

#156

Post by Robin_Message » Sun, Jul 25, 2021, 9:48 AM UTC

username90 wrote: post #128

underdeserver wrote: post #82

Earlier quoted context omitted.

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.

Being able to break down a complex technical problem into mostly one point tickets doesn't mean it is easy or mindless, just that you're good at planning and executing.

Re: Agile at 20: The Failed Rebellion

#157

Post by AndyPa32 » Sun, Jul 25, 2021, 9:55 AM UTC

mmarq wrote: post #154

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.

The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup. I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “im…

This is exactly what drove me off my last team. We were seasoned developers with a combined experience of more than 50 years, 25 of them in scrum. And we were assigned a scrum master that never worked in software development before, fresh of the scrum master training and was telling us in a very condescending tone, how we could improve ourselves and our team. That guy didn't know anything about software development, not anything about our problem domain and nothing really about our client or users. It was ridiculous.

Re: Agile at 20: The Failed Rebellion

#158

Post by TameAntelope » Sun, Jul 25, 2021, 9:57 AM UTC

axegon_ wrote: post #151

TameAntelope wrote: post #120

Earlier quoted context omitted.

I think spending too much time in a large company is damaging, possibly permanently, to a developer's ability to connect value to work. On a basic level, Story Points are there because if you can't tell me how long something will take, I don't want to give you money to go do it. Everyone has to deal with this, at every level. CEOs think about this, janitors think about this, literally everyone is constantly calculati…

I spent around 11 years in large companies(anywhere between 300 and 6000 employees). It highly depend on what you work on and what's your work ethic. In all honesty beyond circumstances which were outside my control, I ended up in a small company and just now I realize how much the idiotic bureaucracy truly bothered me. And I'm acknowledging that precisely agile facilitated this hell. I think you are looking at it fr…

There are nearly zero "must spend, at any cost" situations in business, so no I don't agree with you assertion that "it's not a question if something is worth doing". It's always a question if something is worth doing.

I've seen your argument many, many times before, and it comes from people who have divorced their understanding of value from their understanding of work.

You don't get paid to work, you get paid to provide value, and I'm not saying that's right or how it should be, but that's how it currently is. If, through your labor, you can't provide value above your cost to a company, the work you're doing is not worth the cost. One way to get an idea of how much what you're doing will cost is to ask you and your peers what you think it'll cost, and one way of measuring that cost is a Story Point.

Re: Agile at 20: The Failed Rebellion

#159

Post by jim-jim-jim » Sun, Jul 25, 2021, 10:00 AM UTC

mmarq wrote: post #154

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.

The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup. I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “im…

> We don’t allow scrum masters and agile coaches in hospitals

Give it a few years.

Re: Agile at 20: The Failed Rebellion

#160

Post by the_gipsy » Sun, Jul 25, 2021, 10:04 AM UTC

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.

Open source does self-organise, and manages to produce some products of exceptional quality. It’s just almost completely unsteerable.

In a company, you can pretend to order people around. But the truth is that what really matters is how all the personal and political goals happen to align.