Leap to Scale
Leap to Scale is for technology curious leaders of service firms who want higher margins without adding headcount. Each week, Justin Davis and Greg Ross-Munro show how to turn firm expertise into repeatable, sellable technology products: SaaS, packaged workflows, and AI-powered tools clients can buy again and again. With AI, more of your know-how can be captured, standardized, and protected as IP instead of being rebuilt in every engagement.
We focus on practical decisions: what to productize, how to price it, when to build vs. buy, and how to use AI responsibly without risking delivery quality or margin. Clear steps, real tradeoffs, usable examples.
Leap to Scale
Intro to Software Development Methodologies
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Welcome to Decoder podcast, where we step inside the world of a software development agency and learn how bits and bytes become useful technology. Each episode features conversations with software creators and users about the process, challenges, and fun of building software.
Intended for a non-technical audience, this podcast will help you understand how software is built so you can more effectively engage with software developers for more successful projects.
In this episode, Sara is joined by Greg Ross-Munro and Gregg "3G" Hilferding. Listen today to hear them discuss:
- The most popular software development methodologies
- What methodologies Sourcetoad uses and why (Agile/Scrum)
- Why the Scrum methodology produces the best results for our clients
Welcome to Decoder Podcast, where we step inside the world of a software development agency and learn how bits and bytes become useful technology. Each episode features conversations with creators and users about the process, challenges, and fun of building software. Intended for a non-technical audience, this podcast will help you understand how software is built so you can more effectively engage with software developers for more successful projects. Hi, welcome to Decoder Podcast. I'm Sarah Altenhoff, and I'm here today with Greg Rossman Rowe, CEO of SourceTode, and Greg 3G Hilfordine, VP of Delivery at SourceTode. Hi, Greg. Hi, Sarah.
SPEAKER_03How are you today? Happy Friday.
SPEAKER_00Happy Friday. I'm doing well. How are you?
SPEAKER_03I'm good. This is the last thing we have to do at the end of the day, and I'm going uh with my wife's birthday after this, so it should be good. Good end of the week.
SPEAKER_00Well, we can all kick off our weekend after this. So on today's episode, we're going to talk about software development methodologies. So there are a few main schools of thought about the best way to approach development. So 3G, can you start us off by walking us through the different software development methodologies and explain their pros and cons?
SPEAKER_01This is my favorite topic. I'm glad. I hope we have like three or four hours for this episode so that I can like really dig into it. Um just kidding. I can give a high level. Um there are really two major schools of thought in how you build software. Um, the old school way is commonly referred to as waterfall. And if you think about any kind of like very large project, like a large construction project, um, there's a lot of planning that goes into uh that goes into that before ground is ever broken. You want to have like drawings and plans and schedules and everything all figured out before you spend the first penny actually building something. And that's how software uh used to be built exclusively, and it's how some software is still built today. Now, somewhere around the 70s, a group of software engineers got together and they said, This is not working. Software is different than construction, and we can build stuff faster and learn what is the right thing to build sooner, and just change the software as we learn. And what they came up with, and it's this is very like revolutionary, so they even called it uh the manifesto. It was the agile manifesto. And they cringe I know, I know. Um but they basically said like this big design up front is crazy because it's not the same as a building. You don't like necessarily have to put down the the first floor before you put on the second floor. Um in software, sometimes you can build in totally different orders. And as you learn things, you can just roll out new versions. And so they built this entirely different approach that basically was about like building stuff faster, um, building things in small pieces, and getting things in the hands of users to get feedback, and then just changing the plan as you learned. And this method, like I said, it was like in the 70s that a group came together for this. It took a long time to uh to be adopted, but it is pretty much the standard these days. Right? If you go into most shops um that are building software, they're going to say that they are agile and they might be using one of the many like sub-branches of agile like Scrum or Kanban um or their own flavor. But it is the standard these days.
SPEAKER_03There's still a lot of people out there, especially like big projects using waterfall methodologies, though. I mean, don't you think there's like government work, big like corporate projects sometimes, especially in the beginning of the project, can be more waterfall, you know what I mean? Like than like the later phases.
SPEAKER_01Am I wrong? Oh yeah, no, I think that there's definitely a lot of projects out there still built that way. Some of those projects are being built that way because they're still going on. Like they've been they've been in progress so long that they started before Agile was even existed, right?
SPEAKER_03Um banking software, we're looking at you. Looking at you banks.
SPEAKER_01Yeah. Yeah. The thing, you know, there's a um the whole idea of designing all that stuff up front is always about reducing risk, right? Like if you people have this idea that like if we just have the perfect plan, if we just like think about everything that could possibly happen and plan for it, then we cannot fail. And a lot of people still believe that, but that is um that isn't true if shipping the software is required to be successful. Um, and most of the time it is, right? Like just having a perfect plan is not considered success. Uh, most of the time, having actual software people are using is what you consider success. Um and so that is kind of where there's that breakdown where like it's supposed to, waterfall is supposed to eliminate risk by making sure you have a perfect plan, but the amount of time it takes to do that is just so long that by the time you finally have what you think is a perfect plan, there's already like 10 competitors who have been operating in the market, and your idea doesn't even make any sense anymore because the like whole world has changed around you.
SPEAKER_03Yeah, you should well, um Sarah, sometime you should look up the the brain crack video. Just uh just you type into Google or like YouTube, brain crack, it is not safe for work, but some some of what Greg's talking about is that but um there is a Greg, there is actually a safe for work version of it.
SPEAKER_01It is a safe for work. It is significantly shorter than the uh than the actual video.
SPEAKER_03I think we we we haven't probably decided I assume that this podcast is gonna be like safe for work considering it's a work thing. Um so we weren't good at it. But uh yeah, before we like dive into like what agile is and everything, just um I've been developing software for a long time. I've been on like traditional waterfall projects, I'm sure Greg has as well. And just so you know, like to just have something to kind of compare and contrast with. Um when you start with a waterfall project, uh you kind of do requirements gathering, you go and like you find out, you go and speak to all the stakeholders, you find out what exactly that you think you want to build. Then you go and you do this like big design phase. So you spend like you do re- user research and you ask all these questions, and then you do like you design everything on paper first or in some sort of software system. Then you go and you validate it by showing people um in the in the organization what what you've built in on paper. Then you're you send it over to the dev team, and they go into like a black box, and they don't talk to anybody basically, and they build this build it out according to the spec. And then they give it, they come and they deliver it to you, and then the QA people go through and look at the spec and they say, Yes, okay, that that is exactly where it's supposed to be, and then they like launch it. And then finally users get it, and they're like, What the what on earth is this thing? Like, did you like yeah, I remember you guys asked me like three years ago what my opinion was, but that changed. Um, so that's uh and and I think one of the like the horrible, dirty secrets of the software development world is that it depends on what you read, but like from 50 to 80% of all software projects fail. 50 to 80 percent. Can you imagine like it we have an entire industry built around this stuff and that is not a good track record? If you if you were like, hey, would you like to invest in this thing and like it's got a 75% failure rate? You would be like, no thanks. So I think that some of the agile methodologies were designed, they kind of came out of this idea of like we need to do better.
SPEAKER_01Yeah, can you imagine driving through a subdivision where the contractor uh 75% of the houses uh aren't finished? Right? Like that will never be. And never will be, right? Because like one of the houses is like it's just a garage. It's it's just one large garage. And it's like, wait, why did anyone think that building just a giant garage would make sense for a house? Right? But like, you know, they did the research and they asked people, it just turns out that they only asked uh you know, car enthusiasts what they want from a house, and they never they only like once they heard that they wanted a cool garage, they stopped asking other questions, right? Because they thought they found it. And if you look at the if the software industry could be uh visualized in that way, it would be pretty shocking. Like the some of those failed projects, like the the weird directions that they ended up going.
SPEAKER_00So you you mentioned earlier that there are, so underneath the agile umbrella, there are different methodologies. Um so can you tell us a little bit more about those and tell us what source toad uh what methodology source toad uses?
SPEAKER_01There are a ton. So I think the uh the largest, most popular one that you're gonna run into is the scrum methodology. And scrum is really interesting because it takes you have this idea called sprints, and sprints are typically like one to four weeks in length. Uh for us, we happen to pick two weeks uh in length. And what happens during those sprints is uh all those same exact steps that Greg just described in a waterfall project, they all happen in those two weeks. You do requirements gathering, you uh talk to users, you make plans, you build software, it gets QA'd. You do all of that in two weeks, but you do it for like a very uh narrow slice of the product and you get that uh slice of the product out there for users to use, and then you start another two-week cycle and you work on another feature. And you do those in order of uh importance, and that order of importance, that prioritization uh changes based on what you're hearing from your customers, from what you're hearing from your users. Um but it's actually interesting because you know some people say that Scrum, like there's no planning in Scrum, but there's actually the exact same planning steps. The idea isn't to like not plan, the idea is to spend less time planning the whole thing and only plan out small pieces at a time.
SPEAKER_03Well, why do you think why do you think? I mean, I've heard that about about Scrum and Agile before a lot, which is like, well, there's no like there's no design process up front, and as a result, there's like I mean, we're never gonna really know what we're gonna do. It's like we're building the plane while we're like working on the plane while it's flying. Why do you think that there's that perception? Like what are people getting wrong? Because I run into that fairly often. I don't have a good answer for that.
SPEAKER_01Yeah, I think the the thing about it is that in those two weeks, you're not going to make a perfect product. Like you're not going to add a feature that's perfect for every type of user, for every possible scenario. And so what you see in those, like in a in a scrum process is you know, it's kind of like uh uh carving a sculpture out of a block of wood. You start with this like just like block of wood, and every time you check in, like it is getting closer and closer to what its final form is. And if you check in after the first two weeks of that sculpture, it might look like there's no plan. I see what you're saying. Yeah, yeah, yeah. Okay. Right? It might look like just this amorphous blob, and you're like, what is this? This seems very poorly thought out. Like, this doesn't look like much. But what happens is that that blob, um, the thing about that blob is that like it might turn into something different than what the original plan was, because every two weeks when you chip away at more pieces of it, like you might have thought you were uh sculpting um a person, but maybe you're actually sculpting an animal, or maybe you're sculpting a building. And if you don't make if you don't like get stuck in your head about what you're building, and you let the experience of building it teach you what you should build, then you can kind of change direction.
SPEAKER_03And that's the other way that I love this analogy.
SPEAKER_01Yeah, that's the other way people get like think that there's no planning because like what you said you were gonna do three months ago isn't what you're doing today, so clearly you didn't do any planning. It's like, well, we what we did was we adjusted our plan. And that is the part that can be really scary for people is the idea that like we're gonna tell stakeholders that we're building uh that we're building X, but then a few months later we're actually gonna build Y because turns out people don't need X. Like turns out nobody nobody wanted it.
SPEAKER_03Do you think there's any reason like in this day and age for waterfall to be used in any? Like I know you and I are big we drink at the the fountain or the like worship at the altar of agile and uh scrum, especially, right? Like we are um uh but uh and and some people say like scrum, people like agile people like can say like it's they're religious, like about it, right? Like we're not like religious about scrum, but there's like it's there's like the the steps in Scrum are actually literally called ceremonies, which I guess we can talk about in a minute. But like is there is there um is there is there a is there something you can imagine, a process or project that you can imagine where waterfall would be useful as opposed like where we would choose it over like a scrum methodology?
SPEAKER_01Okay, so first of all, I have to respond to some of some of the other things you said there. Uh I am I am very proud to call myself a scrum bag. Um I I definitely have drank the Kool-Aid. Um you know, my uh my wife and I, when we planned our wedding, we used Scrum to Scrum to do it.
SPEAKER_00Oh, that is so nerdy. Oh my gosh, love it.
SPEAKER_01So nerdy. So nerdy. And so listen, I can tell you right off the bat, there are some type of like you had like did you have like Jura boards, like Kanban boards or something with the key? Well, the great thing about that experience is that I can tell you one of the projects you should not use scrum for is planning a wedding. Are you still married? It's worked out okay. The marriage worked out fine, and the wedding was fantastic. Um but the thing about like uh, and I'm not gonna stay on the wedding thing this whole time, but the thing about the a wedding is that it only happens once. You don't really actually get to iterate on the wedding itself because it only happens one time. You don't get to like like, okay, guys, we're having our first wedding this Saturday. I want everyone to show up. It normally happens most happens once. Normally it happens one time per per couple, at least. Um but there's other projects like that, right? Anything that's only going to happen one time, you can't really use uh you can use you can borrow things from Scrum or borrow things from Agile, but you can't do it exactly that way. And I think one of the best examples is uh space missions, right? Like you cannot deploy and update the software on the rover that we are firing into an asteroid to see what data it collects when it explodes, right? Like you're not gonna get to run that experiment every two weeks and tweak and tune the software and the hardware. And so those things have to be uh big design up front because they only happen one time.
SPEAKER_03You can't deploy software to a rover about to crash into an asteroid yet.
SPEAKER_01Well the interesting thing is that like some space missions we are now able to actually deploy software fixes like as needed, um, which is great because a waterfall process will still have errors in it. Like the software will still have errors that like will need to be fixed anyway. So that's I think the other part of waterfall that you know even if you think it's gonna be perfect, it won't be. So you're gonna end up end up updating it anyway. And so why not just get in the habit of like updating frequently?
SPEAKER_03Yeah. Sarah, do you um like when we were talking about the ceremonies, do you could do you know what we're what we're talking about there?
SPEAKER_00I do. I am a certified scrum master.
SPEAKER_03Oh, you are?
SPEAKER_00I am okay.
SPEAKER_03Well, sorry. Wow, okay. I'm embarrassed.
SPEAKER_00No, no, no, it's okay. I did the training when I started. Um I could know what you guys are talking about.
SPEAKER_03Do you remember can I can I test you? Can you do you remember what the steps of of the scrum cycle are?
SPEAKER_00Um maybe I could study a little bit first and then you can see.
SPEAKER_01This is this is when there's a sudden jump cut. And then you can tell that Sarah's like reading straight off of the website.
SPEAKER_03If this makes it into the final cut, you dear listener, are like listening to something that's not supposed to be here. Um, Greg, do you can you could can you list them out? Do you I assume you remember them being a scrum bag?
SPEAKER_01Oh yeah. Oh yeah. So the basic idea is that the team gets together at the very beginning of the sprint and they have a meeting called Sprint Planning. And, you know, which just goes back to our earlier conversation, like, of course there's planning in Scrum. We have a whole meeting called Sprint Planning. So what else are we doing over planning? Um and that meeting is normally like about a couple hours for a two-week sprint. And during that, the team uh agrees on what work they're going to be completing. They uh figure out like how much they can get done in the two weeks. Um they talk about that work and they make some trade-offs about that work to get something out there faster. Um they might uh set some things aside because they need like a little more information before they could start them. Um and at the end of that meeting, the team gets to work. They start building, they start building software. Um, they split up either solo for something. Like that day. Like that day, literally that day. Yeah. Um they start building software, and then every single day of the sprint, there's a daily stand-up where they coordinate with each other on like what needs to happen to get the the work done that they agreed to get done during the sprint. Now, there's also normally a meeting called Backlog Refinement uh once a week. That's when the team is like talking about the work that might happen in the next sprint. And so teams are always thinking about what they're working on today, and they're thinking about what they're going to work on next. What they're not doing is spending time thinking about what they might work on six months or a year from now. It's just not part of the process. They don't do that because the environment will change in six months or a year. So why spend that time? At the end of the two weeks, they get together and they have a meeting called Sprint Review, where all the work they did gets shown off, everyone sees how it all came together, and they give each other feedback on that work and talk about how that work could be made even better in a future sprint. Um and then they ship the work, they get it out there. And then the very last thing, and this is actually my favorite part of Scrum, and I think that if you're gonna steal anything from Scrum for your own uh business or your own process, uh you should steal this, which is the Sprint Retrospective. And so the whole team gets together for about an hour and they just talk about what went well during the last two weeks, what didn't go well during the last two weeks, and what uh small changes could they make to make the next two weeks the next two weeks even better. And that to me, that reflection, that debriefing, that um intentional uh discussion around performance and putting out quality work is like that's to me where all the magic happens.
SPEAKER_03I would have loved. To have been a fly on the wall for your wedding retrospective.
SPEAKER_02What do you think uh went badly about uh the wedding this uh planning this week, honey?
SPEAKER_01Yes, I uh I admire your empathy, Greg, for being able to figure out uh one of the ways that scrum is terrible for wedding planning.
SPEAKER_03Um man. So that you give like that seems terrific, actually, not thinking my weddings were yeah. I mean I I I I think Greg described the Scrum process as as best as like anybody could. I just the only thing that I would I would I'd want to add is um is that it just it works particularly well with software. Right? I mean the the whole thing about the fact that you can like in construction, you can't build a bathroom and be like, you know what, it'd be better if that bathroom is on the other side of the house. And I'm gonna change my mind every like two weeks. I mean, it it's theoretically possible, but it would be unbelievably expensive. And the reason we have started to move to like a software-based economy and world is because of the fact that we can just pick the bathroom up and move it somewhere else, because it makes sense to do that. But in order to do that, you need a project management methodology that is like flexible enough. Um and then maybe the only other final thing I would like want to add is like, why do you need a project methodology to start with? I I used to I used to build when I was when I my first started out, we used to work in like a shed. Like literally the server room was a garage. It was and then the old part of the house was where the dev sat, um I don't know, mid-90s. And I don't we didn't have we didn't run agile process or anything. We would like come into work every day and we would like try and like solve a particular problem and everyone would work together. And things got messy very quickly because like we were just like working it out all the time, just like inventing ways of doing it. But when you start to get to bigger scales or or process like where you need bigger teams and you need to like put stuff out that is gonna work and is gonna be stable, you all need to be on the same page, and so you have to like pick something to align what you're working on. You you have to all agree about how to do the work, how to chunk it up, and to make sure that uh that it meets the requirements, the the outcomes that you want to are correct. Like you might have a scrum team that part of the process is it has to pass a particular compliance check. It has to pass a particular test. Everything needs to pass a test before it goes live. If everyone is just like doing their own thing, that does not work.
SPEAKER_01Yeah, I think there's a there's another kind of extreme perspective on agile, right? And it's not like uppercase agile, like the agile methodology or the agile manifesto. It's lowercase agile. It's like we should be fast, we should be able to like turn on a diamond, we should be able to do like if something new, an opportunity comes up, we should be able to just grab it and do it. And that is the idea. But a big part of software development for the engineers themselves is that they have to kind of load into their brain a mental map of the software in order for them to know which things they're changing to add new functionality or like change how existing functionality works. And that process, um, if you come in every hour and you say, Hey, it's changed, we're doing something new for the next hour. We're gonna build this feature. It will actually just grind everything to a halt. Because that process of like maintaining that mental map, maintaining that mental model, is like there's a lot of cognitive overhead with that. And you can blow that out of people's brains just by like asking a totally new question about how some like crazy thing might work a year from now. And now you know the team has like shifted their like their mental focus and they have to like spend time getting ramps back up into the current sprint. And so I think Greg, when you described like that process, you were probably running like one hour long sprints, right? Like, yeah, probably technically that's probably what that is. And way that's popular in those days, anyway. Yeah, yeah. That's why it got messy, right? Because it's like you pick up you pick up way more than you can ever finish. And a big part of Scrum is that like when you say you're gonna finish something during a sprint, you mean it. That will actually get done. But then, you know, there's a little bit of discipline around the practice of letting that stuff get done while you're working on what's coming next.
SPEAKER_03And speaking of ending things and getting them done in the right amount of time. I think we're maybe done here, right?
SPEAKER_00Yes, yes, this is great. Uh, I learned a lot. Uh I hope the listener learned a lot. And yeah, thank you to both of the Gregs for your time today. And yeah, have a good weekend. Enjoy your D.
SPEAKER_03Thank you, Sarah. Thank you, Greg. Thanks, Sarah. Good weekend, guys. Thanks, Greg.
SPEAKER_00All right. Bye.
SPEAKER_03Bye.