I've been using scrum for about ten years at several companies. Each time I do it, I explain to everyone that the process has nothing to do with getting people

I've been using scrum for about ten years at several companies. Each time I do it, I explain to everyone that the process has nothing to do with getting people to be more efficient or work harder. It has everything to do with helping me estimate when stuff will get done so that I can let all the dependent parts of the company know well ahead of time. If the work being done doesn't get re-prioritized, I can pretty accurately judge about 3 months out and very accurately judge a month out. That lets the rest of the company plan fundraising, PR, sales, etc. This is where I disagree with the author. You do get fairly predictable output out of a group of engineers regardless of their ability as long as they are consistent in their estimates for how long something will take (it doesn't matter if they over or underestimate, just that they do it consistently). You just won't like the results if they are mediocre. I really want to stress how important the whole self-learning and re-adjustment part of the process is (if someone doesn't scream at least once during a retrospective, they're probably just going through the motions.) While I've run "scrum" for 10 years, the details of how each worked were pretty different depending on the teams involved. That said, I tend to hire self-managing, self-learning engineers which scrum works beautifully for. I also am completely comfortable with delegating away large amounts of authority especially given the type of people I hire.