Comment by psunavy03 | Hacker News Reader

Comment by psunavy03 | Hacker News Reader

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 toxic crap people rant about.

The fundamental assumptions behind Agile are as valid as they were 25 years ago. The problem(s) are control freak managers who are incapable of coaching their teams into taking charge at the local level, devs "who just want to code" and not think for themselves about the larger context of the work, and bullshit "life coaches" using Agile coaching as a way to "break into tech" with no tech skills.

This is fundamentally a crisis of incompetence, where people are failing to implement what at its roots is a better way of working, in certain contexts anyway, because they fear giving power and control to the rank and file.

So true. 90% of Agile practitioners give the rest a bad reputation.

Um....

Isn't there some rule of thumb where some substantial threshold of popular regard defined it?

I mean I get if there is first principles derivation of a concept, but agilation is not that.

Agile is really a communal/socialist mechanism that is ruined the second management more than one later up injects themselves.

... Which is 100% of the time

Not really in this case, because the manifesto was put out there from the beginning. People's incompetence to actually look at a website and read 4 phrases and doing fake agile is one thing. Agile is another.

Mostly agree, but process is a way to tame the incompetence, if incompetence wins process has failed

Well, yes, but - it clearly doesn't work well to only come up with a good idea like that. After initial momentum, people often took it elsewhere, or abandoned.

Which tells you a lot about people out there. Maybe one can't force a shiny cool shoe on a feet incapable of using it well, even if it would be great in many aspects. Maybe we need something that is easier adaptable by real people making up real teams and organizations out there, not just cool books and trainings.

The most adaptable, flexible, maleable methodology is and will always be XGH.

https://medium.com/@dekaah/22-axioms-of-the-extreme-go-horse...

>The entire point is and always has been to get the right people working on the right stuff

This is my sticking point. The whole idea of process-focus is that you can rarely count on having "the right people working on the right stuff." Sometimes the "right person" today isn't the right person tomorrow because they're dealing with an illness or emotional event at home or something else that throws them off their game. The whole point of process control is that reality doesn't match an idealistic notion of "the right person on the right job at the right time".

The whole point of Agile is to organically grow what processes make sense in that particular context, not "process control" for its own sake. Even Scrum was designed to be deliberately incomplete so organizations can do what makes sense for them, not just blindly follow a checklist.

And it's not about someone not being "the right person" because they're human. It's about having the right skillsets on the team working on the right products, architected in such a way as to be releaseable easily enough to be responsive to what customers need.

What needs to die are managers stuffing unrelated work into one team, splitting work across teams so dependencies get ping-ponged back and forth, and then making people do 30-45 minute dailies because it's a status report, not a team sync.

What is dead is TACO Agile . . . Terms And Ceremonies Only. Although it was arguably never alive in the first place, more of a shambling zombie with about as much brains.

It really seems like both sides talk past each other. If you talk to agile advocate about how to implement it in something safety critical that requires good documentation, they’re quick to point out agile isn’t anti-documentation, it’s anti-wasteful-documentation. A good process focus is also always trying to reduce waste. Likewise, a process focused advocate would say the focus needs to be on what the customer requires: working software.

The issue seems to be both sides provide cover for incompetence. Agile folks can eschew tools that help identify and mitigate risks because it’s ignorance masquerading as efficiency. Process folks can focus too much on the process itself when they don’t understand how to track what’s really important.

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.

The entire point of Agile is that you accept that you DON'T KNOW what "the right stuff" is at first, and so you get stuff in front of the customer as soon as feasible and then use that feedback as quickly as possible, over and over again until the cost of going further isn't worth it anymore.

The entire point is moving away from big design up front. Instead, you create hypotheses and then test them against reality. You're not expected to know the entire path, but you ARE supposed to know what vector to take until the next feedback.

>I have yet to meet the product owner that knows what "the right stuff" is.

>Defining the problem is the hardest part.

I have yet to meet a product owner that collects customer requests (or determines customer pain points) and assigns a value to implementing/alleviating them, also known as determining the payoff function.

Determining the most valuable problem to solve is the hardest part.

Reply on news.ycombinator.com