Ep 44 The Many Flavours of Agile (with B. Pagels-Minor)

One huge frustration for development teams as the process is they're made to follow often unnecessarily. Wars can ensue when teams are forced to adopt an approach they don't believe in. BPGL's minor will show you why different agile approaches can be useful. Welcome to the Business of Software podcast, where we share talks from our conferences and discussions with software people that will make you think. You can find out more at businessofsoftware.org. Hello, I'm Kurt Bailey and this week on the Boss podcast Episode 44 we have the many flavors of agile with BPGL's minor. BPGL loves product development and improving the processes of developing successful products, having worked with small and large tech companies to drive product adoption, improve the product experience and evolve product vision. From Mississippi to Chicago to Silicon Valley, BPG has built their career around building great products for amazing brands, while also working to enrich their community around them. Agile methodology can be confusing and difficult, but BPGL breaks it down to bite-sized slices of delicious cakes that will help every team work better, communicate better and provide better returns. In this talk you will learn how to understand which version of the many flavors of agile is right for your company based on your company with many cake references. Not one to watch on an empty stomach. Happy listening. So this presentation, it's called the many flavors of agile, what's the right one for your team? And so I want to give you a little bit of background as to how this came about. So you know, Mike was talking about bad-ass people and I feel like I'm one of those employees for a lot of my companies. And so when I get frustrated I ended up like just like relling and yelling at my managers being like, "Hey, this, like, why is this thing happening?" Like whatever. So one of my managers is just like, "Well, what's your complaint right now?" It's like, "Why does everyone come to me about agile methodology?" Like everyone comes to me and goes, "Bethany, you're the one you're the expert. Like, you're the only one who can help us figure this out." And I was like, "No, this is really simple. It's as simple as cakes." Right? So I'm going to create a whole presentation about cakes in agile and explain to people how you can figure out what types of systems might work for your company. So let's get right into it. So on the agenda today, we're going to talk a little bit about the issue of agile. We're going to come up with some common examples of agile. We're going to do some agile evaluation criteria. We're going to break it down a little bit. You guys are going to be awesome. And then we're going to apply what we learned and then we're going to do a review. Which by the way, you can tell I'm a product/program manager because there's an agenda for every meeting. I don't go into anything without telling people where we're going to go. So agile at the beginning, I always feel like there should be like that "dududu" music when you do this. But so what happened? So in 2001, 17 guys, which they were all guys, obviously the next one is going to be some women as well. But 17 guys went to this amazing Shale. They really do call it a Shale. I double checked it because I wanted to say that out loud. In Utah, and they were all considered experts on how to build great software. And so what they came up with is it really comes down to 12 principles. And these 12 principles are called the agile manifesto. And it's something I definitely recommend all of you read. In fact, a lot of the things that have already been talked about this morning, they're kind of captured there. Like the principles of how you manage teams, the principles of how you build software, they all exist in the agile manifesto. And it's not that scary, like crazy thing that a lot of people think of when they think of agile mentality, which is that it's so difficult. It really is it. And so I like to focus a little bit on some of the core values. And these are the four core values that are most important to me. And even beyond them being the four core values that are most important to me, I really only look at the bold part. Like I look at individual interactions, I look at working software, I look at customer collaboration, I look to responding to change. When I think about how I make sure that we build successful products at every company I work at, if I follow those four core tenants, if I focus on those four core things, I'm always successful. And it also gives us this idea that processes, even when you think about different frameworks of agile, no process should ever inhibit the ability for a team or a company to be successful. You should always just be kind of kicking the door, asking yourself, hey, we've been doing this for a while now. It seems like some people aren't really understanding this. Like maybe we should do something different. So then, I was like, wait, what are some of the common flavors of agile? So a couple things shared, I know there's going to be someone who goes, well, you have waterfall on this list. You have extreme programming on this list. Why do you have that? Because there is still the very simple principle that most people actually don't run one flavor of any type of software development process. A lot of times you have what I call water job, right? You know, some people call it agile fall, right? Because you're running some kind of like some combination of different principles. And so taking in and taking ownership of the fact that those things could be agile like in some principles, I think really helps. But for the purpose of our presentation today, we're not going to focus on the right side, right? Actually, there's right side for there. We're going to focus on Spotify squad model. We're going to focus on lean, scrum, can, band, waterfall. These are the most common flavors of agile that you're going to actually interact with on a regular basis now. So then, I was like, okay, cool. So I'm telling these folks that this is all really simple. It's all really easy. It's going to be like cake. But how do you actually evaluate this? How do you make sure the ingredients are right? So first, you have to look at your team skill level. And skill level can mean different things, right? Because depending on your product, depending on the type of company that you're running, skill, like someone who would be low skilled in one company, maybe super high skilled in another company. So it really is very important to look at your ingredients on your team to figure out exactly what types of skills you're doing with. You get to think about maturity level. So this is something that gets controversial. It's people are like, what's maturity? I'm like, well, you know, it's my mama would say, I need some grown ass folks who know how to do what they're doing, right? Like, are they grown? Can they act on them? Can they act by themselves? Can they be autonomous? You know, if you can't answer yes to a lot of those questions, you have a very low maturity level at your company. And again, that's perfectly fine. You have to find something that works for those people. Then you have the company risk tolerance. So, as Mark mentioned, I work at Apple now, so now like my risk tolerance is super high. Like, when you have a lot of money behind, you can try lots of different things. But I also acknowledge that depending on your company, you may not be able to take their risk. You know, you may not be able to survive deleting 12,000 files, right? So like, it's very, very important to kind of take that into account and start thinking strategically about what it means to take risk with how your teams work, right? Because if you change, if you make changes and it doesn't work and your company can't accept the risk, changes are you really will not have a company after a drive. Like, you might actually really put yourself in danger. And this team size. Now one of the things here is, and this is something that I will talk to, I'm blue in the face, I fundamentally believe teams shouldn't be more than seven people. If they're more than seven people, you're going to get into very complicated situations. In fact, one of the management principles that I really follow is for every single manager that should not be more than seven people that they manage, right? It's a really great ratio. It allows people to be heard, be understood, be successful, right? And so one of the ways I think about it is you have a small team which is less than five people, medium team, five to seven people. Larg team is more than seven people. And when I talk about team here, there's a couple different ways. So there's teams who are technical teams, so those people might be, you know, the product manager, the program manager, the developers are working on it, the designers, the QA. If you're an HR team, it might be the chief, you know, people officer, their HR managers and, you know, talent recruiters. And because again, all these things kind of like apply to different types of organizations, different types of teams, all that good type of stuff. So then it's like, okay, we got all this information, how are we going to break it down? First of all, we have cake, which by the way, this is a strawberry shortcake, it's my favorite cake, so if you ever want to buy me cake, feel free. So first principle, we have waterfall, and it's frucake. Because it's the thing that people don't seem to like, they're always just like, oh my god, Bethany, their frucake was so horrible, it was dry, and I'm just like, well, you know, that's because they do it so far in advance, right? So frucake, with waterfall, you have to do everything at the very beginning, right? So you have to have all your designs in the beginning, you have to have your entire development strategy in the beginning, and then, you know, kind of get stride up actually, because by the time you start working on it, you're just like, wait, like, my cushion rack actually didn't want that thing, and now I'm already built it, now I got to find some other cushion rack for this thing. But I actually think it could be good for certain things. So I really, really think for very, very large organizations or heavily regulated industries, it totally makes sense to want frucake, right? It totally makes sense to have predictable deadlines, predictable deliverables to make sure that you're going to land that contract. I think a great example of this, so I'm in the board of a health organization in Chicago, and we actually have entire software development team that we work with, and they actually build our, you know, our patient system essential. And so every time we want to make a change, they're like, okay, cool, we'll make that change, but it's going to take exactly eight months. Like, every single time, and then we're always just like, oh my god, like, like, why does these other companies can do this in like a week? Why you have to wait eight months. They're like, well, actually, we have to make sure that it's still a hit by compliant. We have to make sure that every patient record is still there. We have to make sure that because we have a custom solution, because we work with LGBTQ people, that you don't lose the field of like someone being gender non-binary. And so it gets to this idea though that like, it's much more important to have a sustained, successful situation versus actually iterating at the same pace as, you know, some other agile principles. So let's talk about like the types of skills that you have to have. So the cool thing about, you know, waterfall again, because I'm going to talk positively about waterfall for an extended period of time. I know no one's used to this, but this gets comfortable. I actually love waterfall because you can have a lot of different skills, right? You don't actually have to have the most highly skilled people in the world because there's so many checks and balances and so many different things that you have to go through. A lot of time, you're perfectly good. You're going to have a super junior person working on a huge part of the business and have it not actually potentially negatively infect the business. You can also have lots of different levels of maturity. So again, you know, in my experience, waterfall works best when you have some super junior people as well as some super senior people because the super senior people have certain amounts of knowledge, certain amounts of understanding that when it's sure that the documentation is done properly and well at the very beginning. And actually this is one of the few times that you can actually operate with a much larger team. And actually you probably have to because if you really want to make sure you get the designs, you really want to make sure you have an engineering plan, you really want to make sure that you have customer input. It takes a lot of resources to get all that done at the very beginning. And also, waterfall is generally associated with a very low amount of risk, right? So again, waterfall, even though it is fruit cake and we don't always like fruit cake, can actually be super wonderful depending on what industry you're working in. So now we're going to go to Canban. So when I was doing this presentation, I thought it was really great. So my work wife who's my QA was like, Bethany, I'm going to help you figure out which cake she's going to do. And she was like, I'm going to start googling cakes and what they mean. And so she was like, Canban has to be tier-m-su. And I was like, why does it have to be tier-m-su? She was like, it literally means to pick up. And that's what Canban is. She just picked up what's in there. And I was just like, you're all you are doing. You're trying too hard on this presentation. But it worked out. It totally worked out. So in my career, I've really been very fortunate in that the entire way I got involved in Adelaide was because someone was just like, I saw this thing called Canban. And you seem smart enough, you go figure it out, right? And that just took me down the whole rabbit hole of what Adela could be. It's because with Canban, it's so simple. Almost any type of team, like any type of team. This conference is team. You could pick up, could throw a Canban board up. And instantly, everyone would be able to understand what's most important and in which order something should be done. I actually worked with a team, the HR team. And the company is like, 1800 employees. And they wanted to do a project on making sure everyone had a specific path to success. So it's like, your product manager, what is your potential going from this job to this next job after that? And I was just like, well guys, we can't do this the way you guys have been talking about it. I heard about this thing called Canban. Let's just use this board. Let's come up with all the tasks we think we need to do over the next six months. Let's put it in order. Let's put it in the highest priority order. And let's make sure that everyone knows that we only choose the highest priority first. And what's really great about this is it made it so easy for everyone to understand what we were doing and whether we were behind or not. Now, as a product manager, I kind of hated it because to a certain extent, I'm just like, well, but what if I really think I want to reprioritize? I can't independently do that because we've all agreed what's the most important thing. But as a team, the team was just like, this is the most visibility I've ever had in any project I've ever done. And I also feel completely like, you know, empowered to just do the work. Like, I don't have to go talk to my boss. I don't have to go talk to this person over here because this thing is right in front of me and I can pick it up because it's the most important thing that we're working on. And so it's always really good for like highly self-organized mature teams. But what's really interesting about it is it's it requires very low skill level, right? Like the you because you can do this with any team, you don't necessarily have to have the like most talented most impressive people in the world doing it. You just have to have someone who's mature enough to go, this is the highest priority item. I do also recommend that it's for small teams. You know, I really, I've never seen CAN band work exceptionally well for a team that's more than like seven people. In fact, more mostly three to five people. Again, it's because you might run out of work too quickly because CAN band you can only prioritize up to a certain point. And with the company risk because it's so easy to put over everything, you can pretty much do any type of company risk and be able to work with CAN band. Now I have to talk about a negative, right? Right. So I mentioned the product manager part of it. The second part of it is a lot of times companies, senior leadership, don't really like the idea. Right. So I've gone into meetings and been like, oh, I'm just like we should just really do a CAN band board for this particular team, like blah blah blah blah blah. And the senior person's just like, but how do I know it's happening? Has blah blah blah blah blah blah blah. And I'm like, well, because the card goes from there to here. Like if the card goes there, it's done. Like, like why are you worried? Right. And so a lot times from like, I think because it is so easy, it's such a small lift, sometimes it gets very nerve racking because there isn't more process around it. But, you know, as we kind of go through this conversation, you'll notice that I really don't think we should have that many processes. So, you know, I think it's actually a really great first step for teams. So then we have everyone's favorite, Scrum, A.K.A. Chocolate Cake. The reason I call it the Chocolate Cake is because everyone's probably run into a flavor of it at some point. Every single team at some point, you know, someone in your company was like, let's do Scrum. Right. And, you know, I think almost every company I've ever started at, we were at Scrum or we were moving to Scrum or we were moving away from Scrum, something like that. And so that's why it's actually a really great first agile methodology because usually people run into it. Now, I'm going to tell you the kind of difficult part, though. Most software developers hate it. Right. Because they've had really negative Scrum experiences. So, a little background about Scrum. In order for Scrum to actually work, you're supposed to have a bunch of very specific roles. Right. You're supposed to have a Scrum Master. You're supposed to have a product owner. You're supposed to have a development team. That doesn't happen to most companies. I mean, we're talking about, you know, the fact that some companies don't even have product owners or have not assigned product owners. You know, most people who may have a product owner, then doesn't have like a Scrum Master. And if you don't have a Scrum Master, you end up in this situation where like, maybe the product owner is also the Scrum Master. Or in one situation, somehow the QA became the Scrum Master. I don't know how that happened. But you end up with all these people working on dual roles. And the thing about Scrum is, Scrum is supposed to be set up that, you know, means a product manager, I can focus on the business outcome. The development team can focus on building the product. And the Scrum Master is supposed to unblock all of us to make sure we communicate well and to make sure the team is successful. And when you have people working multiple of those roles, when it's happening as a business person, I'm also supposed to be, you know, like if I'm also the Scrum Master, I'm supposed to be unblocking them and making their lives better. But, you know, I'm also the business person and my CEO is telling me, oh no, this is not okay. It has to be both this way. We can't miss this deadline, et cetera. And so create so much conflict and it actually makes a lot of those teams very unsuccessful. And so when I hear a lot of feedback about Scrum, it's just, well, you know, all those stupid ceremonies we had to do those. And the person who ran them was just so inefficient. And like I didn't even understand it. And we never actually did anything that we talked about in the retro. And so I just don't understand why we do Scrum. And I was just like, you know, I don't know either. You know, maybe this is not the right thing for us, right? And so, you know, even though most software development teams run some former Scrum, they actually generally miss out a lot, right? Because they don't have the right roles. And actually it was really a great article. I was talking about the fact that so waterfall actually more than 50% of teams that reported in this survey actually run waterfall. And then another like quarter to 30% actually runs Scrum. And then the two teams that kind of responded were like, I'm going from waterfall to Scrum. I'm going from Scrum back to waterfall, right? So it's actually really, really interesting how this kind of goes. And it also shows that like a lot of tinkering has to happen consistently, right? Because you don't really know if this is the right one for you at all times. So let's just go back to the breakdown. So again, Scrum's great because you can have a lot of different skills, right? It doesn't really make a difference what type of skill levels you have. Team maturity doesn't really make a difference. Team size, small and medium. And company risk, I put, you know, like medium because as I've gone and going through this career thing, what I found is that companies that can take a little bit of risk but are not low risk, right? Like they're not like averse risk. They generally do best with Scrum, right? And I think it's partially because of Scrum with the actual sprint cycles. It makes it very, very easy and simple for leadership to understand when things are to come, what date is going to happen on? And then they love that routine, you know, all the time. Of course, development teams hate it because, you know, most developers are just like, well, Bethany, I said it was three sprints, but you know, it was like four sprints and like five sprints. I don't know how, it doesn't have to be this specific, right? And so it's always kind of like this push pull between leadership and the development teams. So then we get to my favorite, which is why it's fun, Fetty Cake. And this is lean. So I call lean the race for the MVP. The entire point of lean is I need to get to my MVP as quickly as possible so I can go get learnings, so then I can go do a whole new MVP again. I actually love that. I love just building stuff all the time. Not even looking back at it and being like, oh, I got enough data, I'm just going to build something else. I don't know why. I actually probably lack follow-through like Mikey as well. But I just really, really, really love building stuff and getting feedback and just kick and butt and take your names and do what I need to get. And so I work really well with really highly skilled developers in teams of expert knowledge and your given field. So one of my companies that it was so shocking to me to be at a company that ran all lean. Like an entire company that ran all lean, that was a billion dollar company, and nothing burned out. And I was at Cars.com. And the chief product officer just came in and he was like, guys, why is it that it takes like six months? Why does it take a year? Why does it take two years to release basic things? At the time, we were losing so much market share to car gurus. And car gurus basically had the exact same thing that we had. The only difference is that they had way less code. They had way less bureaucracy. And so he came in, the first day, we're going to do lean. A lot of people said no. So he was like, OK, well, you're all fired. We're doing lean. And I was like, well, I'm going to do some lean. Right? Right. And it was one of the best career experiences of my life. Because one of the frustrations I had had is a product manager program. As someone who was very responsible for the business outcomes, it allowed me to tell developers, you're smart. Like, you're intelligent. You know more about this code base. Now, I've been here for two months. You've been here five years. Like, you know more about what we should or should not be doing than I do. And so I got to take on partners for the first time I'm going to career. I didn't have to tell people what to do. All of a sudden, they're all like, they're truly self-organizing teams. They're truly agile teams. They would just come to me. Like, I really come in. I come in. Well, first of all, I'm being truthful. I'm not a morning person. And I'm also living in the West Coast. So it feels like it's eight o'clock to me right now. So y'all are lucky. I'm this awake. And so normally, I work. I come in at like 9.45. I'm like, hey, how are you doing? And 9.45, there would be like, Bethany, we made all these five or six strategic decisions. We think they're going to do all this different type of stuff. Thumbs up or thumbs down? And I was like, well, thumbs up. I mean, you said there's a lot of money. Thumbs up, right? And it was such a great opportunity. It was such a happy team. It was probably one of the most, like, the one of the happiest teams I'd ever worked with. It was for the very first time they were empowered to make solutions, right? And they weren't just following behind me, like waiting for me to give them some kind of response to say that they were allowed to be free. Like, they just knew they could be free, right? And secondly, all of a sudden, I had developers who were like, you know, MVP has been out for two weeks. I went ahead and pulled the dashboard, looking what the data says. Like, I'm not a business person like you, Bethany. But it looks like we should do some more of this. And I'm like, oh, man. And in my favorite part, I just got to go in front of the CEO and be like, yeah, we're making a lot of money. Because look at this dashboard. This guy pulled for me. And I get to show up and just look great, right? And so that's why I'm such a huge fan of lean. But the thing is, it's kind of hard. Running lean is hard. And in fact, when I left cars, there are couple teams that just weren't ready for lean, right? They just could not comfortably run lean. It's because they didn't have the right mix. So here, I tell you, you have to have a high school level. You have to have a high team maturity. You have to have a small and medium team. And your company has to be really, really, really, really willing to take risks. So what happens with infrastructure teams? So some of the infrastructure teams are just like, we cannot take these types of risks. We feel very uncomfortable with this. We want to actually just continue to go with Scrum. Or we're going to continue to go with CANBIN. Which actually makes sense. Because when you do agile properly, all of a sudden, different parts of it work differently for different teams. And in fact, that's how we got this Spotify squad model. So first of all, this is my second favorite cake. It's like an Oreo ice cream cake. Because I like to have my cake any to my ice cream. I don't know. I'm very complicated like that. So Spotify squad model. How many of you have actually heard of the Spotify squad model? OK, so we got some real people who have been here. So what I love about the Spotify squad model is not everyone has to do the same thing, right? Because when you truly become agile, each different team, each different part of the organization, may need to operate differently. And they need to make that choice, right? With Spotify squad model, this team over here can run CANBIN, this team over here can run Lean, this team over here can run SCRUB. And the only thing you have to do is when you work on products, for instance, and my last company, one of the last products I worked on, touched on four different teams, right? So four different teams, completely different principles of how we work, because we all had our own working agreements. And so when we had our first meeting, someone got up on the board and was just like, OK, so which type of communication system are we going to use? Are we going to use Slack? Are we going to use Confluence, et cetera? How are we going to document the work? Are we going to use Trello? Are we going to use Jura? Right? And so we came up with working agreement on the fly in the first 20 minutes where I'm meeting on how we were going to work on a six-month project, right? And because we were free enough with the Spotify squad model to do whatever it made since for us, you know? And it was like this really great moment, because it goes straight from where Lean is like all autonomous, and I just look good without even trying to-- we have to actively choose to work well together, right? And it's something that I found when I was working with different development teams throughout my career, a lot of times people don't make that active choice, right? Instead, they're like, well, I'm the infrastructure team. I'm going to deal with like, I want you to have to do this, and I'm just like, girl, we got to go make money. Like, why are we arguing over what board we're going to use? Like, why are we arguing over how many times we're going to have meetings? Like, instead, let's just focus on freeing ourselves up from these processes and just do the work, right? And it just made a huge difference. But the thing about a Spotify squad model is that you have to trust each other. And this is one that I mean, I think that, even through some of these conversations, we talked about how you inspire employees to be the do their best work, right? Like, ultimately, that's what kind of things we're talking about. Like, how can we unblock people? And one of the biggest blockers is trust. Like, how can you trust Sally over there is going to actually do the things she says? She's going to do, especially when she doesn't work on the same team as you do all the time, right? And so when you go into these models, though, you just have to just give it up. You just have to say, like, I trusted every single person who works with this company is going to do the things they say they're going to do. And when we come up for working agreement, it's going to actually work. And so, ultimately, you do have to have a lot of high-level skills. You have to be very mature. You can be, you know, medium to large size. And your company has to be able to take risks. Now, I want to really hone in on the company taking risks. So I mentioned Lean, where you also have to be comfortable taking risks. And now I'm doing Spotify Squat Model, where you also have to be comfortable taking risks. So I think a great example for my own career. I was working at this really interesting not startup but startup, you know, like those ones that are like a teenager. They aren't crawling anymore. They're kind of running. But then they just like trip all the time. I was working one of those companies. And it was so funny because the leader came and he wanted to be Lean. He was just like, oh, yeah, like, you know, I'm like the coolest dude ever. I give a control so easily we're going to do Lean. And I was just like, I don't think that's going to work at this company. And he was just like, why not? I was like, we don't-- like, we-- like, you sure you can take that type of risk? He was like, no, no, we're really good. I was like, well, but that person over there doesn't want to do that thing over there. Like, I know it's going to be a hard sell over there for that team. And he was like, well, but no, we're just make them. I was like, no, let's just do Spotify Squad Model. I was like, we have great trust. I mean, we mess up all the time. We mess up together though. So we have great trust in each other. But we need to acknowledge the fact that there's going to be teams that are just going to be completely against trying out Lean fully. This is a much better strategy for us. This is going to make us much more successful. And we're not going to have major pushback. And so we went through the Spotify Squad Model. All the different teams are doing their own thing. They actually just worked out exceptionally well. And so it goes back to this idea that the process, again, can't inhibit the autonomy of the team. Autonomy of the team is how you get to that synergy where you don't have to tell people what to do. People will go out, they will educate themselves, they will figure out the best strategies, and they will come to you with that information. And that's where the Antiole manifesto is really talking about, which is it's more about the principles than it is about the process. So I actually thought about this. I was like, well, do I really want to make them answer questions? And I was like, yes, I do. Yeah, I'm a product manager. I always make people do things. So I want to come up with a few different examples, because I've given you lots of information. And I just want to see if you guys can kind of figure out which principle or which process might work for the snare that we have. So, sample one. And by the way, all of these are actual examples that I consulted on, or I worked specifically in. So I know what we would have done, and I'm totally finding if you guys come up with an answer differently than what I would have thought about. So I work in a well-established tech company. We no longer rely on outside funding and are profitable. We are concerned that we are releasing less, leading to not getting learning as quickly. And ultimately, siphoning our ability [BLANK_AUDIO] senior leadership has provided me a rock star team to stop this slide and start pumping out MVP's consistently. What methodology might I implement? You could. That's not wrong. Yeah. Really? Yes, lean. So the key here is the MVP's. The MVP's. But like I said, you can. Because technically it's about experimentation. Maybe I would have started off Kamban first and then I would have been like, wait. These guys like really, really, really have everything set up. So maybe we'll just do lean. Like I just want to empower everyone to do the right thing. Sample number two. I work in the medical insurance industry. My product involves medical records and is governed by HIPAA. When building products, I must ensure every single aspect is approved before we get started to ensure HIPAA compliance. The product cannot change after I start to build due to losing compliance status. What methodology could I implement? Good job. See, I gave you like the really easy one after the like hard one to make sure you guys felt great. That's why. So, Sample three. I am a newer product manager at a pretty well established startup. I have a team of five to seven developers who are mixed bunch in terms of maturity and skill level. I would like to instill some sort of agile methodology. But once you ensure is not too disruptive to our processes. Scrum. Yes. And actually, I literally my very first product manager job. I come in and they were just like, we want to do a process. Can you learn? And I was like, I ain't never done this before. Like, literally this is my first job. But Scrum worked. It was so easy. I am a senior manager at a successful tech company. I think our product is great. As well as a talent we have in our organization. I want to empower the individual teams to make decisions in a decentralized manner so that we can innovate even faster. I mean, there's like some words. Yeah, I'm getting this. I like this. I feel like I'm educating people. This is great. I am a manager outside of the tech portion of my organization. I love how quickly the tech teams release products and innovate for the company. And I would love to bring that culture to my side of the business. I know that technology processes can seem intimidating. So I want to ensure it's lightweight and accessible. Can't be perfect. All right. We are a medium sized tech company with under 1,000 employees. We are very comfortable with agile principles and want more freedom for product teams to build new features. When it releases to go out at a reliable cadence. This is a trick question. This is definitely one where you should try all the things and just figure out which one works best. You have like they already know agile. You could do some scrawling, you could do some can-bay, you could do some lean. You could do anything right there. Just a experiment. You got to figure out which one of your teams is going to work best under. I totally lifted this from the Spotify squad model article because I think it's great. Add-off fits all different types of appetites. And really all you are really trying to figure out is whether we have alignment and how much autonomy we want to give our folks. For me, I am the person who is in that top corner over there. That's the only way I really like to operate in my companies. However, you could be in any one of these other ones. So you just have to figure out where you are in terms of your alignment and in terms of your ability to give your team autonomy to figure out which one might work best for you. So, in summary. Any organization or team can run some flavor of agile. I have done it with HR teams. I have done it with my board of directors for the health organization I work with. I do it with Apple every day. You can do anything. Comping in team maturity, team talent and team size. They dictate what type of agile you should work on. But you should experiment. Again, I thought I was a scrum person. I haven't started to fight scrum product owner and all the other stuff. Like the stuff you get to make sure people hire you. I have all that stuff. But what I found is that I can go into a company and the company is in such different states that it just may not make sense for where they are. I'm not going to do anything for like a month. I want to see what people are doing. Maybe we will do this after a month. In three months I may change my mind. In six months I may change my mind because maybe we have empowered people so much that we can move straight into lean. Those are different types of things. I don't know if I said this enough. But process should not really inhibit autonomy. No process is worth having a bunch of folks who don't feel empowered to do the work. And waste is an enemy. So this is that old school like Toyota, like you know talk. Like how can we avoid waste? How can we avoid wasting time, money, effort, energy, spirit? Let's not do that. So questions. The reason we had you warm before lunch as well. Oh yeah, just to get you guys hungry. He tried to get cakes though. I will say this. Yeah. I thought cakes then lunch is even for boss a little bit. A little bit much. Right questions. First of all, great talk. Love that you brought in the Heinrich diagram at the end. I'm interested to hear you talk a little bit more about why you characterize risk the way you did for waterfall on lean. You said that waterfalls for low risk tolerance companies and lean is for high risk tolerance companies. But isn't waterfall actually really high risk from a desire ability and viability standpoint since you wait until the end to deliver customer value and get that feedback. I mean, it's definitely lower for compliance risk, but just knowing that's only one type of risk the companies have to deal with. And then similarly for lean isn't the point of lean to drive down risk from the get go by testing those those really risky assumptions. Yeah. So the way I think of risk in this in this case, which that's a good point is that I'm thinking about the ability of the company to to sustain. Basically, if a project doesn't get done, right, if a project becomes incomplete is the ability of the company to pivot is basically what I'm thinking of. And so lean the reason I say it's high risk is because the entire principle is to pivot right. You're supposed to get the MVP out there. You're supposed to get the information that you're supposed to build something. And if the information actually says, you know, that was the dumbest idea ever, you just go to the next thing. And so when I think of waterfall, it's generally for companies that have very sustained models, you know, I don't think I don't really see a lot of waterfall companies being like a random startup that's trying to disrupt fintech, right? Like you don't normally see that as a company. Instead, you're looking at like one of the big three financial firms, you know, you're thinking of like some of the largest insurance companies that type of thing. Great. Okay. John here. Bethany, thank you. You reinforce some things for me and you challenge some things that I probably old deer. So I'll have to look at that. But can you talk a little bit about how each of those lend themselves to when you have a distributed team. You know, we have teams that that have broad geographic distributions, some in different time zones, some in art. So one of the first agile principles is that co-location is always the best way to do agile. So I always struggle with this, right? Right? Because like ultimately, that's not how the world's going to go. Right? We're going to continue to be spread out even further. One of the things I talk about is like you have to come up for working agreement on how you communicate. Right? Like so let's so great example is in my last company before I switched companies half my team was based on the west coast and I was based in Chicago. Right? So we had to come up with a flash like to start off with even which hours we were going to work because all of a sudden I was just like wait. It's been like three hours. I haven't gotten the thing that we talked about. And so it turned out that they had completely different working hours. So it's coming up with like a very specific working agreement on exactly how you communicate exactly how you deliver exactly how you should make sure that you are showing progress on different things like that. And again, it's not to like say I'm policing you. It's actually because you're doing it at the very beginning. It becomes less of like I'm just following up after you and more about like well we just came to this agreement so I'm just holding you accountable to it. So specifically those are related process processes that one let itself know that one. Don't don't be the most. Yeah, so again it's it's too hard to like just say like universally because you could be a team that's perfect for lean. That's a distributed team whereas most distribute teams probably would never work with lean right because it's so much more about your team skill level so much more about your team's maturity level so much more about your company and the types of product that you're building. Now if I had to like if you put me cross the cross like if you know me to the cross if I had to choose I probably would actually say like something like can manage something like that where it's very clear whatever the highest priority item is right so then even if you don't communicate every day everyone knows this is number one. Definitely thanks for the talk. I have a question about this skill level especially the photo lean and Spotify something something. When you assess those skills does it only include the skills that are kind of within the framework of a profession or in the. doesn't include the jasmine skills, for example, if developers are there making business decisions, do you expect them to have more than just development expertise? So again, it depends on your team, right? So you have to figure out what skills are most important for your team to be successful, right? So like in a more traditional where you have like a product manager, you have product owners, you have developers, you have Q, like those situations, then a developer doesn't have to ever make a business decision, right? So in that situation, all I'm looking for is a developer who has a high school of being a developer, right? But if I'm in a situation where I may not have some of those distributed roles and then a developer has to also make business decisions, then that's some way that I would actually think about, well, that person has to have a high school if I want to do lean. Another way to put it, if say we want to have to do lean, do we need to send our developer team to some training that is not related to corporate development skills? So I think training is always good, right? So it just really depends on, again, it depends on your skills, right? So one of the things, when I did my PMI ACP certification, one of the things I thought was so cool is this one company that was from the suburb of Chicago sent all of their managers, like even managers who were not going to necessarily be running a lot of those processes, they wanted every single one of their managers to be trained on the concepts of how to do lean, they wanted all their managers to be trained in the concepts of change management and things like that, right? And so they were preparing themselves to allow any of those people to step in and do the work that was necessary. So again, depending on your situation, depending on the roles that you have, you probably will probably need to train some folks. Thanks. Thank you. Yes. So, I have an example for if you have ever tried mixing any of these methodologies like two of them. So, example could be a company which is pretty large. You have a different skill set of developers, majority of them skilled. However, your team is so big that you want stakeholders to also be engaged in the process. So, what I'm thinking is that have you ever taught or practiced mixing lean which dev team is going to practice internally, however on the stakeholders side using something like Canvas, so they stay on track with their products. Oh yeah, no, totally, 100%. And in fact, in some ways, some of the methodologies are too far out of bounds for stakeholders, right? Like it's too convoluted or complicated. So you would maybe have a KMN board so they can just easily see this is a project. One, it's now in progress and it's done, right? I definitely agree with that. You want to make it as simple as possible for stakeholders. Thank you. Is there a particular methodology that you find or have observed that is less frictional with continuous deployment? So getting software into production regularly without a lot of distraction. Any of these can be used for that, right? So because I've worked on completely different companies that have used all of these different methodologies and we all did continuous deployment, right? So I think again, it depends on your company, right? It depends on your team, it depends on what you're working with. I find that lean is probably my favorite for that, right? Because the developers are really empowered to make the right decision for the business. So if they find a mistake, you know, at 9 a.m., they can have it in the afternoon release and we have a better experience for our customers. Thank you. I have a good talk. To my mind, isn't Kanban from lean? Like Kanban is a manifestation of lean? So the way I like to think about this is, agile is the wrapper, right? And how you apply it, there's like five degrees of separation between these, right? Like there's like barely that much difference. It's really just more like which ceremony you're going to have. Who needs to be involved, right? So Kanban and lean are cousins, but I would not say they're the same thing. What would be the characterizing difference between the two of you? So with Kanban, again, this is very simple principle, which is, what work do we need to do? What work are we currently working on in what's done? Lean can have that exact same principle, but it's way more about autonomy, right? So the thing is you don't need to have a list of what needs to be done, because your team can just decide that morning, we want to raise this MVP to do this XYZ thing, and that may not be on the board, right? Because you've got new data that says that this isn't the way you should move. >> Or maybe I'm just a crazy red deck from Nevada that doesn't know anything. But my vision of Apple is, they're not, the stuff that I get from Apple comes once a year, which makes my brain say, waterfall, where's the lean coming in? >> So one, you notice I did not mention Apple. >> Gotcha. >> And I will not mention Apple. So there we go. >> Cheers. >> [LAUGH] >> [LAUGH] >> I mean, if you want to catch me in a corner that's not recorded, maybe we could talk. >> [LAUGH] >> Yeah, and cake. >> And cake, yes. >> [LAUGH] >> Hi Bethany, thank you. Chicago representing, right here. >> Awesome, awesome. >> So as I'm sure you've seen in implementing Agile, I have dealt with a lot of resistance to the change and challenges with adoption. Even when I present the actual scientific evidence of Agile, methodologies, to executive leadership and to stakeholders, I still encounter this resistance to change. So have you encountered that and how have you gone about getting the buy-in? >> So constantly, yeah, it's a constant issue. That's why I mentioned so many people have gone through terrible experiences with Agile. I completely acknowledge that it's implemented poorly, it's not well thought out. And so you get into it and then people are just like, I hated everything about Agile. I never want to go back, I'm still scarred. And then we get to be that person coming afterwards, which is like no, but it really works, right? So there's no good way to go about it, right? There's no good way to convince people who have been burned multiple times that Agile is now good. So one of the things that I always ask is for a small pilot, right? It's like, hey, just give me one team over here. We're gonna try it out. If I have more consistent results, can we then expand it, right? And it's worked pretty well for me because you do have to show them to prove to them that it works. Another thing that's worked pretty well, there's some really great Agile coaches out there. So having someone come in and just do a day of talking, especially when they can talk about different examples. Like this one Agile coach, which I can't think it was named right now, but he was talking about gaming development. So gaming development is notorious for never being on time, for putting out very buggy things, for having a huge turnover, right? Because people just get burned out about it because it's so terrible. He was talking about how he was able to put Agile methodology in and he started off again with a small pilot. He was like, let me just give you this one team that's supposed to be focused on his one product. And I'm gonna show you that we're gonna hit our deadlines. And that team became 40% more efficient and they also are leaving it five, right? And so then everyone's just like, well, no, we want to do Agile too, because we're leaving it five, right? So I think it just really, if you really have to prove it to him, you just have to show them that this is something that's possible. And that's the thing about Agile principles, though, you have to have a lot of trust, right? And so sometimes I'll go up to someone and say, I know I'm five foot two black and super, super butch. But I don't understand why you don't trust me. Like, look at this face. Like, I'm adorable. Right? And so that's the thing. You just really have to just break them down. >> In your discussion of your frameworks, you talk about the relative skills that maturity of the ICs. You talk about the tolerances of the company. The thing we're not really talking about in the middle is the manager, really you. >> So that's the thing, true Agile, I'm not a manager. I'm just one team, people. I'm just giving my expertise on the thing that I know about, right? There shouldn't be, because I mean the whole thing is itself organizing teams, right? So that means that every person on the team should be able to step up and say, Bethany, we shouldn't do that. Or Bethany, I know we plan for this thing, but now I think it's actually going to cost us way more. We're not going to get the value. Like every single person, that's one of the things that like in my career, they haven't figured out yet that I just don't tell them things. Right? I just show up and go, this is the data, this is the research, this is what we probably should build. Guys, help me figure out how to break this down. And they started doing it. Even when it was scrum, I didn't have to run ceremonies anymore. Everyone was like, well, I really want to make sure we get stuff done from Retro. So I'm going to take ownership of that. You know, I want to make sure that our daily standards are better. And I just got to, again, walk in at 9.45 with my coffee and look cute. You know? Yeah. Now, that's not always the perfect situation, right? Like not everyone is good managers. In fact, we already learned earlier today that the number one reason people quit is because they're managers. Right? And so sometimes in agile, you have to fire the managers. Right? Because there are the ones who are blocking the actual process. Thanks for listening to the Business of Software podcast. For more information, go to businessofsoftware.org.