Scrum Team Roles, Product Owner, Scrum Master, Developer

Roy vandeWater: Hello, and welcome to the Agile weekly Podcast. My name is Roy vandeWater.

Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.

Drew LeSueur: I’m Drew LeSueur.

Traditional Scrum Roles

Roy: Today, we’ll be talking about the traditional Scrum roles, and how you know that you have gone out of the bounds of them. Clayton, you brought this topic to our attention. What drove you to do that?

Product Owner Boundaries On Technical Practices

Clayton: Just to clarify the three rules we are talking about are the Scrum Master, the Product Owner, and the Developers, or the Development team. I can’t remember what the new Scrum guide calls them. Those people comprise the overall Scrum team.

I was wondering, if you go by the “book” Scrum, there’s a lot of things like, that the Scrum Master should do, but one thing I have noticed, no‑one really talks a whole lot about things they shouldn’t do. It’s the same thing with the Product Owner. I had a Product Owner ask me the other day, what they could do to help the team with the broken build. Doesn’t that seem odd?

From the standpoint of technical excellence or something maybe you could say that the team is having some eXtreme Programming (XP) practice where they’re using continuous integration and their build is broken. In a perfect world, there would care about that and then want to get it fixed, but for some reason the build is broken. It was causing a problem and was impacting the Product Owner in some way, so they wanted to know what they should do to change that.

Roy: Is the question then is the state of build underneath the Product Owner’s authority? Can the Product Owner dictate that the build must pass and make that a requirement?

Clayton: Yeah, that was the thing of like, “Hey, how much say should the Product Owner have in how the team organizes its technical practices?” In this case, the fact that the build was broken was causing an issue with being able to deploy something. That’s why the Product Owner was concerned about it. Until the build was fixed, you couldn’t deploy and if you couldn’t deploy, then the Product Owner couldn’t show progress or whatever the case was.

Roy: That hails pretty fair for that. Then it would fall underneath their responsibility all of sudden, because it’s seems to be like the Product Owner’s to drive value and if something like the build coincidentally happened, not coincidentally, but like blocks the delivery of value. That seems like a very big problem that the Product Owner should absolutely be able to talk about.

Clayton: Yeah, other than maybe just talking about it though, is there anything the Product Owner can really to do? Like they’re not going to get it in and like fix the code?

Roy: That’s, that’s true. Like I think that would definitely be over. The Product Owner would definitely be over‑stepping his or her bounds if they started doing something like that.

Clayton: Beyond just going and telling the team, the strategy of the time was like, “Hey, the build is broken so I can’t deploy this thing that I needed to deploy so is it OK”? The question was really asking me, is it OK if I go basically yell at them, or like tell them that they need to get this fixed as soon as possible. You know.

Roy: I would say that’s totally OK.

Drew: Yeah, I think so too. Like, hey, I need to be able to deploy this whenever I want. You know, it should be able to be deployed at anytime. So the build’s got to be passing.

Roy: That probably should already be part of their negotiated definition of done. Like a future should be deploy‑able. And if their futures aren’t deploy‑able then that means that pretty much none of the sprint work can be done because they can’t deliver any value.

Clayton: Do you think that your opinion would change if you took out of the equation the fact that the deployment and the builds were linked? The Product Owners were just mad because the builds were broken. You know. Like this is the middle of the sprint, basically.

Middle of the sprint, the builds are broken, should the Product Owner really care about that? Or is that like, that’s the technical realm of the team? And, the, you know, they have their problems so they can go fix it.

Roy: It all of the sudden changes. Think that’s a huge difference. All of the sudden the development team should be passionate about it and should really care that the build doesn’t work. But then all of the sudden it’s no longer blocking the Product Owner directly.

If the development team insists on, you know, um, deploying code that isn’t tested or with a failing build. If that’s not part of the negotiated definition of done then I would say that it is not really the Product Owner’s authority to dictate that. The Product Owner may want to renegotiate their definition of done. But unless that’s the case, they can’t. I don’t really think that it’s their place to say anything.

Drew: Also, like this issue, maybe why, the question is maybe why is it coming up? Like, are they building their master branch as, like, a check to see if it works? Or should there be another system in place to where they can build it off their computer somewhere else and then push it to master if it all passes?

Like sometimes I say that because sometimes we’ll let our build system run our build just because we don’t want to run it all locally. And we can just kick it off and not think about it until it comes back. And it’s just an extra check so if it fails, no big deal we’ll get it to pass.

Roy: One big distinction that not everybody uses is that when we’re all talking about the build, we include all of the tests passing in the build. Is that what you are talking about as well Clayton?

Clayton: In this case it is a situation where if you take the entire test suite, there’s a series of builds all broken out. So in order to say that all the tests are passing and all the code’s compiling together and to say, “This doesn’t build,” it all have to be green. If two of them are red, then that’s where the situation comes up.

If these two things are red, that means we can’t progress because in order to deploy, you have to go through steps 1 through 12, and we can’t get through steps six and seven, so that means you can’t deploy.

Roy: In a build environment in which you have to compile something, that’s a little bit different because…A lot of my experience has been with Rails apps or Python app or something like that where it’s scripted and there’s no compilation and linking and all of that type of stuff.

But as soon as you have to start doing that, I’d almost say that it’s a good idea to decouple running your tests and building everything and to separate those two ideas. But as a practice, if you’re on a team, I would say ideally a team shouldn’t allow themselves to deploy something that isn’t passing.

They should have the self‑respect to say, “We care about quality, and we built these tests for a reason, so we’re not going to deploy this until we know that everything is passing.” If that means that maybe they’re old tests and we got to delete them or whatever, everything has to be green before it goes live. That’s a good quality for a team to have.

Scurm Master Boundaries

Clayton: To try to jump to another Scrum role, what are some examples or some different indicators that a Scrum Master might be stepping out of their role, like doing too much?

Roy: When a Scrum Master starts dictating tasks to the team or assigning stories or tasks to individual people rather than the team. How about you, Drew?

Drew: I don’t know. I haven’t been on a team where there’s an official Scrum Master set to me, so it’s harder for me to answer that question. It’s rare that I’ve been on a team where there was a Scrum Master.

Clayton: The Scrum Master sometimes acts as a liaison ‑‑ or to some degree ‑‑ between the Product Owner and the development team or outside stakeholders or third party people or whatever. Is there a chance that maybe the Scrum Master would get too involved with one side of that equation?

They’re supposed to be the impartial middleman to some degree. So maybe they got too involved in a technical detail, or they got too involved in the product stuff.

Roy: I can see them talking to the stakeholders which is part of their roles to protect the development team from interruptions from the stakeholders. I could see them talking to the stakeholders and perhaps promising features or something that the team has not been able to deliver or things that the Product Owner doesn’t consider a priority. I would definitely consider that overstepping their bounds.

It’s like a Scrum Master has the authority to say no, but they don’t have the authority to say yes if people are trying to interrupt.

Scrum Roles Narrowly Defined Has Problems

Clayton: One criticism on Scrum is that the roles are very narrowly defined and is not a good practice. Some people even go as far as, it’s immoral to try and box people into a certain role and say, “Well, you’re only allowed to do this, and you’re only allowed to do that.” How do you guys feel about that?

Drew: I can see that. One thing that I sometimes see is people treating the Product Owner as like, “We won’t do anything unless the Product Owner says it. We’re not going to come up with any good ideas on our own.” That’s troublesome.

The whole team as a team can come up with good ideas and not just implementation ideas on how to implement what the Product Owners says but even good ideas for the product. I don’t think it’s outside of the developer’s realm to pursue good ideas as part of the team.

Roy: It’s definitely within their realm to come up with good ideas and suggest them, but I absolutely think it’s outside their realm to pursue them without checking with the Product Owner because the Product Owner ultimately figures out where the priorities lie.

We’ve all been on teams where somebody wanted to work on some feature X that probably wasn’t very important, but they went ahead and insert it in the backlog, made it a top priority, and started working on it. We’ve all been part of bad Scrum implementations where that’s happened, and that’s a huge smell.

There’s a good reason why there’s a single person who determines all of the priorities and if you are going to pursue something that it should go through the Product Owner first. With that said, I totally agree that the developer should be free to come up with their own ideas and contribute them. Not just free, but encouraged to.

Developer Boundaries

Clayton: What about developers that are stuck in their bounds? What’s a good example of that?

Roy: You guys hinder that with the backlog stuff. One thing you see a lot is when the expectation maybe of the team or the visibility of the team’s progress is low or nonexistent. I actually know a lot of developers that will take on some pet peeves like some technical desk is a perfect example. Like something in system that they don’t like and they want to make it better. Maybe they’ll get a story done or some task done early or something.

Or they’ll come to the conclusion of like, “Oh, I’m blocked on this task and I can’t work on it until I hear from X, Y, Z person.” So in the meantime, rather than go and like help someone else with something else in the sprint or further along the progress of the sprint, they go off and go and do some little pet peeve thing.

“I’m going to go rewrite this part of the test suite,” or, “I’m going to go experiment with replacing this library that we have now that we know works with this new one that personally is better.” That’s one example of it, the team getting outside of their bounds and just doing whatever they want without…as not part of the overall Scrum team, like not have the same goal.

Clayton: What about refusing to implement a feature or something like that? I felt that a few times, where I thought a feature was just the dumbest idea and I felt like we’ve got to come up with a better solution. Is it within the developer’s authority to say, “No, I’m not going to do that, because that’s stupid.”?

Roy: That’s like a two‑way street, because there are some times where developers will negotiate ‑‑ I don’t want to say worse implementation, but they’ll negotiate a less than ideal and maybe a more simplistic solution. The rationality that they would use is like, “Hey, don’t worry about it, Product Owner, because we’ll just do this and then, we’ll ship it and we’ll get feedback. So, it’s OK.”

It’s like the same thing is probably true the other way. Maybe you think it’s a really dumb feature, but the Product Owner could say, “Why don’t you guys just do it and we’ll ship it and if it’s really that dumb, then we’ll find out about it, so you can fix it.”

Drew: With the first one that you were talking about with the like, “Hey, let’s do it the simple way and get feedback.” The way you said it, put a negative connotation on it, where I’ve always viewed that as a positive thing.

Roy: Yeah, I’m saying though like a Product Owner, I think, all the times, the Product Owner unless they are especially savvy or nuance, they hear that as, “We don’t really want to do the big hard thing, but if you let us do the easier thing and then, get feedback.” Some Product Owners will just relent to that, “Oh OK, fine. I can buy that.”

Drew: It goes back to…

Roy: I’ve totally worked on teams before where the Product Owner thought that I was unspecific with confronting him about it, too, and said, “OK, you’re just trying to avoid the hard work.”

Where I felt and I don’t know if I was trying to avoid hard work, so consciously, but I felt like, “Hey, let’s spend a very small fraction of total time and implement this feature to implement the core value you’re trying to get and then, we can build off of that and see if we need all the bells and whistles on top of it.”

It was perceived as like I was being lazy and trying to avoid the difficult work.

Drew: That’s totally within the developer’s realm to negotiate, “Hey, this is an awesome idea. How about by this sprint, we only get this much done because that’s all I can get done, or whatever, and let’s work on this part of it first because that’s the most valuable part.”

Roy: Maybe that’s a good way to frame it as developers like, “Hey, why don’t we do it this easy way first? Then, we’ll get feedback and that means we can also pull in these additional stories.” Now, it’s not like, “I want to do this, so I get less work.” It’s like, “If we do this, look how much more free time that opens up for you to get more stuff done that you want, right?”

Then everybody benefits because you do the easy implementation, get feedback earlier and you potentially could deliver more value in that time period.

Clayton: More often I don’t really think teams like teams try and jump too far into the other roles. I don’t think there’s anybody on the team that’s trying to be the Scrum Master or trying to make a product decision, not necessarily.

[crosstalk]

Roy: …if I don’t do enough of that.

Drew: We sometimes find that internally like where we take turns being the desk Scrum Master during a retrospective or something. It’s good practice for us to do that.

Roy: Yeah, I mean…

Drew: Good practice as in it is we’re getting good practice out of it, but not that it is a good practice, you what I mean?

Roy: Yeah, I know, and there’s probably a lot of Scrum teams out there where facilitation is such a difficult thing and running a retrospective is so much harder than people think. The Scrum Master probably isn’t even very good at it. Let alone, there’s like some random developer on team. They don’t have all the skills required to effectively do that.

Clayton: Makes sense. I thank you for joining us. If you’d like to continue the conversation you can find us at facebook.com/agileweekly. Good‑bye.

Drew: Thanks.

Roy: Thanks.