AA125 - Working with Multiple Teams as a Scrum Master or Product Manager

On the podcast today, we're going to talk about the impact of being on multiple teams So I'm going to say multiple scrum teams or multiple kanban team. It doesn't really matter what methodology you're using here. You're on multiple teams! You're on multiple teams as a product person. As a product person. Well, it could be a scrum master. Yeah. Typically, I've seen that a lot too. The immediate impact that I think of, of being on multiple teams, is missed deadlines or poor quality features or generally frustrated stakeholders and maybe you can't exactly put your finger on what's wrong, right? Or maybe you have somebody that you know is really good. And they seem to be doing a crummy job and you you can't really figure out why. Yeah, I'll just add that sometimes, one of the symptoms is the, the teams aren't happy. Yeah. Right? Yeah. Because they got used to working with you as a Scrum Master partner or whatever. And then they're seeing less of you perhaps or, just not working anymore. And they know that. They usually know. So yeah, this is a very interesting topic because, lately I'm coming across situations where people say, well, we don't need all these, Scrum Masters, we could just have one person do Scrum Mastery on three teams, five teams, whatever. So we're talking about the impact of being on multiple teams. I'm assuming that the impact is lessened, if you have a team that mostly is self sustaining, if you have, if you have a team, I'm trying to not use the word mature. I don't know why. If you have a team that's at an advanced level, there we go. That's a better word than mature. If you have a team that's in an advanced level, I'm trying to With their mastery of scrum or process doesn't even matter what they're using. If you have a team that's at their advanced level with whatever process they're using, that. Could extend your product manager to be able to work with multiple teams because of the team kind of takes care of it, yeah I think that's largely true, but there's also degrees, right? You know, I think the team can if they're a highly advanced team in terms of their scrum mastery Scrum capabilities or just working in a team Kanban, whatever they're using they can to a large degree fill in for The product person or the scrum master, specifically the scrum master, they can definitely do a good job there. But again, it's with within degrees. So if you're not seeing one of these key roles, individual in these roles for quite some time. That might be an indication that perhaps that person is stretched a little too thin. If you're spread across multiple teams, then maybe it's okay because the team handles most of the day to day stuff, an experienced team, day to day stuff, meaning like, Hey, like we, we know how to interview users. We know how to split work in the backlog and how to basically generate new work in the backlog and to interview, like at sprint reviews, for example, like we know how to pull those interview questions and to vet what the priority should be in the backlog. Basically, like the, that product owner role, the team becomes highly capable of performing that product owner role to the team, even if they're not doing the product manager responsibilities, right? They, they, they, they are very familiar with the product owner responsibilities. And, they can really, really help, extend the product owner by doing that kind of stuff. Yeah, I agree with that. I think it's, it's, it's true, but if you have one team that is experienced in this manner and the others not quite as much, you're going to have some dysfunction there. The immediate thing that I could see in that situation is you'll have a product owner that has spent a lot of time on one team and very little time with the other teams. And then the other teams get frustrated, I've seen that before. The other team to get frustrated at the product manager. That they're, this person's. Not, never available when we need them and, and things like that, even though it's not necessarily true is that they're, they're going where the business needs them, and the squeaky wheel is, getting the grease in this, is that, is that right? Squeaky wheel gets the grease. Yes. It's the oil or whatever. Yeah. WD40. It's the cheese. Cheese? I don't know. Don't try this at home. That's right. I mean, the thing we didn't handle right off the bat, we probably should handle right in the intro right off the bat is, Hey, if you're a product manager or a scrum master, how many teams should you have? How many teams can you have? We should have just said like one next question. That's the end of the podcast. And that's the end of the podcast. No, that's a good intro. Maybe we can cut that clip and put in the front. I don't know. You want to be good. Have one team. You know, if you want to be great, have one team. You want to be good. One plus maybe here. It depends. Yeah. And that's when we get into the right factors, right? Um, so yeah, definitely team. I'll use the word team maturity, plays a big factor in this. If you have several teams that are reasonably mature, let's put it that way. Yeah, I mean, it gives the product owner some laxity to be able to, do other things or take on some other teams maybe. Uh, but at the same time, I still, At the risk of sounding a purist, I still say it's not as good as just spending all your time on one team, basically. It's just not. Agile purist is my favorite four letter word. There you go. See our podcast on agile purists. we didn't talk about, the effect of the right or wrong org structure on this. Well, that's huge. That is absolutely huge. Team maturity is something that can be evolved, right? You work with your team and take them up the experience curve, but yeah, the, the organizational structure. Really does play a direct role in, how things are done. So if the org prizes certain, let's say certain rituals. Yeah. For one of a better expression. Your product people, your scrum masters, whoever it is, are going to be stretched it by having to attend and attend to those things, creating artifacts, things like that. People that make a living out of, polishing PowerPoint decks. So that's what the, that's what the org prizes and that's what you're, that's what your value is, that you can actually produce glitzy PowerPoint as opposed to really servicing your customer. Also, if I was a product manager and I was in an organization where I was like fighting against the organization to do product management, like if I had a PMO or something like that, that was, over me, demanding things like, Oh, you just got to deal with these guys and give them what they want and they'll go away. I've been quite a few organizations that, that like, all of the executive level. Who kind of were, they didn't want to rock the boat and that, that, that was their, just give them what they wanted to, how long does it take you a day to prepare a deck to go in front of the, whatever the, the steering committee, steering committee or what, yeah, well, maybe not even a steering committee because steering committee is usually, there's a customer reps in a steering committee, but I'm thinking, I'm thinking like a, like a, like a PMO the, the people who basically review and approve project management functions and activities and stuff like that. Like if you have to go in front of that type of like if there, if there's heavy, heavy project management in your product management because there's a whatever, an old school influence or a shadow of a PMO that used to be there. The men were maybe when the org change or something like that, or, or you have. People in the organization that don't like the product management and quote, agile is like a, a new thing, or a new segment, that, that the organization is trying or something like that, then you might have extra hoops to jump through like this, that, that if you're applying the scrum model and you want to say like 15%, 20% of your time is spent in scrum events, which is single team scrum events, which doesn't include any kind of scaling a model or anything that you could be applied on top of that. And then a percentage of your time is also trying to deal with the strategy layer, right, which Scrum doesn't even interact with. So, now, how much of my time is left now for all this other extraneous, activities really are not necessary? Yeah, I mean, if you're on multiple teams, yeah, I'd say you have very little time left. Yeah, I'm just thinking about one team and now we want to scale to multiple teams potentially across multiple products. So if you're a product manager and you have multiple products, a big indicator here, Given the whole org And the teams are already lined up to benefit you. You've got mature teams, they know the processes, they stick with them, the team members have been there for a while, you're not stuck in forming forever, and the organization supports you. Multiple teams across separate products is still a challenge, in my opinion. It is a challenge, despite the fact that you have the best organizational maturity behind it. People are product thinking, right? It's still a challenge for sure. Because at the end of the day, there are only so many hours in the day, right? You can only be focused on so many things. To quickly pivot to another category that I also think is important is, assessing the PM's level of experience or the scrum masters level of experience. If we're talking about a scrum master, like most of this podcast, we've talked about a product manager, but it applies equally, I think. Yeah. Yeah. It kind of does. Cause if the organization and the team lend themselves to you, feeling comfortable enough to have another team, then you're gonna do it. That's good. Yeah, so I think there's a lot there. So, first of all, People that don't have much experience will struggle right off the bat because they don't want to do the same thing they're doing with team A, with team B, team C, et cetera. Whereas the other side of the spectrum, people that have been around the block a few times, they'll know how to prioritize their time. They'll know how much to delegate to somebody. And they'll encourage the teams to do more of some of those things that they can do more of. Right. So let go of some of those things. And that's something that's learned. Yeah. Because often people are afraid to let go. The, the thing I had to get comfortable with as a product manager is, there are things in the scrum guide that are squarely my responsibility. Stakeholder communication is squarely my responsibility. Figuring out what stakeholders to get at, to arrange so that they're at the sprint review, for example, squarely my responsibility. I had to get comfortable going to my team and saying, I am, I have too many teams right now to do this. With the, with the, the rigor, I mean, the rigor is a good word, I guess, like I have to, I have, I'm, I'm, I'm too scattered across all these teams and all these activities to do a really good job at stakeholder communication right now to get to make sure that we have the right people in the room and I need help. And the team members would jump on that to say, okay, I've got, we got it. Who do we need? Who do you think we need? I think we need this person. Let's reach out to them. If they're not available, I've got these other two people, you know what I mean? And, and to, to open a dialogue, to do all that, like that's, it's pretty simple quite honestly, but it's just, when I get busy. Simple stuff it falls off the table onto the floor and then I just, I can't bend down to pick it up, you know? Yeah. I mean, that's, that's a good way to put it. So yes, the team members will definitely pick up, but it all starts with you being comfortable to let go, right?, and like I said, a lot of people don't feel right doing that. And you need to try that out. I mean, it's not even, it's not even the fact that you have, all these teams. Maybe you just have one team, but the day you're not there, what happens? Right. If you're on a specific day, you're not there. Right. What happens? Right. So you need to make sure that the team is empowered to kind of run with it, right? Yeah. Give them the rope to work with. Yeah, in the period of my career where I was, In contracting. I, I definitely got in the mode of, I can never take vacation, because usually I was partnered with, the teams that were not, they, they were not the advanced level of maturity, so they would need me there to help them with a lot of stuff. So, again, like you can't, you can't, when you're on contract and you step away and things, kind of go to crap. You're the one that's blamed for them. Cause usually the organizations that you're coupled with, they're learning too. So they, they revert to bad behaviors when they get stressed and stuff like that. So you have to work through that with them at the same time and it's, I got in this weird mode where I feel like, well, I can't be gone. You know, that's not true though. Then also it's not sustainable. No, definitely not sustainable in those scenarios. That organization, is probably not going to keep the teams around long enough for the teams to even go up that maturity curve, right? Because you can salvage that situation even in that scenario, right? Assuming you had. You know, teams that stayed intact, that you can work with and empower them over time. Because chances are most of the teams also contract teams. Yeah. So they're not, they're also gonna feel a little bit hesitant about coming out of their box, right? Yeah. And playing in the other lane. With the PM's experience comes a careful analysis of, Your time commitments so the, the role of product manager, I feel like, I've been doing it for a while and I still struggle with the managing the time commitments to the different levels in the organization. For example, every team I'm on, like we talked about earlier about like if you're using scrum, scrum has a percentage overhead just for the events and like not even pulling ahead over just for the events and then you add multiple teams, you add, you stack multiple percentages of overhead. On yourself. So you're basically like carving away a huge piece of your time. And that's just the roles that the team, the, the, the, the, the capacity of the team needs you in. That doesn't even speak to the other roles of the product management job, which is, working on strategy and working on pricing and working on marketing and working with other departments. And, and you can make the same case for a scrum master that doesn't even talk about coaching up in the organization and trying to make change organizationally. I'm hyper aware of how much time I'm committing for each team doing these product activities. the way that I tried to deal with this is I tried to push back against any attempt to, do refinements or any other team specific activities like that outside of the regularly scheduled events. I try to push everything to the time box of the regularly scheduled events. And it doesn't always work. It doesn't always work for certain. Sometimes something comes up that's super important that we have to deal with. But I try to say like, oh, we, we, all these real important items come up. And I really want to get with you to, to, to figure out what we need to do for the future and to get a plan, to get a timeline in place. Usually people that are requesting stuff at the last minute, they all want timelines. Of course. Are you available on Monday? Because we do our refinements on Monday in the morning. So, if you're available Monday morning, we can talk about your very important request. Oh no, I'm too busy on Monday morning. Okay, well how about next week Monday morning? You gotta have it now. If you gotta have it now, I'll find time with my whole team, and I'll find time on the calendars, but if your calendar is totally booked and I have multiple teams So, I have multiple commitments as well. Like, I can't just push commitments to other stakeholders and stuff like that. So, if you can't find the time to sit down with the team, and I could even be out of the room. You know what I mean? You could find time with the team where maybe I'm, if I'm gonna be the roadblock, I can step out of it and trust that my team's gonna do it. Again, going back to our point about team maturity. If I trust my team to do it. But also like the time commitment, the, if you use a scrum and you have time boxes, you already have one tool in your chest to push back against the, like a culture of chaos. It just wants to use all your time. That has helped me a lot for the teams using scrum. You make a good point, you need to know when to say no. Right. And so again, this goes back to the maturity question we raised earlier. A lot of times people just want to say, yes, sir. Yes, ma'am. Right. Whatever that somebody asks for something, but. Yeah. So if you're not that highly advanced on your experience level and you have pretty needy teams, multiple teams, you're going to have a tough time right there, right? It's something's got to give, so this is where people who don't change how they're approaching the work, they risk burnout. Because you know, just say yes to everything and then you'll work longer hours. You'll work weekends. I mean, it's not cool to talk about in in the work environment like people like people's ages and stuff like that But I've been on a lot of teams with with that that that skew younger that want to please People they want to say yes, they don't want to they don't want to be perceived I guess it maybe it's not maybe it has nothing to do with age actually, but They want to be perceived as the go to people. They want to be perceived as like, we can do it, right? But, but like even to those type of teams, I would say like you can, you can still be like that. You can still be gung ho and be all fiery that you want to, take on the world or whatever. But also. You can still be helpful. And track the time that you spend helping people, you can still, you can do both. You certainly can. And I think this just goes right back to the individual team members experience level there too. Sure. Right. They learn to say, maybe not now. Sure. Maybe later. Yeah. And then eventually, decide between A and B. Right. Yeah. Well, Scrum Master actually can help a lot with this. Yes. Because they can intercept a lot of this, from the team members. I mean, I've been lucky enough to be on a couple teams where they had a scrum master that would, tell the team members if someone comes and asks you for something, and you're busy with other things, like don't, feel free to drop my name and say that you're working on something urgent for me, and then let them come talk to me. And, and that's the way they handle it, you know. I'm not saying it's a great process, cause then everything, they'll go, oh, you're always working on something urgent for, And that doesn't, that, why is OM always have urgent things, it may not be a great scenario, but, but it may not be a, it may not be a great excuse. However, it does give the team member an out if they truly are, re like really focused and trying not to come off of, of the tests that they're on. Yeah, that's a good point. I just hope that that scrum master himself or herself You know, they're not on three or four teams because then it becomes difficult right even for them Yeah, I could see that I could see that; I mean, If you're a scrum master for multiple teams and assuming they're all relatively related the other challenge that I could see a product as well. The other challenge I could see is getting these teams to talk to one another and getting these teams to go out into the organization to communicate about what they're working on. Right? So, so basically, broadcasting the signal of all the good work that they're doing that, like when you're a product manager and you have two, three, four teams, it becomes more and more and more difficult to, broadcast. Like, these are all the great things we're doing with the organization. Because because you're stuck like you're you're you you become so close to all the individual problems It's hard to back away to be like look how far we've come You know, I mean maybe maybe like at a like a quarterly meeting or like at the yearly meeting where you talk about You know, maybe if you have some like a like a great framework to say This is where we were last year at this time You mean let me look back at my reports or whatever and then this is where we are this year at this time Maybe if you have a good mechanism for that in your company You can get over this, but I've seen a lot of people get tripped up in just being the day to day of communicating all the stuff. Like that becomes a whole different job, you know? That becomes a whole different job. I agree. Even if you could relay the, the messaging around the good stuff the teams have done, it becomes diluted because you haven't really focused at that level. You've been too deep in the weeds, right? The focus. I guess we're talking about like, the communication out to the rest of the organization, the collaboration with other teams, when you pick work up, like if you were just scattered where you're trying to go as quickly, you, you, but basically what you're trying to do is you're trying to put in as minimal amount of work. to get the work moving and then you're, you're like a cowboy. You're off to this, to the next town. You know what I mean? You just riding away into the sunset. You, you're not sticking around to see the metrics afterwards. You're not talking to everyone about how they feel about the work that's planned. You know, Hey, give me a confidence about how the work that's planned. And you know what I mean? You're not checking in every day, that kind of stuff. Cause you're. You're, you're scattered. Yeah. Yeah, your context switching all the time and that's not a good thing at all. Yeah. Somebody said, if you chase two squirrels, they'll both get away. Right. So I could see the visual, right? Yeah, definitely. It just can't be everywhere. We're kind of dipping into two categories right now. We're kind of dipping into communication collaboration across the whole organization, which is. How do you, how do you let people know what you're working on? Like this is a stakeholder communication. It's stakeholder communication, but also it's, if you're, if you're building features with other development teams that you are not the product manager for, you need to collaborate with that team on the, the solution that you end up with. Right. And, and. Like you want to end up with a a solid architecture that enables you to the future if you're just trying to throw if everything is MVP Whatever we can do into like squeezing out, you know in the time that we have wringing out our resources Like collaboration really will take a hit Absolutely. Right. So then people do things like, they'll put patches on it. Right. So they'll say, okay, well, maybe we can get somebody to go talk to those people over there and then come tell us what they learned. So already you've got more vectors involved, more distortion going on in the messaging. I've seen teams where, or. I should say organizations where they have functions that do this and they hide under labels like change management. These are change management people. Their job is to go relay messaging out to other teams and even stakeholders and customers. Yeah. While I see some value in some, a dedicated piece of the org doing that. I think when you have multiple teams, there's just really no shortcutting that comes. You have to be there. Yeah. You know, the other thing about this community, the other thing that I think about, about this communication collaboration, item that we're talking about is, you have stakeholder teams who say we don't understand how priorities are done You know, we we don't understand like what when things are going to get committed to like what what what the what the process looks like probably because like The product manager at that point has not like gotten their arms around all of the proper stakeholders To, I, there's a, there's a few little, little, little, little, little, little threads. Uh, things that you will hear in the organization. Oh, well, we, we never get back to things that we say we'll do later. A few little threads like that, you know what I mean? Oh, I, I never know where things are at in the roadmap. You know, once they tell me that it won't be done, in the next quarter. Right. There's a few little things like that, that, that could be solved if, if the product manager was focused. One product, one team. All that stuff would be way more clear. Is it a failing of product? I think it's a failing of everybody. Honestly, this is a product of the organization. Everybody, this is the system. It's a problem. It's a, it's a failing of the system. Exactly. This is definitely a failure of the system. The focus, like the, the, the focus and the quality, like everything kind of that we talked about in this, in this topic, the. What I mean, what I mean by focus and quality, I mean, focus and quality of the product managers, output and also, I mean, I say product manager, but it also could be the scrum master as well. If you have a scrum master and they're split across four teams, can you really hold the scrum master accountable that the organization is not moving forward on, an organizational design roadmap? Because you have one person trying to move that roadmap forward. You basically got, one person trying to scurry up four chickens that are running around. I mean, they can only... Best wrangle one. Yeah. Yeah. And we haven't even talked yet about the complexity of the product itself. Meaning if you're like, if you're, if you're a, if you're a product manager and you have one team and that team is like, you've been hired to launch a new product, ground up completely new product. Um, versus you're taking over this legacy product with all this legacy code. And, I mean, you're, you're basically told like, well, just keep it running and you know, everyone will be happy as long as it's basically running and, that kind of stuff. And then you, you got this legacy pro or maybe you've been a product manager at the organization. And I can easily see someone listening to this podcast is in this exact position. You, you were a developer or a QA or somebody in your organization and then you became a product manager and they gave you the product that you used to work on. And you worked for several years, you did a good job. The product is kind of in decline that kind of moved it over here. They're not really doing a lot of new development, but then, but then they see since, since you're declining and rolling people off and not rolling people back onto your program, that's the decline. They're like, Oh, I think you have a little extra time. Your, your product is in decline. We're going to give you this new product. So now you're dealing with this, this product that's in, it's, it's, it's kind of being spun down slowly over time. And also this brand new product over here. Where do you think you're going to spend most of your time? This is like, this is like, you're trying to do CPR and give birth at the same time. Exactly. But you know, but like, but I've seen that. Yeah, absolutely. I've seen it too. I've been there. Yeah, definitely seen that. This is sometimes people are a victim of their own success. So that in that scenario, right, you were a developer, you did a great job, and now you're just nurturing this product through the tail end of the, the product life cycle. And then people say, you're great. You know, here, go do this one. Oh, by the way, you keep the other job too. And by the way, there's a no extra pay for you know, that's it. That's the kicker. No, just yeah, we just realized we're paying you. We're cutting that down. That's right. No, so you got to work Sundays as well. Yeah, just for good measure. But product complexity, though, to come back to that point, I mean, that that really plays into it, especially if you're dealing with You know, a component of the product that the overall product is so complex that you don't have your arms around the whole thing But you have your arms around just a little sliver of it It's critical all these slivers are critical because they combine and magically, you know Come up with this product if you're gonna have more than one Using a technical term here, more than one sliver, that, that you're trying to get developed with multiple teams, you could look, you do run the risk of burnout if you're just going to try your best and run, run, run, run. It's only so much running you can do, trying to hold up your shorts at the same time. Running up that hill. Yeah. Here I go. Kate Bush. Oh man. Nice reference. the thing that stinks about this category, like product complexity, I can easily see, especially if you're a new PM, your new PM, you come in, you have a couple of teams and your product is heavy, heavy integration, like very heavily relies on other pieces of other products or other teams or maybe you, maybe you have like a product suite where like you, your segment of the product does nothing by itself. Like I think of like a large companies like Facebook and stuff like that. We have like a, a PM for engagement and a PM for timelines and a PM for whatever. You don't even have the whole product as your quote product. You just have a segment of features. You know, they've cut away a couple of features and said, Hey, this is your domain. And, that's it, so the product is extremely complex and you may never, I mean, you may work there for years and not understand. Every little corner of the of the product that that's that's a very reasonable assumption. Yeah, I completely agree with you. I was just thinking about analogy like maybe, let's say you're working on something like the office suite, right? But your your team is developing not just Microsoft Word or Excel, but they're developing the ribbon that every product is going to use in the suite, right? You got to talk to all of these teams. But you may also on top of that be responsible for a team that's developing one of those products in the suite. Now, do you have too much, right? That that's what we're talking about. If you're a product manager or a Scrum Master listening to this, my suggestion here is that you make the first move to say that, Hey, I'm doing too much. I feel I'm doing too much bringing up to whoever, whoever, I guess bring up to whoever you're. I don't even know, is it like a reporting person? I don't know who... Whoever your overlord is. Yeah, whoever your overlord is, yeah. My advice is, is, yes, definitely be the first person to speak up, but go in armed with data. Don't just go and say, I'm overworked. It's like, what do you do all day? They don't know. If you have evidence, you can say, this is the amount of time I'm spending here, here, and here. You know, and I'm having to work these extra hours. And on top of that, I'm being told to take on this other team. It's just not feasible. It's like double, triple for scrum masters. Like at least in product, I could say, Hey, I I'm, I'm going to all these refinements and I'm generating all these stories. And I'm meeting with all these users and I'm, I'm going to these demos and I'm, I'm, all these tactical things. I don't have time to work on strategy and I don't have time to work on, help marketing figure out, or pricing or, yeah. Or pri or, to probe new markets or to, to, to elevate our strategy basically. Right. I don't have time to do all of these things. If you're a scrum master, and you are, you are trying to move the organization to the future, I mean, it helps having a vision of what that future looks like having that visualized somewhere, so there's some things that that product doesn't necessarily do. Well, actually, that's not true. Product does do these things. They do project a vision for the future. Product product does absolutely so if you if you find that you just don't have time in product to to even Have your mind in the headspace of the future. I think a scrum master could relate to that Yeah, I don't I don't know what the future of this organization looks like because I'm so busy putting out fires putting out fires meaning like for a scrum master putting out fires the equivalent of that would be Facilitating like getting over blockers and stuff like that and helping teams work with one another and collaborate with one another and stuff like that. Yeah, I, I fully agree with the road map, argument you make, because otherwise you run the risk of stagnating in this muddle through mode. This is what we do. Right. And you have no idea that you can even, there's even right a road ahead that you can improve. So having a roadmap for that helps. Mm-hmm., you can see are you evolving or are you devolving, right? Mm-hmm.. But again, I've not seen Scrum Masters do that all that much because they're just being told, Hey, go handle this, this team. Right. Yeah. You only work half an hour a day. We don't know what you do after the standup. That must be nice. Yeah. Oh boy. Well, listen, if you only work a half hour a day and you're a scrum master, I would appreciate you letting me know where you work in the comments so that I can come get a job as a scrum master. I don't think there's going to be a single comment on that. Oh, there won't be any comment on that. if you're one of those people though, who fuels the pain, of what we're talking about here, let us know. Let us know what your strategy has been, how it's been working for you. And, yeah, don't forget to like, and subscribe. Yeah. Where are my other thumbs? Oh, I only have two thumbs. I don't know why I said my other thumbs.