Robert Martin wrote an article in November, 2010 entitled “What killed water fall could kill Agile”
Martin wrote about the elitism in software development. In water fall, the analysts are elites; they define everything in documentation and leave the work to the developer. When a project fails, it is the developer who bares the blame. The analysts do not as often take responsibility. Hence, as Martin argues, elitism kills water fall.
It’s possible that the same thing happens in Scrum: The Scrum Master is an important role in Scrum. They are usually certified as “Certified Scrum Masters” and most CSMs were project managers in their past. So the Scrum Master, in this situation, becomes the elite. If that is the case, will elitism kill Agile also?
I don’t fully agree with this idea. In our CSM training, one key point mentioned all the time is that the Scrum Mast has no authority in the team. The team decides what they should do. The Scrum Master’s responsibility is to help the team follow the Scrum principle, so essentially, the SM and the team are equal.
But think about the other side: The SM need to be certified, while the team does not. So, it may be that the Scrum Master more easily takes to the role of the elitist, and when the project succeeds, the SM receives the reward and recognition (on behalf of the team, of course), but when the project fails, perhaps it becomes easier to blame the team.
What do you think?
Aaron, I enjoyed your post and wanted to share my view of the scrum master role. Christopher Alexander, in his Nature of Order series, defined 15 characteristics of “life” or “wholeness” in a structure – those elements that give people a sense of belonging, a feeling of comfort, or cause them to perceive themselves in the structure. He was talking about physical structures, but I think the same characteristics apply to social structures. I see the scrum master and product owner seamlessly working together as the perfect boundary that exhibits the characteristic Alexander calls “deep interlock and ambiguity,” the two of them changing almost like chameleons from passionately representing the team’s needs to the business while strenuously advocating for the business within the team. Thus, they are neither team nor business, and yet they are often indistinguishable from either team and business. I wish the role were described in these terms to those who attend scrum master training because, even though it is an ideal, I think it represents a more useful role model than the standard project manager archetype – certainly it obviates any claim to superiority.
Hi Pam, This is a brand new view about SM and PO, I agree SM/PO/Team should work closely just as one team. “deep interlock and ambiguity” seems blur the responsibility of SM, representing the team’s needs is not the responsibility of SM, I like the “sheepdog” definition about SM more. How do you think?