One thing I’ve seen in watching companies adopt agile principles, and specifically with some flavor of Scrum, is the tendency for newly-minted ScrumMasters to feel that they must have the answer for any question asked in a standup, demonstration, planning, grooming, or retrospective.
Now, it’s very typical for the existing Project Manager to assume the ScrumMaster role. It is the closest to what they were doing before.
And it’s natural for ex-Project Managers to hold on to many aspects of that role–we’re creatures of habit, after all. And in waterfall, the Project Manager was responsible–even accountable–for creating that lovely detailed work breakdown structure, and those spiffy cascading Gantt charts in MS Project. All the answers were at their fingertips: Are we On Schedule? Check with the Project Manager–they have a magical way of knowing if things are on track! What happens if we remove a feature? Subtract the tasks from the WBS, re-align any dependencies and voila, the Project Manager has calculated the answer!
Things aren’t so simple in life. Or in Scrum/agile.
If we’re building a healthy team, we should be seeing communication between team members, in a network, rather than in the hub and spoke fashion of a lot of Project Managers. ScrumMasters should encourage this networked mode of communication.
I believe it’s healthier to accept that one individual will not have all the answers. Scary? Sure. But if your team is healthy, the answer to a question is not very far away, because there will be enough communication to retrieve any answer in short order (and enough information radiated by reports the ScrumMaster maintains to answer many simple status questions straightaway). Think about the idea that the knowledge of the team is “too big to know” and that the smartest person in the room is the room.
One way to be sure that your team doesn’t get healthy is to make sure that all communication is funneled through one single individual. (For instance, what does it do to your truck number if only one person has access to the folder where the team’s release plan is stored?)
On some–or maybe even many–projects, rather than being a special expert, the ScrumMaster could be an individual from within the team who steps up to handle the ScrumMaster role in addition to their other duties. The description of the ScrumMaster from the Scrum Alliance’s Scrum 101 page reads simply “ensures that the team is functional and productive.”
So, ScrumMasters, make sure your teams are protected from outside distractions. Radiate information like a single-pipe steam radiator with a wide-open air vent on a freezing cold day. Get the team to the demonstrations, the retrospectives, the grooming, the planning by making sure they know when and where they are. But once things get underway, get out of the way. To borrow a phrase, facilitate your meetings “as though you were cooking a small fish.”
(As a sidebar, and in the interest of thoroughness–not as an endorsement–I’ll link to the “ScrumMaster Manifesto.” I’ll say that I’m pretty sure that I disagree with their statement “WE BELIEVE THE SCRUMMASTER IS A FULL-TIME POSITION FOR ONE PERSON ON ONE SCRUM TEAM.” I think a lot about team size, challenge, maturity, and capability are being assumed by that statement.)