“The team just doesn’t have a sense of urgency.”
Have you ever uttered those words? Or felt the frustration from this preconceived notion? Have you ever wondered why your teams aren’t performing to your expectations? You question whether they just lack passion or simply don’t care? Or maybe they just aren’t into their jobs? Are team members just phoning it in?
Did it ever occur to you that…
Maybe they don’t have the skills necessary to perform the work, and need to be taught? Or maybe they can’t focus due to getting pulled in multiple, conflicting directions? Maybe the user stories are too large, too complex, or too bulky to finish within a sprint? Maybe they are working on outdated laptops, with severe performance issues, and they literally cannot speed up their process? Maybe they don’t understand the expectations due to language, cultural, time zone, or physical barriers? Or perhaps, maybe the sense of urgency was never adequately conveyed because they don’t know why they’re doing the work?
How would asking curiosity-based questions change our internal narrative? The dynamics of our relationships? What if we proceeded based on curiosity, rather than secretly fuming from a place of scrutiny and distrust?
Assuming positive intent (API) is the first step towards strengthening our bonds with our teams, rather than destroying them, based on false presumptions.
I challenge you to try API as your personal internal experiment. Afterwards, reflect on your experience: Did your relationships shift? Did you gain insight about yourself, your team members, or the process? Did you find yourself responding from a place of empathy or concern? How did it feel to assume positive intent – did you feel less frustrated and gain empathy?
This is just one step we can take to strengthen our relationships and build in psychological safety. Not only at work, but in our personal lives as well.
Stay positive! Stay curious!
During a recent client engagement, I advocated that Scrum Masters schedule one-on-ones with their team members. Afterwards I was approached by a Scrum Master who was curious as to the “why” behind this recommendation. He thought the purpose was to receive feedback and answer questions regarding the Scrum Process. His assumptions were correct, but he only touched the surface, so I thought I’d dive a little deeper.
The Scrum Master is a servant-leader for the Scrum team. They serve the development team in self-organization and cross-functionality – through training, mentoring and coaching. Great Scrum Masters want to help grow the team, enforce accountability and encourage productivity, and empower collaboration.
Essentially, the Scrum Master is the team coach.
A One-on-One session is an extremely efficient technique to:
One final note – spending one-on-one time with a person sends the message that the person is valuable. When the focus is on understanding team members’ concerns and helping them be productive, the SM is also building trust…. Which is KEY for high performance.
The technique is not only useful for team members. I often recommend that Scrum Masters schedule regular one-on-ones with the managers of their team members. This is NOT a complaint session nor focused on airing dirty laundry.
Instead, you establish a partnership where you both are helping each team member, and the overall team, be the best they can be. This also helps the manager increase the effectiveness of their own one-on-ones with team members.
I’ve noticed the term “Scrum Master” results in a variety of facial expressions for people who are unfamiliar with the Scrum roles. These run the gamut from confusion to suspicion to outright incredulity.
“What does this even mean? What is this “Master of Scrum”?
Sounds like complete rubbish; an imaginary role that offers no credibility or substance.” Their body language further reinforces their intrinsic cynicism – arms crossed, neck tensed, palms clammy. I imagine they envision hundred-dollar bills engulfed in flames, each time a Scrum Master deposits their paycheck.
I rise to the challenge and dutifully describe the role of the Scrum Master.
A Scrum Master is the “servant leader” for the Scrum Team, Product Owner and organization. This means promoting and supporting Scrum through teaching Values, theory, practices, and rules. Scrum Masters serve the Scrum team by shielding them from outside forces, removing impediments and coaching them in self-organization and cross-functionality, all of which allow them to focus on creating high value products. They also encourage the team to improve its development process and practices to make it more effective and enjoyable for the next sprint.
They serve the Product Owner by offering techniques for effective product backlog management, ensuring goals, scope, and product domain are understood by everyone, and facilitating Scrum events as requested or needed. The organization relies on the Scrum Master to lead and coach the Scrum adoption, induce change to increase the productivity of the Scrum teams and help everyone to understand and enact Scrum and empirical product development. In addition, the Scrum Masters are continually monitoring transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.
Without Scrum Masters, we must assume that the Scrum Team and a Product Owner work together like a well-oiled machine and fully comprehend Scrum. (I have yet to experience this.) Who is going to help those outside the team understand which interactions are helpful and which aren’t? Who will explain the agile “Why” behind the agile “What”? Who is monitoring the health of the team, keeping Scrum events focused & efficient, and coaching the team on autonomy, cross-functionality, and self-organization? Who is continually observing the team dynamics, enforcing the agile mindset, and challenging for continual improvement?
After explaining all of this, a mental light bulb turns on, I know this because their facial expressions change. Their eyebrows relax, body leans forward, fingers steepled at their lips, in a thought-provoking manner.
AHA! Perhaps I’ve cracked the code.
What if we replace the role of “Scrum Master” to “Team Coach”? If leadership and team members viewed them as “Team Coaches”, then perhaps they wouldn’t be continually trying to understand or justify their role.
After all, every great team needs a coach. Don’t they?