4 ms·

What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept

What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a daily basis), sprint reviews (transparency about the finished cycle), sprint planning (transparency about the next cycle), and sprint retrospectives (transparency about the way the team works) > improvement loop In scrum, that would be sprint retrospectives with a commitment to attempt to address at least some issues raised during a retrospective in the following cycle. > once you learned you need mechanisms to preserve the results In scrum, those would be backlogs (for the product and for the sprint). The practices specific to software engineering, such as automation, infrastructure as code, etc., fall out of the purview of scrum and will be picked up by other engineering practices (CI/CD, version control, etc.)

Juliate 4y ago
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.
arnvald 4y ago
The problem is not that Scrum doesn't have these things. The problem is that Scrum is a heavy and rigid set of processes that, besides a few useful things, adds a lot of unnecessary overhead. Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. It's either all or nothing, which is why I believe Scrum itself is anti-Agile.
- azangru 4y ago
  > Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. Of course it doesn't. It wouldn't be scrum if these were removed; it would be something else. Which is fine; but if you prefer to organize your work in a way that isn't scrum, then why would you call it scrum? > It's either all or nothing Isn't it the same with everything else? An agile manifesto, but with only one value rather than four? TDD but with tests written after the code, and without refactoring? And so on?
  - arnvald 4y ago
    When I work with a framework, let's say Ruby on Rails, and I don't use the build-in ORM, I still use Ruby on Rails. Agile is an idea, a concept. Scrum is a tool (or even a framework, according to its website), and for a tool that's associated with a concept of being agile and flexible, it's incredibly rigid.
twawaaay 4y ago
Every team and situation is different. The point of agile is to teach your team to solve problems. To build ability to spot whenever something can be improved and then understand what is expected of them and the tools at the disposal. An "agile from a book" is just a set of answers to some common problems. Your team will be none the wiser about how to deal with other problems that were not addressed by the book author.

Juliate 4y ago

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.

arnvald 4y ago

The problem is not that Scrum doesn't have these things. The problem is that Scrum is a heavy and rigid set of processes that, besides a few useful things, adds a lot of unnecessary overhead. Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. It's either all or nothing, which is why I believe Scrum itself is anti-Agile.

azangru 4y ago
> Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. Of course it doesn't. It wouldn't be scrum if these were removed; it would be something else. Which is fine; but if you prefer to organize your work in a way that isn't scrum, then why would you call it scrum? > It's either all or nothing Isn't it the same with everything else? An agile manifesto, but with only one value rather than four? TDD but with tests written after the code, and without refactoring? And so on?
- arnvald 4y ago
  When I work with a framework, let's say Ruby on Rails, and I don't use the build-in ORM, I still use Ruby on Rails. Agile is an idea, a concept. Scrum is a tool (or even a framework, according to its website), and for a tool that's associated with a concept of being agile and flexible, it's incredibly rigid.

twawaaay 4y ago

Every team and situation is different. The point of agile is to teach your team to solve problems. To build ability to spot whenever something can be improved and then understand what is expected of them and the tools at the disposal. An "agile from a book" is just a set of answers to some common problems. Your team will be none the wiser about how to deal with other problems that were not addressed by the book author.