4 ms·

"Agile is a cult." Is a refrain I've had for a few years. I don't mean like the agile process, I mean the agile culture. I went to an agile conference for work

"Agile is a cult." Is a refrain I've had for a few years. I don't mean like the agile process, I mean the agile culture. I went to an agile conference for work and the things they talked about were just really really dumb, I swear they almost professed that agile could cure cancer.

Scarblac 3y ago
I think it's Scrum that's a cult, agile works fine in the rare place that does it. But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment. Not something you have conferences about.
- t43562 3y ago
  What's the difference between what you're talking about and scrum? IMO the conferences are really there because the way companies think about projects and plans is not agile and it's difficult to marry up the higher level decision making with the way that agile makes decisions much faster. I don't think there has really been a solution to this. Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.
  - Scarblac 3y ago
    Scrum is a strictly defined process, it has Scrum Masters, Product Owners, certifications, books, a number of defined meetings, sprints... Sort of the opposite of agile. > Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doing right now isn't exactly Scrum to the letter yet, you need more Scrum.
    - t43562 3y ago
      Scrum includes retrospectives - they exist to change the process. If the process cannot be changed then it's not scrum. OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the team should be able to have a rotating scrum master - one of the team for a sprint.
      - Scarblac 3y ago
        In my experience, the best you can hope for from retrospectives is small tweaks. The length of sprints, how standups should go, who writes what in tickets. But you can't change the process to be not-Scrum. Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked directly to the customer instead of through a product owner. Or even that tickets on a board are not a useful way to work at the moment. Things have to stay Scrum.
        t43562 3y ago
        Why not? I talked to customers as a dev - it's just that customers couldn't come and pester me to make me do extra work or change priorities. Is that too hard or inconvenient to understand? Scrum fits new development more than maintenance and I've never found any other "phase" where it doesn't fit reasonably. I've been in situations where I've thought we needed longer sprints. Ultimately if the overhead is too much we used the retrospectives to remove it. The problem is if you're the only one in the team that wants some change - then you cannot force it.

Scarblac 3y ago

I think it's Scrum that's a cult, agile works fine in the rare place that does it. But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment. Not something you have conferences about.

t43562 3y ago
What's the difference between what you're talking about and scrum? IMO the conferences are really there because the way companies think about projects and plans is not agile and it's difficult to marry up the higher level decision making with the way that agile makes decisions much faster. I don't think there has really been a solution to this. Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.
- Scarblac 3y ago
  Scrum is a strictly defined process, it has Scrum Masters, Product Owners, certifications, books, a number of defined meetings, sprints... Sort of the opposite of agile. > Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doing right now isn't exactly Scrum to the letter yet, you need more Scrum.
  - t43562 3y ago
    Scrum includes retrospectives - they exist to change the process. If the process cannot be changed then it's not scrum. OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the team should be able to have a rotating scrum master - one of the team for a sprint.
    - Scarblac 3y ago
      In my experience, the best you can hope for from retrospectives is small tweaks. The length of sprints, how standups should go, who writes what in tickets. But you can't change the process to be not-Scrum. Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked directly to the customer instead of through a product owner. Or even that tickets on a board are not a useful way to work at the moment. Things have to stay Scrum.
      - t43562 3y ago
        Why not? I talked to customers as a dev - it's just that customers couldn't come and pester me to make me do extra work or change priorities. Is that too hard or inconvenient to understand? Scrum fits new development more than maintenance and I've never found any other "phase" where it doesn't fit reasonably. I've been in situations where I've thought we needed longer sprints. Ultimately if the overhead is too much we used the retrospectives to remove it. The problem is if you're the only one in the team that wants some change - then you cannot force it.