4 ms·

And here we go with an entire thread of cynical comments where people assume that the jacked-up Agile implementations they've seen at their own organizations ar

And here we go with an entire thread of cynical comments where people assume that the jacked-up Agile implementations they've seen at their own organizations are the only way it ever can be implemented . . . Unfortunately, doing it well requires managers willing to give up power and developers willing to take the headphones off, go talk to other human beings, and be more proactive than just "I did what I was told." Some companies/teams struggle with these things.

harimau777 3y ago
Isn't that the entire problem though? Agile fails to take into account the realities of corporate politics and human (i.e. manager) psychology?
- psunavy03 3y ago
  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.
- kelseyfrog 3y ago
  The complexities of human interaction implies that every system will fail to take into account realities. It's a sociological version of Gödel's incompleteness theorems - either the system is comprehensive and inconsistent, or it's consistent but not comprehensive. Even so, if every model will fail, which one minimizes the quantity and quality of failure? The solution still seems to be, "let's be aware of our system, whether formal, informal, or somewhere in between, and be conscious designers of our interactions with others in the social organization of software development." It requires system-level thinking, which at face value, appears to be something that engineering folks would love to sink their teeth into. At the very least, Agile recognizes that time, features, and effort exist in relation to each other, and that if one[effort] is held constant, social interactions are constrained in a number of important ways.
  - psunavy03 3y ago
    Which is why Scrum in particular is express about being "purposely incomplete." It's intended to leave wiggle room for people to adapt it to their context. Unfortunately mediocre people and mediocre organizations take this as a license to fill the gaps with inane bullshit and call it "Scrum" or "Agile," instead of mindfully determining what makes sense in their context.
    - cqqxo4zV46cp 3y ago
      No no no! Scrum doesn’t get to escape that easily! This is blatant retconning by the Scrum folks. Look at how the scrum guide has changed over the years and you’ll see clear evidence of “fine, we’ll stop being so prescriptive”. And there’s such an essentially-first-party certificate culture associated with Scrum, a completely self-imposed one, that it’s the NORM for Scrum practitioners to be prescriptivist rule-followers lacking any sense of nuance.
      - psunavy03 3y ago
        The plural of "anecdote" is not "data," and just because you feel strongly about something does not make you an authority on the topic or make it universally true.
- randomdata 3y ago
  > Agile fails to take into account the realities of corporate politics and human (i.e. manager) psychology? No, it does. Each of the 12 principles calls attention to what developers need to be thinking about when there are no managers. Agile is, in effect, a framework to help you operate without managers. If you already have managers, and they aren't willing to let go, agile was never on the table.
wallaBBB 3y ago
Seems a bit like blame shifting. Almost any approach will work if perfectly executed by a team with a perfectly matching skill sets, but yeah we have to account for the imperfections (to put it lightly).
- gklitz 3y ago
  > Almost any approach will work if perfectly executed by a team with a perfectly matching skill sets Will it though? The assumption that any project no matter what it is will always succeed if only the team is right seems naive and at the core of many unreasonable critiques of any framework for project execution. Failure is a part of the reality of projects, and when executed correctly agile will let you identify and pivot away from failure early. While more ridged frameworks will keep trying to expand resources, extend deadlines until they explored under the load of living up to ever increasing promises they made to justify the growth.
rightbyte 3y ago
> Unfortunately, doing it well requires managers willing to give up power Agile is the best micromanagement process there is. Nothing even comes close. I guess there is a fitting LoTR quote here about tempting weak mortals with power. These levels of micromanagement did not exist before agile. Sure the bosses could try earlier, but there were no tooling or developer self-imposed mindset for the modern worst practice nightmare. And the process is so stiff I wanna cry, but you are gaslighted into being blamed for it, as you "can change it" -- maybe after the next retro though. Just need to align your agile with the other teams agile first. We are way past agile being nothing but a farce.
- nyrikki 3y ago
  That is cargo cult agile. I encourage you to read 'the art of agile development' as they do provide some guidance around that. But if there is micromanaging going on your org has ignored one of the core principles. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done" There are places Agile is inappropriate or impossible and the book I suggested above calls that out. While I like agile, I don't think of it as gospel. But the people I see who bristle at the mention of it have probably only been exposed to the productized version. Even if the methods don't work the above book provides alternatives that may help. But I promise you, you haven't experienced an agile development environment if you believe the above. Micromanaging is the the polar opposite of that collection of values and principles.
bitwize 3y ago
> And here we go with an entire thread of cynical comments where people assume that the jacked-up Agile implementations they've seen at their own organizations are the only way it ever can be implemented . . . Probably one of the most agile projects ever was Windows 95. They started by building prototypes of the UI elements they wanted to implement in frickin' Visual Basic, putting them in front of end users, gathering feedback and iterating the next set of UI prototypes, till they converged on the design with the start menu, taskbar, and desktop. About the only thing missing was CI/CD. But that was Microsoft at the peak of their powers. They had enormous resources and top-tier talent. And they had bet the company on Windows 95; if it flopped, it would be a disaster. It is very, very hard to have the stars align just right, to put together a team that cared enough about the product to actually do this sort of development rather than cargo-cult it to check off some process compliance checkbox. Yes, I know Windows 95 was a buggy mess. Given the constraints Microsoft was operating under, it's a miracle it worked at all.
ramblerman 3y ago
Isn't that a bit like a defense of communism though? "If only people implemented it properly we would all live in paradise". What matters is how it works in reality, how it incentivizes people and fits in with human nature. Agile seems to leads to more micromanagement and kafka-esque situations for the majority of software engineers that have to deal with it. If anything it provides a framework for bad managers who are mistrustful of engineers to play far outside of their comfort zone, and suggest childish measures that they wouldn't have dared to dream up on their own.

harimau777 3y ago

Isn't that the entire problem though? Agile fails to take into account the realities of corporate politics and human (i.e. manager) psychology?

psunavy03 3y ago
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.
kelseyfrog 3y ago
The complexities of human interaction implies that every system will fail to take into account realities. It's a sociological version of Gödel's incompleteness theorems - either the system is comprehensive and inconsistent, or it's consistent but not comprehensive. Even so, if every model will fail, which one minimizes the quantity and quality of failure? The solution still seems to be, "let's be aware of our system, whether formal, informal, or somewhere in between, and be conscious designers of our interactions with others in the social organization of software development." It requires system-level thinking, which at face value, appears to be something that engineering folks would love to sink their teeth into. At the very least, Agile recognizes that time, features, and effort exist in relation to each other, and that if one[effort] is held constant, social interactions are constrained in a number of important ways.
- psunavy03 3y ago
  Which is why Scrum in particular is express about being "purposely incomplete." It's intended to leave wiggle room for people to adapt it to their context. Unfortunately mediocre people and mediocre organizations take this as a license to fill the gaps with inane bullshit and call it "Scrum" or "Agile," instead of mindfully determining what makes sense in their context.
  - cqqxo4zV46cp 3y ago
    No no no! Scrum doesn’t get to escape that easily! This is blatant retconning by the Scrum folks. Look at how the scrum guide has changed over the years and you’ll see clear evidence of “fine, we’ll stop being so prescriptive”. And there’s such an essentially-first-party certificate culture associated with Scrum, a completely self-imposed one, that it’s the NORM for Scrum practitioners to be prescriptivist rule-followers lacking any sense of nuance.
    - psunavy03 3y ago
      The plural of "anecdote" is not "data," and just because you feel strongly about something does not make you an authority on the topic or make it universally true.
randomdata 3y ago
> Agile fails to take into account the realities of corporate politics and human (i.e. manager) psychology? No, it does. Each of the 12 principles calls attention to what developers need to be thinking about when there are no managers. Agile is, in effect, a framework to help you operate without managers. If you already have managers, and they aren't willing to let go, agile was never on the table.

wallaBBB 3y ago

Seems a bit like blame shifting. Almost any approach will work if perfectly executed by a team with a perfectly matching skill sets, but yeah we have to account for the imperfections (to put it lightly).

gklitz 3y ago
> Almost any approach will work if perfectly executed by a team with a perfectly matching skill sets Will it though? The assumption that any project no matter what it is will always succeed if only the team is right seems naive and at the core of many unreasonable critiques of any framework for project execution. Failure is a part of the reality of projects, and when executed correctly agile will let you identify and pivot away from failure early. While more ridged frameworks will keep trying to expand resources, extend deadlines until they explored under the load of living up to ever increasing promises they made to justify the growth.

rightbyte 3y ago

> Unfortunately, doing it well requires managers willing to give up power Agile is the best micromanagement process there is. Nothing even comes close. I guess there is a fitting LoTR quote here about tempting weak mortals with power. These levels of micromanagement did not exist before agile. Sure the bosses could try earlier, but there were no tooling or developer self-imposed mindset for the modern worst practice nightmare. And the process is so stiff I wanna cry, but you are gaslighted into being blamed for it, as you "can change it" -- maybe after the next retro though. Just need to align your agile with the other teams agile first. We are way past agile being nothing but a farce.

nyrikki 3y ago
That is cargo cult agile. I encourage you to read 'the art of agile development' as they do provide some guidance around that. But if there is micromanaging going on your org has ignored one of the core principles. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done" There are places Agile is inappropriate or impossible and the book I suggested above calls that out. While I like agile, I don't think of it as gospel. But the people I see who bristle at the mention of it have probably only been exposed to the productized version. Even if the methods don't work the above book provides alternatives that may help. But I promise you, you haven't experienced an agile development environment if you believe the above. Micromanaging is the the polar opposite of that collection of values and principles.

bitwize 3y ago

> And here we go with an entire thread of cynical comments where people assume that the jacked-up Agile implementations they've seen at their own organizations are the only way it ever can be implemented . . . Probably one of the most agile projects ever was Windows 95. They started by building prototypes of the UI elements they wanted to implement in frickin' Visual Basic, putting them in front of end users, gathering feedback and iterating the next set of UI prototypes, till they converged on the design with the start menu, taskbar, and desktop. About the only thing missing was CI/CD. But that was Microsoft at the peak of their powers. They had enormous resources and top-tier talent. And they had bet the company on Windows 95; if it flopped, it would be a disaster. It is very, very hard to have the stars align just right, to put together a team that cared enough about the product to actually do this sort of development rather than cargo-cult it to check off some process compliance checkbox. Yes, I know Windows 95 was a buggy mess. Given the constraints Microsoft was operating under, it's a miracle it worked at all.

ramblerman 3y ago

Isn't that a bit like a defense of communism though? "If only people implemented it properly we would all live in paradise". What matters is how it works in reality, how it incentivizes people and fits in with human nature. Agile seems to leads to more micromanagement and kafka-esque situations for the majority of software engineers that have to deal with it. If anything it provides a framework for bad managers who are mistrustful of engineers to play far outside of their comfort zone, and suggest childish measures that they wouldn't have dared to dream up on their own.