Prévia do material em texto
Preface Technical projects are like an old horse I had when I was a kid; they'll flip you when you least expect it! Yet the element of surprise is actually a surety in our technical world. Agile methods, with their focus on helping teams deliver quality features and products quickly and flexibly, have drawn me in as a way to help tame the bucking horse, the element of surprise in technical projects, and Scrum, in particular, as a gateway to discover which day-to-day processes and working styles fit best for a particular team in a particular setting. A ScrumMaster, like a good rider, must know when to go easy on the horse, when to use the spur, when to pull the reins, and when to just hang up the bridle and put the saddle away for the day. There are nearly a quarter million CSMs now, and many more to follow. While this is great news and represents a steady interest in Agile methods, we are in the soup. There is rampant misuse and misunderstanding of Scrum, which diminishes and possibly eliminates the amazing possibilities that people discover by using it correctly. I've observed too many examples of good Scrum gone bad—times in which tough, courageous, persistent ScrumMasters could have really made a difference, but didn't; times when product owners could have been a bit more involved; times when teams hid poor quality and shouldn't have. Additionally, with the advent of several newer methods, the terms Iteration Manager and Agile Master are floating around and representing an increasingly watered-down, dangerous version of what the true ScrumMaster was meant to do. That sucks, and makes me sad—and spurs me to action. I don't want the original vision for ScrumMaster to become lost in the methodology/certification wagon train; I want people to reach their full potential and believe that Scrum is one way to facilitate that. Preface