What I find incredibly motivating is that there is a person on my team who comes into our office every day at the same time whom we call master, gets me to stand up each time we meet, and requests information about what I have done since the time he was here the day before and what I intend to do until his next visit tomorrow. Everybody on my team also seems highly motivated since each of us takes a dedicated story immediately and tries to implement it as fast as possible. Sometimes, I skip writing tests to be even faster. Frankly, I would skip a compiler if I could to save even more time. That‘s how motivated I am. The only interruptions I tolerate when working are when my master creates and assigns a new user story to me in our ticketing system and pings me to fill the story points based estimation accordingly. As a developer, I want to scream with joy infused by all the positive energy so that everybody working in our office building can get energized, too.
I think that Scrum Master is a regrettable name for the role. It sounds like a management role with a significant level of authority already. Maybe that’s one of the reasons why it often attracts the wrong mindset. Scrum Butler might have been a better name, considering what the role is supposed to be about. But what would the rate of Scrum adoption be then? How valuable would a Certified Scrum Butler title be for someone’s career? How many training sessions and exams could one sell? And does an organization with a servant mindset among its management already need a framework like Scrum? At least for the organizations out there performing daily agile theatre, it could be of some benefit, though. Those skeptical voices about how Agile is dead will get louder, eventually looking for someone to blame for the disaster. Identifying who killed Agile at their organization wouldn’t require a lengthy investigation. It was the butler, obviously.
The other day, I stumbled upon a visual overview of one of the popular agile scaling frameworks. Initially, I felt overwhelmed as I spent a long time searching for a product and a customer among all the different methods, practices, roles, and skills. It appeared to be a pretty risky business, at least to me. But then it finally struck me. The customer here is the organization implementing the framework, and the framework itself is the product. So, I stand corrected. This ain’t no risky business after all; it’s a no-brainer, really. It’s perfectly safe.