B (2:51)

You just do it a little bit harder, right?

C (2:53)

Yes.

B (2:54)

Right.

C (2:54)

Just to get more requirements and more planning more, but telling people what to do. And so I studied all of that. They'll stick. All of my project management credentials, applied it and it still didn't work. And I thought maybe I'm just not very good and maybe I wasn't. I was asked to go and be a Scrum Master, which I thought was just a fancy way of saying Project Manager. On this weird Scrum thing I'd been. I knew that Scrum was a thing. This was about 2008, right? So I knew it was a thing, but I didn't know what it was. So me being me, I said, sure, I'll do that. And I went off to be a Scrum. So it was an internal move, right. I didn't apply or anything like that. And so I went off and I was the Scrum Master now. Nobody told me what that meant, what I needed to do. So I went and researched everything I knew about Scrum and I was basically Scrum Project Manager, which is the same thing I was doing before, but just delivering in two week sprints. And I kind of went from there and slowly over time I evolved and sort of worked out what the role was. So it was a complete accident, but as soon as I did it, I realized, okay, this is how I want to be working a lot now. Makes sense to me.

B (4:15)

A lot of people have kind of shared a similar story. Some of them will say by accident or coincidence or I just got called into it. But one thing that you mentioned that is, I guess, slightly different, although I'm sure somebody has mentioned it before, at least I have, which is this idea of becoming the Scrum Project Manager. And you know, to be fair, one of the creators of Scrum, Ken Schwaber, did write a book called Project Management with Scrum. So he called it Agile Project Management, but if you're from the outside, you don't really know the difference. So to be fair, our community has made a disservice to the Scrum Master role by On Purpose Mixing Scrum and Project Management in the same book title.

C (5:02)

So it has, it has. But to be fair, and I don't know whether that was the book that Mike Beadle co authored or not, but Mike was a good friend of mine and mentor of mine and he said to me that wasn't the title, but I think it was the publisher who wanted to put that in to sell more. So they didn't want to call it that in their defense, but they wanted book sales, so they went with it. So, you know, there's always a balance of being open.

B (5:28)

We need to kind of adapt, right? Like, it's not necessarily wrong. It's just project management was and some would argue still is the dominant work management approach in software companies. I think it's a mistake, not because project management is bad in any way, I just think it's inadequate for software. We'll talk more about that this week maybe. But independently of that, as Scrum Masters and potentially as early on the career or in the career Scrum Masters, we also make mistakes, right? And today we want to explore one of those. Karim. So share with us the story of that moment, that hard moment you went through as a Scrum Master and we'll talk about the learnings and what you do different these days later. But tell us that story first.

C (6:17)

I've been quite open about this. So firstly is there are a lot to choose from when you ask that question. Certainly in my early days, probably still now. So the one I'll say because it was probably quite an impactful moment for me and my growth and my development in the role. So I mentioned I was the kind of Scrum Project Manager, you know, I was, I was a kind of a mix of a Scrum Master. I was, I got very knowledgeable about Scrum, you know, and I devoured all of the literature that was out there, which wasn't loads back in 2008, 9 but there was some stuff, right. And I devoured it. I learned about Scrum, I learned about the broader Agile movement, you know, extreme programming, explained that some of those early testing books. And I went super deep into Scrum. I even went super deep into Lean and the background of it. And I was like, I know this stuff inside out.

B (7:08)

I'm.

C (7:09)

I'm great. I've mastered this thing. Like I mastered project management, you know. And what I found was I was basically telling everyone what to do at every point. This is how you write a user story. This is how you split a user story. No, your board should look like this. You've got this column wrong, right? Why aren't you doing that? Right. But it was kind of working, right? Everyone was just kind of doing what I said and we were flowing along and it was all right until I went away. Until I went away for a couple of weeks and I came back and the team had fallen apart. Like they just did nothing that I wanted them to have done. They were just, they were a bit of a train wreck. And I remember thinking, what's wrong with these guys? You know, like I kind of told them everything that they should do. I went away and they didn't do it. And it was by pure chance and I, I will call, call him out because it was impactful and as a Londoner back in the sort of, that, that time there was a thriving meetup scene and I would, because I was, I lived on my own. I was young, free and single back then. I didn't have daughters, I didn't have a wife. You know, I just, nobody missed me if I didn't come home after work. So I would always just go to all the, I'd go to like one, maybe two a week. And the community was small, so you'd get like really great speakers, as I'm sure you do now. Right, but you get speakers who are keynote in conferences, who'd written books. And I went to a session, I think it was the Agile Coaching Exchange here in London, and it was Jeff Watts giving a talk. You know, he's a friend of mine now, but back then I didn't really know him. And he gave a talk about coaching and how your job as a Scrum Master is to enable the team to be more effective, not to tell them what to do. And he talked about all of these techniques and it was a real epiphany. I was thinking to myself, I don't do any of that. I've been telling them what to do and really what I should have been doing is helping them be a better team such that they know what to do. I wasn't growing their capability at all. And that was a big moment for me. I actually went and spoke to him afterwards and I like this stuff. And we had a little chat and he just finished his barefoot coaching, you know, his coach training, which I then went and did in 2011, I think. And I realized there's so much more to being a Scrum Master than knowing about Agile. I learned about team facilitation, team coaching. I learned about the sort of the psychology and the human side. I learned about all of these other things, how to design an engaging retro. I'd been so narrow in my focus. I'd ignored all the other areas, organizational change, coaching, mentoring, teaching. And the team was just basically doing what I said, right? And as you know, that's a dangerous thing. So that was that sort of moment of failure, me coming back, the team having fallen apart, me then going to that meetup and realizing, oh man, I'm really not very good at this. Yet. And it broadened my horizons so much I just went off and studied, studied, studied for the next decade to try and get good at this stuff, right? And so if I, if that hadn't happened, I don't know, maybe I'd still be telling people what to do.

B (10:20)

Maybe it'd still be a Scrum project manager.

C (10:23)

Maybe. Yeah, maybe.

B (10:25)

And actually this is a great story because it kind of illustrates one of the critical aspects between project explicit difference between project management and agile. And Agile comes from the perspective that we accept that work is being done typically in software, although Agile is applied elsewhere. But if we stick to software for a second, work is being done by a lot of people that need to interact. And we Scrum masters, product owners, stakeholders, we don't know how they need to interact, we just know that they need to interact.

A (11:00)

And we also accept that only they.

B (11:02)

Know when and why they need to interact. And that type of management is completely different from the analytical break things down into constituents, smaller tasks that project management brought with it. Let's not forget project management comes from the late 19th, early 20th century. So a totally different reality than what we have today. And I think that what you're bringing into this story, like the idea of coaching, facilitation, organizational change, people systems, socio technological systems, these are things that were not there when project management was developed. So it's quite natural that when we start adopting Agile from a project management background, like I did and like you did, we don't bring that with us, but we do need to discover it and we do need to apply it because it is about working with social systems in the end with people.

C (11:53)

You're right. And it's such a different skill set. You know, I still teach Scrum and I still get people saying, where's the project manager role? Or is the Scrum Master the project manager? And they'll say, look, I even sort of designed an experiment. Now we're mapping traditional project management and it's like we've pushed a lot of that down to the people doing the work. Because the more complex the work is, the more you need the people with their hands on the keyboard, mitigating risk, technical risks, business risks, right? And doing the planning, doing the collaboration, deciding who does what. We push that down to the people who have the information and we create the environment and it's just a completely different skill set. And you know, the, actually the product owner is closer to the project manager for me. And it's not even, not that close. Right. So I kind of, there's a lot more that maps to that side of things. And so I, you know, I don't, I'm not anti project management. I think it's a tool, it works in a context. And this is a tool, it works in a different context when the volatility, the complexity, the uncertainty is higher. We need to take a different approach. So big learnings, steep learnings, and I think those learnings continue. But you're right, one is designed for a different type of work. And I think once we realize there are different types of work and we need to use a tool that's appropriate for the context in which we're working, I think then the conversation becomes a lot easier. It's not good versus bad, it's just here's where we are. What's the best tool for the job?

B (13:24)

And I do want to say and call out the enormous and positive contribution that the project management community has brought to knowledge. I mean, let's not forget that simple things like stakeholder management were introduced by the project management community. Although they were not the first ones to talk about it. They institutionalized and industrialized that approach. But it is, as you say, a completely different skill set. And for those interested in knowing more, there's a couple of episodes where we interviewed David Marquet, perhaps one of the most enlightened leaders of this new way of looking at how to manage work. So check those episodes out. Karim, thank you very much for sharing that story with us. You're welcome.

A (14:08)

All right, I hope you like this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those deep.

B (14:47)

Dive interviews as well.

A (14:49)

Agile Business Intelligence, creating product design visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars, It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrum mastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great.

B (15:51)

It's important.

A (15:53)

But doing it together, that's next level.

B (15:56)

I'll see you in the community. Slack.

D (16:00)

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.