He’s our key integrations guy, backend engineer, and Help.com’s appointed Scrum Master. Matthew connects the dots and helps the rest of the team stay on the same page. Needless to say, it’s easier to get things done when he’s around.
My main focus is team communication. In general, my preference is to get conversation started and let it go on naturally and only periodically realign it with the intended topic. That doesn’t often happen in planning or other non-technical meetings, so I’ll frequently find myself feeling more like a conductor than a facilitator. It’s challenging because the more active I am in a discussion, the more I tend to get involved in the discussion, so I have to actively keep my own preferences in check.
Adoption and adherence to the Scrum framework is a pretty universal problem. Not everyone sees the value in the various activities or methods, so they see it as a waste and want to cut it in favor of “getting back to work.” So, as a Scrum Master, you try to gauge and coach teams through it while educating about the process.
For example, every team that I’ve worked with tends to overestimate how much they can get done in a period of time. However, if the team isn’t allocated enough, they tend to ‘gold plate’ their work. So you have to encourage them to plan with an attitude of cautious optimism.
Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” (Wikipedia)
Parkinson’s Law: “Work expands to fill the time available for its completion.” (Wikipedia)
I do exactly what I did this morning. Stopped everyone, made sure I had the correct interpretation, then, depending on the issue, address it right away or identify who or what is needed to get past the issue. Usually that means getting smaller and more issue-focused conversations started.
Agile, in general, is an inspect-and-adapt framework that lets you periodically adjust how you do things to repeat successful practices and avoid other behaviors that detract from success. The sprinting aspect of Scrum fits into how we build things well by offering reasonable durations of no changes and short-term achievable goals for the team. Even so, neither Scrum or Agile ensure success; they limit the impact of failure and allow for adjustment.