A Scrum Master has a tough job. He is supposed to help his team perform without actually diving into the work himself, for if he did, then when someone has an impediment, he would be busy and likely not have the broad context needed to solve the problem outside of his immediate work. Preserving a big picture perspective is important. Firemen don't leave the station without their Fire Captain. The Captain isn't allowed to enter the building and must stay in the fire engine (or near it) and coordinate his team via radio. (I've even heard that Fire Captains are literally locked inside the fire engine to prevent them from abandoning their post to rush into a burning building.)
Everyday, the Scrum Master's job is to figure out how to get the team perform better, which is much harder than developing code. The worst situation a Scrum Master can be in is have a team that isn't delivering software in a predictable fashion, and the team always claims that everything is going fine.
Day after day of standups where nothing interesting is spoken of, and sprint after sprint of missed sprint goals is enough to make a Scrum Master cry. If this is the case for you, then you need to fix this!
Here are some methods on "loosening up" a team so they share their problems:
It's a tough life being a Scrum Master. You rely on those doing the work to tell you what ails them, and you can't help them if you don't know what the problems are. You can't be a Scrum Master if they won't tell you of their problems. You can't be a Scrum Master if they don't trust you to take their problems and treat them in a way that works both for the team and for the organization.
You can't solve problems that you don't know about.
If all else fails, embarrass them: Tell them you'll cry if they won't do their jobs and open up about what isn't working.
No one likes to see a Scrum Master cry.
[1] One time during a standup, I brought up two impediments, each of which were quickly judged by an attending manager as one being too hard, and the other too small when there were other bigger problems. These are signs of a reluctance to change. If an organization can't be bothered to fix small problems or is unwilling to do so, then the adapt part of Scrum is broken outside of the team's scope and that is a sad situation.
Everyday, the Scrum Master's job is to figure out how to get the team perform better, which is much harder than developing code. The worst situation a Scrum Master can be in is have a team that isn't delivering software in a predictable fashion, and the team always claims that everything is going fine.
Day after day of standups where nothing interesting is spoken of, and sprint after sprint of missed sprint goals is enough to make a Scrum Master cry. If this is the case for you, then you need to fix this!
Here are some methods on "loosening up" a team so they share their problems:
- Ask questions about tasks which aren't progressing very well (a 1 day task going into its third day)
- Encourage risk taking and nontraditional ideas, activities and actions
- Figure out how to make it OK to "call uncle" so you know they need help.
- Don't immediately judge impediments: "That is too big to tackle, just live with it," or "that is such a small impediment when I know there are some really large ones that are holding us back."[1] The team is supposed to air impediments, not be told to air only the impediments the organization wants to handle.
- When an impediment is discovered, track them! Put them on a big visible chart of some kind. Don't try and be a "waiter" that takes their teams "orders." Unlike working in a diner, the cycle time of solving impediments takes more than twenty minutes, and usually up to 24 hours. Within thirty minutes after standup, no one remembers what happened though the person who brought it up will remember at standup the next day. The impediments should be visible in the team area so that everyone knows the status of them.
- Celebrate whenever an impediment is brought up. Usually an "atta-boy" will work.
- Acknowledge people in a public setting for exposing impediments.
It's a tough life being a Scrum Master. You rely on those doing the work to tell you what ails them, and you can't help them if you don't know what the problems are. You can't be a Scrum Master if they won't tell you of their problems. You can't be a Scrum Master if they don't trust you to take their problems and treat them in a way that works both for the team and for the organization.
You can't solve problems that you don't know about.
If all else fails, embarrass them: Tell them you'll cry if they won't do their jobs and open up about what isn't working.
No one likes to see a Scrum Master cry.
[1] One time during a standup, I brought up two impediments, each of which were quickly judged by an attending manager as one being too hard, and the other too small when there were other bigger problems. These are signs of a reluctance to change. If an organization can't be bothered to fix small problems or is unwilling to do so, then the adapt part of Scrum is broken outside of the team's scope and that is a sad situation.
No comments:
Post a Comment