3 ms·

Agile, or the "Agile Cult" the author mentions? Agile merely recommends biasing in four directions: - Individuals and interactions over processes and tools -

Agile, or the "Agile Cult" the author mentions? Agile merely recommends biasing in four directions: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan And also to comply with 12 principles listed here in all their 2001 internet glory: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html There's nothing wrong with any of that, and a lot that's quite good. Failing to take into account the realities of corporate politics and human psychology when you implement it doesn't make the idea bad. There's no cause so noble that it won't have a few incompetents following it. What's more, there's a difference between expecting someone to change at a healthy pace as opposed to RIGHT NOW, and saying that they don't need to change at all. Implementing whatever flavor of Agile requires growing pains in the same way that getting physically fit or learning a new skill does. That's healthy. A lot healthier than just sitting on the metaphorical couch with a bowl of Cheetos. Just because a bad personal trainer pushes someone to the point of injury is not evidence that exercise itself is bad.

OldGuyInTheClub 3y ago
Your bullet points may (or may not) be fine for commercial software. If you're working on anything governed by the US Federal Acquisition Regulations (FAR), they are a minefield. - Process compliance is usually baked into the contract. If the contractor stipulates to complying with a process, especially a government process, then it had better be followed and documented - Documentation is not optional. People move on, get fired, and/or die. Because the s/w works today, it may not tomorrow when MS, Redhat, or whomever push patches - "Customer collaboration over contract negotiation": Once the contract is in place, it is in place. Customers will _always_ try to add scope and eventually try to direct the individual performers. If you're Firm Fixed Price, you are dead in the water. If you are Cost Plus Fixed Fee (CPFF), you will dilute your profit when you inevitably overrun. -- Aside: CPFF means the fee is fixed at contract start. If you overrun you may get your costs but the fee stays the same. And so on. An even bigger problem is when Lean/Agile gets glommed on to hardware efforts where you can't simply issue a patch every 30 minutes and where you can't have the customer in your day-to-day shorts.
- psunavy03 3y ago
  And yet the government is starting to realize that the FARs need a major overhaul if the DOD is to have a prayer of staying competitive in the 21st Century. You're not describing a critique of Agile so much as you're describing why the government sucks out loud at software.
  - OldGuyInTheClub 3y ago
    I'll let you fly the plane whose software is written without requirements, updated on the fly, and released without regression testing.
    - cqqxo4zV46cp 3y ago
      This characterisation of Agile methodologies is exactly what I’d expect if someone has spent their career in the US govt contracting machine for long enough to have been convinced that it is a remotely good idea.
    - psunavy03 3y ago
      Nice strawman. Now read this paper on how Saab Aerospace used Scrum@Scale. https://www.scruminc.com/wp-content/uploads/2015/09/Release-version_Owning-the-Sky-with-Agile.pdf https://www.scruminc.com/wp-content/uploads/2015/09/Release-...
      - OldGuyInTheClub 3y ago
        So, they don't talk to the direct customer (the Product Owner is a proxy), they do the parts of Scrum that they want to do, and there is no proof whatsoever offered. No graphs, no data, no circles and arrows. It sounds like an article written for a Scrum consulting blog which, whaddya whaddaya, it is. Thanks for the chuckle. Got some new terms to add to our Bullshit Bingo cards.
        deleted 3y ago
        [deleted]
thenanyu 3y ago
> There's nothing wrong with any of that, and a lot that's quite good. There's a lot wrong with it. The problem with even these four foundational principles is: there are a significant % of situations where they are the exact wrong thing to do. Sometimes they are good! Sometimes they are very very bad. There's no replacement for good management and judgement. Individuals and interactions over processes and tools — there's a lot of value in having things done in a standard manner. Most of the time, you shouldn't try to be a special flower. Working software over comprehensive documentation — have you ever seen a team develop themselves into a corner? Or run head first into a pit of real-life complexity? Try implementing USB without comprehensive documentation. Customer collaboration over contract negotiation — customers will often take advantage of you. Both internal and external customers. The contract helps a lot when the customer is antagonistic. Responding to change over following a plan — sometimes you should just stick to the plan.
- psunavy03 3y ago
  Once again, someone mistakenly assumes that the Agile Manifesto favoring the items on the left magically means ignoring the items on the right. This is a strawman. "That is, while there is value in the items on the right, we value the items on the left more." It doesn't say we junk the items on the right.

OldGuyInTheClub 3y ago

Your bullet points may (or may not) be fine for commercial software. If you're working on anything governed by the US Federal Acquisition Regulations (FAR), they are a minefield. - Process compliance is usually baked into the contract. If the contractor stipulates to complying with a process, especially a government process, then it had better be followed and documented - Documentation is not optional. People move on, get fired, and/or die. Because the s/w works today, it may not tomorrow when MS, Redhat, or whomever push patches - "Customer collaboration over contract negotiation": Once the contract is in place, it is in place. Customers will _always_ try to add scope and eventually try to direct the individual performers. If you're Firm Fixed Price, you are dead in the water. If you are Cost Plus Fixed Fee (CPFF), you will dilute your profit when you inevitably overrun. -- Aside: CPFF means the fee is fixed at contract start. If you overrun you may get your costs but the fee stays the same. And so on. An even bigger problem is when Lean/Agile gets glommed on to hardware efforts where you can't simply issue a patch every 30 minutes and where you can't have the customer in your day-to-day shorts.

psunavy03 3y ago
And yet the government is starting to realize that the FARs need a major overhaul if the DOD is to have a prayer of staying competitive in the 21st Century. You're not describing a critique of Agile so much as you're describing why the government sucks out loud at software.
- OldGuyInTheClub 3y ago
  I'll let you fly the plane whose software is written without requirements, updated on the fly, and released without regression testing.
  - cqqxo4zV46cp 3y ago
    This characterisation of Agile methodologies is exactly what I’d expect if someone has spent their career in the US govt contracting machine for long enough to have been convinced that it is a remotely good idea.
  - psunavy03 3y ago
    Nice strawman. Now read this paper on how Saab Aerospace used Scrum@Scale. https://www.scruminc.com/wp-content/uploads/2015/09/Release-version_Owning-the-Sky-with-Agile.pdf https://www.scruminc.com/wp-content/uploads/2015/09/Release-...
    - OldGuyInTheClub 3y ago
      So, they don't talk to the direct customer (the Product Owner is a proxy), they do the parts of Scrum that they want to do, and there is no proof whatsoever offered. No graphs, no data, no circles and arrows. It sounds like an article written for a Scrum consulting blog which, whaddya whaddaya, it is. Thanks for the chuckle. Got some new terms to add to our Bullshit Bingo cards.
      - deleted 3y ago
        [deleted]

thenanyu 3y ago

> There's nothing wrong with any of that, and a lot that's quite good. There's a lot wrong with it. The problem with even these four foundational principles is: there are a significant % of situations where they are the exact wrong thing to do. Sometimes they are good! Sometimes they are very very bad. There's no replacement for good management and judgement. Individuals and interactions over processes and tools — there's a lot of value in having things done in a standard manner. Most of the time, you shouldn't try to be a special flower. Working software over comprehensive documentation — have you ever seen a team develop themselves into a corner? Or run head first into a pit of real-life complexity? Try implementing USB without comprehensive documentation. Customer collaboration over contract negotiation — customers will often take advantage of you. Both internal and external customers. The contract helps a lot when the customer is antagonistic. Responding to change over following a plan — sometimes you should just stick to the plan.

psunavy03 3y ago
Once again, someone mistakenly assumes that the Agile Manifesto favoring the items on the left magically means ignoring the items on the right. This is a strawman. "That is, while there is value in the items on the right, we value the items on the left more." It doesn't say we junk the items on the right.