I've read the original manifesto and principles, and quite frankly I'm not that impressed with them either.
Some of the principles are actively harmful, like welcoming changing requirements late in the process.
Some of the principles are actively harmful, like welcoming changing requirements late in the process.
"Individuals and interactions over processes and tools"
OK, not terrible, but why not "interactions and tools over individuals and processes"? De-emphasize individual's egos and ritualized processes, focus on the things that get work done and communication between entities.
"Working software over comprehensive documentation"
Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.
"Customer collaboration over contract negotiation"
Fine. You'll still need a contract, but it's definitely important have a collaborative rather than adversarial relationship with customers.
"Responding to change over following a plan"
Tends to make sense when gathering requirements, turns into a horrible idea later on in a project. Also fails utterly when working with something like a factory (making a hardware product with embedded software). If your entire view of software is web apps, this one seems like a good idea. If you're making something with a manufacturing deadline, it's a recipe for disaster.
This means something a little different. It wasn't talking about "end-user" documentation. Rather, it meant "product specifications." Do you need to design the system upfront in UML before you start writing code? You may still need something like a whiteboard sketch or something similar, but that wouldn't be "comprehensive."
The distinction is more about how granular you need things. Do you need to negotiate every piece of business-logic and get signoffs on mockups up-front, and in the case of paying customer, rather than internal stakeholder potentially including placing them into a legal SOW? Or can you just agree to a bullet-list of high level functionality, and then establish a working arrangement to receive feedback and refinement. Build and MVP and get some use, then make it better. Likely the initial understanding of the requirements was flawed anyway, so being reactive to the change, with buy-in from the customer will be a better plan for success. But yeah, this might not work with physical products.
> Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.
Another problem:
It makes onboarding new engineers difficult. Without any documentation on what each API endpoint does, or the purpose of every repo, getting an understanding of how the system works ends up requiring scanning through code manually or taking a lot of time from other engineers asking questions.
It's especially bad when microservices are given non-descriptive names like Galactus or Omega Star.
The point is that documentation by itself doesn't deliver any value, and there are diminishing returns with amount and detail level of documentation.
Agile doesn't say you shouldn't document, it says you shouldn't spend more time documenting your API endpoints than Implementing them.
You can get there with a big document for a program that doesn't work
You can't get anywhere with a program that works and no document. You might get sales, but that's someone else's job
I certainly would have preferred just a big document instead of the code I was given on my current role
So that’s the why. You can ask for elaboration, or disagree with the results, but the opinion of the signers of the Agile Manifesto, based on their experience, is that to prefer the former over the latter, while acknowledging that the latter principles have value, they tend to succeed (and enjoy their work more) when deciding between the two (there are always trade offs) to give greater weight to the more lightweight, practical, and less rigid values — hence the use of the word “agile”.
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"
Internal teams! My work these days is directly with people paying for the thing. That's why Agile gives me the shivers.
In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.
The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.
> In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.
Doesn't matter - the people paying for the software are not the ones that are going to be using it, so showing it to them is pointless (they just want their bullet points/requirements checked off).
Showing the software to the users is equally pointless, because they don't have the authority to request changes (any change is a bill that has to be approved).
See my other reply to you: https://news.ycombinator.com/threads?id=lelanthran#34381865
> The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.
Maybe, but unless you have an alternative that addresses the problems in not having contracts, there's little point in telling other people that they don't understand the problem.
"Oh, we hit our schedules and costs 100% of the time", she said.
I was incredulous, so I pressed her on the point.
"Well, compared to the contracted schedules and costs, we run 200% over on average by the time we deliver. But what happens is that customers quickly figure out that what they contracted for isn't anything like what they actually need. And every time a requirement changes, we add time and money. A lot of time and money. More than enough to make up for any actual overruns. So we always hit our schedules and costs exactly, by the time we're done."
In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.
...
> In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.
How is that a scam? "We will deliver $X in $Y months for $Z money" is easily predictable by the client when the client wants to change $X.
If the client doesn't change $X, the client can understand what they will pay and when they will get it.
When the client changes $X to $X+a, they still understand that delivery will be "$x+a in $Y+b months for $Z+c money". In fact, the original contract they signed made it clear to them what the cost and time was for changing requirements.
More to the point, when they want to make a change, they can balance the need for the change against the cost and time. Even better, because they know these things upfront, someone at the client will have to approve the cost and delivery time for the new requirements. That person is not going to give the supplier a blank cheque.
It's a good deal better than "We deliver working parts until you are satisfied or until you run out of money. We cannot tell you in advance how much this will cost and how long it will take."
I mean, if experienced developers are unable to get their software development supplier to deliver with only a small margin of money/time overruns, what hops is there for the procurement person at any company?
Since external customers and non-swe stakeholders expect binding contracts and even waterfall, I would consider it essential to learn how to interface agile processes with the said contract-driven stakeholders. Telling them that we are trying our best just doesn’t work.
What's the alternative? Never have contracted-for software? Only accept contractors who are prepared to do Agile?
How does the procurer then put out bids, without having requirements up front?
How do they evaluate bids from various suppliers without knowing what the final bill is? How do they shortlist the three "best" bids with no costing information? How do they even know if they can afford it?
How are the suppliers supposed to submit bids without knowing what they are going to bill for?
How does audit make sure that the process was fair?
Once you start supplying/developing software for companies that are large enough to have a procurement department, you better believe that the process all runs on paper[1].
[1] Or the digital equivalent.
This isn't a useful analogy - more often, it's like asking a crew how much it would cost and how long it would take to paint your house, except the house isn't built yet, you're not sure what you're going to use it for (or whether you'll actually use it as a house rather than a B&B), plus you reserve the right to change colors at any point in the process.
This was written in a time when documentation/spec was often written before the software, without taking into account the difficulties of implementing it.
Agile seems to imply that software comes before documentation in terms of priorities.
A lot of the points in the manifesto turn out to be slightly redundant. Comprehensive documentation, as entered into a tool, is wasted time when what you need to do is spend time with the customer developing their ideas into good software.