Software Development Methodologies (Two Big Players)

April 27, 2020

Jake Anderson

Q:  Let’s talk a little bit about software development methodologies.  What types exist? And we can kind of dig a little bit into them, but I guess from an overview, what is out there that you might hear or that companies might follow? 

A:  There’s really two big players in this space, one of them being “agile,” I like to also think of, sometimes people say “lean,” I think they’re more or less one and the same, and “waterfall,” are really the big two.  Depending on the organization you’re working with, some of them might have benefits over others. We tend to lean more towards the agile approach, but the big difference is, maybe it’s easier to start with waterfall.  So, in a waterfall, you think of it as a waterfall, it goes down one set of rocks, then it goes down another set of rocks, and then down one more, same thing. So, it might start in sales and then sales hands it off to design, and then design finishes and hands it off to development, development finishes and hands it off to QA.  So you’re kind of going down this exact series of steps and when one team is done, they are done. So when Design is finished with design, they’re no longer involved in that project and they’re moving on to the next things. A lot of companies operate this way, it’s a very common model. Another way is agile, and agile takes this group of people and it gets them working on the same thing together and they’re slowly moving that needle more and more.  So, say you’re building out user authentication for an application. Well, Sales is obviously going to sell that user authentication feature, but they’re going to be talking with designers and developers during that process, as well as talking with the client, making sure that everybody is aware of exactly what user authentication needs to look like. And then Design and Development get together and say okay, what do we have available to us? Are we working with Facebook and Google and doing kind of a social sign on?  Are we just doing a typical email password sign on? Do I have to confirm my password, confirm my email? And so working together throughout this process and then Development builds it, shows it again back to Design, hey Design, is this good? Or hey, I ran into this small piece, what can we do? And working together throughout the process feature by feature.   

Q:  You mentioned that we focus more so on lean software development or again, an agile kind of methodology.  Talk to me on why are there certain projects that we work on that have caused us to lean that way? Because obviously there are pros and cons in different situations for different companies, for different types of projects.  Why did we go the route of a more lean or agile approach?  

A:  We were waterfall for a long time and we’ve been migrating more and more into the agile space, and the reason being is when you take that waterfall approach, cool, the client has a great experience through the sales process, now we’ve gotten to design and the design process has gone really well, and they’re super excited, they’re starting to see their idea come to life.  Well, the biggest chunk of time when you’re trying to develop something is the actual development of it. It’s the writing of the software. And so you have this period to where you’ve gone through sales and design, now Design has handed everything off to Development and there’s potentially this huge span of time to where maybe the client is waiting to get feedback on something or all of a sudden we get partway through as a development team and we run into something and Design and Sales have moved on, they’re no longer involved in this, and so having to get them back into the context and mindset and remember everything and all the decisions that they made , why did this designer put this button here in this way, most of the time if we went the agile approach they remember that and it makes a lot of sense as to why they did it, but forcing somebody to go back to the mindset that they were in potentially weeks, if not months ago, given the fact that they’ve been working on other things now on that of that, is difficult.  

Q:  And I find with a lot of projects that we’ve learned from, it’s when we’re dealing with more  difficult cases or complexities, or even just a larger invariability in what the client may actually know versus what they need to know, what I mean by that is, we have clients a lot of times come to us and they have incomplete operations, which is okay.  But it’s the lean or the agile processes work a little bit more to have everyone commit and do a lot more resource gathering, testing, and challenging those assumptions in the beginning and then putting those I guess bigger complexities, features, functions, ideas out in front of them so they can respond to them, versus waiting two months, three months, six months, depending how long it took to design and do the UX and UI of that.  And so it’s been huge, because it’s just as much of a mental game, it’s flipping and making sure the client knows, hey, let’s put the hard work at the beginning and let’s make sure you know that a lot of things that we’re building, especially in the software space and the automation space, they’re interlinked through operations and too many times, let’s say it’s something new, it’s usually something new, an innovation team is doing something new, a midmarket company is switching their processes, or it’s a startup and they have never done it before.  Too many times the startup was dreamt up a couple months ago, it’s on a napkin, we’re trying to formalize it. If we went the waterfall approach, you get six months in and everything has changed. And it’s just natural, because it’s new. They’re trying to think thorough and during the course of time no matter how long it is, they wake up in the middle of the night going ooh, I think I forgot this piece, I forgot that piece, I don’t know how fulfillment is going to work or logistics, or all these different things. So, that’s where, from a client side perspective, I found it’s tough.  It’s definitely, you have to be able to commit to the lean approach. You have to be a able to be involved and be ready to think, not just hand us what you want and go, I’ve done it, but integrate in to understand and then see things and make decisions in a more real-time, let’s just call it faster fashion, than waterfall may provide.  

A:  Yeah, and I think you also highlighted one of the key benefits of agile, and that’s flexibility.  And when you take a waterfall approach and Design has finished the design, and you as the client have off on that design, that’s essentially finalized all the different features.  And as a development team, we go and we scope, everything is based off of that design, now we get it and we build it out. And so if all of a sudden if your needs change, customers dictate something else, well, you’re kind of in a weird spot, we’re in a weird spot, because it’s like we already agreed to do this, and you wanted to do this, but now things changed, versus when we take more of this agile approach and we say, this is the amount of time we’re going to try to get this thing done in, and let’s just work together.  Yes, it does require more commitment from you, the client, but it gives us a lot more flexibility as we grow, and we get to essentially build each new room of the house together, versus you saying this is what I think I want my house to look like in six months and we go and we build it. It’s like, no, let’s start in the living room, what do you want your living room to look like, and then the kitchen, those are pretty important, so let’s talk about that, and let’s slowly get to the whole house being built rather than you trying to think in your head of this is what I need my house to be.  

Q:  I think one of the biggest things that we try to counteract, because one of the cons that comes out of sometimes client’s perception of lean software development, is budgets just expand.  You’ve heard the stories that clients go, well we’ve done this internally, externally, and it was supposed to take three months and it took 24 months and it cost our company hundreds of thousands, or millions of dollars.  And so that’s something that we try to take great pride in protecting that budget, and it’s something on our end that it’s hard to always overcome, but it’s forcing discovery in the beginning, it’s challenging those client assumptions and saying hey, is this your core offering?  Does this provide value? And so that’s something that I’d say we battle to do, because it would be too easy, but we’d probably have no clients. We’d still have them come to us and we’d just say, we don’t know, maybe three months, maybe six months, sounds great for business because we could just take as long as it takes, but obviously that doesn’t work for most clients.  And so tailoring it down, and that’s where user stories come in, and it’s more than just that, it’s more getting on the same page with the client, really hammering hard on these discovery sessions and coming out in agreement and alignment on what we’re doing, why we’re doing it, and what that next step looks like. And we talk about, not to go too far off, is too many clients think they’re building something for the next million users, and one, it’s not necessarily about the users, but sometimes we realize they’re only building their product to get an ROI and they will get the ROI with the next 100 purchasers or buyers of their product.  And so it’s focusing on that, because if you spend 40 grand and make 400 off 100 U, why are you focusing on U? Sure, it’s fancy, it’s the pie in the sky, but that’s where in lean software development and agile methodology, it’s trying to fight against the tendency to let things go on. We like finite schedules, as people, as humans, it’s hey, we only want to work on this project optimally for 10-12 weeks, even if you want it to go on for 40, let’s just take a chunk of 10-12 out, realize what you need, build that, reassess, because lots of things are going to be changing.  

A:  Yeah, and you point out that agile is not a silver bullet, it doesn’t solve all processes.  If you as an organization are like ooh, agile, that sounds great, I’m going to implement that now, we’ve worked with a lot of companies that are agile and it has taken them over a year if not years to get certain things launched.  And a lot of that has to do with maybe not implementing agile properly. The whole purpose is people over process, making sure that you’re giving the people that are working on this project the time and space that they need to get that project done, eliminating any other distractions or responsibilities from their plate.  That means having 2-hour long meetings every day about what they should be building while they’re in that meeting is obviously going to delay your timeline by 20%. And so that’s just for one meeting. And so the more meetings you have, so there’s this give and take, but the purpose of agile, again, is people over process, the flexibility, having and taking that iterative approach, as well as getting user feedback and client feedback a lot faster.

Start a Project