One of the core tenants of any good Agile practice has to be the openness and transparency of the exercise. There’s little room for opacity in a well run Scrum – both within the development group as well as with the business team & users. One of the phrases that I both love & hate is the expression: Servant Leader.
I love the concept of the Servant Leader because it immediately conjures images of someone in an authority role serving those who he* is responsible for. It inverts the traditional image of “boss” and “worker.” Thanks to this inversion, you’ve effectively cleared the mental reasons for someone in a worker role to avoid sharing an idea, opinion, or concern. At the heart of Agile is the need for the leader to quickly understand the true facts of the situation, whether it’s an estimate that’s turning out wrong, a requirement that’s incomplete, or a technical hurdle that needs more hands. In a Servant role, it’s my responsibility to take care of the hassles, nonsenses, and nuisances. Cook the food, feed the troops, clear the table, and get ready for the next meal.
I hate the concept of the Servant Leader because it’s not really authentic. Sure, I’m going to do whatever I can to make you happy – but if I’m not sold on the results there’s no real question of how these roles are going to change. You’re going to be responsible for the outcomes and I’m going to be responsible for figuring out if there’s any consequences. This notion of servitude and being subject to each other can compete with traditional structure and focus. The expression “servant” seems dated, and in our modern language might seem insensitive. I don’t have any first-hand experience with this (I’ve never had a coworker or colleague say that it’s offensive) – but if it were, I wouldn’t be surprised.