What Project Managers can bring to Agile with Andrew Mitchell

Join forces with Mark Metze and Andrew Mitchell as we traverse the landscape where traditional project management merges with the dynamism of Agile. With Andrew's 30 years of experience at the helm, learn how the blend of these two worlds enhances the Scrum Master's toolkit, adapting to an ever-shifting economic terrain post-pandemic. It's an exploration of growth, flexibility, and the value-driven approach that today's Agile practitioners must embody.

Embark on a deep dive into the art of forecasting in Scrum, breaking down the science of setting delivery dates without breaking your team. This episode isn't just about numbers; it's a masterclass in communicating with stakeholders and cushioning teams from the brunt of unrealistic expectations. Andrew and I peel back the layers on how data like velocity and throughput shape forecasts, and how presenting timelines as ranges can smooth out the bumps in the journey of project completion. Aligning team efforts with company objectives through OKRs, we discuss the dance between rigid deadlines for compliance and the agility needed for innovation.

As we sail towards the sunset of this episode, we leave you with the compelling tale of how empowering leadership can transform an offshore team's assertiveness, processes, and autonomy. It's a testament to the dual role of Scrum Masters as both shield and compass for their teams. We wrap up by inviting you to keep the Agile flame burning by joining our LinkedIn community. Share this knowledge-rich voyage with your colleagues who seek to steer their Agile practices towards uncharted territories of efficiency and resilience. Until our paths cross again, remember to iterate, adapt, and stay Agile.

Connect with Andrew on LinkedIn:
https://www.linkedin.com/in/andrewmitchellpmp/

Join the Agile Beers Novia Scotia Meetup:
https://www.meetup.com/scrum-beers-halifax/

Listen to our past episodes with Fred Deichler:
https://theagilewithin.buzzsprout.com/1449787/13791132
https://theagilewithin.buzzsprout.com/1449787/13904290

Discover Peggy's Cove in Nova Scotia:
https://en.wikipedia.org/wiki/Peggy%27s_Cove,_Nova_Scotia

Join the Alliance and support the show:

Transcript

Speaker 1: 0:06

Welcome to the Agile Within. I am your host, mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Welcome back to the Agile Within. This is Mark Metz. I want to introduce to the podcast today Andrew Mitchell. Andrew comes from Halifax, nova Scotia in Canada, and Andrew is a Scrum Master and Agile Coach, but he's also a meetup host and a content creator for the Scrum Beers Halifax meetup. So welcome to the podcast, andrew Mitchell.

Speaker 2: 1:03

Thank you very much, Mark. Pleasure to be here.

Speaker 1: 1:05

Great to have you All right, andrew. I'm coming to Halifax for a day and I can only do one thing. What is that? One thing that I have to do?

Speaker 2: 1:13

I mean if you're coming to Halifax for a day. First of all, let's be clear, it's beautiful here all year long, but don't come in the winter. Come July, August, August, September are probably our best months, and as beautiful as the city is, one of the most iconic things on the east coast of Canada is the Peggy's Cove Lighthouse, so you can take a ferry ride from downtown and a bus back. It's a beautiful lighthouse on a rocky shoreline and it's absolutely a must-see in this area. I recommend it to everyone. Stunningly beautiful. Look up Peggy's Cove, Nova Scotia folks will really see why that's awesome. So so look up Peggy's Cove, Nova Scotia folks, you'll really see why.

Speaker 1: 1:43

That's awesome. So we'll have to put a link in the show notes for that for people to look it up. All right, well, andrew, I want to get to our podcast topic for today. So, andrew, what can project managers bring to Agile?

Speaker 2: 1:55

Let me go back before I get into this because I want to give a little bit of my history and why I feel this way. So I started my career. I've been in almost a 30-year career. I've worked primarily early in my career as a software engineer and then I knew I wanted to lead projects and I got into project management in about 2007. I was leading a few projects and it never really felt if I'm going to be honest, never felt fully authentic. I never loved telling an engineer that they had to do something because the project plan said that it's March 1st and she's supposed to start it today. It just never felt right. And, interestingly enough, when my career took a bit of a pivot and I've done some other things systems analysis, business analysis the Great Recession, like many folks, called me to do a bit of a pivot. But then I wanted to get back into project leadership around 2012. And I got the opportunity to work for a cool organization as a Scrum Master and it just totally felt authentic to me.

Speaker 2: 2:49

And Mark, you and I met actually about I don't know three years ago, maybe longer, doing PSM2 training class, which is an excellent class, and I honestly like a lot of Scrum Masters, I resisted project management. I resisted the need to do long-term planning. In fact I almost had a visceral reaction to the phrase project management. But I think the landscape for project management has changed in the last, especially in the last five years, especially since the start of the pandemic and even more recently since the increase in interest rates and the economy has changed and what that has led to in the last year and a half, this kind of great resignation, that's actually turned into a great firing for a lot of tech workers and I think for a lot of engineers. That wasn't so bad because they were able to find other opportunities.

Speaker 2: 3:37

But for our profession as scrum masters, I've seen organizations looking to make a pivot away from pure project management sorry, pure scrum master into like hybrid role and needing to do different types of things. And that's kind of the framework and we can get into that more if you like. But that's kind of the topic that I want to paint here and I know that's probably controversial still for a lot of scrum masters. Why would we want to do project management? But I think I look at it like this and I've always talked about having a toolkit and my toolkit has now I've kind of dusted off some of my old project management tools and thrown them back into my Scrum Master toolkit and I need to pull those out at times and we can dig into those in some more as we go on.

Speaker 1: 4:18

So, as Scrum Masters, our primary concern should be how do we increase value to our customers, to our users and within our organizations? It shouldn't be about being agile, it should be about generating values. I would hope that we would have a growth mindset and see what, within project management, we could use, what could benefit us to bring value to our organization. So what are some of the aspects of project management that you found that can bring value, actually, mark. So what are some of the aspects of project management that you found that can bring value?

Speaker 2: 4:47

Actually, mark, if I may, I'd like to just kind of pivot a little bit again and kind of define the problem a little bit more. And what has happened in the last couple of years is our leaders and executives are asking and stakeholders are asking different questions, and I think that's partially because of the economy. I think we spent a decade post Great Recession with low interest rates and organizations Look at the big tech firms, the Googles, the Apples, the Metas putting a lot of money into startups, into their business, and buying up startups, and they were willing to take more risks. Interest rates have gone up, costs of borrowing have gone way up. Those companies aren't willing to take the same amount of risks.

Speaker 2: 5:27

And what we've done as scrum masters and I shouldn't say we I am as guilty of this as anyone. I remember being asked questions in an organization about when something is going to be done, what is the delivery date, what is your estimate? And I would say that we're agile. We don't talk about dates, we just deliver continuously. Well, you know what? That's not good enough anymore. That doesn't answer the questions that our leaders and executives are wanting to ask. They need to know, they need to make planning decisions. Does that mean we should dust off Gantt charts and do work breakdown structures? No, those are not the tools I'm talking about. I think there's a few things that I learned as a scrum master that were really valuable, and here's a couple of them and stop me, if I go ahead, I've got like six or seven I could go through. I'm going to start with one of the things that maybe not is a true tool of project managers, but it is kind of like project managers are really good at talking about their wins. One of the things that we haven't done well as a Scrum Master community, at least in my estimation, is communicate well with leaders and executives and talking about how good our teams are, and this is something I've always said. I brag about my teams at any possible point that I get to anybody in my organization that will listen Doesn't mean I'm not transparent about challenges, but I think that that is something that project managers are really good at and that goes along with. When I did the master's certificate in project management which I have, which led me to write the PMP the designation from PMI, project management, professional designation we said that there was an entire chapter on communication. So communicating with leaders, communicating with stakeholders using different types of tools, building communication plans around that. Project managers are really, really good at that and I've seen it. I've worked with some incredible project managers in my career and they are just so good at making and communicating with executives and that's really important and one of the ways they do that is understand the business behind their product.

Speaker 2: 7:47

I think sometimes us as scrum experts focus too much on we're making progress here, we've got a high velocity, we've got whatever scrum metrics we are, our throughput is high, our cycle time is low, we're managing work in progress and that's all great stuff. I still use those metrics, but you know what? They make no sense to most executives, nor do they care. They want to know when and how much, and maybe we don't control the how much so much in Instagram because our teams tend to be fixed teams so there's kind of a fixed cost, but we need to just get out there and embrace some of those conversations around that. So it's a lot of around that, mark. It's around pulling those tools out, around communicating with stakeholders, about managing risk and about I actually hate the word estimating.

Speaker 2: 8:39

One of my goals in life is to remove estimating, the word estimating, from project delivery and talk about forecasting. I won't get into it, but Daniel Vacante and his group at ProConBondorg do some great work around forecasting, using data to forecast. One of your previous guests, deakler, has done some great work on that as well. We've got to get out in front of that and talk to stakeholders about when we're going to deliver things. Now. To me, I always say, the great thing about estimated or delivery dates is the whooshing sound you make when you blow by them.

Speaker 2: 9:21

But I use that as a joke, because I think that we need to have the dates that we're trying to commit to deliver something has a good conversation.

Speaker 2: 9:33

It allows me to protect my team from executives who are coming in and asking individual questions to team members and saying, no, no, we're working on this date. And as soon as it becomes obvious that we're not making that date, and if that happens, we can have a conversation in the team about do we want to talk to executives about moving out our deadlines or reducing scope and involving product in that conversation. I think that's really important. So those are the kind of things that I'm leaning into as tactics to pull or tools, I should say to pull, from that project management toolbox and use as scrum masters. And I will say I don't. When I say making estimates again, I don't think it's going into work, breakdown structures and estimating and spending three months doing requirements up front for a year-long project. I think it's using the data that we have, like velocity, like forecasting, like velocity, like throughput, whatever metrics you're using in your team and projecting those to try to come up with a delivery date.

Speaker 1: 10:33

What would you say as a Scrum Master and possibly leaning on some of your project management skills? What would you say to a development team who comes to you and says, well, this whole projecting, a delivery date, is hogwash. You need to trust us. We're going to work as hard as we can. It'll be ready when it's ready.

Speaker 2: 10:51

Great, great question and one I've dealt with on many teams. I had that exact same question on a team I worked with a few years ago and we had that they didn't want to be pushed to a date. And I think some of those questions from teams come because dates get used as sticks in some organizations. Right, they get used to you tell an executive a date and they pencil that in their calendar and if you're not making that date, they come and beat the team and figuratively of course, with the stick and say why aren't you meeting this date? Now you have to start working overtime, now you have to start working weekends to make this date. So back to your question how would I deal with my engineering teams? How have I dealt with my engineering teams when they say we'll deliver, when we'll deliver, I'm fully with you.

Speaker 2: 11:36

I know there's a. I'm like Mark, you're my engineer. I'll be like I'm with you. I know there's a lot of complexity. I've been in your shoes. It's been a while.

Speaker 2: 11:45

I know there's going to be things that we don't know. We're going to uncover unknown unknowns. These things that we don't know we're going to uncover unknown unknowns and that's going to cause our scope or our timelines to change what a date gives you. We're trying to project a date and, by the way, a date isn't certainty Like, again, we should be giving dates with percentages, like, hey, there's a 50% chance we can make it for March 5th, but you know what, if we push that data out to March 20th, there's like an 80% chance we'll make it. And there's a whole other podcast and more experts on how to do those estimates for you. But again, so I would say to you, mark, or to my engineers, having a date that we think we can deliver something in, even if that's a pessimistic date, allows me to work with stakeholders and executives. Communicate that date, communicate the risk behind it. So, hey, executives, you want that on March 5th. Like you said, it's a 50-50 that we're going to make that, but if you're willing to push it out a couple of weeks, it's like 80%. And remember, 80% still means we're going to miss it one time out of five.

Speaker 2: 12:47

So giving us that opportunity to have the conversations with executives and leaderships and organization stakeholders around dates gives us cover, gives us protection from the team and then when we see as a team, whether in our daily scrum or a sprint planning event, that we've uncovered some massive new scope.

Speaker 2: 13:05

Maybe there's a piece of tech debt that we've uncovered that we need to fix before we can deliver a feature that allows us to have a conversation inside the team and figure out what our new date or new scope would be. It allows the product owner and I to go to executives and say here's where we are. That is actually what risk management was in project management, what risk management was in project management, except in the old days. You would raise a change request that would go to a change control committee and you would spend hours writing a document and an hour debating it with executives. It's really that kind of thing, but it's a much leaner process. So, again, dates protect the team and allows us to have conversations. Not that we're trying to be not trying to be transparent, we're going to be very transparent but it allows us some cover so that we can have better conversations with leadership.

Speaker 1: 14:01

I think words are important and I really like your choice of words and I try to do this too and not use estimates and use the word forecast, For instance. I think everyone can empathize with a weather forecast, and even when the weather person says there's an 80% chance of rain, how often are they wrong? Right, how often are we disappointed by the forecasts of the weather person said more than likely it's going to rain. They gave us even a 90% chance and it's like 10% really, and then it pour, uh, and then it pours down over here just ruined my weekend. So forecasts aren't perfect. But when we hear the word estimate in my mind, estimate brings with it. Okay, I've done my homework up front and I'm estimating how long it's going to take, and I think that conveys a more exact measure just by using that word. And I'm not sure if you've seen any softening of reactions when you use the word forecast as opposed to estimates when you communicate to leaders. Have you? I mean?

Speaker 2: 15:00

I think. So I'm working on it. It's still a work in progress because when you put a date out there, it becomes kind of written in stone. So I'll be honest, I'm still on that journey. I've recently started with a new organization and I'm actually going to start putting out dates with percentages. Again, I don't have a lot of data on my teams and I'm relatively new, but at first they're going to be swags, they're going to be wild guesses, and then we're going to get some data on what we can actually deliver and then do some percentages. But I think that's really important.

Speaker 2: 15:34

And, if I may, I mentioned his name really quickly Fred Deichler, who I know was a guest in your podcast. Fred's great and he's doing some other work. He's got some other presentations. He did one to my group around forecasting and some of the tools he's using. So I would encourage folks to look up what Fred's doing. He's done some presentations. He's on a speaking tour right now. He might be in Europe right now actually talking about some of this stuff. I know he's going to Europe again this year, so check out Fred's work.

Speaker 1: 16:02

We'll put a link in the show notes for that as well. Have you used, instead of dates like a specific day March 3rd 2024,? Have you used either ranges or maybe months, quarters, things like that for projecting?

Speaker 2: 16:17

releases further out. Yeah, 100%, mark and again, I'll go back to project management. On this, one of the things that we learn in project management training and we were good at communicating is the term the cone of uncertainty. You're probably familiar with this, but projecting a date for when something is going to deliver is much like a radar Radar starts from. I do a lot of boating in the summer. My buddy used to have a radar on his boat.

Speaker 2: 16:44

You can see radar kind of projects out and as the signals go out they bounce back and the further they go out, the less strong the signal you can see. So, like radar, honestly, kind of like your own vision, you can see what's coming up really in the close by. You can see that You're pretty firm about that right. You see a lighthouse that's representing a reef. You know that that's right there, but you don't know what's coming. You don't know what's over the horizon and presenting a reef. You know that that's right there, but you don't know what's coming. You don't know what's over the horizon.

Speaker 2: 17:16

And so an organization I worked with when we did roadmaps, you know we would do kind of a rolling calendar so we would know like, so it's almost March. I would have a really good idea, maybe a high percentage of certainty, of the date I'm going to deliver something. And you know what? I would probably just say the week of I would probably look and say I'm going to deliver. I think this team is going to deliver something the week of Monday, march 11th, and that's going to be pretty firm on that.

Speaker 2: 17:35

And then as we go into the next month, the next quarter, we're like I think we're going to get this feature X in April, may. If we're looking like later in the year like, yeah, this, the roadmap may change but I think this feature can be delivered in in the fourth quarter of this year, like, I think that is one tool that we can use. And you know what? That could be as simple as just putting it into a, into a spreadsheet or a table and projecting those out. And we use that communication tool at an organization I worked with all of the scrum masters, delivery leads contributed to that and it was really important because that organization, while teams were kind of independent and had a vertically integrated, they're also part of a larger platform, so we could kind of build that out there.

Speaker 2: 18:22

And that is so important to allow, again, stakeholders, executives, to see what's coming. It's really important if you're in a commercial software business, you've got salespeople out there making commitments on when you think you can deliver stuff. So this stuff is really important. That is a really simple tool. Just start projecting the next stream, or maybe it's just this quarter by month, maybe next month March being our next month, maybe it's by what you think you can deliver by week or by sprint, by what you think you can deliver by week or by sprint. And then you know work with product work with your engineering leads and start forecasting when you think you can deliver stuff by month or by quarter. Again, the further you go, the less certainty you have. But I think that's a really good metaphor that everybody understands.

Speaker 1: 19:02

We won't necessarily go down this road. So I'm maybe a little bit jaded on this, but I would give advice to the sales staff and probably advice isn't as strong enough but I would tell them to sell what you've got, Don't sell what you don't have yet. But I digress. So sometimes dates are a necessary evil and we have to, absolutely no matter how much engineers don't want to work with them. Sometimes we have to have them, Like in an instance where you have to be in compliance or the company is going to heap large fines for every month that they're out of compliance and you have to work with a date.

Speaker 1: 19:37

If you're at a startup, you have to make money quick and if the company runs out of money, well, guess what? You're not going to have a job anymore. So you have to work with dates in those sorts of situations. So maybe talk about how you have to work with with dates in in those sorts of situations. So maybe talk about how you have in the past communicated that urgency to the teams and gotten them to rally around and maybe discuss has there been a specific situation where having a hard date like that actually did create the focus and really got everyone working together in a much better way.

Speaker 2: 20:13

Oh, there's so many juicy things to talk about there, mark, but I think you hit on the one about focus right. Focus being a scrum value Teams kind of need to focus on things so it's kind of a bigger piece right. As an organization that went through a transformation this will lead to the answer to your question, I believe but went through a transformation and really leaned into objectives and key results. Now that's one of many platforms. There's evidence-based management, there's KPIs and some of those go together. But what we did as an organization is that the executives, on an annual and quarter basis, set their goals for the organization and those trickled down throughout the organization, to the business units, to the teams, and that was really important. So the team understood what is valuable to the organization and how what they were working on today actually contributed to quarterly and annual goals of the organization. They also allowed them to, and so we actually used sprinkles right. Sprinkles which really should be were increments of getting towards that objective or key result. You want to borrow from the scrum guide. I would say that sprint goal mapping to that OKR, that OKR is actually a product goal, right. A product goal exists for a period of time until you either achieve it or it's no longer valid. So that's how we did that and then understanding that the dates were important to the team and why they were doing it and what they were doing. It gave them focus.

Speaker 2: 21:39

The other piece of that of helping teams get focused and helping them drive towards state is getting them to understand their customer. Like I remember, I worked over a decade ago in a in an organization a government organization and it was a waterfall project and we we had some really great business analysts. I was part of the business analyst team. We had some great systems analysts and we wrote incredible specs and then hired senior developers and gave them a spec and a date and said go to it. We brought them in later.

Speaker 2: 22:10

I don't know. I suspect that it's as these teams were that I worked with that understand those goals. So when you're understanding what your customer needs, what your customer wants probably some of those goals are tied to revenue or, if you're in not-for-profit or government organizations, it's probably about your engagement of your users, your engagement of your community, less so the money. Understanding whatever those goals are and letting the team understand that They'll rally around a goal, they'll rally around a date and, to be clear, if they understand that. But if you also tell them we need this done, we'd like this done by this quarter, and they look at it and say no, no, no, that's too big. There's a big new architectural piece underneath that we need to deliver first, they can have those conversations. So you know, getting all of these people together, having those conversations, understanding what the organization wants, understanding how to get there, giving the engineering team input on the forecasted date, they'll rally around it. I've seen it. It's amazing.

Speaker 1: 23:17

So sometimes getting everybody together and explaining what is needed. I've seen and I've heard of cases where, when people start asking the hard questions about what is needed, why it's needed, sometimes the solution becomes much simpler, or I guess I should say the problem becomes much simpler, because you truly discover what really is valuable and what really is needed. We can paint this picture of we need this system to be in place, but do we really need a system? What problem are we trying to solve for a customer? And it may be a very narrow slice of what's needed by this particular date to get us over the hump. So, having those conversations and having team members being open enough to ask those hard questions, yes, you do have to get started and I've felt that before when someone keeps asking the questions and you feel tempted to say, well, we just need to get started, we need to stop asking questions. But sometimes the answer does lie in the questions that we ask that we don't need everything that we said we need.

Speaker 2: 24:21

Yeah, a hundred percent, a hundred percent. You're right on the mark.

Speaker 1: 24:24

All right, so I want to yeah, yeah, go ahead.

Speaker 2: 24:27

I just want to go back a little bit and kind of and repaint this picture that we started to. We've talked a lot about forecasting dates and I think that's really important. Those aren't the only. I don't want to give folks the impression that those are the only. That's the only important thing that we can take from project management. I touched on some of the others, but it's you know, you need to build relationships with stakeholders and leadership as a project manager. That was something that was ingrained in me. You need to understand what those folks want.

Speaker 2: 24:56

If we actually would have, if you're part of a PMO, you would actually have probably weekly or bi-weekly or some regular interval meetings to talk about your projects with senior stakeholders. Like you need to build those communications. It's not enough just to schedule a demo and see who comes right. It was part of your sprint review process. You need to learn what your customers value and sometimes it's because they're the ones that are using your service that you're providing to your product. So lean into those. Those are the things that, again, I think project managers just do inherently. And then, yeah, and then help your team understand how that work. What they deliver contributes to what leadership values and then give leadership what's valuable.

Speaker 2: 25:38

Don't feed them. Maybe a burn-up chart's not a bad. Burn-up chart's not a bad communication tool because it tells you how you're progressing towards a goal, but don't give them story point and velocity and other agile metrics that don't make sense. Give them the information that's valued to them and honestly, maybe it's because I was a consultant for 15 years and even as a consultant I dreaded the weekly status report.

Speaker 2: 26:01

You know what? I had two status reports for my teams. I just call them script reviews and I talk about what the team has done, what they've achieved, what our projections are and what some of our challenges are Like. Don't hide that, be transparent. But that's challenges are. Don't hide that, be transparent. But I think that those are some of the key things that I saw project managers doing really well. Some of those were in the project management body of knowledge that I studied back in 06. Some of them were just kind of learned on the job, but those are the ones. So I just want to say that it's not all about dates, as we've talked a lot about dates here.

Speaker 1: 26:33

Very good point. So are there lessons from project management and project managers can we take with regards to our views on leadership as scrum masters?

Speaker 2: 26:46

I've got it. So there's one of the leading thinkers and presenters in the PMI world and the Project Management Institute world. I think it's still doing it, but I actually got to see him. He came to Halifax a decade or so ago. His name is Neil Whitten.

Speaker 2: 27:01

One of his quotes just really stuck with me. He said as project managers, his slogan was if it is to be, it is up to me as the project manager. Project managers take accountability for things. All respect to Neil, because I think he was right in that format. I like to turn that a little bit and say to my scrum teams if it is to be, it is up to we. We as a team need to work together to achieve that.

Speaker 2: 27:32

Having said that, one of my biggest pet peeves in organizations and I can see my wife pointed out recently it's also in my personal life, whether it's family members or friends is when I see something that needs to be done in an organization and nobody's taking accountability for it. Maybe sometimes I jump in like a bull in a china chop and be like pull people into a Zoom room and say, all right, here's this problem. Pull people into a zoom room and say, all right, here's this problem. It's been sitting here for a while. Why is nobody working on it? And and and. Let's have a conversation. I could and I, I'll, I'll, do that in a, in a much politer way than that, but, like, I think, that accountability piece, you know, let's not just focus on our own teams.

Speaker 2: 28:12

One of the anti-patterns I think. I hate actually hate anti-pattern, but you guys already mean it's one of the bad patterns. Anti-patterns, I think. Actually I hate to say anti-pattern, but you guys know what I mean. It's one of the bad patterns. Anti-pattern sounds like jargon. One of the bad patterns I see some scrum masters doing is thinking that the service to organization part of their job, which is from the scrum guide, only means taking organizational blockers and working on those. It's not. It's fixing anything in your organization that could impact your team. And maybe there is another team that ideally you don't have a lot of dependencies, but you're always going to have dependencies. Maybe you've got a shared service team that's working on an architectural item that has a bug that is holding back your team and you see, nobody's working on that. I just you've got to get in there, you've got to get in there and do that and that's a project management skill set. That's a project management competency that I think we need to really lean into.

Speaker 1: 29:08

I've seen, as scrum masters, us focusing on the servant side more so than the leadership side. Yes, we are called to serve our teams, but not just be servants, but be servant leaders. So, if I may give an example, sometimes the team doesn't need coaching and doesn't need teaching, but they need mentoring. So I had a team that was an offshore team that was working with my company, and they were very frustrated because they were needed to get code reviews done and other members from other teams weren't giving them code reviews in a timely manner. Because of the culture in which they lived in and were brought up in and because they didn't work for the company they worked for a separate company they didn't feel comfortable asking for people to help them other than just saying, well, I asked for a pull request and nobody's gotten to it yet. So after a couple of attempts, I saw this wasn't going well. So what I did was I said okay, what I'm going to do is I am going to provide a model for you and show you how I think could be an approach. I would let them see me engage with someone else, and this is part of working remotely. If you're working in person, you could do it in person too, but remotely. I would reach out to a person and say this person on this team has a pull request and they sent it yesterday and we really need to have this code reviewed today in order to get this moving. And the response was well, I'm kind of busy today, so I'm not sure I'll get to it. So when will you be able to get to it? Tomorrow, tomorrow morning, tomorrow afternoon, yet tomorrow morning.

Speaker 1: 30:42

So the next morning followed up with a request. Hey, you said you were going to get to that code request, or that code review, this morning. How's it going? What's the situation look like? And it was like well, I've got something else to do, but then I'll get to it. Okay, so 10 o'clock, 12 o'clock, when do you think you'll get to it? And so I'm being a little bit pushy, but in a sense you kind of have to be pushy.

Speaker 1: 31:06

So what I did was I gave them a model to show, and once they saw how it was done and saw that it could be effective, then they could go forward and do it. The beautiful part of this story is they actually came up with their own method of doing it. So each sprint they enlisted a different person to be the nag, and so the person that was the nag was responsible for going to people and making sure that code reviews were done in a timely manner. It's amazing that once you start following up like that, that people's attitudes start changing. It's like you know. Do I really want to have George hound me about when this is, I'm just going to go ahead and get it done so I don't have to be hounded and things looked up a lot better. So that's an example of, I would say, of leadership and how, as scrum masters, we can be leaders for our teams without necessarily just bringing them donuts or scheduling meetings or things like that.

Speaker 2: 32:01

Yeah, not that those things aren't important. I mean, I remember I was in the office a few years ago, pre-pandemic, and our cooling system broke down and I went out and bought the team popsicles because it was hot. You should still do those things, but you're totally right, mark. Again, one of the things I hated about being a project manager was being the nag, and one of the criticisms I used to get was Andrew, you're too nice for this job. But what I've learned is actually nice is a superpower, because then, when you are starting to learn, lean in and ask difficult questions, they see that you're serious. So don't mistake somebody who's nice or somebody who maybe seems weak, as necessarily weak, because they may have some other skills, and I think that's really important.

Speaker 2: 32:49

I'll give you another example, mark. I know we're probably getting low on time, but also I'll be brief. Yeah, I've seen, like I, there's an example fairly recently where we had a critical bug that nobody was working on and I saw this. Well, actually, my, my product manager worked to reach out to me and made me aware of it and and nobody was working on it, and I believe, and so and I just jumped in and put a bunch of folks in a team and everyone was like oh yeah we'll work on this.

Speaker 2: 33:14

I believe that was successful because I took ownership. I took the risk. I think there's a lot of people see issues, bugs, whatever that situation might be, and be like I don't want to put up my hand first because if I'm wrong I'm going to own it. You know what we got to do that as scrum masters. That's part of the toughness of this job is sometimes we're going to take accountability for stuff to get it done and sometimes you're going to be able to take the blame. I believe, especially over a long career. But I've even worked with some incredibly young and incredibly talented scrum masters.

Speaker 2: 33:55

You kind of can build a sixth sense in your organization about what the right decision to make is. But just taking accountability and owning something just so that other folks have again I'll use the same metaphor have the cover, the protection to work on something so that if they do something wrong it's not pointed at them. Sometimes it's a perception in organizations that they're going to be blamed. Sometimes it's a handover from previous organizations who blamed. Sometimes it's legit. Sometimes you work in cultures that are blaming. But our job is to kind of get out there and take the risk. That is part of being a servant leader.

Speaker 1: 34:35

Well said, andrew. Well said Well. We are coming up at the end of our time and I want to give you a chance. So, andrew, if our listeners out there want to reach out to you, what's the best way for them to do that?

Speaker 2: 34:48

I'll give you two options. So I love connecting with fellow Agilists on LinkedIn. So, mark, maybe you can put my LinkedIn profile on the show notes. I will. I accept everyone. Feel free to reach out to me there. So I'm Andrew Mitchell. There's probably only one in Halifax, nova Scotia, canada, and that's a little beautiful part of the East Coast. And you mentioned my meetup groups Grumbeers Halifax. Look us up on meetupcom slash Grumbeers Halifax. It is mostly virtual. We do have some local events in Halifax, but we have been attracting a small group of folks from across North America and occasionally Europe. So we do two or three events a month, and one's a lean coffee where anyone can come in and ask questions, and I'm working on bringing in speakers to be interviewed. So check us out there, any one of those two places check me out, All right?

Speaker 1: 35:41

Well, this has been another episode of the Agile Within. It's been Andrew Mitchell and Mark Metz. Thank you very much and we'll see everybody next time. Andrew Mitchell and Mark Metz, Thank you very much and we'll see everybody next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, Mark Metz.