4 ms·

The problem with Scrum is people talking about how this should be more Scrum, or how this is not really how Scrum is/defines things/should happen. Rather than

The problem with Scrum is people talking about how this should be more Scrum, or how this is not really how Scrum is/defines things/should happen. Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work. The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environments as the exact opposite.

azangru 4y ago
If you replaced the word "scrum" with the word "agile" in the message above, would you still advance the same argument? Would you say that the problem with agile is that people are talking about how this or that should be more agile; or how a company isn't really agile; or how the way it does things violates the values or principles of the Agile Manifesto? If you would, then why does it seem a problem for you when the same applies to scrum? Scrum, as defined in the Scrum Guide, is perfectly consistent with the Agile Manifesto. It is one of the ways of putting the manifesto into practice. Scrum's framework clearly promotes interactions between individuals, customer collaboration, working software, and response to change. If individuals, who, according to the manifesto, are more valuable than the processes, decide that the processes defined in scrum aren't working for them, they are always free to reject scrum and work out another set of processes. But if a team doesn't yet know what processes would work for it, scrum is as good a place to start as any, to actually feel what enacting the manifesto actually involves.
- marcus_holmes 4y ago
  > scrum is as good a place to start as any No, it's not. It's a very bad place to start. Because Scrum is a fixed process, with a fixed meaning. If you started with Scrum and then stopped doing sprints because they weren't working for your team, you would quickly run into all sorts of opposition around "we're not doing Scrum properly; we need to be doing sprints". Whereas if you started with nothing, no process at all, and later tried adding sprints, everyone would evaluate sprints by themselves with no preconditioned notion of how that should work within the rest of the process.
  - azangru 4y ago
    > Scrum is a fixed process, with a fixed meaning. I completely agree. The reason I think it's a great place to start though is because this fixed process, with its fixed meaning, is well suited to the work involved in building new products. > If you started with Scrum and then stopped doing sprints because they weren't working for your team... ...then you would stop doing scrum. The objection "we're not doing Scrum properly; we need to be doing sprints" would only make sense in the context where you would be pretending to continue to be using scrum after throwing parts of it away. The moment you stopped doing sprints, you have made a decision that scrum as a process isn't working for you, and have switched to something else. You shouldn't keep calling it scrum to avoid confusion.
- Juliate 4y ago
  > It is one of the ways of putting the manifesto into practice. It is not because it specifically mandates a given methodology imposed upon a team. The ethos of the agile manifesto is precisely the opposite. And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations. It's "what everyone do". It's the "best practice". It's also become a huge red flag for hiring, still few company realize that yet.
  - azangru 4y ago
    >> It is one of the ways of putting the manifesto into practice. > It is not because it specifically mandates a given methodology imposed upon a team. You are misreading what I have written. Yes, Scrum specifically mandates a certain set of practices. However, all these prescribed practices are aligned with the agile manifesto. The manifesto never said be anarchic. The manifesto never said do not follow any processes in your work. If that were your understanding of the manifesto, you would have to object to all and any processes that have any predefined structure to them. Code reviews? Nope, that's a process. Pair programming? Nope, that's a process. TDD? Nope, too rigid. And so on. Scrum is A way to put agile values and principles into practice, not THE way. But it is certainly not antagonistic to the manifesto. > And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations. I am re-reading this sentence, and the previous two paragraphs, and just can't connect them together into a coherent thesis. Scrum is a good place to start in theory? — Well, yeah; that's what I've been saying here. — But in many places Scrum is practiced atrociously? — Well, yeah, don't do it atrociously then; do it properly.
  - twawaaay 4y ago
    I think it is worth to note that there is nothing wrong with the scrum techniques. Just like any shoe you find in a store might be fully functional and useful to somebody it might just not be good fit for you. Now, that might not be a problem for a more traditional development process of the past. In the past we would just choose one of the prescribed processes that was deemed the most fitting. But the agile came and basically said that any set process is by definition wrong. The goal was to pursue constant improvement, forge the process as you go along and the idea was that the company that can improve faster will, over time, prevail over competition (you can't say "win", because it is an infinite game). And that the faster you can execute the iterations of these improvements the faster you can improve overall. And that the higher management is usually ill suited to do this because it just takes too much time to get the improvement iteration and that they usually don't know the specifics anyway. And out of all this came the idea that the team itself should be responsible for improving their own process because this is the only way to do it fast enough. In practice when the team notices a problem I may offer a possible solution for discussion and this solution will frequently be something already known from typical "agile"/scrum/kanban literature. Again, not saying it is all wrong but it needs to be viewed as a collection of solutions to individual problems rather than collectively a solution to fixing development process.

azangru 4y ago

If you replaced the word "scrum" with the word "agile" in the message above, would you still advance the same argument? Would you say that the problem with agile is that people are talking about how this or that should be more agile; or how a company isn't really agile; or how the way it does things violates the values or principles of the Agile Manifesto? If you would, then why does it seem a problem for you when the same applies to scrum? Scrum, as defined in the Scrum Guide, is perfectly consistent with the Agile Manifesto. It is one of the ways of putting the manifesto into practice. Scrum's framework clearly promotes interactions between individuals, customer collaboration, working software, and response to change. If individuals, who, according to the manifesto, are more valuable than the processes, decide that the processes defined in scrum aren't working for them, they are always free to reject scrum and work out another set of processes. But if a team doesn't yet know what processes would work for it, scrum is as good a place to start as any, to actually feel what enacting the manifesto actually involves.

marcus_holmes 4y ago
> scrum is as good a place to start as any No, it's not. It's a very bad place to start. Because Scrum is a fixed process, with a fixed meaning. If you started with Scrum and then stopped doing sprints because they weren't working for your team, you would quickly run into all sorts of opposition around "we're not doing Scrum properly; we need to be doing sprints". Whereas if you started with nothing, no process at all, and later tried adding sprints, everyone would evaluate sprints by themselves with no preconditioned notion of how that should work within the rest of the process.
- azangru 4y ago
  > Scrum is a fixed process, with a fixed meaning. I completely agree. The reason I think it's a great place to start though is because this fixed process, with its fixed meaning, is well suited to the work involved in building new products. > If you started with Scrum and then stopped doing sprints because they weren't working for your team... ...then you would stop doing scrum. The objection "we're not doing Scrum properly; we need to be doing sprints" would only make sense in the context where you would be pretending to continue to be using scrum after throwing parts of it away. The moment you stopped doing sprints, you have made a decision that scrum as a process isn't working for you, and have switched to something else. You shouldn't keep calling it scrum to avoid confusion.
Juliate 4y ago
> It is one of the ways of putting the manifesto into practice. It is not because it specifically mandates a given methodology imposed upon a team. The ethos of the agile manifesto is precisely the opposite. And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations. It's "what everyone do". It's the "best practice". It's also become a huge red flag for hiring, still few company realize that yet.
- azangru 4y ago
  >> It is one of the ways of putting the manifesto into practice. > It is not because it specifically mandates a given methodology imposed upon a team. You are misreading what I have written. Yes, Scrum specifically mandates a certain set of practices. However, all these prescribed practices are aligned with the agile manifesto. The manifesto never said be anarchic. The manifesto never said do not follow any processes in your work. If that were your understanding of the manifesto, you would have to object to all and any processes that have any predefined structure to them. Code reviews? Nope, that's a process. Pair programming? Nope, that's a process. TDD? Nope, too rigid. And so on. Scrum is A way to put agile values and principles into practice, not THE way. But it is certainly not antagonistic to the manifesto. > And Scrum might be a good place to start with in theory, while in practice, it's become in many corporations as the standard way of operations. I am re-reading this sentence, and the previous two paragraphs, and just can't connect them together into a coherent thesis. Scrum is a good place to start in theory? — Well, yeah; that's what I've been saying here. — But in many places Scrum is practiced atrociously? — Well, yeah, don't do it atrociously then; do it properly.
- twawaaay 4y ago
  I think it is worth to note that there is nothing wrong with the scrum techniques. Just like any shoe you find in a store might be fully functional and useful to somebody it might just not be good fit for you. Now, that might not be a problem for a more traditional development process of the past. In the past we would just choose one of the prescribed processes that was deemed the most fitting. But the agile came and basically said that any set process is by definition wrong. The goal was to pursue constant improvement, forge the process as you go along and the idea was that the company that can improve faster will, over time, prevail over competition (you can't say "win", because it is an infinite game). And that the faster you can execute the iterations of these improvements the faster you can improve overall. And that the higher management is usually ill suited to do this because it just takes too much time to get the improvement iteration and that they usually don't know the specifics anyway. And out of all this came the idea that the team itself should be responsible for improving their own process because this is the only way to do it fast enough. In practice when the team notices a problem I may offer a possible solution for discussion and this solution will frequently be something already known from typical "agile"/scrum/kanban literature. Again, not saying it is all wrong but it needs to be viewed as a collection of solutions to individual problems rather than collectively a solution to fixing development process.