Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Is a Tainted Term

pcloadletter.dev

Post reply on HN
Print view View original

101–108 of 108 posts

Re: Agile Is a Tainted Term

#101

Post by Jensson »

foofie wrote: post #41
i_have_an_idea wrote: post #8

Agile/Scrum is one of those things that are impossible to criticize. You can come up with a well-reasoned critique of Agile and there's always some Agile evangelist that pops up to tell you that you're not doing "real agile" and, therefore, your experience is invalid. At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the…

> You can come up with a well-reasoned critique of Agile and there's always some Agile evangelist that pops up to tell you that you're not doing "real agile" and, therefore, your experience is invalid. What I've seen the most is people putting up straw men in place of Agile, and proceed to attack the strawman in spite of being repeatedly pointed out they are pummelling a straw man.

Problem is that managers actually tells you to follow that straw man.

Re: Agile Is a Tainted Term

#102

Post by nothercastle »

whstl wrote: post #60
thimp wrote: post #12

Earlier quoted context omitted.

I’ve seen agile done well once. Yes it does happen. The process was not described, spoken of or even considered. It just existed between a few like minded decent engineers. Their manager got an “agile PM” forced on them and it broke. The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.

I also had perfectly operating squads crumble to dust because of PMs, more than once. I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.

I honestly don’t understand how teams in large companies operate without pms. In the initial 5 man design phase sure skip them but when it need 10 groups to deliver some small change that they give zero fucks about the pm is there to keep everyone annoyed enough to do their job.

Re: Agile Is a Tainted Term

#103

Post by nothercastle »

hkt wrote: post #16
thimp wrote: post #12

Earlier quoted context omitted.

I’ve seen agile done well once. Yes it does happen. The process was not described, spoken of or even considered. It just existed between a few like minded decent engineers. Their manager got an “agile PM” forced on them and it broke. The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.

Exactly the same thing here. Once some interloper with paper qualifications and no tech background rocks up and says "this is how agile works!" you're doomed. The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anythin…

Not everyone deserves a voice in every conversation. We had an office assistant once’s that had really strong opinions about how to implement features. They were not well informed.

Re: Agile Is a Tainted Term

#104

Post by Tabular-Iceberg »

viraptor wrote: post #96
Tabular-Iceberg wrote: post #69

Earlier quoted context omitted.

He's not saying replacing customer collaboration with programming. He's saying replace bleeding clients dry under the pretense of customer collaboration with programming.

He's saying the customer collaboration is just a con for bleeding clients dry and he should just do programming. I read "just" as only/instead in this case.

As presently practiced they all indeed are cons for bleeding clients dry. I haven't met Zed, but I can't imagine he thinks he can read minds, he must ask at some point what the customer wants to get out of the project. But the endless bikeshedding meetings and piles of useless UML diagrams and other documents is indeed just a scam.

The most absurd thing of it all is that even in-house development organizations behave the exact same way, despite having the exact opposite incentives.

Re: Agile Is a Tainted Term

#105

Post by watwut »

whstl wrote: post #98
watwut wrote: post #93

Earlier quoted context omitted.

Agile does not really works. It sometimes works, exceptionally, usually the more you try to do the by the book agile the worst it gets. Every single time they make agile reform, everything stats to suck and everything turns into ritualized micro management.

I'm all for criticizing agile etc if it doesn't work, but this is such a generic complaint. What's "by the book" agile? Scrum? The things in the manifesto? Something that some rando Scrummaster said? And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?

It is generic, because it is the most common result of agile.

> What's "by the book" agile? Scrum? The things in the manifesto?

Definitely scrum.

> And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?

Every single detail and aspect of your work is determined by someone or something else. You have zero individual autonomy, zero individual responsibility. And zero option to do something good or bad. "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.

Yeah, it is not one person telling you how to do things. It is that every aspect of work is decided by someone else or some committee. When you have one person telling you how to do things you at least can adjust to them and negotiate some space with them.

Re: Agile Is a Tainted Term

#106

Post by pydry »

Tabular-Iceberg wrote: post #67
pydry wrote: post #47

Earlier quoted context omitted.

>Is it really vaguely defined? https://agilemanifesto.org/ does this look like a clear and precise proscription for a good way to engineer software? Or does it look more like a bunch of "inspiring quotes" from a discount southern baptist church website from the 1990s? I learned this the hard way when I was younger when I tried to write some tests for some bugs and my boss told me that we needed to deal with it with m…

They couldn't be more precise than that because each team and project has their own set of constraints and capabilities that determines how they achieve the Agile goals. I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process and not just a bunch of magic incantations to do that, like the enterprise world seems to think.

>They couldn't be more precise than that because each team and project has their own set of constraints and capabilities that determines how they achieve the Agile goals.

Part of the reason I think we need this is to be able to categorically rule "agility" given the constraints a team is under. We need a framework that can say with crystal clarity that if you force waterfall planning on a team, they won't be agile no matter how good their coach is.

This needs to be a simple yes/no framework - something that could easily be answered with a questionnaire with objective answers to questions that can't be bullshitted. "Does your company do X, Y and Z?" "Ok, you've rejected agility".

This could include things like "will you rule out measuring productivity?" (Y/N) or "will you expect detailed plans from your team on the features they plan to build with milestones?" (Y/N). "Will the team have unfiltered access to the customer?" (Y/N). These questions need to be the awkward kinds of questions that managers who want waterfall in agile's clothing will have to answer wrongly.

>I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process

The authors never even mentioned the word empirical. When I said that the vagueness of the agile principles let people project their own desires onto what "agile" is, this is exactly the kind of thing I meant.

I think empiricism is quite possibly something that ought to be included in an "agile v2.0" though. For me agility does mean doing a series of small experiments on lots of different things and keeping/expanding on the things which work and dropping the things which don't. However, that's something I picked up by myself. The principles didn't teach me to do that.

Re: Agile Is a Tainted Term

#107

Post by whstl »

watwut wrote: post #105
whstl wrote: post #98

Earlier quoted context omitted.

I'm all for criticizing agile etc if it doesn't work, but this is such a generic complaint. What's "by the book" agile? Scrum? The things in the manifesto? Something that some rando Scrummaster said? And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?

It is generic, because it is the most common result of agile. > What's "by the book" agile? Scrum? The things in the manifesto? Definitely scrum. > And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing? Every single detail and aspect of your work is determined by someone or something else. You have zero individual auton…

> "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.

See, this is already not "by the book" Scrum.

The team decides those things in a retrospective, and as long as they are releasing in a reasonable timely manner, it's alright.

If someone is being unreasonable and putting their foot down too much, then it's a management issue that doesn't have anything to do with Scrum. Either the person is a dictator, or they don't have authority and there's no management to put an end to it.

Scrum also doesn't work when the team is burning in a building on fire, but we don't blame Scrum for that.

I'm all for shitting on it, but those problems have been happening in companies for millenia. Scrum won't fix them, you gotta fix each separate problem by itself.

Re: Agile Is a Tainted Term

#108

Post by whstl »

nothercastle wrote: post #102
whstl wrote: post #60

Earlier quoted context omitted.

I also had perfectly operating squads crumble to dust because of PMs, more than once. I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.

I honestly don’t understand how teams in large companies operate without pms. In the initial 5 man design phase sure skip them but when it need 10 groups to deliver some small change that they give zero fucks about the pm is there to keep everyone annoyed enough to do their job.

It works easily without PMs if you have engineering managers and product owners.
Post reply on HN