Live data from Hacker News

Agile Is Dead

agilepilled.com

81–90 of 99 posts

Re: Agile Is Dead

#81
post #73
post #68

Earlier quoted context omitted.

A company with hundreds of engineers and anyone of them can overpromise on some random feature? Sounds like a widespread communication issue.

That is why we have processes - so people know what promises they can make. Communication is hard - you can spend all day, every day in meetings and get nothing done and still fall behind in communication needed to make this large project work.

I've been there.

If it happens too much, then the process is not working. Do you agree? If it happens occasionally, then it's just variance.

If it is important to a team to know about this variance, then I could imagine someone would think of measuring it, temporarily, to understand the situation. But not turn the whole thing into a process.

I've been on teams that transformed every little mistake into a lesson, burdening the whole team with cargo cult processes. Things we did because "once upon a time....". That's not healthy. I'm not implying that's your case, just showing another perspective.

Re: Agile Is Dead

#82
post #36

Earlier quoted context omitted.

> Individuals and interactions -- over processes and tools That's why I proposed having a "build team" where you ask an individual to run your compiles for you, rather than dealing with an impersonal CI system. More Agile. The old Manifesto sounds nice, but it's more a reaction (overreaction?) to some pathologies of the time than something that will get you very far without otherwise knowing what you should be doing.

Fair enough. The original reaction for that pathology is "The Mythical Man-Month", it's what started everything. From my point of view, we're still man-monthin'. The Agile folks just translated a personal reflection from Fred Brooks into a culture (then some companies made it into a cult). Anyway. In your opinion, what the pathologies for _this_ time would be?

> The original reaction for that pathology is "The Mythical Man-Month", it's what started everything.

In software, Gerald Weinberg was writing about how to organize and optimize this stuff at least a decade before Brooks.

And Edwards Deming's work led to a lot of agile ideas. That strain of thinking is traceable at least back to the Napoleonic-era's Prussian artillery. The mythical man month isn't really a software problem; it's a human organization problem.

Re: Agile Is Dead

#83
post #24
post #13

The old manifesto is fine, isn't it? --- Individuals and interactions -- over processes and tools Working software -- over comprehensive documentation Customer collaboration -- over contract negotiation Responding to change -- over following a plan --- I still like it. The problem is not the lack of a good manifesto, is that people don't get it. Anyway, I like that someone else apart from me is thinking about these t…

Agile is like communism - it sounds like a great idea. Except it never seems to work anywhere, and everywhere that it turns into a train wreck consisting of 45 minute daily stand-ups and 3 hour meetings arguing about T-shirt sizes or whether points are equivalent to time or not, the only explanation anyone ever proffers is, "well, you weren't doing Agile right". No fucking shit. Nobody can do Agile right. I would arg…

Agile always fails because it's undermined from the inside.

Communism always fails because it's undermined from the outside.

Re: Agile Is Dead

#84

When I hear about Agile these days, it's almost always an excuse not to do the right thing. The last time it came up was someone resisting defining our company's product delivery process, which has always suffered from a lack of clarity. The time before that, it was someone saying "Let's be Agile about this", but meaning "let's do a shitty version of this, and pretend we'll come back to it later, rather than just mov…

To a lot of folk, that's a feature! Capital A "Agile" is just sort of a pointer to "ayyy you've heard of other companies doing this" in a lot of people's minds. I think we'd end up doing this no matter what. If it wasn't "agile" it would be "brisk methodology" or "go-minded development" or something. The reality is people sort of just like having hand-wavy terms that they definitely know other people have heard befor…

> I think we'd end up doing this no matter what. If it wasn't "agile" it would be "brisk methodology" or "go-minded development" or something. The reality is people sort of just like having hand-wavy terms that they definitely know other people have heard before, but have been given an ever shifting definition for.

Totally. That's "best practice!"

Re: Agile Is Dead

#85

I wish you the best of luck in fighting one buzzword with your new one. If it gains traction I'm sure it won't be used by the champions of your buzzword to sneak in their own desires instead of rigid adhereance to your definition. I recently stumbled across a blog post from 2006 explaining all the problems commonly heard today about capital-A agile. That means we've spent at least 18 years faffing about letting conme…

The con men [edit: pluralize] aren't selling their product to software engineers. They're selling to management. So they twisted agile into some kind of feel-good micromanagement called Agile (with the cap A), which is what appeals to management.

How would anyone ever expect a framework that diffuses control from managers to sell well . . . to managers?

Re: Agile Is Dead

#86

Dumb shits misapplying Agile because "we do standups" are dead. The entire point is and always has been to get the right people working on the right stuff in such a way that they can validate their assumptions and get customer feedback as soon as possible. Not how well you "do Scrum," "increase your velocity," or any of that trash. But actually applying these concepts breaks some managers' brains, and then we get the…

But, after 25 years of IT and 15 years of agile, I have yet to meet the product owner that knows what "the right stuff" is.

Defining the problem is the hardest part. After that, asking the team what they think they can do to create a solution for the problem: that is the easy part.

Re: Agile Is Dead

#87
Of course, Agile manifesto is bad so I create a new one. Now let's see if we can start making conferences, writing books and release new versions every year.

Some teams don´t need Agile. In many products it doesn't make even sense to use it.

I think we like to gather and discuss how to fix the world, but we know shit. The people that want to get the things done just need the resources (time, tools, money, etc). Facilitators, that should be the role of PMs.

Re: Agile Is Dead

#88
post #51

Earlier quoted context omitted.

If the customer doesn't think their project is important, why should I?

hence why a contract is still important.

Correct. "while there is value in the items on the right, we value the items on the left more.

Re: Agile Is Dead

#89
post #13

The old manifesto is fine, isn't it? --- Individuals and interactions -- over processes and tools Working software -- over comprehensive documentation Customer collaboration -- over contract negotiation Responding to change -- over following a plan --- I still like it. The problem is not the lack of a good manifesto, is that people don't get it. Anyway, I like that someone else apart from me is thinking about these t…

I like it too, but was always a problem for me: > Customer collaboration -- over contract negotiation Customer is often too busy with his own work to collaborate meaningfully.

As stated in the manifesto "while there is value in the items on the right, we value the items on the left more."

That doesn't mean there isn't room or need for contracts. A contract can and should exist with clear expectations of the customer's involvement and availability with customer response and turn around times and what the consequences are if the customer doesn't fulfill their end of the "bargain".

Re: Agile Is Dead

#90
post #81
post #73

Earlier quoted context omitted.

That is why we have processes - so people know what promises they can make. Communication is hard - you can spend all day, every day in meetings and get nothing done and still fall behind in communication needed to make this large project work.

I've been there. If it happens too much, then the process is not working. Do you agree? If it happens occasionally, then it's just variance. If it is important to a team to know about this variance, then I could imagine someone would think of measuring it, temporarily, to understand the situation. But not turn the whole thing into a process. I've been on teams that transformed every little mistake into a lesson, burd…

Do not throw away process because bad and wrong processes exist. Anytime you have a process you need to have a process in place to review and modify the process as needed. You should reward people for successfully changing the process - enough that people don't feel like it is a wasted effort, but not so much people look for ways to change it just to get the reward.

The right process is very valuable. However I will fully agree that there is a lot of bad process out there that people are following because change is too hard (sometimes this is all in their head and change is easy if you would just try!)

Post reply on HN