Ask a Professional Scrum Trainer - Self-Managing Teams and Business Impact
In this Scrum.org Community Podcast episode, Lindsay Velecina from Scrum.org sits down with Robb Pieper and Jason Malmstadt of Responsive Advisors to answer the real, practical questions practitioners have about self-management in Scrum in a live Ask a PST session.
Listeners submitted questions like:
- How do you get management to support self-management?
- What should you do when a team resists taking ownership?
- How do you handle a disruptive team member without taking over?
- What metrics show that self-management actually works?
- How can junior Scrum Masters enable self-management when they’re not technical?
- AND MANY MORE!
Robb and Jason tackle these questions head-on, sharing stories from the field, strategies for creating healthy team boundaries, and tools to make decision-making transparent — including Delegation Poker, feedback loops, and working agreements. They also discuss how to tie self-management to real business outcomes to gain leadership buy-in.
Whether you’re just beginning your Scrum journey or coaching mature teams, this episode gives you actionable guidance and small experiments you can start using today.
Transcript
Lindsay Velecina 0:00
Welcome to the scrum.org community Podcast, the podcast from the home of Scrum. In this podcast, agile experts, including professional scrum trainers and other industry thought leaders, share their stories and experiences. We also explore hot topics in our space with thought provoking, challenging, energetic discussions. This episode is a recording of a live ask a professional scrum trainer episode where a live audience joined to ask their burning questions and brought their current challenges to an interactive session with a professional scrum trainer. We hope you enjoy this episode.
Lindsay Velecina 0:39
Good morning, good afternoon, good evening, wherever you're located today. Welcome to today's Ask a professional scrum trainer. I'm Lindsay velasina with scrum.org I will be your moderator today. And today, our session is focused on self management and the business impact of that so burning topic here in Scrum and Agile. And today we have Jason malmstad and Rob peeper here from responsive advisors, one of our partners here@scrum.org and they're both professional scrum trainers. So welcome Rob and Jason Lindsey.
Lindsay Velecina 1:16
Thank you and everyone. Hey, everybody who is scrum.org we
Lindsay Velecina 1:20
are the home of Scrum. We were founded by Ken Schwaber back in 2009 and our mission is to help people and teams solve complex problems, and we do so through our training, certification and ongoing learning opportunities. You can check all of those out on our website, there are a lot of free ways to learn. You already found this session, so it seems like you're taking advantage of that, which is great. And with that, I will pass this over to Rob and Jason to introduce themselves and kind of set the stage for today's Q and
Robb Pieper 1:59
A I can go first. I guess I'm on the top of the slide. Hi everybody. I'm Rob. I I've been a professional scrum trainer for a while. I think 2013 or 2014 is when I got my license. So that's 1213, years. It's a while. Teach a variety of courses. I'm pretty technical in my background, but I also have got a business degree, so I'm somewhere between tech and exec on a pretty regular basis. Been in the software development world for a long time, since, actually, I was 13 programming Commodore computers, and eventually went to school for it and became a professional software developer. And I still do it. It's just not my full time job. But yeah, I love talking about topics like self management and all that. So that's why I'm here today,
Jason Malmstadt 2:45
all right, and my name is Jason momstead. I am coming to you from just outside Milwaukee, Wisconsin, where it is freezing cold and will be for the next several months. My background is also in software development, and I learned about Scrum early in my career, when my boss took me to a hallway lined with post it notes and said, I assume you're familiar with Scrum. And I said, Nope, what's that? And quickly learned how much I enjoyed Scrum. It resonates with me because I'm I like to make plans, but I like to abandon those plans when I learn something new, and so I've been teaching scrum since 2017 joined the professional scrum community, Scrum trainer community, rather in 2022 and yeah, I also teach a variety of courses, APS, PSM, pspo, handful of others. So that's me,
Lindsay Velecina 3:39
all right. Fantastic. So it's time to start getting into questions. Do one of you want to give a brief, very quick overview to kind of set the stage for our Q and A and why you chose this topic?
Robb Pieper 3:57
Yeah, I could jump in on that one. It's a topic that I run into a lot self management is not just sort of a foundational element of Scrum, but even Kanban done well, really exercises self management. And it's it's a tough it's a tough thing for especially larger companies, to grasp, just because we're so used to a little bit of a top down mentality in most companies, where leadership sets direction, their reports, do their thing and kind of follow that direction, and we just kind of all follow orders to get work done, but you miss out on a superpower that's that self management can provide. And I mean, you don't even have to be using scrumor Kanban for it to be powerful. So yeah, we're focusing more on the business benefits of it, like how this can help companies be more successful if they leverage it. It's not just you know about people being happy about their work, though, that is a benefit. Companies can also benefit from leveraging this sort of superpower. That's my thought on it.
Jason Malmstadt 4:58
Yeah, I would agree. I. I I know that when I first understood self management, actually, before that, when I just kind of heard about self managing teams as part of Scrum, I just thought it was kind of pie in the sky, until I saw it work. And, yeah, I've become very passionate about the topic, and I think it's, it's a missing piece and a lot of teams scrum on the implementations. It's very easy to focus on the mechanics of the framework, and, you know, conducting this event well and managing your backlog well, and those are all very important. But when you miss out on the self managing piece, we tend to miss a lot of power of Scrum. And like you said, other other methods that could benefit from self management. Awesome.
Lindsay Velecina 5:42
Thank you. All right, so we have some questions starting to come in. You haven't entered your questions yet. Please enter them into the Q and A box, and we will be capturing them that way again. Please don't utilize the chat. Utilize the chat for any technical questions or just comment. We're going to try to keep those separate. So this first question that came in, so, how do you help management, support teen self management?
Robb Pieper 6:11
I've I've got an idea on that one right away. Go for it. Do you like solving everybody's problems all the time? Do you like vacations when, when there was a, actually a manager once, a long time ago. He's a director of an IT group, and he says, My number one job is to literally do nothing. But that obviously can't happen, because there's always a fire. There's always a system that needs tweaking. Blah, blah, blah, but done well, you create these systems where they run themselves, and you have time for a vacation, and you can breathe, and you can sort of monitor things, and trust that that people are going to solve the problems, but that that doesn't just come for free. I mean, it takes effort. It takes establishing vision and context, empowering people, training people, hiring the right people. There's a lot to it. So, I mean, just from a conventional manager's perspective, you're going to be solving everybody's problems all the time, and everybody's going to come to you with every single problem, if you don't find some way to empower people to solve their own problems through self management.
Jason Malmstadt 7:15
Yeah, I would add to that, and it's kind of the reason we titled The Ask a PST session this way, is that it can be really easy to focus on self management as a as a way to make the team happier, which I'm all about it like I love the fact that when teams are good at self management, people are more engaged. You know, you read Dan Pink's book drive, they have more autonomy they have, you know, they can work with each other better, like all those great cultural impacts. I don't want to minimize those, but that's not going to move the needle when someone feels the stress of I have to be the one to solve the problem, or it's not going to get done, right? So I think it's important to also while promoting the cultural and interpersonal benefits of self management to tie it to real business impact and and show what's not getting done because the managers feel they need to solve all the problems and micromanage the teams and tell people exactly who what to do, when and where and why. You know when I would look for just a small win from self management. Find some small problem that we don't do our normal let's step in and solve the problem for the team, but let's give them the context, give them the boundaries, and let them solve the problem. Find that small win and then try to replicate that as well as you know, make it really transparent what's not getting done because we're spending our time in the weeds. A lot of times that gets lost. The trade off gets lost like we could be solving these bigger systemic problems or capitalizing on other opportunities, but instead, we spent half our time this week in the minutia, right? If we can make that trade off more apparent, that becomes very enticing to allow self management to work.
Lindsay Velecina 9:00
That makes a lot of sense. Thank you. So there's actually a question here, kind of going back to your intro. This is specific for Jason. So it says, Jason, you said, until I got self management, until I saw it work. Can you describe the before and after and the event that made self management click for
Jason Malmstadt 9:21
you Sure. Yeah, this is a story that I tell in my PSM classes, the scrum master classes, because we talk about in those classes how one of the things that a scrum master can do, and it's my favorite of the choices, is actively do nothing. And that's the that was the hardest for me to learn, because when I first became a Scrum Master, I thought of myself as chief problem solver for the team, that if there was just anything slowing the team down, it was my job to get it out of the way. And I don't remember the exact moment or what. The problem was, but I remember the team struggling with something, and me choosing to not solve it. Me to having an idea, and me choosing to just, I'm gonna back off. And I I didn't have this analogy back then, but I use it all the time. Now I'm a father of two young kids, getting less and less young by the day. And when I had taught them how to tie their shoes, they knew the steps. But as anyone first learning that is and weren't very good at it yet, and being an impatient guy, there were several times where I want to get out the door and just tie their shoes for them so we could get out the door. And I just, in that moment, realized I need to back off and let them do it, or they're always going to need me to do it. And I'm not saying the scrum master is the or a manager is the parent of the team by any means, but it was just a really helpful learning experience for me to be like, sometimes you just need to back off and let people work through stuff, and they're going to be stronger on the other end of it. And so I just remember having that epiphany. It's like, I don't have to solve the problems here, and by the way, I don't have the answers to every problem anyway, so we're going to have better solutions. If I just back off, I can still brainstorm ideas, and as we are ideating, add my ideas to the pile. But once that, once that clicked for me, I just started seeing it everywhere. It's like, nope. Now it's not the right time to jump in and try to solve it here. So that's what it was like for me.
Lindsay Velecina 11:21
Great. Thank you. Thanks for sharing that and thanks for asking that question. Next one here. So I'm going to try to get this question right. If, if I do not get it right, please let me know. So what do you do in teams that just won't self manage, although they're presented with the opportunity and methods just because of a quote, unquote that guy in the team.
Jason Malmstadt 11:52
So teams that are given the opportunity and the methods of self management, but they just don't
Lindsay Velecina 11:59
seems that way, and something about that guy in the team, sure? Not sure. I'm getting that part of the question, but
Robb Pieper 12:10
guess we can't ask clarifying questions. Can
Lindsay Velecina 12:13
we we? Can we? Can Dennis, if you are on, can you please clarify? And then we will get back to your question.
Jason Malmstadt 12:24
I think I know what he's saying, but I if, if Dennis, if you can add some clarification,
Lindsay Velecina 12:30
we will jump back to Dennis's question in a moment. This next one here. How do you make self management, make sure self managing teams aren't just lip service from leadership.
Robb Pieper 12:50
That's a hard one. How do you how do you make sure? Well, the easy question, or the easy answer here, is really just ask, ask people like, do you feel like you have the power to solve problems? Do you feel like you're you're respected and empowered to do your job as a professional? If no, then let's investigate a little bit further. This actually is a tactic that I'm borrowing from a book called management 3.0 and I actually just came up yesterday with a phone call with one of my clients, and it's a technique called delegation poker. And if you've never heard of it, just Google it. There's a lot of resources from the author's website on the subject. But imagine the manager is in a room and you've got the team, or some typical power structure where person makes decisions and tells everybody and the other people do what they say. And you want self management to work. Sometimes, the first place to start is, where can the team self manage? What are we allowed to do? What are we not allowed to do? Can we hire and fire each other? Oftentimes it's a no. But you know, have that conversation. Can we choose our lunch breaks? You'd think that's always a yes, but maybe there's a reason that's a no. So having a conversation about a variety of different sort of things, where is it the team's decision? Is it the manager's decision? Is it somewhere in between? Can help you start to figure out where we can make our own decisions? Just saying, Oh yeah, you guys are Scrum teams. You're self managing, and then that it's just a hand waving. I don't feel like there's enough specifics there for people to really run with the ball to setting up some boundaries and some context. I think it's a good start to make sure that it's not just lip service.
Jason Malmstadt 14:36
Yeah, I think when I when I see the phrase, or hear the phrase is just lip service to me that means it's it's something that's spoken but the behaviors don't back it up. So I would try to find ways, or find examples of behaviors that is not in line with what we're saying about self management. So for example, if we. Say, oh, yeah, we want self managing teams here. We want you to work through your own problems, and, you know, we'll just provide the vision and constraints, and you guys solve the problems. Okay? And then a team goes and does that, and then when the solution is presented, or the here's how we're going to solve it, they're overruled, not because of a clearly known constraint, or not because of, like, Oh, I see we're trying to do here, but we, you know, we can't actually hire 10 more people. We don't have the budget. That's fine. That's a constraint. But if it's like, oh no, we don't like how you solve that, so we're going to mandate you do it a different way. Well, now the behaviors aren't in alignment with what's being spoken. And so I think finding ways to sort of retrospect on that. I don't necessarily mean like a formal sprint retrospective, like a scrum team would have, but having those discussions, you're going to have to create psychological safety on that. I'm not saying you should stand up and call your boss out in the middle of a town hall, right? But finding ways to provide that feedback to say, Okay, here's what we say we want, and here's some examples of, hopefully, where our actions are lining up with what we say we want, but here's some examples where our actions, our behaviors, aren't aligning with what we say we want. So how do we how can we handle that differently, both for these examples that we found, and then, what does that tell us about our system of self management that needs to be fixed? So take it back to the behaviors. Actions speak louder than words. Awesome.
Lindsay Velecina 16:14
Thank you. Thank you both. So we did get some more clarification from Dennis. So let's go back to his question, just in case folks just joined. So what do you do in teams that just won't self manage, although they're presented with the opportunity and methods just because of that guy in the team? So the clarification was that one of the guys in the team is very disruptive. He just won't go for the team decisions or priorities and choose to go in his own direction. He isn't affected by the team majority because He is senior and always knows best. Also gets very defensive when the team or scrum master confronts him on his behavior.
Jason Malmstadt 17:04
Never felt, never faced that before. No, I was kidding.
Unknown Speaker 17:09
So that is what is meant by
Jason Malmstadt 17:12
that guy. Yeah, I feel like I might have done that guy before. I don't know, what about you?
Robb Pieper 17:18
I don't know. No one's ever told me if I was that guy, but I did run into a situation like this once before, almost, almost exactly the same situation. And so I can tell you what happened, and whether or not you like the solution is up to your team. But when we trained this team, this is a long time ago, 12 years ago or something, they were, they worked at this bank, and a little bit of an old school culture, but, you know, good people. And they had a gentleman there that had been with the bank a really long time, 2030, years, whatever it was, a while, but not quite retired. So he had seen a variety of different technology architecture ideas implemented over time. And you know, back in his day, putting all your business logic into stored procedures was a good idea. And so, I mean, if you're a developer, you probably know that. I can't speak for 2025, but 12 years ago, it was really hard to write automated tests for stored procedures, and the team was trying to move more towards that direction, where more logic was under automated tests so they could improve quality. Long story short, this more senior architect guy was just not having it, and he was, he was exactly what you're saying here, Dennis, about sort of that guy who just kind of won't play ball. But we, when we train the class, we're like, hey, self managing teams. Could they vote someone off the island? If you know, they've tried everything, and it's just not working out. By vote them off the island. I don't mean fired, but like, hey, we don't want to be on a team with you anymore. Go find another team. They did that eventually, trying to work with this guy, trying to work with this guy, they came up with a vote. And, I mean, they couldn't really, it was, it was not a non binding resolution here, but by voting somebody off the island, they realized no one wants you on the team anymore, so he went and found something else to do, but, like, it really affected him. So he actually started reading books, and ultimately became a whole lot better of a people person. Is he realized technical chops aren't enough on a team, but you also have to be able to work with people. So I don't know if that would solve your problem, but like, go back to a working agreement. What sorts of power does your team have? How do we resolve conflict? Let's get aligned on that first and then deal with conflicts, rather than we don't have the tools to navigate through conflict, and now we have a nasty one in front of our face. That that is the solution. I could go all day on that one, but
Unknown Speaker 19:40
that's great. Maybe you can turn the ship around. Yeah.
Jason Malmstadt 19:43
I mean, I do think having someone, you know, finding something else to do is is on the table. I think of that as plan Z. I think first, and I've had to have some really hard one on one conversations with people who. They were optimizing for their their solutions right? As Dennis said, they're senior, they're always right. They're optimizing for the perfect solutions. And we had to get to the place where it's like, if you want to go fast, you go alone. If you want to go far, you go with the team, like you're not, if you're always right. And this guy wasn't always wrong. He was right a lot of the time, but we had to start looking at some worst case scenarios. Okay, what's the worst thing that could happen if you don't get your way and the team goes a different way, like, we're going to lose $10 billion and the whole system crashes very rarely. So like, can we find some small, low impact things that you don't get your way on, you're willing to let the you know go with this self management aspect of the team is going to come up with a solution, and then we experiment. And how do we make short feedback loops so that we're not making a potential bad decision today and we find out about six months from now? How do we find out about today or tomorrow or next week and slowly build up that muscle. It took a lot of time to get a team and a difficult person to a place where he was willing to not get his way all the time, but it ended up getting more work done and making the team more resilient. So I think you have to really just talk one on one about what you're trying to achieve. We're not just trying to always have the best technical solution we want that of course, we're also trying to make a resilient team, because, long term, that's going to make us more successful, and if we just default to what you want every time, we're never going to get there.
Lindsay Velecina 21:37
Okay, thank you. Looks like Dennis added a little bit more here. I will let you both if you want to reach out to him after this, sure and continue the discussion. That would
Lindsay Velecina 21:52
be super All right, let's move on, because we have a lot of questions coming in. Any tips for junior scrum master being non technical on a technical team?
Jason Malmstadt 22:10
Yeah, I've got, I've got a couple off the bat. You know, don't, don't try to pretend you know more than you know. Technical people can smell that about, you know, 10 miles away, I've, I think one of the fastest ways to build up trust is to be vulnerable. And it takes a lot of vulnerability and courage to say, I don't know the technology here, but I will say, as a technique, a back scrum master with a technical background, I've been the most effective on a scrum team as a Scrum Master, I think when I intentionally stayed out of the technology, like when I was when I was I'm not saying that's true for everybody. I'm just saying that that I've been both a developer and a scrum master, and in the in the weeds of the technical aspects of the product every day, and I've also been a scrum master on teams where I just I did not take on a developer role. Could I have maybe, but I chose not to ramp up on that particular technology, and so I was able to see the bigger picture and not get lost in the weeds and not sort of miss the forest for the trees. So I think just being upfront about it and saying, Look, I don't know the technical aspects. What am I missing? But then reminding your team that you're not there to solve the technology. As a scrum master anyway, you're there to look at the system right way. A football coach isn't there to run the play for somebody. They're there to, you know, see the overall strengths and weakness of the team to help them get better. So just lean into it. It's not necessarily a bad thing. Okay?
Lindsay Velecina 23:41
Thank you. All right, this next one here, when you've got a member of a team or many who aren't self managing, how long do you wait to let them try to improve before you jump in and coach or corral?
Robb Pieper 23:57
Oh, wow. So that I mean case by case basis here. I mean, in some cases, it's how dangerous is it to let it go? How dangerous is it to actively do nothing? In this case, some self management. We haven't talked a little bit too much about this anyway. It requires boundaries. It requires some set of context. It's not about doing whatever the heck you want to do. It's about doing what, what needs to be done within certain confines, like, we can't exceed this budget, we can't exceed these quality requirements, you know, we, we're, we're to use the scrum framework, you know, you've got all these things that sort of establish the framework within which you operate. And sometimes you see a team that is not self managing because either they don't understand the context or maybe the boundaries are too constrained, like you're not allowed to make your own decisions. That's too constrained for self management to work. And sometimes you see that without clarification. Around what we can make decisions on we are afraid to make decisions like, back to the lunch break. If I don't even think I'm allowed to choose one and take my lunch break, that's an environment where self management is probably not going to work. And so re establishing where the boundaries really are and what really matters could be a first step. Yeah. I mean, a lot of I think what we're covering uncovering through these questions, is a lot of team dynamic stuff, a lot of people problems and Scrum, and just working together as a team tends to expose a lot of that self management. It's a pretty simple concept, but like, once you add in all the nuances of your individual people and culture and company culture, it gets interesting, but I'll stop there. I could get on these soap boxes. Really easy.
Lindsay Velecina 25:48
All right, thank you. All right, so what's your approach to identifying bottlenecks and issues coming from managers, micromanaging the teams, and then what's the process to show them they're actually the issue
Unknown Speaker 26:01
here, that management is the issue.
Speaker 2 26:05
Yes, that's what. That's how I am reading it.
Jason Malmstadt 26:07
Yeah, gotcha. That's, that's I want to go to my favorite consultant. Answer of it depends, and then just stop there. Now I I think you're, you're, you're, instincts are in the right place, right? We need to show, not tell, right? And so finding a way to show that, to show that there's a bottleneck, because we are being micromanaged because we aren't given some authority. And I think what Rob said is really worth underscoring here some authority, not Wild Wild West, not anything goes. There are have to be boundaries. There have to be constraints. When there's no boundaries, when there's no constraints, it's actually overwhelming. And self management doesn't work very well, because you start running into all these invisible walls that you didn't know were there. So when, management is micromanaging and stepping in and either solving problems for the team or not giving them the room to solve problems, or what have you, you just have to find a way to make it visible. And that could look like a lot of different things, right? Kanban before. Right? Some Scrum teams use Kanban. Some you know, if you have that visualized workflow through a system, and you're actually measuring, hey, this item is waiting here because we're waiting for, you know, Bob sign off, and we had to wait three days because we are not allowed to move forward until Bob gives us the Go ahead, right? That's a problem, and that's quantifiable data. Or perhaps it's, you know, measured, measuring time of rework, right? The team had a a solution forward, and then Jane didn't sign off on it, or Jane told us to go redo it because she didn't like the way we chose to solve the problem. And so that caused, you know, an extra week delay. Now, any way that you can kind of show that quantification is great when you can get it, although qualitative, you know, anecdotes aren't a bad way to start the conversation anyway, but I think it just really comes down to how you're measuring your workflow, your productivity, your value delivered, and tying it to real business outcomes. We didn't meet this deadline, or, you know, we we got a lower feedback score. We got lower engagement or whatever, tying it to real business outcomes because of the lack of self management authority. It's hard to speak to that one without knowing more details of your your specific context. But show is better than tell. I think is covered
Lindsay Velecina 28:39
quite a bit there. So think, I hope that helps.
Robb Pieper 28:43
Yeah, I'm a big supporter of transparency. In that case,
Lindsay Velecina 28:47
absolutely All right, so moving right along. So it's like rapid fire here. There's so many questions we're trying to get in as many as we can.
Lindsay Velecina 28:57
So can you talk about how I can show the benefit of self management in terms of the quality, usability and value of the product itself. I like that question like that too.
Robb Pieper 29:12
I can run with this one. Yeah, okay. Can you so self management doesn't necessarily mean you're going to be successful. It's a tool, but again, it's about this idea of the team or people or organizations working within confines that don't require external management, but you're still going to make mistakes. The scrum framework creates sort of a checkpoint. You got sprint reviews in Scrum, where a self managing team produces a solution and we show it. We create transparency around what we built. It's usable. We can take a look, we can play with it, and we can make decisions about if this is acceptable and if we want to change, or if we want to adapt something related. To it, but that checkpoint helps the self managing team not go too far and make mistakes. So yeah, I'm a little I wouldn't say I'm stuck on this one, but so the benefit of self managing teams in terms of quality, value, usability, if we have these checkpoints established, and you've got members of management, or members of the just stakeholders in general, people who care about what you're building, and they see what you're building, but they can see in in short cycles, the changes and, oh, wow, we made a mistake. Let's fix it and correct it immediately. It's going to be a lot easier to let teams self manage, because you have a safety net, I think where people get hung up is we have these teams that are self managing, or, in other words, it's the Wild West, and they're doing whatever they want, but we don't have a checkpoint, and we're still implementing more of a large batch waterfall approach, where it's an entire year before I see results. And now, as a manager, I'm a little freaked out, like this team can do whatever they want and I'm not supposed to get involved yet. I don't know if they're going to meet our objective within some confines of Time or Expense or whatever. So yeah, long story short, with self management, requires boundaries. One of those boundaries should be some regular checkpoint to make sure that we're on the right track as a self managing team, and to catch our mistakes, which we're likely to make in small batches.
Jason Malmstadt 31:23
I can just add one small thing to that is piggybacking what you said when we're just kind of layering self management onto a traditional or waterfall project plan where we're just developing, developing, developing, and then a year later we have something to show for it, that frame, that that frame of reference, or that mindset, is very task driven, right? I'm going to trust the self managing team to do all the tasks we've put in the project plan, right? But when you get more goal driven, which is how Scrum is, is meant to be applied, right, we're not just managing items on a backlog. We're achieving a sprint goal, and we're achieving a product goal. And if we write those goals, well, they're flexible, and there might be more than one way to achieve them. Then teams have the ability to self manage towards those goals and try different paths to get there. So if our goal is to double our user base or to increase our attention on the platform from 5% to 10% or whatever your metrics are, right? The team can actually self manage towards that and probably learn what's working and what's not working faster, and that can help with the usability, the quality, the value delivered. Because you're you're managing towards those goals and finding alternate paths quicker when you reach those roadblocks and, oh, gee, adding this feature didn't move the needle the way we thought it would. Okay. Now let's try something else that's usually a more quickly and more effectively done with the self managing team than one person calling all the shots.
Robb Pieper 32:56
Lindsay, I think you're muted.
Lindsay Velecina 32:59
He was losing totally, was, I am sorry. What a big faux pas.
Jason Malmstadt 33:05
So it's just a dramatic pause. That's fine.
Lindsay Velecina 33:10
Yeah, I am here. Sorry, everybody. So would you agree that a self managing team is also a team that is able to run scrum on their own with minimum dependency on the scrum master, including hosting a retro?
Robb Pieper 33:27
Oh, that's a great question. So self management like think of it like layers of maturity, much like a child can make certain decisions at the age of five. And you know, you go on recess at school and they give you a big red ball, and you can just learn to play kickball and pick your own teams. And that's at five or six years old. People are allowed to pick their own teams. It's crazy. You go to work in the corporate world and you're assigned to teams and La, la, la. So self management, I feel like there's some layers of maturity that you have to demonstrate before you're going to take on the next in larger companies, there might be more layers to that maturity that need to be demonstrated. In a very, very small company, say, I don't know, five founders that work together to create a startup, you're gonna have a lot more power as a self managing team. So, yes, an advanced, maybe not even that advanced, but like a somewhat mature, team, should be able to run all their own scrum events and minimally dependent on a scrum master. And if they find impediments, they're going to find a way to crush them while their Scrum Master is out solving other bigger scrum master problems. Over reliance on a scrum master is typically a sign of kind of a lack of self management, a lack of maturity, right? I mean, first place to start is your daily scrums, if your developers aren't managing that event all on their own, I'd say there's probably still some work regarding getting self management to work on that team.
Jason Malmstadt 34:55
Yeah, I like the way you phrase that question, though, because it minimally dependent on. In this Scrum Master, I would agree with. And especially, yeah, running their own retros and all that stuff, I see a similar question that you didn't ask a lot, which is, was that mean, we no longer need a scrum master? And I think that's a that's a hard No, I make a lot of sports ball references, even though I'm not a big sports ball person myself, but I do know that even the most like championship winning, Super Bowl winning, whatever you know, World Series winning. Teams still have a coach because they recognize the value of having someone looking at the bigger system and helping them improve. Are those coaches at the professional level hand holding them through the basics? No, they're they're solving bigger issues. So I think a very mature self managing team still gets value out of having a scrum master, but I would expect that scrum master to be spending less time on running every single retro and, you know, hand holding the team through the basics, and, like Rob said, solving the bigger organizational problems, still providing value to the team, though, right?
Lindsay Velecina 35:58
Scrum Master is much more than a facilitator, yeah, for sure. All right. Next question, how do you manage a team member who keeps digging into other people's responsibilities and then complains there's too much work?
Robb Pieper 36:16
I'm not sure I fully understand that question. How to manage a team? How to do you manage a team member who keeps sticking to other people's responsibilities and complains there's too much work?
Lindsay Velecina 36:27
Yeah? So the team member is instead of just focusing on whatever they're focusing on for their team, they're doing other people's work and then complaining that there's too much work. Gotcha?
Robb Pieper 36:44
I I think we have a situation here where maybe it's a bit more of a hero, or a person who feels it's their job to do everybody else's work. A good self managing team is going to expose that work, and everybody's going to see that there's too much work, and we're all going to work together to solve that problem. It's not just on one person to solve this problem.
Jason Malmstadt 37:05
Yeah, I just gave this advice yesterday because somebody was asking, do we divvy up the work for the sprint at Sprint Planning, or day by day at daily scrum? And technically, Scrum teams are free to do either. But I'll tell you, I given my personal opinion, which is, I strongly prefer not divvy up all the work at at Sprint Planning, because you're assuming what's going to happen throughout the sprint. You're assuming equitable divide of the work. And now I start the sprint with a whole bunch of stuff on my plate that I got to get done by the end of the sprint. And so if you need help, I'm less likely to help you, because I might love to help you, but I've got this other stuff that I can barely handle. So I think I'm kind of assuming a little bit the background behind that question, that maybe we're sort of pre dividing up your work and my work and his work and her work and and and operating that way, and maybe again, getting more goal focused, and coming to the table every day at daily Scrum and saying, Okay, here's how do we move the ball forward today? And agreeing who's going to do what and when, can maybe stem some of that kind of changing the underlying paradigm, instead of just telling this person to mind their own business. Because if we're working at the scrum team, all the business of the team's business.
Lindsay Velecina 38:18
So, okay, thank you. All right. I hope that helps. So this next question, I'm going to try to get this right so management's understanding of self managing is a team that manages their own tasks, not a team that has autonomy. How can I reduce this misconception as management may resist this change?
Jason Malmstadt 38:51
I mean, I'll just throw a second plug for a tool that Rob mentioned before of delegation poker. I've sat down with teams before and gone through the different decisions that need to be made. And like playing poker, you know, keeping a poker face and hiding what you have in the cards we've okay. You you come up with what you think this is. And for those of you aren't familiar, a delegation poker just defines a spectrum of who's making the decision with what degree of influence. So you know, some of them are management decisions, some of them are the subordinate decisions. And you know, if I think it's my decision as the manager and you think it's your decision as the team member, there's a mismatch. And any relationship when there's a mismatch of expectations, it's a recipe for disaster. So getting at least making transparent where those mismatches are, right and going through lots of it sounds like in this question, the manager is thinking, oh, yeah, you can manage that little day to day stuff, but the big strategic decisions, that's my job, and maybe some of them are, and I probably wouldn't change those all overnight. That's a lot of change. To upset the apple cart really quickly, that that is often too hard to take, but like, lay out the decisions that maybe you think the team should be making, and the managers and agree, make that transparent and just start there. Don't expect it to change in that conversation, and then say, okay, maybe, maybe we can move the needle on this one. Maybe this can be a team decision, or if you use the delegation poker, maybe it's, it becomes a consult versus tell, or, you know, whatever, you can look up those terms. But yeah, I would start by making it transparent. It sounds like there are mismatched expectations, and I can't, I can't work on them if we don't all see where those mismatched expectations are in the first place.
Robb Pieper 40:42
Okay, yeah. My thought real quick, it sounds like a maturity thing, that either we're not yet mature or we are and we haven't yet demonstrated it. I like the delegation poker thing, yeah,
Lindsay Velecina 40:55
okay, yeah, that makes a lot of sense. All right, so this next one. Do you think that self management is strictly related to communication? My experience is that devs might prefer the model in which there's one member, the leader that knows all and can answer to every question and give task assignments then to communicate with each other and with the PO and stakeholder. Sorry if I got that wrong. It's a little hard to read. What do you think about it? I can reread it if needed.
Robb Pieper 41:36
Sure. No, I totally. I get that one. I understand, I think I understand what's being asked here. All right, here's the thing. I would love for somebody to tell me what to do, but I love it. They have to always be right. That's the thing. If you've ever been in a situation where somebody told you to do something because of their seniority, of their power, and they were wrong because they either don't do the work, or they're disconnected, or they don't understand your actual context. So they told you the wrong thing to do, and then you do the wrong thing, and then now you're the one to blame when it doesn't work. That that typically frustrated me, so I as a developer would always want to know what problem we're solving. You hand me a stack of requirements, I'm going to be asking, why are we doing it like this? Why does it have to be this way? Especially if it doesn't make sense. I want to understand context. Now that's just me. I like to solve problems. I don't just like to push buttons that people tell me to push. I can't speak for every type of person and their motivation. If you are the type of person who doesn't want to solve problems and you just literally want to do what you're told to do, no judgment. If you've got an entire team of people like that, your your benefits from scrum will be fairly limited, because you're going to rely on one single brain to know everything which can't really ever happen, to be able to give all the right commands at the right time in all circumstances. When that doesn't work, you'll find the team just doesn't have the same power. I mean, it's sports, and you pick any sport where we're working together to move a ball down a field. In Europe, you call that football. Here we call that soccer. It takes a group of people to all see what the score is and where we are in the field and where the ball is moving to make decisions on the ground about how they interact as a team. If you had to rely on a person to tell every player on the field precisely how to move and predict every movement in that ball, I do not see how a team would score. It's all we're trying to replicate with Scrum.
Jason Malmstadt 43:34
Basically, I'm just going to pick on something that the question the way it's worded, like the model in which there's one member, the leader that knows all is unpopular opinion. Perhaps that person doesn't exist that we kid ourselves when we think there's if I just get this one person who can make all the decisions and the rest of us can just manage the tasks you're you're going to be missing something. Cognitive diversity is a crucial thing on any team, and we all have different perspectives. Someone can be the most senior and the most expert, but they may miss the they may miss the most basic or an easier way, or sometimes the expertise becomes a stumbling block, because you think about the most complicated things, you miss the simple things. Like, we're going to get better solutions in the long term when we get everyone's input, and I think you're just operating in a model that if we could just put this one person leadership, they can make all the decisions, and I think you're going to hamper yourself that way.
Lindsay Velecina 44:36
Thank you. All right, so we already had kind of a similar question to this, but I'm going to ask it because it's a little more specific. What metrics, if any, do you use to help demonstrate how self management improves business impact? Wants to take that one?
Robb Pieper 44:56
Metrics, huh? Well, so I like the idea of, let's. It back to self management and business results. Is this working? Is this not if you're using Scrum, let's say we're using Scrum as designed out of the box, and you have sprint reviews, and you've got stakeholders attending them, and you've got self managing teams, building solutions that align to a sprint goal, and we're demonstrating them. It's pretty easy to take down notes in that meeting of like, Hey, did we get any critical feedback? Yes, okay, what was that feedback? Hey, you just built 40% of the wrong thing. Stop building that. Hey, that's good to know, because that would have cost us an extra million dollars to go down that path. So I don't know if I have a perfect metric, but if we can start capturing some information about the feedback we're getting and the results the feedback produced, like, do we save money because we stopped building the wrong thing? Did we improve revenue because we found a new product opportunity or a new enhancement that could lead to better sales if we're starting to find those kinds of benefits? Yeah, it's not directly from self management, but it's the results of self management are what we find in the increment, increments that meet your sprint goal consistently and are improving over time, are usually a sign of a good self managing team.
Jason Malmstadt 46:10
I think of it experimentally, right? Any, any middle school science student can tell you that in the scientific method, you have a control group and an experimental group, right? So if you are growing in self management, you probably have the way it's always been done with, which is lacking in self management, where there is a that, that person from the last question, who just knows everything and makes all the decisions, right? And then there's some decisions that we're experimenting with self management, we're going to break the rules, or we're going to change the policy, or we're just going to normally about the boss would step in and decide here, but we're going to self manage this one and then just try to compare results. And sometimes it's not one to one, because not everything is repeatable. But if you can, if you can define an experiment and say, we're going to do this thing differently, we're going to solve this problem, we're going to provide this piece of value, and then compare that to a similar situation as you could from previous experience, or just run a thought experiment and say, Okay, what if we hadn't done it this way? Well, we would have had to run this up the chain and have three different sign offs, and that would have expanded this by a week, and that could have led to the, I mean, you don't have to make it a perfect, you know, double blinded experiment. Don't take it that far. I'm just saying, like, if you can kind of do a apples to apples comparison and say what would have happened, or what typically happens in situation, and then again, tie it to real business outcome impacts. Not just we delivered X number more story points, but this is what the customer did with it. This is what the revenue changed. This is what our user base changed, or whatever business metrics are important to you. That's going to make a more powerful statement on self management than just well we feel better about it. Awesome.
Lindsay Velecina 47:51
Thank you. All right, moving right along. So how do you build in psychological safety in helping team self manage. How do we tie those two things together?
Jason Malmstadt 48:07
Psychological safety, I think of psychological safety, and I heard this definition at a conference. So maybe someone can put in the chat where it's actually from, but the ability to challenge the status quo, to ask questions, to do things differently, even to fail from time to time without being ostracized by your team. And that could be by your team. It could be by management. If we're talking about self management here, right? So if I am worried that I'm going to make a decision, and I'm either going to be overruled, which is frustrating, or worse, penalized in some way for making that decision. I'm going to opt out of self management, and I'm just going to say, Well, fine, then you make the decision, right? Why do I want to try to make a decision? And then I get my hands slapped. So management really has to buy in to to not penalize teams for making decisions as a team that aren't perfect, doesn't mean we can't give feedback, right? I'm not just going to be like, Oh, that decision lost us lots of money. Good job. Team. Like, no, no, we can give real feedback about, hey, we don't like the results of that. That's fine. That's part of the feedback loop process. Right psychological safety doesn't mean we treat failures as successes, but it means that we honestly and openly examine them with a positive intent, with respect, with and not penalizing the people like you should have known better, or, you know, whatever I mean, we do it in a constructive way that encourages saying, Okay, we tried something. We like that part about it. We don't, maybe don't like these results. How can, what can we learn from it? So, the best example of this that I've seen, it's not really a self management thing, so pardon the diversion a little bit, but I was working at. Company once that had a reputation for poor work life balance, and I was leaving on vacation for my with my family, and my flight got moved up, and I still have I thought I still had to be part of a meeting, so I told my boss, hey, I'm going to be calling into this meeting, but I won't be on camera because I'm gonna be on my way to airport. My flight got moved up, and my boss was like, No, you don't need to be at that meeting. And I was like, No, it's okay. It's fine. I'll be there. He's like, No, you don't need to be at that meeting. He had to go so far and say, Jason, I'm not telling you, you're you don't have to be at the meeting. I'm telling you, do not show up to the meeting. Like he had to go so far in the other direction, because the cultural pressure was pushing me to just work during my vacation. And so self managing teams, if they're new to this, and trying to create psychological safety, you may have to kind of push the pendulum past what it's like, oh, this is okay, and say, no, it's actually good that you experimented. We don't love the results, but this is a good thing, and we want to continue this self management. And now, how do we learn from it? You may have to push the pendulum past pendulum past the middle point.
Unknown Speaker 51:07
Thank you.
Jason Malmstadt 51:08
Not sure if that anecdote helped or not. I
Lindsay Velecina 51:10
hope that helps made sense to me. Helped me. All right, so
Lindsay Velecina 51:18
this is an interesting question. So the self management concept is great. However, if the team tends to group think, to keep harmony, it becomes risky. Any tips to try to bust the group think? As a Scrum Master, I
Jason Malmstadt 51:34
just got off my soapbox. Rob, what do you think?
Robb Pieper 51:38
Just like one, there's a lot of hard balls getting thrown today.
Lindsay Velecina 51:41
Yeah, these are everyone came prepared. They knew. They understood the assignment.
Robb Pieper 51:46
Yeah, so group think. I think we need to take away the ability to have artificial harmony anonymous surveys, where people can't gage the reactions of others before they make their own decisions. Could work. I know some facilitation techniques, say, with retrospectives. Start off with everybody just writing down their ideas onto a post it note, and we stick them up on a board, and you don't know what's going to be up there yet, and you can start to get the facts before we start looking at them, that can help expose, I guess, differences in opinions. I mean, you can always just call it out. Interesting, how we all think the exact same all the time. That kind of makes most of us useless, at least as a team. You know, those are some ideas. I mean, we need to, we need to expose, or find an alternative path to break the artificial harmony and maybe, maybe start with an easy thing, not something like, oh, let's talk about the architecture of some system, but let's talk about where we go to lunch. You know, that's that's very easy to start with. You know, if everybody always says, Oh, I'll go wherever Bob wants to go, well, we'll just go there. No, let's get some debate going. Who doesn't like these options? Jason, didn't you have some some idea about restaurants and how to choose them, and,
Jason Malmstadt 53:03
oh yeah, there's a voting technique. I'm not gonna go into that, because we don't have time. You can look up CGP, gray, easy voting to like a 62nd video. I really appreciate this question, because I do not like group think, and I, and I, I start to get nervous when we all get to an agreement too quickly. I feel like we're missing something. And so I'm a big fan of the opposite of straw Manning an argument. So straw Manning an argument is making it artificially weaker, okay, so you can defeat it more easily. The opposite of that is steel Manning an argument. So if we're all getting to groupthink in an agreement right away. Then I try to think, Okay, what's the best argument? How can I argue against what we're getting to just so that we're considering other options? Sometimes you can build that skill and and get good at trying to come up with the best argument against what you're where you're headed as potential group think, sometimes you need other people, so you bring in somebody outside the group and say, Okay, here's where we're headed, you know, almost like a debate team. Like, take the opposite position, try to make a case for why we shouldn't go in this direction, or why we shouldn't land here. And then I guess I would finally just say, just call it out. Like, say what you're going to do. Like, say, Okay, we got to that decision really quickly, and it's great that we're all, you know, happy about it, but I'm, I'm worried we might be missing something. So let's, let's consider alternatives. Let's, you know, devil's advocate is sometimes used. Let's make the opposite case, just to make sure we're covering our bases. Awesome.
Lindsay Velecina 54:37
Thank you. I hope that helps. All right, so we don't really have any time to take more questions. We're kind of wrapping up here, but we will figure out a way to get these questions addressed in some way, shape or form. So don't worry about that. We will figure that out with Rob and Jason. But any parting words you want to leave with the group today based off of like, the types of questions that were asked? Any piece of advice that you want to leave them with.
Robb Pieper 55:05
Yeah, I've got one I'll throw out there. So a big theme I'm seeing are not so much self management issues. They're people, people issues. And there's lots of books to read, or lots of I guess, chat, GPT. I'll probably give you a summary of these books, a book by Dan Pink called Drive. I think that's a great book to read. It's a great book to if you don't read the book, get the audio book. Watch a video. There's a video on this on YouTube, very popular talks about autonomy, mastery and purpose, and those are some of the keys that really unlock the power of self management. And so that might be a way to start to socialize this. If the words self management are getting a negative reaction, stop talking about that. Let's talk about something else that's related and see how that lands people. Issues are tough. I mean, we all come with our own opinions, our own context, our own histories, and when that comes out on teams, it can really affect things like self management and using Scrum in general. So, yeah, there's a lot of people topics. I'll just leave you with that book recommendation at a minimum. Happy to give you more book recommendations if you want to contact me.
Jason Malmstadt 56:19
Yeah, one thing I've learned, and this has helped me with with self management, is just and I alluded to this in the last question. Just say out loud what you're trying to accomplish. Like, when I first became a Scrum Master, I thought I had to, like, secretly nudge them toward, oh, I don't think they're self managing very well. So how can I prompt with questions and whatever? Like, just say it out loud. Like I'm noticing that I don't think we're as self managing as we could be. And, like, self manage your way to, you know, brainstorm ideas of like, how are we going to solve that? What are some ideas we have? You know, again, if you put the goals out in front of people, then they can get creative about how we're going to solve that problem. They might surprise you of thinking things you didn't think of. So don't be afraid to just put it out there. Of of my observation is we could be more self managing, or we're struggling with self management in this area. Am I off base? Do you all agree with that assertion? And if so, what are some ideas to improve that and just set up little experiments and feedback loops? I think we often think of Scrum as an incremental value delivery framework, which it is, but also getting better at using Scrum, or any way of working really, is often best done incrementally as well.
Lindsay Velecina 57:32
That's great advice, all right. Well, thank you both for taking the time and thank you to our audience. We had about 100 or so people stay on for the entire hour who
Lindsay Velecina 57:43
joined us on the live session today, so that that's fantastic. And I hope everybody
Lindsay Velecina 57:49
got a lot of value out of this. I certainly did. And thank you, everybody and Scrum on, you.
Transcribed by https://otter.ai