Hacker News Reader

>The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion.

thank you, Thank You, THANK YOU!

It is a useless set of vague platitudes which offered nothing but a sense of seeming aphoristic depth. How so many people fell for it is still a mystery to me. Instead of focusing on the core problem of Requirements gathering and Software Specification, well known trial-and-error approaches were dressed up as something profound and a whole industry was created out of thin air. People seem to have forgotten the works of Fred Brooks/Barry Boehm and that their iterative "Spiral Model" IS Agile. There is nothing new i could find in the "modern" Agile/Scrum movement except mindless emphasis on Processes/Tools which is insanity, eg; The position of "Scrum Master" is the very definition of a "Bullshit Job" and should be abolished forthwith.

> the core problem of _Requirements gathering and Software Specification_

Where I work there was a huge shift in this.

From Business analysts (BA), who usually had comp sci or engineering degrees, and an expectation to get PMP and CBAP / PMI-PBA / other BA certification to move up, were responsible for requirements.

Now we have product managers and scrum masters with a 1-3 day agile certification and no comp sci or engineering background who are responsible for requirements.

My sympathies!

Nothing is worse than non-domain knowledgeable, non-technical people lording it over actual Technical Engineers who do the work.

I always recommend Dave Packard's 1960 "Speech to HP Managers" to every "Manager" - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...

Relevant Excerpt:

Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.

This is how great companies were built.

> Scrum (the catholic church to agile's christian sect)

At least the Church only had confession once a week in private.

Hahahaha.. this is brilliant!!

And treat this comment as an acknowledgement for all future occasions on which I quote you.

> those hallowed commandments are, frankly, ill-defined bollocks.

I wish I could upvote this more.

> It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion.

Then you're just complaining about the nature of language, because people do the same thing with religious text, literary text, the law, contracts, even daily conversations and flirtations. This is hardly a point that you can hold against the Agile manifesto.

> I once had it used against me to justify not writing tests

If you thought of your work as a complex system where there are a lot of variables which have multiple underlying causes, then you would have been able to describe some undesirable effect as being heavily caused by not having writing tests. And really, this is why people don't get Agile--they don't see their work and their organization as a complex system.

>Then you're just complaining about the nature of language, because people do the same thing with religious text, literary text, the law, contracts, even daily conversations and flirtations. This is hardly a point that you can hold against the Agile manifesto.

Funnily enough the features of language which are ideally suited for flirtation and writing poetry and preaching religion or nationalism and other such "let your fantasy go wild and fill in the gaps" uses of language aren't as appropriate when you're doing engineering.

Law and contracts ARE different (more like engineering), incidentally. What is described as "legalese" actually exists because non-legal equivalent language is often insufficiently precise and subject to dangerous and costly misinterpretation. Mathematical discussion has the same problem to such an extreme degree that it's almost pointless using English at all most of the time.

>And really, this is why people don't get Agile

The reason people say "people don't get Agile" is because they don't get that when the manifesto flirted with them it encouraged them to fill in the gaps with their own idealized version of software development that wasn't necessarily shared by everyone else.

> aren't as appropriate when you're doing engineering

Yeah but that's not the point that I'm making, is it? What I'm saying is that people project their own meanings into language all the time regardless of whether the language is being used in deeply personal interactions or in professional settings; therefore you can't just fault the Agile manifesto for its supposed "ambiguity".

On the point re: how laws and contracts are different -- sure, these things have gotten more precise over time, but if the language of law was inherently precise then we wouldn't have a need for judges and courts and congresses. Heck, even mathematics isn't safe from the problem of the imprecision of language. Wasn't there a time just in the last year or two when people were debating about the correctness of the statement, "one plus one always equals two"?

Which, really, brings us to the ultimate question, which also happens to be my response to your last sentence:

> The reason people say "people don't get Agile" is because they don't get that when the manifesto flirted with them it encouraged them to fill in the gaps with their own idealized version of software development that wasn't necessarily shared by everyone else.

So then is it a problem with the manifesto or with the people?

>Yeah but that's not the point that I'm making, is it? What I'm saying is that people project their own meanings into language all the time

That was MY point.

>therefore you can't just fault the Agile manifesto for its supposed "ambiguity".

You absolutely can. They didn't have to write it in an obtuse, ambiguous and metaphorical way that practically required people to project their own meaning. They deliberately chose to.

Scrum is a clear example of a methodology that is relatively (not completely) unambiguous. It's describing (in theory) a much more concrete form of "aspirational agile" and as such is at a lower risk of becoming all religious.

>On the point re: how laws and contracts are different -- sure, these things have gotten more precise over time, but if the language of law was inherently precise then we wouldn't have a need for judges and courts and congresses. Heck, even mathematics isn't safe from the problem of the imprecision of language. Wasn't there a time just in the last year or two when people were debating about the correctness of the statement, "one plus one always equals two"?

It's a sliding scale. Flirting and poetry is way over on the far left with the agile manifesto. Scrum is further to the right. Legalese is further still to the right. Math further still. It's fairly self-evident that the level of specificity required in the language used varies depending on the task. Being too specific when you flirt is common sitcom grist and nobody's ever made poetry out of a shopping list.

>Which, really, brings us to the ultimate question, which also happens to be my response to your last sentence: So then is it a problem with the manifesto or with the people?

It's the manifesto.

I think that you fundamentally misunderstand the purpose of the Agile manifesto. It’s not meant to be an algorithm or a highly specific set of instructions—it’s really just a collection of values that are meant to be the foundations of specific Agile frameworks, like Scrum. If you have trouble understanding that, then you must have trouble understanding the difference between Mission-Vision statements and KPIs.

I see exact parallels between the Agile Manifesto and Agile Movement same as the Golden Plates of Moroni and Mormon Church.

>It's a sliding scale. Flirting and poetry is way over on the far left with the agile manifesto. Scrum is further to the right. Legalese is further still to the right. Math further still. It's fairly self-evident that the level of specificity required in the language used varies depending on the task. Being too specific when you flirt is common sitcom grist and nobody's ever made poetry out of a shopping list.

Beautifully said, you have a way with words!

In your opinion, are the four principles of the "modern agile" manifesto any better, or do you predict that they will fail completely as well?

They’re purposely ill defined.

The outputs they seek are emergent.

You also belittle scrum for becoming too specific.

Seems you’re still processing what to make of any of it.

Knowledge work is immaterial and should have no prescribed rails or all you get is run of the mill outputs.

It’s similar to business; billions have been spent investigating what technology or management style brought the biggest gains. The math quickly becomes so Byzantine there no meaningful conclusions.

No matter how detailed our consciousness will let us imagine, there’s still one reality ruled by physics. Esoteric math may be correct in that it has the order of operations right, but that truth doesn’t give it any real influence on physical reality.

>They’re purposely ill defined.

Yes they were. The cynical side of me says that this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares and were unconcerned about the fallout that would ensue.

The less cynical side of me says they did it because they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details, but wanted some way to push people in "that sort of direction".

The net result either way was... well, a kind of religion.

>You also belittle scrum for becoming too specific.

No, I didn't belittle scrum for being specific. It's one of the good things about it. It is, however, a specifically defined bad way of running a team. We do need designed processes as specific as scrum, that are less one-size-fits-all and that have a more systematic and refined approach to software quality, estimation and design.

"Scrumban" is definitely an improvement, but even that is still lacking.

I'd like to see software team processes treated in many respects as a kind of "software to run teams", specifically meaning:

* That it gets iterated frequently and responds to feedback at every level (not just team, but philosophically - by its founders).

* That it's clearly and precisely defined.

* That there are a variety of different config switches depending on circumstances (e.g. number of people, skill distribution, are you building CRM or flying space rockets, etc.).

* That the individual pieces (e.g. retros, sprint planning) can be chopped and changed and upgraded/iterated on individually and yet still couple to each other sensibly - akin to the UNIX philosophy.

>Knowledge work is immaterial and should have no prescribed rails

No, anarchy is no good either.

Who is they? The original authors have little to do with the administrative state that’s been wrapped around our agency.

Anarchy is no good.

Haha.

Your efforts are constrained by physical science, social objectives.

There’s plenty of structure to prevent anarchy.

But you would further impose problem solving constraints on others thought work.

Shit n hellfire; what a dumpster fire of a culture.

Would you say something as minimal as “E=mc^2” promotes anarchy? It hardly illustrates the full meaning of relativity.

Perhaps where you perceive emptiness and anarchy, others perceive correctness and order.

Like religion; one mans abstraction is another mans insanity.

>Who is they?

The 17 authors of the manifesto.

>But you would further impose problem solving constraints on others thought work.

I would, yes. I've worked with a diversity of methodologies and several times with no explicit methodology all and in a team context we ended up a disorganized mess.

You might try to accept the rest of us don’t jump through the hoops of having a financially thriving job for you.

It’s not to bring order to chaos. It’s to afford shelter, food, and healthcare.

Sorry, not sorry.

Perhaps you’d be happier living as a hermit, where you can organize as you wish; everything just so! without the rest of humanity, that does quite a bit of the heavy lifting for you, interfering.

>this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares

> they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details

Money quotes!

I had attended a presentation by Kent Beck on "eXtreme Programming" well before the Agile/Scrum movement started and came away with the exact sentiments listed above.

To apply one of my favourite phrases to your post;

"What ineffable twaddle" !

I highly recommend to you the works of David Parnas, Barry Boehm, Fred Brooks, Gerald Weinberg for edification.

Start with the paper; "A Rational Design Process: How and Why to Fake It."

Big fan of all of those already. Fred Brooks in particular is seriously underrated.