The problem is that the author did not define what engineering is. Given that, your conclusion is valid. Regardless I do agree with the author. In fact, in my

The problem is that the author did not define what engineering is. Given that, your conclusion is valid. Regardless I do agree with the author. In fact, in my opinion, the fact that scrum is not an engineering process is its largest shortcoming. My opinion is that the difference between engineering and programming is that engineers support non-functional requirements. In other words they are responsible for satisfying technical constraints on a system. These are things like can my system fit within a certain size, weight, can it run at a certain speed, etc. This means that many people who are doing programming are actually doing engineering. Anyone who has tried to optimize a program is trying to meet a non-functional requirement on speed or memory usage. Scrum does well if you want to bolt things onto your system. As a user I want to do x. Do you want to add a button? Make a user story, estimate it. Do you want to add a payment system? Make a user story, estimate it. It's simple and that makes it seductive. This sometimes works for non-functional requirements. System running too slow? Do a spike story. It was because we're using bubble sort under the hood. Make a story to swap it out with quick sort. But what if I want to change my response time of my system from 2s to 1s? Well we need to re-architect our system and launch a new satellite into orbit. Alright, so you can do that in a sprint, right? For me, Scrum is a toy process of what business people think engineering is. It fails as a process because it doesn't account for non-functional requirements and it doesn't admit its shortcomings.