3 ms·

Scrum is a strictly defined process, it has Scrum Masters, Product Owners, certifications, books, a number of defined meetings, sprints... Sort of the opposite

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.

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.