[crdoconnor]

>Take tests for example: blindly going for coverage metrics will be much less effective...

I agree. However, this is about tools and processes, so it's not really relevant to my argument, which is that you shouldn't explicitly deprioritize tools and processes.

>I don't understand your last statement.

I'm making fun of people who cargo cult 'agile'. Actually standing up is the least important feature of stand ups. Sitting down during a stand up and seeing people's reactions is is a good litmus test. It highlights those people who put a great emphasis on non-functional rituals.

[edejong]

I was trying to convey that fostering an environment within which tools and methodologies can be understood for their specific merits is more important than the tools and methodologies themselves. Or: a tool shouldn't be a crutch, but a training aid. At least, that's how I interpret it.

Obviously, the true spirit of the agile manifesto is the non-prescriptive, ambiguous wording.

Unfortunately, 'scrum' has come to be known as 'agile', which I think is an unfortunate consequence of all the cargo-culting going on. Rituals are fine, as long as they have any depth and identity to them. The Scrum rituals are shallow, simplistic and feeble. Without identity it is no wonder many participant want them to be over as soon as possible...

[crdoconnor]

I'll agree that the manifesto is vague enough that you could reinterpret it your way. However, its inimical vagueness is hardly a point in its favor, since all that means is that people project whatever meaning that they really want on to it. Meaning that it has very little meaning.

But it still strongly implies that tools basically don't matter, and I've worked on teams where people did choose to interpret it that way, which ironically led to waterfalling...

[edejong]

Yes, I agree with that standpoint. The agile manifesto is too vague to be used prescriptive. It requires a certain amount of intelligence and wisdom to acknowledge that. It's also not able to bootstrap: you need to be grounded in the philosophical underpinnings in order to understand it.

I'd really could go on to talk about those underpinnings, saying that they are mystic and grounded in certain Western cultural ideals (that are deteriorating at a rapid pace at the moment). But, HN is probably not the right place to discuss it and it is 1 AM here.

[jrs235]

> you shouldn't explicitly deprioritize tools and processes

Is it fairly safe to say that the goal of most [software] companies isn't to just make good software or to develop [good] software fast but to find a repeatable process to make good software quickly? And this is why tools and processes are still needed.