3 ms·

> 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

> 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

>> 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.