Peoples Choice Award - 2024 Broadband Award Winner
Deep dive today with Nathan Kennedy and Logan Jessop. These fine dudes are Scrum Masters at Voyager and, to quote the Scrum guide, they are accountable for the scrum team’s effectiveness.
They walk the walk, everyday.. or rather, on a fortnightly schedule. We’ll plunge head first into the details and hear all about the inner workings of their 2 weekly sprint cycles, managing multiple teams, and how they ended up becoming Scrum Masters of the Universe (at Voyager).
Christian Espinoza:
For the past few episodes on the podcast, I have been talking with people at Voyager to get a better understanding of the Agile mindset: what it is - what it is NOT - and the journey that Voyager has undertaken to become an Agile company. However, my discussions have been - as they say in the business world - “high level”. We’ve discussed broad concepts and fundamentals that underpin Agile, from the Manifesto thru today, but we’ve never really gone under the hood to see how the whole engine works. That’s all going to change right now. Today I sit down with Nathan Kennedy and Logan Jessop. They are Voyager’s Scrum Masters and, to quote the Scrum guide (yes - there’s a bit of that on this episode!) they are accountable for the scrum team’s effectiveness. They walk the walk, everyday.. Or rather, on a fortnightly schedule - to be exact. We’ll plunge headfirst into the details and hear all about the inner workings of their 2 weekly sprint cycles, managing multiple teams, and how they ended up becoming Scrum Masters of the Universe (at Voyager) …
Christian Espinoza:
I want to delve in a little bit deep today with the actual sprint. Can you walk me through a typical sprint, at least at Voyager and how we do it, and then talk generally about the sprint and what is that?
Logan Jessop:
At Voyager we run a two-week cycle, Wednesday to Wednesday where the team’s kind of come together, figure out the work that we're going to get through over the next two weeks and then break it down and do that work over the next two weeks. But obviously there is a lot more in, in it that goes into it as well.
Christian Espinoza:
So is Wednesday like a magic day or?
Logan Jessop:
So when we, when we started this, we actually did originally say we'd started on a Tuesday. And that was due to the Monday of the public holidays so that if the, there was ever anything that we needed to do on the kind of last day of the sprint, we weren't missing that because of the public holidays.
Christian Espinoza:
That makes sense.
Logan Jessop:
And then the other thing was because of the kind of nature of the work that we do coming in on a first day after the weekend, there's often sort of fires to put out or operational things that do need to be done. And so then having a sort of two hour session while we're potentially having to do operational stuff was, was not ideal. So we kind of settled on a, on a Wednesday, and that was kind of based off feedback from the entire technology department really. That was kind of the one thing that they were keen about.
Nathan Kennedy:
And, and it it's something that we started with and we hadn't really looked back. If you look at a lot of the official documentation online and things, or a blog post that people write about it, they often talk about going Monday to Friday. But it's certainly not the, you know, there's no prescriptive thing to say that you have to do that. So yeah, we've sort of put our spin on it.
Christian Espinoza:
Okay. Starting with Wednesday, what happens? Just maybe run through in order, you know, how do you, how do you go about its Wednesday.
Nathan Kennedy:
We actually start our sessions with, by closing out the previous sprint. And by closing out the previous sprint, we have a retrospective session, which we'll talk about in more detail shortly. So we start with that and that officially closes a previous sprint. And then we start on our next sprint and our, our, our first sprint starts with our sprint planning session. So the purpose of the sprint planning session is to take backlog items that we have on our product backlog , so those are like our, our stories and to take that product backlog, take those stories off there and create a sprint backlog. And the sprint backlog is a focus. It's a, it's a list of the work items that we're going to focus on within that two-week period. Okay. And so, as part of that exercise, we first we start with some words of wisdom from our product owner, which helps provide a bit of guidance as to where we are wanting to put focus this sprint.
Christian Espinoza:
So who's in the meeting so far? We've got a product owner, we've got the, the scrum master, which is you guys.
Nathan Kennedy:
Correct? Yeah. So we have the product owner, we have the scrum master and then the, the development or the engineering team. I might just say, we note on that. If you look at the official scrum guide, it refers to the three roles as the scrum master, the product donor and the development team within Voyager. We've chosen not to use the term development team because we have an actual department referred to as development. And so development means different things to us than It does according to the guide. So because our team is cross-functional, it's not just developers. We have developers, we have systems, engineers, voice engineers, network engineers and each squad has a combination of various engineers. So we don't, we don't refer to them as the, as a development team. We would, we refer to them as an, an engineering team.
Christian Espinoza:
I see. And so you talk about what came before, the previous sprint?
Nathan Kennedy:
We would first talk about availability of team members over the next fortnight. Now this takes into consideration things like annual leave. If people are going to be away on training, or if they're going to be involved with something else or if there's public holidays, especially. And so, we can determine at least a rough percentage wise as to what our team availability is going to be like for that coming fortnight. And then what we'll do is we'll apply that percentage to our, our velocity, which is something that we've built up over time, which we can talk about shortly. That velocity becomes our sort of measuring stick as to how much we can achieve in that sprint. And then when we go through the process of estimation, we have our, we start off with our blank sprint backlog, and the product owner has ordered the product backlog by business value and priority.
Nathan Kennedy:
And we just take the top item off, we go through an estimation exercise and then and then push it into the sprint backlog. Now, based on that velocity that we've already estimated to know how much we can fit into that sprint. We keep doing that until we get to the point where our sprint backlog is, is full. And at that point we would define some sprint goals around what the, what we are wanting to publish to the business of what the team is going to be focusing on for the next two weeks. And then we, then we, we officially kicked off our sprint.
Christian Espinoza:
And so how long does this meeting sort of take usually, is it timeboxed?, Does it, or is it just you know, organic, as long as it needs to be?
Nathan Kennedy:
So we do keep it timeboxed, but we don't have a specific timeboxed full of planning or the retro because we have these sessions back to back. We have about two and a half hours. We have a two and a half hour time box for both of those sessions back to back with a, we break in the middle,
Christian Espinoza:
If this was say across several different teams, would you do it all on a, you know, with all the different teams that we have at Voyager or value streams, would you do this all throughout the day if you're looking after multiple teams?
Nathan Kennedy:
Absolutely. So those Wednesdays are a really big day for us scrum masters with the kind, we have two teams each. And so it's I, I do hosting veins in the morning and their networks in the afternoon.
Christian Espinoza:
Wow.
Nathan Kennedy:
And Logan will be voice in the morning internal systems
Logan Jessop:
Exactly. Voice and then internal systems
Christian Espinoza:
Far out. And so, okay. So, Wednesdays, you're completely out of action with these meetings and they're called retrospectives?
Nathan Kennedy:
So start, so yeah, we start with the retrospective, which is for the previous sprint, and then we so that, that officially concludes that previous sprint. And then we kick into sprint planning for our next sprint.
Christian Espinoza:
Right. How do you guys handle multiple teams like, Logan? How do you handle, you know, these multiple teams, especially when you're talking to each of them separately within these separate meetings?
Logan Jessop:
Yeah. So it's, it's been a, definitely a learning experience. So last year I was running, I was actually doing voice and networks. And then I just had voice for just voice for maybe five months or so. But now I'm just, I've just taken over internal systems again as well as a kind of voice customer experience team's been, been run up as well, but that's more of a kind of operational thing. It's not they don't do retros or anything yet. And the teams have, as we've gone along the kind of agile transformation, we've had a, a more kind of uptick of, of people kind of managing and self-managing on the board themselves anyway. So it's, it's a lot less management now than it was when we initially started running the, the kind of agile within the, within the technology department.
Christian Espinoza:
So how many, how many members, why, how many people would attend these meetings say like in each, in each team?
Logan Jessop:
So it does, it does vary. I mean, each team, the, the scrum guide kind of prescribes that you should have. No, I think it's, is it seven plus or minus two Nathan? Or is it yeah,
Nathan Kennedy:
Something like that.
Logan Jessop:
Yep. So I think for, for internal systems, there's five that come to the session six, including me, I think, and then for, for voice it's about eight. But the idea is to sort of keep it to the people who were working through the sprint, who are going to be working through the sprint and who can provide the value around what we can actually do a sprint and, and the, the learnings from what we've completed in the previous sprint,
Christian Espinoza:
You guys have both referenced the scrum guide, how prescriptive are we, or should an organization be to the scrum guide without maybe you know, having a little bit of flexibility themselves?
Nathan Kennedy:
Yeah, that, that's actually a really good question, because if you start to read the scrum guide, it actually stipulates in there that if you're not following it to the T you are therefore not doing scrum. But in saying that the scrum guide itself has become a lot less prescriptive over the years as it, especially as it's, as it's move well beyond software development. So, you know, its origins were in software development and, you know, they released a new scrum guide late last year in, in 2020. And just reading through that, it's actually become a much smaller document and they've actually taken a lot of, a lot of the prescriptive stuff out of there. Like for example just one simple example is when they talk about daily standups, they used to talk about that the, you know, answering those three questions. What did you do yesterday to work towards the goal? What do you plan on doing today to work towards the goal? And what blockers do you have? Now It just talks about the purpose of the meeting saying that it's a, it's a daily meeting for the team to align and, and ensure that they're all aligned, you know, working towards that goal.
Christian Espinoza:
Right. So not necessarily...
Nathan Kennedy:
Talk about how to run the meeting.
Christian Espinoza:
I see. So then taking the blueprint from the scrum guide, so then what happens next?
Nathan Kennedy:
Okay. So we've got our, so we've completed our sprint planning and the sprint is underway. So what we would then do is, is on a daily basis, we have daily standups. So the purpose of the daily standup, as I mentioned just before, is a, a very short meeting. So they're timeboxed to 15 minutes and it's to, to ensure they don't cut into everyone's days too much. We have them at the same time, in the same place every day to ensure that it's very simple, everyone knows where to be. And when, and the purpose of that session is just, it's not, it's not an, an update meeting and more importantly, it is not a meeting to update the scrum master and that they can often be a bit of a misconception. Um.
Christian Espinoza:
So how do you mean?
Nathan Kennedy:
The purpose of the meeting is for the team members to align with each other on what, on what they're working on that day. And, and quite often what comes out of that is, is team members will say, oh, I'm currently working on this, but I'm a little bit stuck on it, or I need some help on this one. And then someone else can go, oh, that's cool. I can help you with that. And so that's the main purpose of is to get the team aligned and, and, and to sort of ensure that collaboration continues.
Christian Espinoza:
How long are the daily stand-ups usually?
Nathan Kennedy:
So their timeboxed are 15 minutes. Sometimes we'll get through them in five sometimes 10. If there's a little bit more to discuss, well, we can, we can go up to that 15, but it's pretty important that we don't go beyond that 15 minute time box primarily because there's quite a few standups happening within the business now. So they're often pretty close to being back to back. So, we don't want to ensure that they're running over that being said, if it is determined as part of that daily, standup, that there's more conversation required. We don't discourage that. We just don't encourage during the standup, we would encourage that people have satellite meetings after, after that daily standup.
Christian Espinoza:
Yeah. I find that...
Logan Jessop:
See's the common catch phrase is "we'll take this offline".
Christian Espinoza:
Yeah, yeah, yeah. I, I was actually going to say, there's so many meetings where people will say, well, take this offline and there's rarely time offline to actually do anything because you're just in meetings.
Nathan Kennedy:
So the ceremonies themselves do not actually take much time. Okay. So, you know, we have that two and a half hour session and that's, that's the main one. That's, that's the meaty one. That's and that's once a fortnight. So although it takes up a lot of our time as scrum masters, especially when we are doing multiple teams for the team members themselves, it's two and a half hours a fortnight. Then we have the, then we have the daily standup, which is 15 minutes a day. And then other than that, we have where we will sort of prepare our backlog for the upcoming sprint and that's like a, maybe an hour or so every fortnight before the planning. And other than that, that that's it really, so that it's not, it's not as heavy as it may be a, as people might think.
Christian Espinoza:
Right. And this is across all the teams, like, like Logan you're, you would operate in the same way?
Logan Jessop:
Yep. It's all, it's all a pretty standard kind of format across all the teams and, and the idea behind that was if there were any movements around which we have had quite a few moving people around the different teams that it just kind of keeps it as sort of standard for them as possible without too much kind of shock as they move between different, different squads.
Christian Espinoza:
Yeah. And I like that. It's all at the same time. Same. I was going to say same channel.
Logan Jessop:
Yeah
Nathan Kennedy:
Pretty much. Yeah.
Christian Espinoza:
How do you measure the progress or how do you see that progress? Cuz you talked about velocity and so, I mean, based on how many things get done, can you talk about, you know, firstly, what is the "definition of done" in, in, in your case and also how does that progress get tracked?
Nathan Kennedy:
So the, the, the definition of done is like a, a contract almost whether the, the, the, the team has previously decided what we consider to be as done. So that could, that could be something along the lines of ensuring that everything has passed all the tests ensuring that documentation is updated ensuring that any demos that are needed to be done are done to ensure that say, you know, if help desk need to be trained or anything like that, to ensure that that's all done. So that becomes, that formulates part of our done by having that definition of done it ensures that when we are working through stories on our board, there's no ambiguity as to whether or not, you know, if you see a story pushed over to that done column, you know, that it's as part of that being in the done column, it has met that definition of done. So that's what, that's what the definition of done is about in terms of, of tracking progress and, and velocity. It's important to note that velocity is not used as a performance measure. It's used to help us understand how much work a team can complete within a sprint. And velocity to one team can be completely different to a velocity in a, another team. Like there's no the, the, the velocity value is very abstract.
Christian Espinoza:
Maybe talk about your estimation because that's something where, okay, so you're, you're doing all the sprint planning up front and you're tracking your velocity, but how do you actually estimate, you said it was a bit abstract.
Nathan Kennedy:
We've actually tried two different types of estimation here. At least within our latest iteration of our agile journey. Many years ago we used to use at least in the software development team, we used to estimate with time bucket it's, it's something. So something might be an hour, two hours, four hours a day or two days. Right. the only problem with trying to track things down to time is that there's that sense that I have to have this done within an hour, or I have to have this done within two hours, but that's not the purpose of it. So we, what we did was when we went so a couple of years ago, when we on our latest iteration of very agile journey, we started with t-shirt sizes. So really, really simple. It was basically when we look at a, at a piece of work, is it a small, medium, large, or, or is it an, an XL?
Nathan Kennedy:
So, there's like, you know, four options thereof, of size, and it's all relative to one another, right? So you might have a story which you've previously deemed as large, and you've got this other story and it's like, well, compared to that large, this is a medium. All right. And then based on that, if you were to then put a, a, a number value on that, on that sizing. So small as a one mediums are two larger three, and so on and so forth, at the end of that sprint, you could add up all those sizes and it gives you that number and that becomes your velocity. So when it comes to planning in the future, you go, okay, we know, and, and your velocity is something that gets realized over the first few sprints.
Christian Espinoza:
Right so it's over time?
Nathan Kennedy:
Over time, so what we do is we have a rolling six sprint average. So based on the last six sprints, and that's what we use as our estimated velocity. So we know that, you know, out of using this t-shirt sizing, we know we can do approximately X number of points. And so when we're estimating going, that's an XL, that's a large, that's a medium once we hit that sort of velocity total, so, okay. We've got enough work here.
Christian Espinoza:
So you mentioned before, these are not performance measures, so the velocity does not measure performance. So I'm wondering how do you know that you're at least tracking? Is it just keeping up with the velocity? Is there a something where you can gauge the, the results or measure them?
Logan Jessop:
Yeah, so we have a the tool Version One that we use to do all our kind of sprint work has a built in it's a burn down chart, but you can also get burn up charts. So what that does is it basically say at the start of the sprint, you've got a velocity of 60 story points that will then as the sprint goes through kind of plot out at, at each day of the sprint where your ideal completed work is, or your completed estimate is at, so say in the, in the, the sprint is 10 days and you've got 60 story points. You need to get six points done per day, right? So on the third day, your ideal estimate would be 18 story points. And then it will also track the actual work completed. So as the days move on, version one will track where you are at actually as well as where you should be ideally. And that can then become a conversation that have in the daily standup saying, Hey guys, we are looking quite far behind or we're tracking really well. Obviously if you're tracking really well, you're probably not going to change anything. But if you are far behind, what can we do to sort of move things along? Is there any blockers that we need to be aware of? Is it just that there's quite a few still, or is in review? Did we misunderstand, did we misestimate that kind of stuff.
Christian Espinoza:
So it provides you some immediate feedback that you can use On a daily basis.
Logan Jessop:
Yep. Yep.
Christian Espinoza:
Right.
Christian Espinoza:
We’ll be right back with Nathan and Logan in a minute. Growth is a podcast about people, their stories, their challenges, and how they help to shape technology for all of us. I sit down with my colleagues at Voyager and ask them questions that I hope we all want to hear about. Nothing is scripted, and what they say is what you hear. If you like this episode, follow us on your favorite podcast app. You’ll get new episodes as they come out, and you can also catch up on past episodes too such as my interview with CEO Alf Wallis, or Agile Coach and former Practice Lead, Daniel Stastny. Listen to us commercial free, fat free, sugar free. I’M joking - of course not sugar free! And now back to my conversation with the Scrum Masters.
Logan Jessop:
So the way that we currently sort of struck sprints in in Voyager is we have, we have a sprint goal, which is kind of, or multiple sprint goals. Each team again, is different in that respect. But we have these goals, which we've kind of, we published to the business and we say over the next two weeks, this is what we are targeting to get complete. And it's sprint goal, maybe something maybe something big, maybe something that's, that's quite small. But it's a, it's something that we are committing to getting done over the next two weeks. And so there will probably most of the time be a body of work within the sprint that contributes to that sprint goal, but there will also the other pieces of work, which don't contribute to the sprint goal. And that's, I think come from the kind of nature of, of what we do and that we obviously acknowledge that we've got quite a bit of maintenance and operational stuff that we need to get through Within the sprint. Anyway. so towards the end of the sprint, the main focus, if we haven't completed it is, is kind of getting sprint goal complete. Because that is the, the big piece of business value that we have committed to, to delivering over the two weeks we need to.
Christian Espinoza:
So what happens to any sprint goals that don't get that, that, that you don't meet? Do they roll over? Do they get...?
Logan Jessop:
Yeah, so again, I guess that depends on why the sprint goal wasn't met. So sometimes it's actually, we've, we've determined that that doesn't actually need to be a sprint goal. That business value is no longer required due to something. So one that one that comes to mind is we had a sprint goal around having a, something, a product released for consumers. And then we had a competitor do the, the same thing. So it kind of then became a sprint goal that we didn't weren't necessarily rushing towards. Because we had kind of been almost beat into market which is what we were targeting with the sprint goal. Anyway.
Christian Espinoza:
Yeah, we have in previous episodes, we've talked about the bigger picture is really how we can collaborate as teams. How can we be self-managing, highly functional, and respond to change and adapt more, more efficiently and quicker. Do you feel that these two weekly sprint cycles help and, and that tempo sort of helps to enable that end?
Nathan Kennedy:
Absolutely. In fact, that sort of leads into one of our, our final ceremony that we have, which is one of the most important ones and that's our, our retrospective session. So I mentioned we had this immediately before our sprint planning. So at the end of, of every sprint, we, we, we take time out to actually sit down and actually look back on the sprint and look at what things worked well, what things didn't work so well, are there things that we should start doing or are there things that we could, you know, just try and then have a look back on the things that we, we were trying and are they helping us, are they hindering? Should we do more of that? Should we do less of that? And by actually taking that time out to do that on that regular cadence, that two weekly cadence means that there's that opportunity to keep looking at what we're doing and look at ways of improving.
Christian Espinoza:
Yeah. I remember when I talked to Daniel on the podcast, we, you know, we, we, we both, how in more traditional project management, there's lessons learned at the very, very end of a project it's a bit late. And then you, what do you do? You file it away and you forget about it until it happens again and you make the same mistakes. So how do you, I guess that I guess it speaks for, so two weeks in itself, you're going to, you're not really going to forget about those kinds of lessons, if you will, or, you know, what, what went well, what didn't went, what didn't work well, because you implemented immediately and you push on with that, right?
Nathan Kennedy:
Yeah, exactly. Right. And the other benefit is it is only two weeks, so if we're going to try something and it really doesn't work, you know, we, we haven't lost much. You know, we, we certainly, we certainly gain more than we lose by trying by trying new things.
Christian Espinoza:
I'm, I'm curious, how did you guys land in this position as scrum masters? Logan? I know, I know you said you have some background in voice but, but how, how did you become a scrum master?
Logan Jessop:
I'm Not sure how though we want to go back, but when I left university, I had a couple of, I had a degree in history in sociology, which I could not get a job in. So I found.
Christian Espinoza:
Really?
Logan Jessop:
Yeah. Can, can you believe it? So then I got a job with this slightly eccentric guy in Davenport who was running kind of a VoIP based business out of his, it wasn't out of his house then actually, but out of a very small office there. So I think there was about four of us at the time. And then over the next I worked there for, for four years we kind of grew quite a bit and then Voyager came along and purchased that business. So I just came over to Voyager, made the ferry ride over, and then it became we were kind of doing just the same job here. Right. So they kind of, we picked up our phones and our computers and we moved to the CBD. And that was kind of what we did for maybe about a year after that. Following that kind of had a kind of project to sort of merge with Voyager for the most part, which we did. And that kind of meant the stuff that I was doing, which was sort of helpdesk sales accounts that was kind of all handed off to the other departments within Voyager.
Christian Espinoza:
You were doing all of that?
Logan Jessop:
Yes. Yeah. Yeah. So I was doing when I was there, it was, I was the, the operations of it. So provisioning...
Christian Espinoza:
You were everything.
Logan Jessop:
Yeah. Yeah. So then I kind of was, didn't have much to do. And then Voya essentially kind of shoulder tapped me and said so we had a guy come in, James Dickinson came in and sort of gave interviews to everyone in the technology department. And he kind of earmarked where he thought people would, would be good for. And he earmarked me as a scrum master.
Christian Espinoza:
Did you know what that was then?
Logan Jessop:
No, no, no, no. So he, me just scrum master and then it was basically like, you've got two weeks to kind of teach yourself. And then Tim came on with
Christian Espinoza:
Not the defend at all.
Logan Jessop:
No we, we had Tim, I think without Tim it would've been...
Christian Espinoza:
Tim Phillips?
Logan Jessop:
Yeah, yeah. Without Tim Phillips, it would've been definitely the deep end for me. So
Christian Espinoza:
He was guiding you, coaching you.
Logan Jessop:
Yeah, exactly. So he was kind of coaching us around what a scrum master was, the ideas behind it. I had literally no experience with agile at all.
Christian Espinoza:
And now you're running a couple of teams yourself.
Logan Jessop:
Yeah, yeah, exactly. The safari books that VO offers was really good if I can give a plug to that. So literally for two weeks, I just kind of sat on safari books and chatted with Tim and Nathan and we sort of figured it out from there.
Christian Espinoza:
I think you'd appreciate as a, a student of history and sociology that the real advocacy for learning through books, online books, physical books, we have an agile library.
Logan Jessop:
Yeah. And so, it's just part of that piece of continuous learning and kind of challenging yourself. I would never have been able to be a scrum master without Voyager. It would never have been something that I could have done because you need experience because you need qualifications. And so being able to kind of get that opportunity and be able to really make the mistakes that we, that I've made during that time has been, has been pretty awesome.
Christian Espinoza:
Wow. Nathan, you recently just got promoted to agile practice lead, which is awesome by the way. Can you, can you tell me a little bit about the importance of that role?
Nathan Kennedy:
Yeah, sure. So as out of the agile practice or, and, and, and specifically with the practice lead, so I'm, I'm a scrum master as well. So I'm scrum mastering two teams like Logan. But on top of that, it's just ensuring that the that the agile practice is continuing to move forward here at Voyager. What that means to me is that we've done a great job with rolling out agile within the technology space. But if you look at our pillar, which has become an agile business, it's not become it's not the technology department becoming an agile part of the business, it's become an agile business. So, what, what, where I really want to take to practice is that we are pushing those agile ways of working outside of technology and throughout the business.
Christian Espinoza:
Right, right. And so is it your role is an agile practice lead, but also a scrum master? Does it get to be quite conflicting or is it all does it all sort of flow naturally for you?
Nathan Kennedy:
I'd say at this stage, it seems to be flowing quite naturally, which I'm really grateful for. It helps having teams that are really embracing that, that self-organization. So I I'm able to sort of step back a little bit and the team's, but is to continue working at the, at the same sort of pace. But saying that, I've only been on the role for a few, for a few days now. So we're keen to see how that, how that pans out we are currently on the lookout for another scrum master.
Christian Espinoza:
Right. So if you're in the, what region would we you'd be looking for? Auckland, Christchurch?
Nathan Kennedy:
Christchurch, And the primary reason for that is the, the bulk of the team members within the Christchurch branch, not all like they are spread around the country, but the bulk of them are, are in Christchurch.
Christian Espinoza:
Guys. I want to ask you one last question here to each of you, if you weren't a scrum master, what would you be doing? Logan I'll start with you first.
Logan Jessop:
Honestly, I probably, would've just I think I would've gone back to study and probably kind of got a this is going to sound super pretentious as well. Would've got a museum was, you know, my, my museum curatorial masters was the, was the way for me. But I just needed I needed a job that paid money.
Christian Espinoza:
I'm so fascinated by that response. Why museum curation?
Logan Jessop:
I mean, so, you know, history was, was, is a very big passion of mine. So I, I, you know, I, I got accepted to the, to the honors. I got you know, I was, I was starting it and then landed this, this job kind of last minute. Right. I think realistically it was the, it was something that appealed to me, but I was still also, you know, not really ready to get a proper job, I guess looking to keep studying and looking to keep furthering that side of it. But you know, realistically now I could probably never go back to university. I don't think
Christian Espinoza:
Never say never my friend. Nathan, what about you, if you weren't a scrum master what, what might you be?
Nathan Kennedy:
That's a really, really good, good question and really difficult to answer. So me I've always been into technology my whole life, right. And so when I left school at initially I didn't really know what I wanted to wanted, wanted to do, but I did have an interest in, in computers. And so I, I landed a job. I did, I did some training, I did some training courses and landed a job, building computers and really loved that, you know, working with the computer hardware at that point, I knew very little about like software development or anything like that. It was about building those, those machines. Then I, so I, I stuck with that for a few years and actually started working for a service agent that was doing like warranty work for Hewlett Packard and things like that.
Nathan Kennedy:
And it was around that time that on the side, I started gambling a little bit in software development. Hmm. And I was starting to get a little bit bored of the computer hardware side of things and was quite fascinated how you could do almost anything with software, you know, and so started dabbling with that for a few years while I was still, you know, professionally working with the computer hardware. And at the time the, the company I was working with at the time we had our own in-house developed so software. And so I actually started getting started helping out the team with that, and then eventually that kind of flowed over. And that became my main focus. And so I actually, then my, that became my full-time job was actually working on our in-house software. And then from there I went and worked at a, at a web agency a website, you know, designing and building websites and things.
Nathan Kennedy:
Oh, yeah. And it was that was when I came to Voyager. So I started at Voyager in 2013 and I started as a, as a developer. Obviously we were much smaller back then. I think there was probably around about 30 staff nationwide. And when I joined the development team were two other people, two other developers there. Yeah, so that, that was us. We were the development team. And then one thing I'm, I'm really grateful for Voyager for the various opportunities that have, that have been presented to me over the years. So I took on the role of the development team leader when we scaled up development team. So there was a big hiring process. So lots of stuff learned with that. I was all of a sudden having to hire people and actually be a team leader for people.
Nathan Kennedy:
So that was a big learning curve. And so did that for a few years. And then I was presented the opportunity to try out this role of being a scrum master. Now it's not something that I would've ever thought to have tried much like Logan it's, I would've never have thought to myself I'm going to be a scrum master, but I embrace the opportunity and I it's as cliche and as cheesy as this may sound, I kind of feel like I've found my calling and it's through absolutely love being able to see success through, rather than stuff that I'm necessarily doing myself. Just being able to facilitate the success to others and yeah, just absolutely loving it. So in terms of what would I be if I wasn't a scrum master, who knows, but, but I would've never have thought I would be a scrum master.
Christian Espinoza:
Guys. I want to thank you so much for being on the podcast today. I really appreciate your time and really good luck with the next sprint. I have to say!
Nathan Kennedy:
You very you very much.
Christian Espinoza:
That’s it for another episode in our Agile series. The Growth Podcast is a production from Voyager Internet. The show was produced, edited and mixed by me. Transcription by Josh Yeats. Special thanks to my guests, Nathan Kennedy and Logan Jessop. If you enjoyed this episode and would like to hear more, follow us on your podcast app. We release a new episode every week, and although our podcast production is not part of the Sprint planning, I feel we do a pretty good job. If you like the show - tell us about it! You can send us an email to [email protected]. If you don’t like what you hear, I’ll put you in touch with the scrum masters directly so they can guide you through a retrospective session and see what can be improved for next time. Nathan and Logan - thanks in advance! Until next time, Peace.