> "Customer collaboration over contract negotiation"
TLDR: Businesses purchase development effort in terms of contracts, and the contract is almost always "You will deliver $X for $Y amount, in $Z months or less". Agile is the opposite of that as far as business is concerned - "We will pay $A per hour until our money runs out or we are satisfied with what we get".
I've never understood this one, to be honest. Business runs on contracts; in any interaction with the outside world (suppliers, customers, employees, etc) the businesses contract is what makes or breaks that interaction.
In 999 out of 1000 cases, no contract == no interaction.
I mean, look at it this way: when you ask a crew to paint your house, you specify the colors upfront. You don't iterate with them on after every room, or every wall.
You certainly will not engage with any crew who wants to paint your house using the guidance of the Agile Manifesto, because then you'd have little to no upfront indication of the cost, you might have a house not gully painted (because you're paying per hour for their time, and once your money runs out they stop working).
Agile works great for teams internal to the business - the money never runs out unless the business shuts down. But for external developers, the business cannot engage without a contract, and that contract will be "You will deliver $X for $Y in $Z months", and not "We will pay you $A hourly until we are satisfied with the result".
The practical result is that the agile way and the business way are entirely opposites of each other. This explains why dev teams within companies constantly complain "This isn't Agile!" ... because business is trying to enforce some sort of "Deliver $X within $Z months" and the agile team is working with "We'll collaborate until the stakeholders are satisfied"
TLDR: Businesses purchase development effort in terms of contracts, and the contract is almost always "You will deliver $X for $Y amount, in $Z months or less". Agile is the opposite of that as far as business is concerned - "We will pay $A per hour until our money runs out or we are satisfied with what we get".
I've never understood this one, to be honest. Business runs on contracts; in any interaction with the outside world (suppliers, customers, employees, etc) the businesses contract is what makes or breaks that interaction.
In 999 out of 1000 cases, no contract == no interaction.
I mean, look at it this way: when you ask a crew to paint your house, you specify the colors upfront. You don't iterate with them on after every room, or every wall.
You certainly will not engage with any crew who wants to paint your house using the guidance of the Agile Manifesto, because then you'd have little to no upfront indication of the cost, you might have a house not gully painted (because you're paying per hour for their time, and once your money runs out they stop working).
Agile works great for teams internal to the business - the money never runs out unless the business shuts down. But for external developers, the business cannot engage without a contract, and that contract will be "You will deliver $X for $Y in $Z months", and not "We will pay you $A hourly until we are satisfied with the result".
The practical result is that the agile way and the business way are entirely opposites of each other. This explains why dev teams within companies constantly complain "This isn't Agile!" ... because business is trying to enforce some sort of "Deliver $X within $Z months" and the agile team is working with "We'll collaborate until the stakeholders are satisfied"