What is the deal with Agile and all it’s variations?

Agile is all over software development, and it has spawned a lot of variations. So, why is Agile so popular for development? When is it not a fit? And how do the popular Scrum and Kanban fit in?

Full Transcript Below:

Cris:

So how does an Agile method of development help address software projects in general?

Andrew:

So it’s really great when you can do an iterative approach based on a lot of just learning and whatnot.

Cris:

I obviously taught Kanban and Scrum over on the Agile side.

Andrew:

How realistic that is. How realistic that’s going to line up with the real world. That’s debatable.

Cris:

So Andrew, we’re jumping in today and we’re talking about development styles. I want to focus more on what would be the Agile development styles. So we’re going to try and talk Scrum and Kanban a bit, but I think naturally we’ll probably pivot to maybe fixed projects, your fixed bid and maybe black box style projects and stuff.

Andrew:

Yeah, sounds good.

Cris:

But in your interpretation, what is Agile? What does Agile development mean?

Andrew:

Sure. Well, Agile is just a methodology for dealing with constant change, typically in software. It’s just a very iterative approach where you’ve got cycles of feedback from customers, iterative learning and improvement, with the idea being that the end goal is ever shifting and we need a way to compensate for that.

Cris:

Okay, so we’re talking obviously software development. Most of the time, these are ideas that maybe are building off of something that exists already in the market or is brand new. So how does an Agile method of development help address software projects in general? Is that a good thing for software projects? Is it a bad thing? How is it going to go?

Andrew:

Yeah, it’s a great thing when you can do an iterative approach where you’re basing a lot of your development on what are customers saying, this thing that you put in front of them. You didn’t get it quite right, or they didn’t even quite know what they needed now they use it. So, it’s really great when you can do an iterative approach based on a lot of just learning and whatnot. Not as great when you have a very specific number of things you have to get done, and it’s extremely rigid timeline, extremely rigid budget. Something like that it’s going to be more of a waterfall type mentality where everything is planned and I’m moving. How realistic that is, how realistic that’s going to line up with the real world, that’s kind of debatable. But that is traditionally how people have dealt with really static projects.

Cris:

Got you. So let’s maybe break those down a little bit. You mentioned waterfall. I obviously taught Kanban and Scrum over on the Agile side, so maybe define those a little bit for our viewers.

Andrew:

Yeah, so Scrum and Kanban are both just Agile methodologies that can be used independently. They could be a hybrid combined together. Scrum is really focused on, oftentimes it’s deliverables, but oftentimes it’s two week deliverables where you’ll plan out the work for the next two weeks, you get an idea of your velocity. We can complete typically this amount of work in a two week period, and then you just really focus on those things. They get out to the customer because you’re releasing and then you’re gathering that feedback and you’re constantly iterating over and over again in this learning Scrum process and Scrum has roles to it. You’ve got a Scrum master who keeps everything on the rails and asks certain questions to guide the discussion. You’ve got a product owner, which is typically the client who’s the advocate for the the client that says, “This is what my customers need.” They don’t have an understanding necessarily of how these things are going to be implemented, but they do define the priorities and the requirements and ultimately they prioritize them and say, “This is more important than that. You need to deliver these things first.” And then of course you’ve got the development team, so that’s more of the Scrum methodology and then Kanban, it’s a very visual process. You use a Kanban board that looks like a bunch of cards on a board.

Cris:

Oh, like the card wall?

Andrew:

Yeah.

Cris:

Okay, got you.

Andrew:

Yeah, exactly. And that’s just really about velocity. It’s about focusing on a small amount of items and just maximizing throughput. But there’s not this predefined release cycle to it. It’s just all about throughput and velocity and I would say it’s simpler on the surface. There’s not all these different roles. It’s more about just getting throughput and providing this visibility.

Cris:

Yeah, starting with the task here, the definitions or I shouldn’t say definitions, the priorities of things are adjusting and then you’re getting something processed and you’re moving it through and across this board and it’s just going back and forth until it gets out.

Andrew:

You can see cards moving, exactly. These are the cars, the five cars that these three people are working on and we expect to see them progressing through this board and other cars moving to in progress.

Cris:

Okay, got you. So circling back a little bit, we talked about obviously Agile works very, very well for projects that again, are a little more, as I guess I would say ethereal and open-ended on stuff. But is there a place where you really would run into those hurdles where having an Agile methodology on your project is just not going to work well? You talked about very tight definitions, but let’s break that out a little more. What does that mean? Having tight definitions for your project and why Agile doesn’t really work well for that?

Andrew:

Well, It can still work well, but there needs to be a real sense of priority. If these things get done, but these things don’t get done, that’s okay because we put those really important things in the initial releases. So there’s still some flexibility that’s needed there with this understanding that we may not have budget or time for everything. Then Agile can work well or these are the most important things, these are less important. I’m essentially saying the same thing, but there’s got to be the sense of priority. Where it doesn’t work well is I need it all, I need it within this exact period of time, there can be no change in the plans, there’s no room for customer feedback. Thinking more along the lines of government RFPs and things like that, where it’s just extremely rigid. I would say, not that Agile was impossible, but-

Cris:

Much harder.

Andrew:

It’s not as good of a fit for something like that where you don’t have these feedback loops and whatnot.

Cris:

Got you. How should you be aware of how to budget as a client if you’re going to go down an Agile road because it’s different than Fixed-Bid.

Andrew:

Well, you’re going to budget in terms of sprints. So you’re going to set a budget for let’s say, 20 sprints, knowing the sprint is two weeks, multiply that by 20. And then you know how many developers you have on the project and ultimately you’re going to budget out a project that’s going to take so many sprints, that many iterations. Now, how many sprints you need is a different question. And it comes more back to roadmapping and breaking, defining your requirements, defining your success criteria, really understanding what your users want and then going through this whole roadmapping process of breaking things down into chunks of work that can be at least estimated at a fairly high level. This is going to take one to two weeks and then you can get the idea of this scope of, “Okay, this is going to be a project that’s going to take somewhere between 18 to 25 sprints. Do I have a budget for something like that?” If not, well, then we better start shaving features or at least saying these are the important ones and then we’ll keep going if it makes sense.

Andrew:

So that’s really we’re doing the MVP comes back in of let’s really focus on what are the minimum things we need for this project to be viable, the minimum viable project, that’s MVP, and really putting those things first. And so that’s how you’re budgeting is. You’re budgeting around your MVP, what we initially need and then it’s up to you based on the response you get, if it makes sense to keep going down that path.

Cris:

Should your project ever change methodologies throughout the course of a project? This is more of opinion.

Andrew:

I think it’s a waste of effort if you’re changing methodologies during it. So if you’re starting Agile and you switched to Waterfall, you probably grossly misunderstood what your requirements were. So I think it wouldn’t be the best. I think it’s just best to understand what your success looks like and ultimately how much flexibility you have in delivering that. But to say, “We’re going to switch from one Agile methodology to another, like from Scrum to Kanban.” Certainly you could do that if doing a two week release cycle that makes sense. Yeah, absolutely. You could just focus more on velocity.

Cris:

Got you. Perhaps, obviously I’m slightly different opinion, maybe is that you could have more of an upfront maybe R & D phase of work that tends to tailor more to an Agile style of stuff because you’re trying things out, getting the feedback, and then maybe you line your feature set in, and now you go with more of an actual fixed approach for a phase one version of the project. Does that seem like it would make sense possibly?

Andrew:

If there an advantage to doing it that way, I would just question what’s the advantage to that.

Cris:

Got you. Could be investors, could be overall cash flow changes, things of that sort. Usually money comes into play when you’re talking about how you want to go about something.

Andrew:

Right, yeah. And that might be a good reason.

Cris:

That’s good. Well, any other thoughts for those watching us today? Anything that is useful as far as methodologies, how you should pick them, why you should pick them, so on and so forth?

Andrew:

Well, certainly using Kanban is less structured than Scrum, so if it’s just a matter of I’ve got tasks I want to get going, that’s certainly the one you can hit the ground with the fastest. It doesn’t necessarily mean it’s the best for you, but-

Cris:

It’s starting point.

Andrew:

Yeah, It’s a very loose…I don’t know if unstructured is the right word, but yeah, it’s a way to get going quickly. And I would say too that Agile methodology isn’t really necessarily a competitive advantage that Affirm does that now because it’s just so common.

Cris:

So prevalent, yeah.

Andrew:

So it’s more about understanding what it is and the pros and cons of the trade off. But yeah, I would say probably most companies are doing Agile at this point or some flavor of it anyways.

Cris:

Cool, awesome. Well, I appreciate you taking time to chat on this and hopefully those of you who’ve been watching this were able to get a little bit of information and hopefully have a better track on trajectory of their project and how they want to make it excel even more.

Alexandra:

Thanks for joining us for this episode of Bixly Tech Tuesday. I hope this conversation with Cris and Andrew has given you a little bit more insight into Agile methodology and even other ways to approach planning your software project. If you have any questions about what we talked about today, don’t be afraid to leave those in the comment section down below and don’t forget to check out our free custom guide. It’s actually linked in the description to this video, and that will walk you through the whole process of planning out your whole app idea. If you feel like you’re ready to talk about the idea that you have, go ahead and check out our website, bixly.com. There’s actually a button there, free app validation meeting. And then you actually get to meet with Cris for 60 minutes to talk about your app idea and start strategizing how to execute it. Thank you for joining us for this episode of Bixly Tech Tuesday.