Comment by goostavos | Hacker News Reader

Comment by goostavos | Hacker News Reader

Parent Full thread

>Everyone seems to agree that we're doing Agile wrong

The fact that we've all heard this line (yet never heard a solution) should make it pretty clear that it's more of a management religion than an engineering practice. "You're doing it wrong" is the perfect built-in, pre-packaged defense to the Agile system that agile managers/consultants/etc can rattle off with zero effort and an air of superiority. Had a bad experience? Well, you were doing it wrong. It's not an issue with the system.

I recently worked at a place that was the text book example of agile/scrum development methodologies -- Which I don't mean figuratively, I mean in the literal sense, their big claim to fame was that they were the subject of a case study on the success of Agile methodologies. So, having worked in a place that was studied for "getting it right," it's extremely annoying to see all critiques of agile had waved away under the flag of "you did it wrong"

Just about every complaint in the article existed at this place as well. For me, at the tip top of the list was meetings. Planning would take hours. Sometimes it would be split up over two days. That is two days out of the 10 you have available for development eaten up by talking about what you're going to develop. Then there's a meeting to show what we did in those 10 days. Then another meeting to talk about what we think we did in those 10 days and how it could be better (which was of course done through stupid time wasting games ("I wish I could have ___" "I was happy when ___", "I should start doing ___"))

Then layer on top of all that a whole hierarchy of people whose whole job description is to be "agile" -- which not a single developer was able to explain to me the meaning since the day I started.

I'm ranting too much, but the whole agile thing just gets under my skin. It's such a massive waste of time. Leaving that company was a happy happy day. I now work at a place where 'planning' takes 15 minutes in front of a white board. Engineering discussions take as long as they need with the relevant parties whenever needed. Other than that, you're left alone to fucking do your job.

> ...doing it wrong...

Back when I was a wee lad, with nary a keyboard callus upon my digits, I learned about a little thing called Murphy's Law. In brief, it says that if anything can be done incorrectly, someone will eventually do it that way. It was a warning to those designing things, to make doing the wrong thing impossible, or at least much more difficult to do accidentally.

As a result, among those taught about Murphy's Law, "doing it wrong" was a design flaw. If, for instance, you could destroy radio reception in a handheld device by holding it in a particular way--a way that did not cause pain or discomfort in an ordinary human hand--it was the fault of the device manufacturer, not the user.

If you can do Agile "wrong", then it is a problem with Agile.

As for myself, I just think to myself that someone, somewhere, has weaponized an idiot, and has launched it against me. It is equal parts Inspector Clouseau, Mister Gumby, Ali G, Drunken Master, and a particularly evil djinn. He will do exactly what you ask, in the most malicious manner possible. He will follow a process with absolute rigor, and produce the worst possible outcome.

I firmly believe that such people actually exist--individuals so brutally incompetent that they are indistinguishable from malicious trolls. So you might as well plan around a person intentionally trying to break your design while still maintaining the plausible deniability of not breaking any of your rules.

Agile cannot hold up under the assault of a weaponized idiot. There are simply too many possible attack vectors.

>individuals so brutally incompetent that they are indistinguishable from malicious trolls.

The concept of "functionally evil". Declaring someone "evil" implies motivation; "functionally evil" just means "assume evil for practical purposes".

It's arguably worse than actual evil, because (per Dumas fils) rogues sometimes rest.

"Weaponized idiocy" has entered my lexicon. Thank you, sir :-)

I agree with what you're saying, but I also wonder, if not agile, then what do you see as a better alternative?

It sounds like you're suggesting that Agile methodologies have flaws that allow projects to be easily sabotaged. While I agree with this, I'm not sure I see an alternative? Is any development methodology going to be immune to this problem?

Human communication is messy, subjective, and open to all the imperfections that come along with the human condition. Unless you're working alone, any development methodology is going to be susceptible to "people problems". I don't see this as something that's unique to agile. I'm sure I could come up with hundreds of ways that idiocy, incompetence, and maliciousness could sabotage waterfall projects as well.

People within the software industry have a great advantage, in that they use their skills to both solve business problems and automate the solutions. Increasing the efficiency and effectiveness of the software team is a business problem.

There are some common elements to that problem that encourage the re-use of certain solutions--source control, for instance. The only mandate that needs to descend upon the team from above is to examine and improve your own processes.

There is only one other profession of which I am aware that can, given the opportunity, make every tool that is required for the job. That is the blacksmith. If a blacksmith discovers that a certain specialty tool would be useful for a routine task, he could either modify an existing tool or make the new one from scratch. No sane customer would barge in and demand that he use the "wrong" tool for the job. You might just find that red-hot tongs are the wrong tool for proctology.

But that happens to software professionals all the time. And that's where the weaponized idiot comes in. Allowing the customer to tell the skilled worker which tools to use sets up the situation where you could be performing surgery with a grapefruit spoon, while wearing oven mitts, or knocking down a brick wall with a rubber mallet and a hamburger spatula from an outdoor grill set. The unbelievable outcome is that sometimes that task still gets done.

A development process is a tool that software professionals use to do their jobs. If management needs another tool to help them do their jobs, those software professionals would be all too happy to make one. But let's not try to weld those two different tools together and call it a supertool. Agile is one of those welded-together things now, and the different parts might not work well together in your shop.

If your team cannot work without such a process, it may be because the business has neglected to hire a workable mix of masters, journeymen, and apprentices. Too many masters, and they may come into conflict. Too many apprentices, and they may struggle for direction. Too many journeymen, and they will leave to be masters elsewhere.

The only development methodology you really need is to make sure that every team has at least one master on it, and to let them pick their own tools and apprentices. If they can't get the work done with that level of autonomy, fire them and hire someone else. That's not a problem you can fix by going Agile.

Reply on news.ycombinator.com