[galangalalgol]

Individuals and interactions over processes and tools.

If the team likes scrum thats fine but picking scrum vs kanban, or bitbucket vs gitlab vs cvs, those are details a team cam and should be in charge of and revisit whenever they feel like. Because all that matters is working code, and what gets you there is skilled people that communicate well.

[Cederfjard]

Working code is not all that matters, typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable, sooner or later there won’t be any money rolling in to fund developers writing that code. Not every company will have enough ”skilled people that communicate well” for this to be an automatic byproduct of developers doing their thing, especially in larger or immature organizations.

[pracer]

> typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable

the problem is that this assumes that estimates can be accurate, which in some projects may be the case, but in general there are always unexpected problems, things you didn't know you didn't know, etc.

If it happens that a company goes under because they lost all income because there was no deliverability, the problem was the company had the wrong team of engineers. Either too much "isolated geniuses" or too much inexperienced. Sometimes also happens that the management decides the way of doing work without technical involvement. Even companies I've been that decided to rewrite a mature and solid big piece of software, because they "needed to use more strategic technologies". Meaning, the technologies that were the "cool thing to use if you are a cool startup". And they use Agile (so they claim).

[Cederfjard]

It doesn’t assume that estimates are accurate in that they need to approach perfection, but it does assume that good processes and tools can help make them reliable enough to be useful for the business over time (who of course still have to take the remaining uncertainty into account).

[galangalalgol]

There is a reason the agile manifesto starts with the line I quoted. The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability. But if you dont have those individuals interacting well there is no tool or process that can save you.

[Cederfjard]

> The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability.

Here’s where I disagree and would say that a well-functioning process certainly can help with that, albeit not perfectly, of course. And that is by aiding the invididuals involved in interacting well.