Lindsay Velecina: 0:00

Ryan, welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Ryan Ripley: 0:20

Hi everyone. I'm Ryan Ripley with Agile for humans and professional scrum trainer with scrum.org I'm stepping in as a guest host for episodes highlighting the experiences of other scrum.org professional scrum trainers. I hope you enjoy getting to know these amazing people. All right, welcome. It's another episode of becoming a scrum master. I'm your host, Ryan Ripley, this week, we are talking to Matt Dominici. Matt is a fellow PST. Did we do our TTT together?

Matt Dominici: 0:48

We did, yeah, way back in 2017 maybe 2016 or something like

Ryan Ripley: 0:53

that. Quite a while ago, Matt and I went through the process of becoming a PST together, but before that, we were both Scrum Masters, and that's what we're chatting about today. So Matt, let's get right into it. Can you share the story of how you first encountered Scrum and what motivated you to become a scrum master? Was there a particular moment or experience that sparked your interest?

Matt Dominici: 1:14

The last one is interesting, I think was like a series of sparks over time that kind of led me to to where I am now. I think I started the first kind of stab at this. I was a QA director at a time, at the time, head of a QA team getting squished and dumped on all the time. It felt our job was to, like, throw the brakes on every single project that came our way so we could have some semblance of hope of putting something of quality out. And it wasn't really working that well. I had heard of Scrum from like a colleague at a different company. I never really tried it. So I went out and I took a class similar to PSM, maybe one of the letters was a little different. And so I took the class. I read Scrum and XP from the trenches, by Henrik Nyberg, which really helped solidify my understanding, but also my appreciation for what this whole Agile and Scrum stuff was. So at this point, I had a QA I took it upon myself to make the company go Agile. And the problem is, I took a very like academic approach. So I put together some slides, I wrote a bunch of papers explaining how awesome this newfangled thing was, and I was at the point where I was about to get all of the engineering managers into a room and walk them through what I thought was going to be my beautiful presentation, and the CEO caught wind of it and just shut it right down, just like, don't, you're not doing this. And I was super upset. But he was a smart guy. He was right, like he knew I was about to go and get myself killed. I was going to go and tell everyone they were doing everything wrong, and we had to stop everything, and we had to start doing everything differently right off the bat. And blah, blah, blah, blah, blah, he was right about that. In the long run, though, that that company failed, just as I did, the interesting story, they dwindled, and eventually a competitor sued them. They got acquired for paper. It was this whole thing. But the lesson in that for me was, one, this is hard. And two, change management is a thing, right? You can't just throw a bunch of stuff at people and tell them to do things differently. So that was my, you know, doing Scrum in the worst possible way, or trying to force scrum in the worst possible way.

Ryan Ripley: 3:20

So then why come back to it if it didn't go well, what was the hook?

Matt Dominici: 3:24

So the hook for me was, in part the book, so that the XP and Scrum from the trenches, or whatever it was called, that really sunk, sunk its teeth into me. And I was like, the approach wasn't right, but I was still a believer, and this is probably a better way to do things, rather than either total chaos or waterfall or whatever. And so I made a note of that. I took my lumps, and I kept my eyes open for scrum master job postings. And I was like, I'm gonna just become a scrum master. So I left the management role behind. Realized I had a passion for this scrum thing. So I was like, I probably need to leave this behind and go deep into that. So left management, became a scrum master at a different company. And now this company was already at the point where they stated that they wanted to go scrum in particular, and so that was a nice place to land. We formed, like a really small group of Scrum Masters. I was the first, I think, outside hire as a scrum master that everyone else was like internal. We had one person that was a developer, we had one person that was from QA. We actually had a salesperson that joined the scrum master team, which was an interesting, different topic, but worked out pretty nicely, and we worked together as a group. And the second spark for me was we got together and did a book club on succeeding with Agile by Mike Cohn, which I think is maybe a little bit dated now in some of the specifics, but it still mostly holds up, similar to the Nyberg book. And so we did a book club on that, and we just started doing some of the things that we were learning about together and over time. Time we started to develop this reputation within the company as kind of a group that could get things done and not just complain about stuff. And so that was a nice place to be. And as that reputation grew, I decided to spend some of my trust capital. I guess you could say there was, like, this really large impediment in this company around releasing, and this was a SaaS company, so like, releasing is important. It was infrequent. Took a lot of time. Was, like, really expensive just to get a release out the door. And so I spent the time to make the case that we actually needed to spend some time and money on fixing this. So I was still a scrum master for a team, but I started doing some digging, and I started going to all the other teams and talking to people. Actually became the release manager to embed myself and this stuff. And so I sat with every person involved in a release, from top to bottom, developers, QA people, the ops people, everyone in the company that had something to do with a release. I just wrote everything down, wrote what everyone was doing to get a release out the door, and I calculated the cost of a release and how much time it took. And it was a crazy amount. It was like, hundreds of 1000s of dollars, like, not even including the cost of the actual development work that was going into this stuff. So now I had stories from people, and I had a bunch of data, and I took that to the leadership group and basically got some buy in to spin up what we call the Dev Tools team. That's probably the wrong word for that kind of a team, but like a team that was focused on solving this problem, and so I became the product owner of this team. So I'm still scrum master. Scrum Master was still my job title, even scrum master for a different team, and became the product owner of this sort of Dev Tools team at the same time. And we had a pretty clear goal and mandate was to help teams to ship faster, safer, cheaper, more frequently, all that kind of good stuff. And over the course of a year or two, we chipped away at it. I did a lot of what I didn't really realize at the time, but was product management type work. I was doing user research. I was like talking to the developers. I was talking to the ops people. I was discovering the actual pain points that existed for all the people that were involved in this, and based on that, and working with the team, devised a strategy. We came up with a roadmap with input from the team and others, and drove it that way. We, like did a lot of cool stuff. We sent people from our team out on what we would call a safari. We would go, send someone from our little Dev Tools team to go sit with the scrum team for a month and actually work with them and live in their world and feel their pain and all that kind of stuff, and then come back to our team with some new ideas. And so this went on and on for, yeah, probably a couple of years. But by the end of it, like we had reduced the time and the cost to do a release by a factor of 12, or some ridiculous amount, and got to the point where, okay, let's release every month. Let's release every week, two times a week, every day, multiple times a day, by chipping away at some of that, and I'm hand waving over like a lot of the technical stuff that had to be done to enable that, but that whole experience was that kind of big spark that helped me realize how important the scrum master accountability really is like without it. Before that scrum master group got there, nobody was really taking ownership of the problems. Nobody was spending the time to do the research, to make the case, to actually make something happen. There was a lot of complaining going on. We knew there were lots of problems, a lot of venting sessions and that sort of thing, but no action. And so that kind of sparked me to where I am now, right? Just helping people understand that the scrum master role is it's a critical leadership role. It requires action. It's not just updating and calendaring and all that stuff. It's actually quite, quite a lot more than that.

Ryan Ripley: 8:53

Yeah, I like how you transitioned right into the next question. So it looks like we were going to ask about a project or situation where you had in a eureka moment. It sounds like this Tools group was that eureka moment for you as a scrum master, and it showed you that value. And so now I'm curious how has your perception and execution of the scrum master role evolved, and are there aspects of the role or accountabilities that you view differently now compared to when you first started?

Matt Dominici: 9:21

Yeah, for sure. You know, this has been like a big topic as of late to, you know, can managers be a scrum master and all that kind of stuff? And my view on all that has changed quite a bit. It may not be quite the question you're asking, but I feel like if I could go back in time and go back to being that QA director that I was, however many years ago, that was with the experience that I've had being a Scrum Master, I think it'd be a lot more effective as a manager with all of those tools. Sure. So I don't know if that's like necessarily a change of perception on the scrum master role or accountability itself, but more of a like the impact of it is more far. Ching, I think that I initially thought,

Ryan Ripley: 10:03

Oh, it's great. So what advice would you give to someone who's aspiring to be a scrum master? Is there a particular mindset, skill or habit that you believe is crucial for success in this role? Yeah, the

Matt Dominici: 10:17

first one is what I said at the top, you got to be okay with failure. You're going to take your lumps. And if that really scares you and you're not okay with that, might not be the role for you, might not be the accountability for you, because it's it happens a lot in the beginning, but it also happens throughout your journey, right? You're never you don't have all the answers, so being okay with that is really important, I think, kind of broadening your view beyond just Scrum and Agile, I think, is really important too, and getting into just straight up leadership and management type things, right? Throw a couple of other books at you. First break all the rules if you have that one, oh, there we go. It's not the one book that everyone should read, but it's, I think, one that Scrum Masters should read. It's nothing about Scrum. It's nothing about agile. It's about management and employee engagement and all that sort of thing. But that's a tool that I've relied on a lot as a scrum master. I think another one would be probably the responsibility process. I think that's actually true for everybody. That matter if you're a scrum master, Agile coach, if you're just like a person in the world trying to get things done, responsibility, process is like, a really core thing. It's a simple concept, but there's a lot to it. So it's probably worth, worth reading the book and being able to lean on that.

Ryan Ripley: 11:32

Yeah, Christopher Avery's Great. His work is, I've been through a lot of it, and definitely beneficial, especially when you decide to apply it. So it works really well.

Matt Dominici: 11:42

Yeah, that's the thing. It's like deciding to apply, but also catching when you should apply it, if it's only moments where it's like, something happened three weeks ago or a month ago, and I'm like, I didn't do the thing. I just stayed in the bottom of the I stayed in denial. Didn't really get to action.

Ryan Ripley: 11:56

Matt, I appreciate you doing this and for being here and for talking through all of this. Is there anything that you would like to promote or put in front of the audience before we wrap this up? Yeah, I think

Matt Dominici: 12:07

for now, just look me up on LinkedIn. I don't think there are any Matt Dominic's besides me on LinkedIn, so just find me there. We've got some new things cooking. So we'll have some new websites and that sort of thing up. If you go to YouTube, you can look up impact agility. That's going to be the name of the new sort of venture here, bunch of content coming out there over the next little bit

Ryan Ripley: 12:25

cool. All right, Matt, thanks for doing this. Great talking to you, and hope we can do it again soon.

Matt Dominici: 12:30

Awesome. Thanks, man. You