> Sprints are useful like achievements in video games are useful; they make us feel warm and fuzzy inside. Motivation is a powerful tool, don’t misunderstand me

> Sprints are useful like achievements in video games are useful; they make us feel warm and fuzzy inside. Motivation is a powerful tool, don’t misunderstand me. The problem is that those warm fuzzies are mostly for the sake of the management team. It makes leaders feel in control and informed. They know exactly what was done and when it was completed. Sprints are used to reduce risk "that the wrong thing is delivered", to make sure end to end functionality is considered as soon as possible. And yes, it may not be easy to find a vertical slice the fits in a sprint, but you can push for it. Thus this summary is too generic... > Scrum (noun) - 1. [software] Any good process that works good Scrum is not a binary thing. It is a method that guides a team to produce tangible increments of the product quickly to inform the further development. I.e the idea is that you can and must pivot a lot during development of multi month effort. So if you are 100% sure about the requirements, waterfall development/ frozen requirements, is the most efficient way to produce a thing, zero meetings needed, no adaptions needed. The only problem is that most software development environment do not provide a high enough certainty, and that in the end big course corrections are needed when the outcome is finally produced/testing or integrated. Scrum opts for smaller corrections spread through out the development, yes there is overhead. It is a trade-off. And like everything else Scrum/Agile can be misused, misinterpreted by "management" and "engineers", however, that doesn't mean the idea of "Scrum/Agile" is "bad". The goal of Scrum/Agile is "getting stuff done" namely the right stuff. If it does not work for you/your team, no problem, but i think it is helpful to differentiate between the idea/ideal and the implementation in your context. I have seen Scrum fail miserable in some teams, and it some it was the best thing ever. > I’m incentivized to stop. I have never been in a scrum team, that was incentivized to stop.... because when we were done early... we would just pull items from future sprints a head. However, this can be tricky if other items in the sprint are not yet done. So that the team should help each other to get the other open tickets done. This is a trade off: Scrum deals with a team, that delivers software as a team. (which can have drawbacks). > The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. > Let’s just talk about the worst possible scenario where the scrum master is a non-technical, non-product people manager. soo how do you get from the above statement to: > In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done. That is a total misinterpretation of the scrum master and is the contrary what a scrum master should do. The statement didn't say the Scrum master should perform "interactions" on behalf of someone... > Scrum Master isn’t a full-time job. Who said it should be a full-time job ? Some scrum masters can guide two/three teams, or do fulfill other roles in the company. Finally at the end of the article the author links to a follow up "Scrum vs Kanban". https://qvault.io/jobs/kanban-vs-scrum/ https://qvault.io/jobs/kanban-vs-scrum/ Just one thought on this row in the cited table: Release methodology Scrum: At the end of each sprint Kanban: Continuous delivery In almost all scrum teams, where I have been, we had multiple releases per sprint, the most mature team I have been on, had "deploy to production" as part of the DoD of a ticket.