There is one very important step that the author missed: ensure you have customer buy-in. This is also the hardest step to do, but I feel like a lot of scrum-ta

There is one very important step that the author missed: ensure you have customer buy-in. This is also the hardest step to do, but I feel like a lot of scrum-talk glosses over this. A medium bug appears in your production environment. Will your customer really wait till the next sprint to get it prioritized, then fixed? Or, your customers expect functionality, time, and dollar estimates in a proposal before they start a project. Sure, some teams think they can do scrum under the covers, and give them what they really want, but in the end do you have the right language in your contract to address changes made during the project? Will the customer really care that feature X didn't make it because it wasn't prioritized high enough at the last grooming? Until you get this buy-in from the people paying you, there is a huge conflict about how you want to do things vs. what the customer expects. And generally, they'll win until you convince them. But why should they change? They're happy with how things are going the way it is.