Clayton Lengel‑Zigich: Welcome to another episode of the Agile Monthly podcast, I’m Clayton Lengel‑Zigich.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Clayton: I tried to think of all the reasons why we didn’t record a podcast, but they were all excuses.

Roy: The real reason is we went to the bar and went drinking instead.

My Boss Told Me To Do This Driven Development

Clayton: That sounds like an excuse. Today we’re going to talk about a common pattern that we have observed in a few different places, and it goes something like this.

You’ve got maybe some direction from the product side of the fence where the product owner’s got a boss, and they’ve got a boss, and somebody comes down and someone’s boss’s boss says, “The team should do this.” So the product owner comes in and says “OK here’s what we’re doing, because my boss told me to do this.”

Maybe that gets going a little bit, gets some traction and there’s some idea of what the team’s supposed to be doing, but then maybe someone on the technical side of the fence, like the dev manager or the dev manager’s boss, might say “Well, I want something to be done on the team and I don’t want to go in the backlog to get that stuff done. That might take too long.”

They force the dev manager to direct the team to do something. And since the team reports to the dev manager, the team feels obligated to do that. It’s like a bunch of different parties in the organization playing puppet master with the team. And the team never really gets a whole lot of traction. Would you say that’s a fair assessment, Derek?

Development Managers Undermining Product Owner Authority

Derek: Yeah, I mean, the first pattern is that usually the product manager, product person has trouble a extending…The pattern I tend to see is the product owner has trouble establishing authority and priority in the backlog because of stakeholders that they report to.

About the time they figure out how to get that done and they actually start to get the team baked a little bit and get going, what happens is the dev management side starts to realize that they’re no longer in control of their team, which was probably an illusion to begin with. And so to reassert control or authority back over their team, they tend to start asking their team to do things that aren’t part of that prioritized backlog.

Then the team a gets confused and there’s all sorts of tension between the product owner and the dev manager and the team doesn’t know what to do because they want to do what product wants them to do but they don’t want to be fired and they report to the dev manager. And so there’s just this crazy alpha thing that starts to happen and then the team generally starts to go fairly batshit about that time and all productivity goes out the window.

Clayton: Yes, I’ve always wondered when we see that if it’s a situation where the team feels obligated to do what the product owner says because they feel like, I read the Scrum book, or someone told me about Scrum and that’s how it’s supposed to work.

But, the fact that they all report to the dev manager, if the dev manager can instill a certain control, I wonder maybe it’s because usually the product owner is not at the same level or above the dev manager in the organization. So, they don’t really have the authority to go tell this person, “Too bad. You have to do things through the backlog.”

Mis-Alignment Within The Organization Around Product Owner Authority

Derek: What tends to happen is they tend to report usually to different tree structures. Then their bosses tend to report to different people. Often time in an organization they don’t report…their tree structures don’t cross paths, until you’re at the top tier of the organization.

What happens is the struggle goes up a level or two, and then at that level it’s like, I don’t want to bring this to my boss. Clayton, you and I report to the CEO, and I’m the VP of project management and you’re the CTO.

Our underlings are having this out a little bit, which really we’re having it out, we’re just doing it through our direct reports. But we don’t want to go to our boss and have it out because our boss is going to say, “Are you being a bunch of stupid little children? Why can’t you get along”?

Clayton: No, we can’t solve this pithy little problem on our own.

Roy: I think that’s the answer. It sounds like the development manager and the product owner just need to talk, and be like, “Hey, this isn’t working.” I like the idea of the development manager being organizationally apart from the product owner. I feel like one shouldn’t be above the other.

Loss Of Perceived Control

Derek: The trouble that you run into is when you start to go, at least on the Scrum side, you start to do something that’s more Scrum‑oriented, you start to give a lot of power to the team through empowerment, so the direct dev manager feels like they’re losing a lot of authority that they probably never really had anyway, because they don’t feel in control.

From a product perspective the product owner starts to take a lot more authority about the direction of the product. A lot of times the CTO or the senior dev manager or the dev director or the program director, or whatever you want to call it on the dev side, usually used to have a ton of influence in how the product was developed.

They start to feel like their control, or their influence, is going away. I think a lot of it is insecurity of, “Wait a minute product, you don’t actually need me and my management structure, you just need my developers.” Now a lot of times what you then see is it’s almost like the product owner is almost like the manager or the developers because the developers have respect for the product owner and are listening to the product owner and doing work for the product owner.

I think what happens is you get panic and the panic is like, “I have this urge that I still have control over these people. I’m going to ask them to do something and if they do it I know I still have control.” If they don’t do it and they refer to the product side of the fence then I know I’m losing my control and then that creates blowback upstream.

Clayton: Yeah, we’ve seen teams that have been fractured along those lines where there have been some people on the team who have the allegiance to the dev manager and not the whole structure. Then some of them they just don’t like that person or don’t get along with their manager.

They gravitate on the other person that has somewhat resemblance to the manager who is usually the product owner at this position of authority. You get this kind of fractured team.

Even if the two people aren’t trying to do it purposefully as a power struggle, maybe the dev manager overhears some conversation from the product owner or the product group saying, “I wish the teams would go faster.”

Maybe they’re not even trying to be malicious about it, but they think, “Oh I need to jump in there and make the teams faster. That’s my job, I manage the teams.” Those are the things that you could accidentally cause a rift in the team when you don’t even mean to.

Roy: I think it’s just a matter of making a mental switch from commander/control manager to more of a servant leader, right. Whereas a development manager you start to think more in line of like, “How can I help the team”? Rather than “How can I get the team to do what I want”?

With the product owner that’s a pretty common thing I’ve seen on multiple scrum teams, where the product owner start to take up the role of like the manager of the developers rather than being a member of the team. I think that’s a mistake, it’s very important to make the distinction between like, “You’re the product owner, not the team owner.”

The Product Owner As Part Of The Delivery Team

Clayton: Derek you were sharing some drawings that you had about how you’ve seen some team structure where the product owner is also the manager and they’re outside the team or sometimes they’re inside the team and sometimes they’re also the scrum master and all these different things.

I thought that was pretty interesting, I think in my experience. There are so many product owners that don’t ever treat themselves like a team. Most of the time they don’t, except when it behooves them. If there’s a decision to be made or they’re involved somehow and what the team is going to do next or something like that, then they’re definitely a part of the team.

When it comes to maybe being responsible for everything or like the not special treatment scenarios, they always view themselves as like, “Oh, I know I’m just separate, I’m not part of the team. I’m this product person throughout the organization. I report to the different tree.”

Derek: Yeah, I think it’s difficult. I go back‑and‑forth between where I think the product owner really…I definitely think the team should not be reporting to the product owner from an organizational structure or perspective. I definitely don’t see a ton of value in that or any value in that, I see a lot of conflict.

I go back‑and‑forth between whether they’re part of the team or not part of the team. Certainly they’re not part of this, the development team or the product team or whatever you want to call, the people doing the work…

Roy: Right, like they’re not going to pair with one of the developers.

Derek: Yeah, but I get a lot of questions. Should the product owner be a stand‑up? Should the product owner be part of the retrospective? A number of [inaudible 08:48] and I get really indecisive because on one hand I really think they are the customer. If we really think about it they are a proxy for the customer.

I don’t think the customer should be part of the team but I think they should be in damn close proximity interacting with the team and collaborating with the team a ton. When it comes to stand‑ups, yeah they should probably be there just so that if the team has questions there can be some dialogue that happens. When it comes to retrospective, I don’t know, I’m a little more at horn.

[crosstalk]

Clayton: …retrospective because that’s one pattern I’ve seen a lot, is the product owner will treat the retrospectives as optional. Where when they think they want to be there or there’s something that’s on their mind then they’re definitely going to be there and they’re going to be the loudest voice in the room.

When there’s some other conflicting meeting or maybe they don’t have anything to say to that particular retrospective they treat it like, “Yeah, I don’t really need to be there.”

I have seen where the team will make some decision about something that affects the product owner when they’re not there and then they get all up in arms like, “Well, hold on, you guys can’t make choices without me.” “Well you optionally decided not to come to the meeting, so what do you want”?

Roy: I feel like it is important for the product owner to be present at the retrospectives for exactly what you mentioned. Just because they don’t have a problem, like the rest of the team might still, so they want to bring up with them. They probably should be bringing that up throughout the week, but I totally think they should be part of the retrospectives.

They should be sitting with the team, and participating in stand‑ups. Other than having the authority to choose the priority of the work, they should be a team member. I agree they shouldn’t be pairing on any of the work because there’s a conflict of interest there, but they should be involved in all the other ceremonies.

Too Much Familiarity Can Lead To Lack Of Candor

Derek: One of the things I see as a problem with that is there becomes too much familiarity, and then they actually do not do the product ownership role well enough. If I’m the customer of a service, when I’m no longer happy with the service I can voice very strongly that I’m not happy.

I can even say, “I’m so unhappy that I’m willing to go get my service somewhere else.” I’m sorry, Target, if you piss me off, Wal‑Mart is more than willing to take my money and they’re pretty close to the same thing.

Where if I work at Target, it becomes very difficult for me to say, “Hey Target, if I have a bad experience I’m going to stop working here,” because I have a bunch of friends. If I’m negative about it, then people stop shopping there, and maybe I lose my job. I see that happen with product owners, they consider themselves too integrated into the team.

The benefit is there’s more, “Hey, we’re all in this together,” which I think is really good, but they lose their objectivity with the team to say, “Ultimately…”

Clayton: Maybe they would get to a point where they’re too comfortable? They spend so much time with the team, and they think the team’s doing a good job, they know they’re trying really hard, all those kinds of things. If I’m the Target consumer, do I think everybody at Target’s trying really hard? I guess, but I don’t really care. If they piss me off enough I’m going to go somewhere else.

Roy: I think that’s bad product ownership. It shouldn’t matter. I feel that that is not having the courage to say what you think, not being honest with yourself about how you really feel.

Clayton: Does it make it easier to get in that position if you spend too much time with the team, or you treat yourself like you’re in it with the team?

Roy: I agree that that definitely makes it easier, but I don’t think that excuses that behavior.

Living In A No Product Owner World

Derek: In a perfect world, there is no product owner. The team is the product owner, or they’re sitting with the customer who is guiding the product, or you’re doing something that is lean start‑up enough that you are getting instant feedback and everybody is providing value to team. The problem is, we don’t live in that world.

Most of these organizations that are trying to do an agile adoption are so far from that, I don’t think they can jump right into that. In the same way, I don’t think they’re adult enough to be like that. You’re absolutely right, I should be able to say, “No hurt feelings.” It doesn’t matter how much Clayton and I are friends.

If I believe the work we’re doing is not quality I should be able to have that discussion. I shouldn’t have to worry about his hurt feelings. The reality is, that’s not the case of most people in corporate America going through transformation.

Roy: But it is what they should be striving for. That’s why we use the core protocols. We have that kind of atmosphere within Integrum. It’s not that I don’t want to hurt your feelings, it’s because I respect you and appreciate the work that I’m going to give you this feedback, tell you the truth.

Derek: This is why I struggle with Agile a lot. If we really look at the ideal, Scrum is bullshit. Creating this big schedule, doing all these burn‑downs, doing a lot of this stuff ‑‑ to me, if we’re all adults, we’re all acting in the right way, we’re all part of the product ‑‑ why do we need a Scrum Master? Why do we need product owner? Why do we need any of this to begin with?

Some of the process is there just as tools to help us build discipline. Once we have some of that discipline and we’re mature enough to do that, all that stuff becomes optional at that point.

Roy: Like bootstrapping the team and then letting it run on its own?

The Product Owner’s Authority

Clayton: I think that’s fair. Most people that think they’re at that level [inaudible 14:30] if you think you’re an expert programmer, you’re probably not an expert programmer. If you think you don’t need any discipline reinforcing process, you probably aren’t disciplined enough to go without it.

I wanted to go back to one thing you mentioned at the beginning, Derek, about the scenario where the product owner is giving some stakeholder feedback, for instance the scenario of, “The product manager told me that the next thing we’re doing is this, so we’re doing that,” and comparing that with what they’re supposed to be doing, which is being the customer. I think those two things are misaligned.

Do you think that takes away from the product owner’s credibility? They’re not representing the customer, they’re representing some other person…

Derek: Yes. I had this conversation today in spades. A common thing that I hear all the time is that if Clayton is the boss, I am the product owner, Roy is part of the development team, and I come in and say, “Hey Roy, we’re going to switch this sprint and we’re going to do this big project X,” and you feel like this is just the dumbest thing.

We always try to do it, we never really do it. You don’t understand it. You ask me, “Why are we doing that? Why are we not doing the big thing that you said was so important last week”? My answer is, “Because Clayton said we need to do it, so we just need to do it. Mom said we need to do it.”

I become the barking dog with no teeth that has no bite, because I have now told Roy I have no authority at all. I just do what Clayton tells me. From that point forward, everything I say is utter BS. Roy’s going, “Why am I even listening to Derek”?

Roy: I should just listen to Clayton.

Derek: Two seconds later, Clayton is going to walk in here and tell us whatever he told us was crap anyway.

Clayton: You seem expendable at that point.

Derek: Right.

Clayton: OK. I just wanted to cover that real quick…

Derek: If you’re in that position ‑‑ this is what I’ve been coaching…

Clayton: It’s the real world follow‑up.

Understand The Why If You Want To Be A Product Owner With Authority

Derek: …The real world follow‑up, because I want to make sure that people understand, is never ever say, “Somebody upstream told me.” It is your responsibility as a product owner, if Clayton tells me, “Our new priority is X,” I need to ask Clayton why.

I need to understand why, so that when Roy asks, “Why are we doing this”? I don’t say, “Because Clayton says.” I say, “Because as a business, we need to do X‑Y‑Z, we need to achieve this, we need to do that.” When I’m able to do that, I have the respect and authority necessary to guide the team in the future.

Even though I’m not the one who came up with the idea. I’m not taking credit for the idea. I’m basically shielding…You don’t need to understand what every part of the business is doing, Roy. As a team, you just need to trust me that I’m doing the right thing for the product and the team.

Clayton: All right. I think we’re out of time, so thanks.

event-stream: Analysis of a Compromised npm Package