I can imagine that the term “servant leader” means different things to different people in software development. One is the meaning referred to in the podcast, focusing on social harmony and treating teams and organizations as a kind of family. It probably comes close to what Robert Greenleaf had in mind when he coined the term more than 50 years ago. But does it mean the same in the context of Scrum, for example? I don’t think the official Scrum Guide implies it. As far as I know, Scrum adopts the term and a few ideas but not the whole concept of servant leadership as described by Greenleaf. The primary purpose is to remind Scrum masters not to abuse their power and treat the other stakeholders, particularly the developers, as subordinates. I don’t think there is the expectation that they live up to Greenleaf’s lofty ideals, and maybe it’s more realistic to see Scrum masters as “lightweight servant leaders.”
I believe that if a professional is going to call themselves something, they should know what that something means.
I call myself a capitalist and know what that means – all the good and all the bad. People call themselves socialists, and I think they know some of the good, but none of the bad. A Scrum Master who calls themselves a “Servant Leader,” should know all of the good, and all of the bad that comes with their adopted leadership philosophy.
It would seem that the scrum community wants to keep the term “servant leader,” but back away from its originator’s intended meaning. Adam Smith defined Capitalism, Karl Marx defined Socialism, and Robert Greenleaf defined Servant Leadership. If you disagree with Greenleaf, the scrum community should find another term, invent one of their own, or expand their definition of a scrum master to include the aspects of servant leadership they like.
Then again, I also think Scrum is ill-suited for anything related to software development, so at some point, we’re trying to optimize a system that is fundamentally inappropriate for real-world software projects, if for no other reasons than:
1) Scrum does not have the concept of fixed-scope deadlines, despite businesses being driven by contractual obligations that must be fulfilled by a date.
2) Software developers are not fungible, so two scrum teams can never be alike, making all multi-team metrics useless, and single-team metrics pointless (no pun intended).
3) Revenue-generating customer value cannot be subdivided and delivered piecemeal while still satisfying the customer.
4) All non-trivial software projects have too much risk for estimates to be worth doing, especially as they open the door for Parkinson’s Law (“work expands to fill available time”).
Everything else Scrum does wrong is simply a matter of the road to hell being paved with good intentions. Scrum means well, but introduced the idea of, “If it’s not working you’re doing it wrong,” as well as, “If it’s not working you need to adjust it until it is,” which eliminated a critical macro-process (i.e., Scrum itself) improvement process. Had Scrum accepted that its process was fundamentally flawed a decade ago, today it may have evolved into something worthwhile. However, if it did evolve, it would most likely have simply become a clone of the Project Management Institute, thus losing their competitive differentiator for customers seeking something new to adopt as they undergo their “digital transformations.”
I can imagine that the term “servant leader” means different things to different people in software development. One is the meaning referred to in the podcast, focusing on social harmony and treating teams and organizations as a kind of family. It probably comes close to what Robert Greenleaf had in mind when he coined the term more than 50 years ago. But does it mean the same in the context of Scrum, for example? I don’t think the official Scrum Guide implies it. As far as I know, Scrum adopts the term and a few ideas but not the whole concept of servant leadership as described by Greenleaf. The primary purpose is to remind Scrum masters not to abuse their power and treat the other stakeholders, particularly the developers, as subordinates. I don’t think there is the expectation that they live up to Greenleaf’s lofty ideals, and maybe it’s more realistic to see Scrum masters as “lightweight servant leaders.”
I believe that if a professional is going to call themselves something, they should know what that something means.
I call myself a capitalist and know what that means – all the good and all the bad. People call themselves socialists, and I think they know some of the good, but none of the bad. A Scrum Master who calls themselves a “Servant Leader,” should know all of the good, and all of the bad that comes with their adopted leadership philosophy.
It would seem that the scrum community wants to keep the term “servant leader,” but back away from its originator’s intended meaning. Adam Smith defined Capitalism, Karl Marx defined Socialism, and Robert Greenleaf defined Servant Leadership. If you disagree with Greenleaf, the scrum community should find another term, invent one of their own, or expand their definition of a scrum master to include the aspects of servant leadership they like.
Then again, I also think Scrum is ill-suited for anything related to software development, so at some point, we’re trying to optimize a system that is fundamentally inappropriate for real-world software projects, if for no other reasons than:
1) Scrum does not have the concept of fixed-scope deadlines, despite businesses being driven by contractual obligations that must be fulfilled by a date.
2) Software developers are not fungible, so two scrum teams can never be alike, making all multi-team metrics useless, and single-team metrics pointless (no pun intended).
3) Revenue-generating customer value cannot be subdivided and delivered piecemeal while still satisfying the customer.
4) All non-trivial software projects have too much risk for estimates to be worth doing, especially as they open the door for Parkinson’s Law (“work expands to fill available time”).
Everything else Scrum does wrong is simply a matter of the road to hell being paved with good intentions. Scrum means well, but introduced the idea of, “If it’s not working you’re doing it wrong,” as well as, “If it’s not working you need to adjust it until it is,” which eliminated a critical macro-process (i.e., Scrum itself) improvement process. Had Scrum accepted that its process was fundamentally flawed a decade ago, today it may have evolved into something worthwhile. However, if it did evolve, it would most likely have simply become a clone of the Project Management Institute, thus losing their competitive differentiator for customers seeking something new to adopt as they undergo their “digital transformations.”