9 ms·

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 w

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.

SAI_Peregrinus 4y ago
Yep. "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.
- jacobr1 4y ago
  > Working software over comprehensive documentation 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."
- jacobr1 4y ago
  > "Customer collaboration over contract negotiation" 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.
- Sohcahtoa82 4y ago
  > "Working software over comprehensive documentation" > 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.
  - brazzy 4y ago
    "over" does not mean "to the complete exclusion of". 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.
  - t43562 4y ago
    Rather have a big document for a program that doesn't work?
    - Dudeman112 4y ago
      Yes 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
      - t43562 4y ago
        I meant: you'd be happy to hand your stakeholder a document about the code you would have written if you'd had time to?
- mindcrime 4y ago
  Note that the AM doesn't say not to create documentation, or use processes and tools, etc. It just says to favor the alternatives with the implication that you have to exercise some judgment and discretion on deciding what to do when. The AM in and of itself isn't a methodology and it isn't terribly prescriptive. It's a high level description of a general notion of how to approach things, which can be (and should be) tailored to your circumstances.
- fijiaarone 4y ago
  The Agile Manifesto starts with “We have found…” 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”.
- lelanthran 4y ago
  > "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"
  - LAC-Tech 4y ago
    It's like you reached inside my head, pulled out my crudely formulated thoughts and feelings on why it struck me as ill-advised, and refined and explained everything perfectly. Internal teams! My work these days is directly with people paying for the thing. That's why Agile gives me the shivers.
    - t43562 4y ago
      It's unfortunate that you haven't understood any of the problems of writing software or buying on contract despite having it laid out for you. 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.
- Aeolun 4y ago
  > Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation. 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.
- seadan83 4y ago
  Keep in mind the agile manifesto authors were consultants, working as consultants, and the manifesto is largely in the context of software consultancy. 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.
fijiaarone 4y ago
Better to death march irrelevant requirements to bankruptcy than adapt to reality?
- LAC-Tech 4y ago
  Theres a third option - see if you can think of it!
rerdavies 4y ago
I can't think of anything more actively harmful than implementing requirements that are wrong.

SAI_Peregrinus 4y ago

Yep. "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.

jacobr1 4y ago
> Working software over comprehensive documentation 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."
jacobr1 4y ago
> "Customer collaboration over contract negotiation" 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.
Sohcahtoa82 4y ago
> "Working software over comprehensive documentation" > 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.
- brazzy 4y ago
  "over" does not mean "to the complete exclusion of". 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.
- t43562 4y ago
  Rather have a big document for a program that doesn't work?
  - Dudeman112 4y ago
    Yes 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
    - t43562 4y ago
      I meant: you'd be happy to hand your stakeholder a document about the code you would have written if you'd had time to?
mindcrime 4y ago
Note that the AM doesn't say not to create documentation, or use processes and tools, etc. It just says to favor the alternatives with the implication that you have to exercise some judgment and discretion on deciding what to do when. The AM in and of itself isn't a methodology and it isn't terribly prescriptive. It's a high level description of a general notion of how to approach things, which can be (and should be) tailored to your circumstances.
fijiaarone 4y ago
The Agile Manifesto starts with “We have found…” 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”.
lelanthran 4y ago
> "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"
- LAC-Tech 4y ago
  It's like you reached inside my head, pulled out my crudely formulated thoughts and feelings on why it struck me as ill-advised, and refined and explained everything perfectly. Internal teams! My work these days is directly with people paying for the thing. That's why Agile gives me the shivers.
  - t43562 4y ago
    It's unfortunate that you haven't understood any of the problems of writing software or buying on contract despite having it laid out for you. 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.
Aeolun 4y ago
> Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation. 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.
seadan83 4y ago
Keep in mind the agile manifesto authors were consultants, working as consultants, and the manifesto is largely in the context of software consultancy. 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.

fijiaarone 4y ago

Better to death march irrelevant requirements to bankruptcy than adapt to reality?

LAC-Tech 4y ago
Theres a third option - see if you can think of it!

rerdavies 4y ago

I can't think of anything more actively harmful than implementing requirements that are wrong.