Interesting. I think the author got it wrong but by totally different reasons, LOL. I really don't like SCRUM, but sounds like the Author got it totally wrong.

Interesting. I think the author got it wrong but by totally different reasons, LOL. I really don't like SCRUM, but sounds like the Author got it totally wrong. Problem #1 - Scrum Is Vague: Nope, it can be vague, you can create your own dialect from SCRUM, but you can do SCRUM by the book and it's fine Problem #2 - The “Sprint” : The context switch is a problem, however you can build a feature or a set of features iteratively, in 2 weeks block. It is doable and normally I have to admit you move forward with more confidence because you are able to expose your work sooner to the users (i.e as a beta feature) Problem #3 - The Scrum Master: "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.": Nope it will never happen. Scrum Master don't do follow-up on the dev team. SCRUM has well defined cerimonies to introspect the development. At least I never saw or heard of this issue. Problem #4 - Estimates: You don't have to over-engineer it. We size cards to make sure that everyone understood the problem. If I card a card as L and the whole team sized it as S, we discuss to make sure that we are all on the same page. It helps us a lot to map all work to be done in one card Beside that I don't think doing SCRUM you spend more money than necessary.. Normally the SCRUM master is one developer and SCRUM actually can be used to reduce the development costs. It's pretty common to have teams with 1 or 2 senior devs and the rest juniors, forcing the seniors to do coaching and micromanagement from the junior devs...