Joining an existing team as a new scrum master with Matthew Venamore

Matthew Venamore [00:00:00]:

As I'm going along on having a look at this reminding myself of what the elements are in the scrum guide and using that to come up west doing things really well and making sure the team know where they're doing things really well and then also finding those areas for improvement as well or suggestions for improvement. So they’re the two things really is just listening, letting it sit in, and comparing that against the scrum guides to work out where we can improve things.

Neil Benson [00:00:30]:

Welcome to Amazing Applications. Hi, it's Neil Benson from Customery. It's great to have you join me. Thanks so much for downloading another episode. Today, I'm gonna be talking with Matthew Venamore. He's a Dynamics 365 scrum master. He runs his own consultancy business called Empyrics, and he's based here in Queensland. Matthew and I worked together for over the years at the Royal Automobile Club of Queensland. And recently, he stepped back in as a scrum master with one of my teams. And I wanted to find out from Matthew what's it like diving back into an existing team that's already been going for several sprints and are partway through a project. This is episode 144. You'll find show notes with timestamps, a transcript, and other resources at amazing apps.show/122. Let's meet Matthew Venamore.

Neil Benson [00:01:22]:

Matt, welcome to Amazing Applications. It's great to finally, finally have you on the show. 

Matthew Venamore [00:01:26]:

Yeah, yeah. I know we've been talking about it for a few years I think actually.

Neil Benson [00:01:30]:

Yeah, that's right. So we wanna get right into it. You know, you and I have worked together for three or four years delivering Dynamics 365 and Power Platform applications. You've recently joined one of my teams as a scrum master into a preexisting team. What's that like? What’s it like coming in as a new scrum master into our preexisting team? How have you found it so far? 

Matthew Venamore [00:01:50]:

It's always challenging because one of the outcomes that I always try to achieve as a scrum master is to have an empowered team. So coming in and identifying all the things that need to be changed, it is not a great way of doing that. I don't think them. So a lot of it is it's a very sort of standoffish stance that I take when I go into that sort of position because I've done it in this role and my last role as well. So it's really just sort of giving yourself a few weeks to step back, understand the team, understand the people, how they work, and those sorts of things, and just allowing them to sort of keep doing what they were doing just so you can observe really and, you know, use that as an observation period to work out better ways of doing things or ways that you can add the most value to the team. 

Neil Benson [00:02:37]:

So you don't recommend just diving into the first sprint planning meeting and driving it to an outcome and telling the team what to do and just set better goals and things? 

Matthew Venamore [00:02:35]:

No. That all comes with time definitely because I think if you sort of come in and you sort of start even with just making suggestion up to suggestion of, you know, changes, changes, changes, improve this there, all those sorts of things, I think you would tend to come off as not a servant leader more as a leader of trying to drive the direction rather than being the person that has just support them in that approach. So it's a — I think a more scrummy sort of way of approaching it.

Neil Benson [00:03:18]:

Do you have a like a checklist or a framework in mind whenever you're to assess a team's current performance, find out where their weak spots are, where their strengths are? Or do you just use that time to observe and let that information flow into your head and seep into your consciousness before you take any action? How do you approach it? 

Matthew Venamore [00:03:37]:

Yeah. It's a bit of both, actually. Little from column a, little from column b. And so I constantly like, even at the moment in my other browser session, I've got the scrum guide sitting there. I refer back to that more than you would probably think, even though it's short, that scrum guide, you know? It's only 13, 14 pages. I still don't know it back to front. So I do like using that as my framework. So I keep when I then have that first period of observation. that's just what I'm comparing everything against really. So, yeah, you're right. Just letting all of that information feed in and sort of settle into a position so that you can make a proper assessment of where things are at. And as I'm going along on having a look at this reminding myself of what the elements are in the scrum guide, and using that to come up with we're doing things really well and making sure the team know where they're doing things really well and then also finding those areas for improvement as well or suggestions for improvement. So they’re the two things really is just listening, leading it sink in, and comparing that against the scrum guide to work out where we can improve things. 

Neil Benson [00:04:44]:

One of the things you did recently was take the team through, really, like, a scrum basics. Here's the framework. Here's all the components of it. I like that because it was your point of view. Here's I love some of your the language, like Agile doesn't exist to me. There's scrum. Agile is a dirty word in your mind. I remember that from the presentation. And it just sets the team in a really good level playing field. Some of the members of the team have been practicing scrum for four or five years, others for a few months. Some of them are certified, some of them are not. And it just gives everybody a really good baseline to — so this is how Matt understands the framework and would like us to continue to apply it. Brings everybody up to that similar level of knowledge. 

Matthew Venamore [00:05:21]:

Yeah. Exactly right. 

Neil Benson [00:05:22]:

Is that something you've done before? Let’s just kick off with that.

Matthew Venamore [00:05:38]:

Yeah. That — it's something that I tried to do. This time, I actually did that a little bit differently than I have done before. Normally, it's a I do a much bigger, longer presentation on, you know, it's almost the half-day introduction to scrum sort of seeing, which I think is becoming a little bit more overkill the more people have become familiar with scrum and how it works. So, yeah, I actually chose to sort of make it a bit leaner this time and just focusing on the framework, all the different elements of the Scrum Guide, different events, and etc. etc. and using that as a bit of a launching point to remind everybody of this is sort of the ideal that we're trying to achieve from scrum, and we've got a way to go in this area. This other area, you're doing maybe a little bit too well. I don't know if you remember that that courage section, yeah, team taking on way too much work every sprint and never delivering it. I think it's just a good — because even though that scrum guide’s like, only thirteen pages, that's not much to it, there's still a lot to it, if you know what I mean. It takes a lot to understand it and apply it well. So, yeah, that's why I actually thought that this time, it would make it better to just provide that view of these are the elements that we're trying to implement, values, empiricism, and all those different areas and just focusing on some of the ones that we probably need to improve on a little bit, I think. Yeah. And, like, I think it gives a much better level playing field to everybody to sort of do a little bit of a reset. And I think even over time, like, you know, when we're working together on RACQ, it went for a couple of years, now there was a couple of resets that we needed to do to sort of get everybody focused back again to say, “Let's get back to basics and make sure we're delivering it well.” So yeah, I think a refresh on the idea of what it is. So there's while we've got this framework, it is just a framework. What we're delivering is a product, which is what takes most of the time on everybody's day. So everybody's not always thinking about the framework in which we do it. Yeah, so I think that provides a simpler base layer for us to then be coming back to. And for me, from a coaching perspective, that then allows me to say in future like, do you remember these elements? I don't know. We could pick one of the values of openness, perhaps, you know, make sure we're being open. It allows you to just refer back to that a little bit more simply, yeah, and trying to keep it as simple as possible, knowing that people are trying to deliver a complex product all at the same time. 

Neil Benson [00:07:54]:

Yeah. 

Matthew Venamore [00:07:54]:

That's my thinking there. 

Neil Benson [00:07:56]:

Yeah, you brought up an important lesson there that even over a long period of time practicing scrum, teams can drift away from the original framework. They introduce some of their own technical practices, perhaps. There are new stakeholders that come and go, maybe some changes in the team composition as well. And suddenly, we have 20-minute stand-ups instead of 15-minute daily scrums. And we wait for the scrum master to arrive before we kick off the daily scrum. And just some little unconscious habits I think can creep in. 

Matthew Venamore [00:08:22]::

That's right, yeah. 

Neil Benson [00:08:24]:

So that reset, even for a long-running team, can be a really helpful mechanism just to get back to the basics.

Matthew Venamore [00:08:28]:

Yeah, absolutely. Absolutely. Yeah, yeah. Like and it is part of the coaching element, I think. You know, that's a nonstop art of being a scrum master. It's not a day goes by I don't think where you sort of don't really need to remind someone to say whatever it might be, make sure we're being empirical about this or whatever it might be. So it's an ongoing process as well so.

Neil Benson [00:08:52]: 

So you don't find there are some people who would say that the job of a scrum master is to work themselves out of a job to set up a team that is self-managing and can handle itself and doesn't need a scrum master anymore? Why would you need to have a scrum master once the team is up and running? What would you say to that challenge, and why does the need for a scrum master perennial rather than acute? 

Matthew Venamore [00:09:12]:

Yeah, I agree with it. Like, that is your goal. If you can get to the point where you're not coaching the team and they do understand the framework and they understand the reasons behind the framework, they're applying it and they're building a beautiful product with lots of value in it, yeah. Job done. You can sort of take that off and say, in an ideal world, that's where you'd love to get to as a scrum master because you've then achieved your goal. But reality being different to ideal, it's not quite as realistic as that, I think. But, you know, it does leave — so if you've still got that scrum master role, there's still other elements of value that you can provide because it's not just to the scrum team. You've got your other responsibilities, you know? You're assisting the product owner to help come up with ways of managing the backlog. You've got the responsibility of advocating scrum to the rest of the organization. So, you know, whether that's advocating a Nexus be set up, etc, and those sorts of things to the organization as well. So if you do get to the point where the team have taken on that scrum framework and are really living the values, that can open up some time for a scrum master to start focusing on some of the other responsibilities as well. So, yeah, it's not just around that scrum team.

Neil Benson [00:10:27]:

I liken it to, you know, a professional sports team. You know, the best rugby teams in the world or soccer teams in the world or whatever sport or even, you know, golfers or tennis pros, they might have been professionals since they were teenagers, and here they are in their mid-twenties or thirties or forties and they still got a coach. Why? Because there's always something to improve. There's always something you need to remind them on, some mindset things, some technique things. And their life has changed. Their competition has changed. And the same in our scrum teams, you know? The competition of our team has changed, the environment changes, the stakeholders move on. So we always need that coaching continually, I reckon. I love your aspiration of working your way out of a job, but I don't think we're gonna be getting rid of you anytime soon.

Matthew Venamore [00:11:06]:

No, no, no. I don't think so either.

Neil Benson [00:11:09]:

Do you think there's any difference about being a scrum master for a business applications team compared to applying the scrum framework and being a scrum master of for a team building some of their corporate product, particularly custom development, which is where scrum's origins came from was the development of custom software? Do you think configuring and deploying business applications is that much different? 

Matthew Venamore [00:11:28]:

No. I don't think so. You know, really from what I've seen and most of my scrum master roles have been in the Power Platform and Dynamics. I've already done one that wasn't, and it was web-focused. I don't notice too much difference. You're still using — like the team still use very similar concepts, right? Like, to deliver that, you know, we'll have CI/CD pipelines to deliver it through. You know, that's how we actually move out value through our quality process and things like that. So a lot of the things, not that different, to be honest. It might have been different in 10 years ago when I first started in Dynamics, way a little bit different then because it's matured a lot as a product. Our app makers can start deploying their own pipelines and, you know, it's really matured over time. And I think what we are trying to really do with the scrum framework is to deliver really great value, something that means something to the business and drives those outcomes. So, no, I think it's quite similar role. If I went to another role and when I was doing this web role, I was using all the same tools, all the same approaches, trying to adapt the mindse for people. And yes, very similar.

Neil Benson [00:12:50]:

I've had a couple of conversations recently with people who say that scrum and business applications shouldn't or couldn't or can't go together. And I don't really understand their perspective because I've seen — I haven't, like you, I haven't used scrum outside of business applications much at all. But I've heard and I've seen I’ve read case studies of it being applied in all sorts of industries and sectors and with all sorts of teams building all kinds of complex products, not just software, but educational programs or marketing campaigns or school curricula or whatever it might be. And for those folks who are struggling to apply it to business applications, there's a mindset thing we need to unlock. 

Matthew Venamore [00:13:26]:

Yeah. I was just gonna say I think it's a mindset probably and also not understanding the Scrum framework and what it's trying to achieve, you know? It's trying to achieve value through empiricism. You can sort of summarize it as that. So if that's not what you're doing, then you're not really doing scrum. And so you probably just haven't applied the framework particularly well, I think. Yeah, so that's my thoughts. 

Neil Benson [00:13:48]:

I've heard that rebuttal as well. So, yeah, some people have maybe worked on a scrum project, and it hadn't gone so well, and they blame the framework. And the people who love practicing scrum would say, “Oh, maybe you weren't applying it properly,” which is always our best defense, right? Don't blame the framework. Blame your application of it. And yeah, I can understand that would be annoying to somebody who's, you know, recovering from a horrific project where they felt that scrum was a hindrance and not a help. 

Matthew Venamore [00:14:21]:

Yeah, definitely. I think everybody's been through a horror project at one point or another, so there's nothing that will heal those wounds. 

Neil Benson [00:14:18]:

So in terms of — you touch there on understanding the scrum framework, how important is it, do you think, for product owners and developers in the scrum team to take scrum training to get maybe certification? Have you seen that work really well and they become a lot more productive and the contribution become a lot more valuable because I've had that training certification? Or is it more of a tick-box exercise to boost the value of your LinkedIn profile and move on to the next role? What’s your thoughts on training and certification these days? 

Matthew Venamore [00:14:48]:

About the certification part? Yeah, now I love getting certifications myself because it's good to advertise that I do know most stuff. I passed these difficult exams, and, you know, I know my stuff in order to pass those exams. But I think the training element is key. As we mentioned before, just a short refresh sessions just to set the groundwork of what it is that we're trying to work with here really are very critical to understanding it. I think that session I ran was only an hour or two hours. You know, digging down into the details of how it can work and giving lived sort of examples in training of how it works is really important because a lot of the questions — and I think I got one just last week, someone in the team asked, you know, you keep saying these things about how a daily scrum should be run and can you where you're meant to focus on your sprint goal and how you're gonna get there by the end of the sprint. One of the questions I got was, “Can you give us an example of a daily scrum and what the discussion should be?” and things like that. And so, you know, I think training can help with those sorts of things to run people through those examples of this is that sort of thing that you do in your daily scrum. This is what you're doing in sprint planning. And also trying to instill that level of understanding of empiricism, which is really key to all of it. And that's not something you can just explain in a sentence. You really need to understand the value that empiricism itself brings. It's not just a simple click the switch to turn someone's understanding on and to see the value of that. So they're the sorts of areas that I see in training becoming really valuable in. We had that conversation the other day of I think it'd be really great to have a full team training. So when you're kicking off that product with the team on that training course of scrum with lived examples and put them through those so that I can actually see it work and see what we mean when — and it makes that team a little bit easier to coach then because you're just reminding them of the things that have previously been through and things like that. Yeah, so training, yes. Certification, if you want to. 

Neil Benson [00:17:07]:

Yeah, okay. Yeah, I feel like it's the same way. I don't know if you remember, but we did record a couple of our daily scrums when we worked together in the RACQ project. A couple of the odyssey teams, we were in one of the meeting rooms, and we recorded them. So those are available as an Amazing Applications back catalogue somewhere. I'll put a link to that episode in the show notes for people who want to —

Matthew Venamore [00:17:26]:

Completely forgot. Thank you, yes. 

Neil Benson [00:17:27]:

Yeah. We wanna listen in on a Matt Venamore-facilitated daily scrum. It's a few years ago. I don't think we did sprint planning or sprint review retrospective live recordings. Those meetings tend to be a little bit longer than 15 minutes. 

Matthew Venamore [00:17:40]:

It’s a little bit longer, yeah, yeah, that’s right.

Neil Benson [00:17:43]:

Yeah, I can think sharing, you know, if you have a coach or trainer who's got those real-life examples, that's critical. And that's one of the reasons I enjoy delivering training to the business applications community because there are some great scrum trainers available. Some of them are also Microsoft MVPs, but none of them have got business applications experience. And so when people go on a two-day training course with a certified scrum trainer or professional scrum trainer, that trainer is unlikely to have ever heard of Dynamics 365 or the Power Platform and has no examples to share with you. 

Matthew Venamore [00:18:12]:

Yep, yep. 

Neil Benson [00:18:12]:

So, yeah, it's something I would really appreciate working through with with our community is sharing those examples. That's why we love to have guests on the queue to give us that real-life experience. 

Matthew Venamore [00:18:23]:

Yeah, yeah, yeah.

Neil Benson [00:18:24]:

We talked about scrum masters joining a new scrum team. What about the experience for product owners and developers when a new scrum master joins? What can they do? What should they do? Should they be on their best behavior for a couple of weeks and try and fake it while the new scrum master’s assessing their performance or?

Matthew Venamore [00:18:41]:

Now that I've let the cat out of the bag on observation.

Neil Benson [00:18:45]:

What can they do whenever a new scrum master joins the team to really help that person be successful and really which will lift hopefully the performance of the whole team?

Matthew Venamore [00:18:53]:

Yeah, I think the answer is transparency. Just keep doing what you were doing just so that you get to see how you work. It is the main thing, yeah, because that's what I want to see as a scrum master is, you know, knowing how you do things at the moment because — and it's not so much about the how they've implemented the framework, but it's just a really good way of getting to know the people in your team and seeing how they work because that's sort of something that sits outside the scrum guide. It's more of a leadership thing in terms of understanding who it is on your team, understanding how they work, their preferences, things that they do because of their personality, which is all fine, and they're all the things we really need to work with. So yeah, just being yourselves, being transparent is key to that, I think. And yeah, probably after that, being a bit flexible in terms of how we deliver our product. 

Neil Benson [00:19:55]:

Okay. Have you ever encountered a team that is maybe a bit resistant or skeptical or bitter, and you've had to work really hard to dig them out of a dark place?

Matthew Venamore [00:20:04]:

Yes.

Neil Benson [00:20:05]:

Or find yourself being pushed away by a team who doesn't really appreciate this command's just help? Any challenging situations you found yourself in? 

Matthew Venamore [00:20:12]:

Yeah, definitely. Definitely. It's —

Neil Benson [00:20:14]:

Sorry. I don't mean to bring up bad memories.

Matthew Venamore [00:20:20]:

It's alright. I'm good to talk about it now. It's a couple of years ago. No, just kidding. There's some people who — and it's one of the reasons, like, as you said before, like, that I struggle with the term agile and people who have say, oh, no. We're being agile. Really? You're probably not because you just used that word.

Neil Benson [00:20:38]:

You don't like the word, I know. It's funny.

Matthew Venamore [00:20:41]:

it's even more difficult to get those people to change their mindset than people who would just prefer to do waterfall. It was a couple of years ago now. And we're a federal government organization and had all of these processes around agile, and none of it was delivering value in the way that you would expect the scrum framework to deliver it in. So people were very resistant to do it, like where I did that sort of reset thing. Again, saying, you know, this is what we've got, this is what we're working towards, these are the areas that we need to improve on. And they were, yeah, very resistant to it. It's probably a cultural thing that I came across there. And apart from me and one other scrum master who was there, who was he was awesome, and he kept hitting the same thing. Like from a cultural perspective, there was no support from the executives, and therefore the teams felt like they weren't supported. So it was very difficult to manage that situation from a cultural perspective. I may have made some improvements over my time there. But overall, I wasn't able to change the mindset. They had effectively just implemented mini waterfall.

Neil Benson [00:21:55]:

It's tough when there's a leadership culture that put in place that way that the people are just feel ingrained in and they're not empowered to change it. 

Matthew Venamore [00:22:02]:

Yeah. 

Neil Benson [00:22:03]:

And even if they wanted to change their mind, they seem unable to sometimes.

Matthew Venamore [00:22:06]:

Yeah, that's right. Yeah, yeah. It's not an easy process to go through, right? Like, I hear the business transformation and agile transformation mentioned a lot. Like, a transformation is a very serious undertaking even for an individual, let alone at a corporation. So it can't be taken on lightly and thinking you can just hire some people to transform your organization. It doesn't work like that. 

Neil Benson [00:22:30]:

Yeah, I prefer just to work at the team level, to be honest. I'm not here to transform an entire organization and, you know, have dozens of scrum masters and agile coaches around running around the place. I just take on one team at a time, one product at a time, and I really enjoy it. We build some great apps together.

Matthew Venamore [00:22:45]: 

It's about the product. 

Neil Benson [00:22:46]:

Yeah. 

Matthew Venamore [00:22:47]:

That's right. 

Neil Benson [00:22:47]:

Think about your own performance, though. Any doozies as far as things you've done as a scrum master that you look back on and go, oh, what was I thinking? Any regretful moments or learning opportunities that you've come through you can share with us? 

Matthew Venamore [00:22:59]:

Yeah, yeah. The first one is probably using a definition of ready. That seemed like a really good idea at the time. You know, there's definitions for done. Right? So let let's work out what our definition is when we're ready to start working on it. 

Neil Benson [00:23:15]:

It can be a sore spot, you know, that developers starting to work on a product backlog item that just when they get into it, just isn't ready. So let’s put a definition in place. That's gotta be the way to fix it, right? 

Matthew Venamore [00:23:25]:

Yes. It seems like a logical way of approaching it, but the outcome is not like that whatsoever. It becomes a stage gate. Well, sorry. No, not always with an analyst who is there to check everything along the way. I think for certain mindsets that can then become a stage gate, and it doesn't get to ready until it's been overanalyzed, which then stops the empirical learning by doing. Yeah, so it then sort of gets stuck in this loop of getting ready, getting ready, getting ready before it gets to the point of actually being worked on. While you can have some guidelines as to when a story is ready, I think that really needs to come from the refinement that happens between the discussion in the team, and the team then need to make the call. Yes, this story is ready, I know enough, and I'm happy to start working on it. So it becomes more of a discussion than a definition, I think, is the way to manage that much better yet because the definition of ready just became a stage gate, and it really slowed everything down. And the outcome of that is that there wasn't enough stories for our three squads at that time to work on. That's a learning that kind of their definition ready again. 

Neil Benson [00:24:44]:

I think I've seen it used temporarily, you know, for a few sprints to help teams improve the quality of the product backlog items. As long as like you said, it's a set of reminders. It's not a set of criteria that have to be checked off. It's not a checklist. 

Matthew Venamore [00:24:58]:

Yes. It's not a checklist, yeah. 

Neil Benson [00:25:00]:

You don't need to have the product owner's manager sign here before the team can start development. But it just says, you know, have we estimated it? Do we understand the acceptance criteria? Are all the developers comfortable with it? You know, those kinds of gentle reminders can be useful to improve the quality of the items. It's a delicate one for sure. 

Matthew Venamore [00:25:17]:

It is, it is. Yeah, yeah. And I think trying to get the mindset in place where it's around a discussion with the team to determine when it's ready, and then the learnings then come back in the retro. So in the retrospectives, that can come back as a learning to say oh, no, this story wasn't ready. What was it that we missed out in this story? You know, did we need a little bit more of this or that or understanding or we didn't have the list of fields ready or I don't know. Whatever it might be. Yeah, yeah. So just pushing it through the cycle. 

Neil Benson [00:25:47]:

It's also important that there’s openness and trust within the team so that anybody can speak out and say, “Hey, I don't mind feeling stupid in front of the team, but I don't understand that story yet” or “Hey, have we forgotten the test implications of this story or the security implications of this story because we seem to have not described that or discussed that when we discussed that particular item, and I'm scared it's gonna blow up and take longer than we expected?” So if we have that environment where anybody can speak out, that goes a long way without having to put a definition in place.

Matthew Venamore [00:26:15]:

Absolutely. That safety is a key element in teams, and I've only sort of just been putting that into practice in the last couple of roles that I've been in, yeah, and trying to judge and understand that there is a safety for the team to be able to bring out those things because it's a key element of transparency, right? You can't be transparent if you're not feeling safe. 

Neil Benson [00:26:36]:

Yeah, yeah. If you feel I have to hide something or not speak up, yeah. 

Matthew Venamore [00:26:39]:

Exactly. That's right, that's right. So it's something that I sort of actively work on now. 

Neil Benson [00:26:44]:

A couple more questions for you, Matt. What do you think is the appropriate level of technical experience for a scrum master in a Dynamics 365 or Power Platform team? Do you think you need to have had hands-on experience building apps before, maybe using apps before, to be an effective scrum master? Could you parachute into more of a Java development team, having never been a Java developer, and be as good a scrum master as you are in a Dynamics 365 team? Or do you think product experience is critical?

Matthew Venamore [00:27:12]:

Yeah. I think product experience — or maybe not critical. It really eases the path of what it is you're doing. The example that I can think of is, like, you know, I can understand the backlog of Dynamics story cards really easily, whereas when I worked on the Web 1.0, it just took me a bit longer to sort of understand what is that story even about. I don't get that one at all. And then, you have to go back to the team to get an understanding. It just slows things down a bit. I don't think it's critical, but it is valuable definitely. Like, because I, you know, I can add things to conversations as well as part of the refinement sessions and, you know, I can throw out a question here and there that isn't a silly one and is valued by the team. So, yeah, it certainly is valuable, not critical. What I would say, though, is that I have begun to think that it is critical for a product owner to have that experience and knowledge of the platform so that they can help drive it in the direction it needs to. 

Neil Benson [00:28:19]:

Well, that's a whole another podcast episode, I think, on the qualities of a great product owner. 

Matthew Venamore [00:28:23]:

Yes, yeah. Possibly, yeah, yeah. I was just — a whole lot of thoughts that were coming in there. So I'll put them on hold.

Neil Benson [00:28:29]:

Alright. Next time, we'll come back and circle around on that one. 

Matthew Venamore [00:28:31]:

Yeah, yeah. 

Neil Benson [00:28:32]:

The last thing I wanted to touch on because you and I have worked together in a couple of environments where we've had multiple scrum teams. So we found ourselves having 10 or more developers, and we have to split the team into two, and then I think we had three at one stage and then back down to two, I think. What's your experience being like scaling scrum? Some scrum practitioners think, you know, are trying to avoid scaling scrum, keep a small team for as long as you can. Others are quite comfortable with three, four, five, six scrum teams. When does it make sense? When is it too hard? What are the critical things to bear in mind when you're thinking about scaling scrum, and is it really necessary? 

Matthew Venamore [00:29:05]:

Yeah, I think it is necessary because I think whether we had, like, 25 people or something, I think, in total working on the platform Dynamics. And, yeah, it would have been a little bit too much, I think, because you start to, at that point, you know, I coached team on using Three Amigos to get those discussions going within the team. That just becomes a little bit too big to manage that with a team of that size. And so, yeah, it's definitely valuable to do that. And I think as you remember, we got the team to help work out. You know, they self-managed that split as well. And one of the things that came out of that split as well is that it made more sense. You have to be careful, I think, to make sure that your scrum teams aren't split down technical lines. And that's one thing that when we did that, it worked quite well because it was almost like a sub-product team with that that we had working. So we were sort of — they had two different visions of what it was that they were building, even though they were using the same platform. So, you know, effectively two different products almost. And that worked really well. The element that I think didn't work well is working with other teams, you know, agile teams doing integration and other platforms. Really, if we were working on one product, we should have had some of those people embedded in our team so that we were delivering integration at the same time as delivering that piece of work. That was a big struggle, I think. So that would be a learning that I would encourage is to make sure you have that cross-functional element, including integration, migration, even if you can, and all of those sorts of things, yeah, because then it makes easier for the product owner to be able to say, you know, “At the end of this sprint, this is what I wanna see. I wanna see this thin strip working end to end, including migration bits, data integration as well, and things like that so.

Neil Benson [00:31:04]:

We created a lot of dependencies for ourselves by having separate work streams. Is that API ready yet? Oh, what sprint have you got that in? Oh, we need it now. Can you start? Oh, it's just we weren't self-managing enough. We couldn't control our own destiny. We're always relying on other people, and that just created a lot of dependencies that held us held us up. 

Matthew Venamore [00:31:23]:

Yeah, that's right. That's right, yeah. And the scaling as well became difficult there because when you scale that and we scaled it using a sort of a Nexus framework, those became the discussions. Like, when are you ready so that we can then be ready and it's you're just trying to manage dependencies across teams, whereas if you build your teams more so around a product or, you know, a sub-product or something, it's less likely that you'll have crossover and need to do those sort of dependency management because they can just be managed within each of the scrum teams. You still would need your Nexus to manage the overall delivery, but it would be a much more lightweight Nexus than otherwise.

Neil Benson [00:32:06]:

Yeah. Great discussion. Well, thank you very much, Matt, for coming in and joining us on the show. For those who wanna stick around and get to know you a little bit better, you'll get a hang on for five minutes. I'd love to do a retrospective with you and discover a little bit more about your background, how you got started. So for those of you who have joined us, Matt is an expert scrum master I've had the pleasure of working with on several projects, building several products together. How did you get started in your Dynamics 365 career? Were you practicing scrum first and then Dynamics, or was it the other way around? How did you get into this whole game, man?

Matthew Venamore [00:32:33]:

Yeah. It was a bit of a, you know, a crossover in my career, I guess, when I fell into Dynamics, I think, as most people do in a project — oddly enough, a project that we're now replacing 12 years later.

Neil Benson [00:32:46]: 

Wow. So this was your first Dynamics project?

Matthew Venamore [00:32:49]:

Yeah, that's right. 

Neil Benson [00:32:50]:

Oh, wow. Wow. 

Matthew Venamore [00:32:51]:

And at that point in my career, I've been through — I've done development for 10 years, something like that, then software delivery manager for five years, where I'd started getting into the agile side of things, but I hadn't actually come across scrum at that point. So I've been trying to implement the multitude of Agile tools that are out there and just using those to sort of pull things together without a clear framework. And at that point, I had decided that I wanted to learn a bit more about the business side of things, so I took some roles as a business analyst. And one of the first ones just happened to be this Dynamics project. And then I just got hopes from there. I think nearly every project I've worked on since then has been a Dynamics-related project. It was, yeah, just one of those things. And then on one of those projects, they hired a scrum coach who’d take the whole project through the scrum framework and delivery method. And then, it just sort of all clicked into place. Like, my previous experience of the — because I'd previously been looking at Agile things, then the scrum framework made it all sort of fall into place for me. That's why I started loving the scrum framework because it had direction. It had a reason for being. It was there to deliver value, and these are the ways of doing that. Yeah, so it was, again, an accidental — you fall into the right place and discover something that you love. So I did that with both Dynamics and scrum. Although, as I say to everybody, I love Scrum, and I love Dynamics most days. So it's, yeah, it has its frustrations so. But still, I'm still here still loving doing it and loving the journey of watching it turn into the Power Platform and become this great toolset and platform for delivering almost anything.

Neil Benson [00:34:48]:

I was just reflecting on the first time I think I met you was at I saw you present at a user group meeting. In fact, we had our local Brisbane business apps user group meeting last night, and you were presenting in that same room probably 10 years ago when I first saw you so.

Matthew Venamore [00:35:04]:

Yeah, right. Right. Okay. 

Neil Benson [00:35:07]:

Feels like a lifetime ago. Final question then. Because I know you live in Brisbane, you've got a few kids at home, you must have some favorite Lego sets. What are the Venamore family into in terms of Lego? What's your favorite Lego set at home? 

Matthew Venamore [00:35:18]:

I'm actually the biggest Lego person in the house. My twin boys, you know, they're okay with it. Well, one of my boys, he loves Lego as much as I do. He's a Ninjago sort of dude. He loves those. But for me, it's most of my kit is either Star Wars, currently. So any Star Wars kit, I'm up for it and keen on. And that hails from my many days as a youngster, running around screaming spaceships. That's me all over. So anything space-related. 

Neil Benson [00:35:47]:

Yeah, there's a bit of a resurgence in the old Lego space sets, and I think they've re-published some sets from when I grew up in the eighties. 

Matthew Venamore [00:35:55]:

Really? Oh, okay. 

Neil Benson [00:35:56]:

But classic Lego space stuff just tugs at my heartstrings.

Matthew Venamore [00:35:59]:

Yeah. Oh, it does, absolutely. Yeah, yeah, yeah. No, it's very good. I rebuilt a bunch of my space Lego sets during COVID when there was no chance to leave the house. So I gotta continue that little fun journey of reminiscing my youth. Yeah, so no, it's good. 

Neil Benson [00:36:16]:

Well, folks, thanks so much for joining us. Matt, been a pleasure to have you on. We'll make sure we include links to your social media and more people can find you, your LinkedIn profile, and everything will be in the show notes. And I really appreciate you coming on today. Thanks so much.

Matthew Venamore [00:36:28]:

A pleasure. Thanks for having me. It's been really good. Thanks, Neil.