On teams with a culture of working like this, you can almost watch the product take shape every day versus just hearing about progress in meetings.
In this episode, Richard and Peter answer the question: “I get the basic definitions of the Scrum roles. In the real world, though, what do these roles look like when they’re done well?” Hear their take on what it means to be a great ScrumMaster, Product Owner, or Scrum developer, beyond the “by the book” Scrum Guide answers.
Learn More
Certified ScrumMaster Workshop (virtual, instructor-led)
Certified Scrum Product Owner Workshop (virtual, instructor-led)
Advanced Certified Scrum Product Owner Program (virtual, instructor-led)
Agile & Scrum Crash Course (online, self-guided)
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!
Peter Green
If you’ve got a question you’ve been struggling with, email us at mailbag@humanizingwork.com, and we’ll see if we’ve got a good answer for you.
Richard
Before we jump into today’s episode, just a quick reminder to rate and review the Humanizing Work Show in your podcast app, or if you’re watching this on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you. Your help spreading the word is super meaningful to us!
Peter
And if you want to get access to even more content we produce, not just the show, you can sign up for our weekly newsletter at humanizingwork.com/hwnews.
Richard
On to this week’s question: “I get the basic definitions of the Scrum roles. In the real world, though, what do these roles look like when they’re done well?” To answer this question, we’ll give a quick reminder of the official description of each of the roles and then we’ll talk about what we’ve seen and experienced from these roles when they’re played particularly well.
Peter
Let’s start by talking about what a Scrum team is built to do. Scrum teams are intended to be what Harvard Researchers J. Richard Hackman and Ruth Wageman call a “real team,” meaning that they have a compelling purpose that requires interdependence of team members, they’ve got all of the skills within the team boundary needed to achieve that purpose, and it’s clear to everyone who is on the team and who isn’t. Scrum teams succeed when they have these conditions and then we point them at a compelling purpose that contains complexity within that team boundary. We got into more detail about this concept in our episode called “These Six Things Improve How Teams Work,” so check that one out for more info on this.
Scrum teams are cross-functional in the same way that a sports team is cross-functional. To illustrate that, let’s think about a basketball team, for example, that’s staffed with people with very specific skills for the position they’ll play. A great center is usually the tallest person on the team and defends the rim and rebounds well. A great point guard handles the ball well and effectively runs the offense. A shooting guard scores at an elite level, etc. And then, on any given play, their specialty doesn’t matter as much as doing the right thing for the team in that moment. If something unexpected happens, an individual might play outside of their specialized role in order to accomplish a good outcome. Scrum teams are the same way. We bring people onto the Scrum team because of their specialized skills, but on any given Sprint or on any given day, that person might work outside of their specialty to accomplish the current goal. There are two specialized roles, the ScrumMaster, who is a bit like the team’s coach and facilitator, the Product Owner, who makes final decisions on what the team should do to accomplish their compelling purpose, and then a more general role called Developer that encompasses all of the other skills needed to create the product or products the team delivers to accomplish their purpose.
Richard
So, on to the question of what do these look like when they are done well in the real world, let’s start by looking at Product Ownership. What does it look like when the Product Owner role is done well in the real world?
There’s a minimal version of product ownership that we see in the wild sometimes, especially in big companies, where the PO is pretty much just a backlog administrator. They take requests from various sources and turn them into detailed tickets in Jira. I want to be really clear: That’s not what we’re talking about when we talk about great product ownership.
Here’s how we define great product ownership, and then we’ll look at how this plays out in the real world. Product ownership, done well, is learning and communicating what to build, who it’s for, and why we’re building it in collaboration with a cross-functional Scrum team and other stakeholders in order to maximize the flow of value through that Scrum team.
So what does this look like when done well, for real?
First off, great Product Owners build learning into their work at multiple levels of detail. They’re not just taking requests– they’re doing customer research all the time—interviews, observation, market analysis, and various other product assumption tests. They’re getting feedback from stakeholders on work in progress. They’re monitoring recently released things to see how the product is being used.
To support this learning, great Product Owners have a backlog that has different amounts of detail on different time horizons. Small detailed backlog items in close, larger items further out in the future. This helps them communicate well with stakeholders. And it leaves room for learning on those items out in the future. (Check out our PO Board episode for a more concrete way to structure this.)
Great Product Owners collaborate with their Scrum team every day. They usually show up to the Daily Scrum. Not so much to check on the status of the work, but to plan today’s collaboration with the team, both for work in the current sprint, where the team needs info and feedback from the Product Owner, as well as for work in the backlog, where the Product Owner needs info and feedback from the rest of the team.
Great Product Owners actively cultivate and manage relationships with their stakeholders. They proactively get input and feedback from them, and finally, great Product Owners really do see their work as maximizing the flow of value through their team. They’re aware of how much investment a day or a sprint of their team represents. And they model the value of their backlog items so they can deliberately make moves to maximize the team’s ROI. This almost always includes balancing short- and long-term concerns and employing the key skill of good slicing of backlog items so there’s clear value at every level of detail.
Peter
The ScrumMaster is one of the more difficult roles to describe to someone unfamiliar with Scrum because it doesn’t have a clear corollary with other roles in a typical business. It’s not, for example, the same thing as a project manager, who is tasked with things like planning out projects and tracking their status, it’s not like a team lead, who has ultimate responsibility for the outcome of a project or might have direct reports on the team. ScrumMasters often have very little positional authority in the organization, and so a great ScrumMaster is great because of how they influence people towards outcomes, not because they have a specific job title.
With this lack of clarity regarding what a ScrumMaster is supposed to do, many ScrumMasters simply end up acting like a team admin; they’re taking notes at meetings, they’re administering whatever tool the team uses, maybe they schedule the meetings, they might show up and recite the three questions at a Daily Scrum. But, again, that’s not what we’re talking about when we’re talking about great ScrumMasters. But when done well, great ScrumMasters are multipliers of their team’s capability.
Great ScrumMasters in the real world know that every team needs three things to be successful: the team needs clarity about what they should deliver and why it matters; they need an ever growing capability to deliver those outcomes over time; and they need systems that enable the team to thrive. Great ScrumMasters know that clarity, capability, and systems have a business aspect to them, and a human aspect to them, and so they are constantly monitoring the current state of their team through those lenses.
Great ScrumMasters also recognize that there will always be conflicting opinions in each of those areas. Different stakeholders are going to want the team to deliver different things for different reasons. Various people are going to have different opinions about what new capabilities the team should develop over time. And everyone is going to have their own opinion about how the system should improve.
And so the second great skill ScrumMasters have is the ability to break through on tough, often long-standing conflicts. They ask great questions and listen to team members and other stakeholders in order to empathize and understand their viewpoint. This deep listening and effective question-asking allows them to see beyond stated conflicts to a deeper shared goal. They help make that shared goal more visible to everyone and work through new paths to achieve that shared goal.
The third thing that great ScrumMasters do is best captured in a story about some research that was conducted by Will Felps on the effect of what he called “bad apples” on a team. In this study, Felps enrolled a marketing organization that, over the course of a summer, brought in teams of summer interns to work on marketing projects. During orientation, the interns were placed in teams of four and given a one day challenge to turn a marketing brief into a proposal for how to deliver effective marketing. Then Felps hired an actor to sit in on several of those teams, so there were some that the actor sat on, and some that were just pure interns. And the actor, who was named Nick, would play the “bad apple” role. The Bad Apple had three archetypes: the Jerk, the Slacker, and the Downer. Nick plays these roles really well over the course of the research, on 40 different teams during that summer. On average, he reduced the performance of the groups he sat in on by 30-40%. All 40 of them were worse than the control groups– except for one, what they called the “outlier group.” On that group, there was one team member that was just unfazed by Nick’s shenanigans. And we’ll quote from Daniel Coyle’s great book, “The Culture Code”:
We’ll call this person Jonathan. He is a thin, curly-haired young man with a quiet, steady voice and an easy smile. Despite the bad apple’s efforts, Jonathan’s group is attentive and energetic, and they produce high-quality results. The more fascinating part, from Felps’s view, is that at first glance, Jonathan doesn’t seem to be doing anything at all. “A lot of it is really simple stuff that is almost invisible at first,” Felps says. “Nick would start being a jerk, and [Jonathan] would lean forward, use body language, laugh and smile, never in a contemptuous way, but in a way that takes the danger out of the room and defuses the situation. It doesn’t seem all that different at first. But when you look more closely, it causes some incredible things to happen.” Over and over Felps examines the video of Jonathan’s moves, analyzing them as if they were a tennis serve or a dance step. They follow a pattern: Nick behaves like a jerk, and Jonathan reacts instantly with warmth, deflecting the negativity and making a potentially unstable situation feel solid and safe. Then Jonathan pivots and asks a simple question that draws the others out, and he listens intently and responds. Energy levels increase; people open up and share ideas, building chains of insight and cooperation that move the group swiftly and steadily toward its goal. “Basically, [Jonathan] makes it safe, then turns to the other people and asks, ‘Hey, what do you think of this?'” Felps says. “Sometimes he even asks Nick questions like, ‘How would you do that?’ Most of all he radiates an idea that is something like, Hey, this is all really comfortable and engaging, and I’m curious about what everybody else has to say. It was amazing how such simple, small behaviors kept everybody engaged and on task.” Even Nick, almost against his will, found himself being helpful. The story of Nick, and what Coyle calls “the good apples” is surprising in two ways. First, we tend to think group performance depends on measurable abilities like intelligence, skill, and experience, not on a subtle pattern of small behaviors. Yet in this case small behaviors made all the difference. The second surprise is that Jonathan succeeds without taking any of the actions we normally associate with a strong leader. He doesn’t take charge or tell anyone what to do. He doesn’t strategize, motivate, or lay out a vision. He doesn’t perform so much as create conditions for others to perform.
And that is the third skill of a great ScrumMaster. They create those conditions for the team to perform well.
Richard
The third Scrum role is “Developer.” Remember, “Developer” refers to everybody else on a Scrum team, who is not the ScrumMaster or Product Owner– all the people who actually build the product. On a software team, this includes programmers, which is often what we mean when we say “developer.” We mean software developer. But it also includes testers, designers, and any other specialties who are required to build the product. In Scrum terms, they’re all developers.
So, what makes a good developer in the real world?
Obviously, it’s important that they have the technical skills required to do the job. But since that’s really context specific, let’s assume someone has that and look at what makes the difference that turns somebody from a technically competent developer into a great developer on a Scrum team.
Three things: Number 1 is a team orientation. Great developers are focused on contributing to the team’s shared commitment as represented in the Sprint Backlog. They’re not just focused on getting tasks in their own specialty done. They’re focused on, “How can we collectively get the most important things done today?” This is what Peter described earlier on a successful basketball team. They’ve got their role, but they’re contributing to whatever needs to be done for the team in that moment.
Sometimes, this looks like contributing to work outside their specialty. Sometimes, it looks like prioritizing helping others over getting tasks done; sometimes, it just looks like resisting the temptation to cherry pick the interesting technical work from further down the backlog.
Number 2 is engagement with the whole work of the team. Great developers in Scrum recognize that literally building the product—for example, programming or running tests—is just part of the work. Backlog refinement, planning, coordination, demoing work and getting feedback, reflecting and improving the team’s whole work system–these are all important parts of the work, too. And great developers engage in those activities with as much energy and skill as they do the technical work. Ironically, on these teams, the Scrum events usually become way more efficient, and these teams end up spending less time in meetings, even as their meetings accomplish more results.
Finally, number 3, great Scrum developers have a bias towards “working software” or whatever the equivalent is in their domain. Instead of going heads-down for days or weeks to work on a big chunk of something, they work in thin slices to get faster learning and feedback. On teams with a culture of working like this, you can almost watch the product take shape every day vs just hearing about progress in meetings but not seeing it until big chunks are done.
Peter
So that’s what the Scrum roles look like when they’re done particularly well.
Please like and share the episode if you found it useful, and keep the questions coming! We love digging into these tough topics, so send them our way.
Last updated