B. Pagels-Minor: The Many Flavors Of Agile

Agile methodology sounds confusing and difficult, but B Pagels-Minor breaks it down to bite-size slices of delicious cakes that will will help every team work better, communicate better, and provide better returns. B has been a firm believer in agile for many years and has been bringing the joy of lean, kanban, and scrum to the workplaces of many through thoughtful and direct communication and consultation.

In this talk from BoS USA 2018, you will learn how to understand which version of the many flavors of agile is right for your company based on your company and team size, skill level, project complexity and more. Contains many cake references.

Warning – do not watch on an empty stomach.

Slides

Transcript

So I definitely was really worried about those stairs. These are new shoes and I was like if I didn’t slide all the way down everyone’s going to be really excited.

So like Peldi already said this I’m nervous too, you guys are so cool! I’ve talked to you, you are all very amazing people. So if I started like getting clammy just like look at me really deeply, look at my soul, inspire me, and we can keep on going.

So this presentation. It’s called ‘the many flavors of agile and 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 end up like does he like wrestling and yelling at my managers being like “I hate this, like why is this thing happening?!” Like whatever. It’s one of my managers is just like “well what’s your what’s your complaint right now?” Why does everyone come to me about Agile Methodology? like everyone comes to me and it goes you know Bethany you’re the one you’re the expert. Like you’re the only one who can help us figure this out. I was like ‘No this is really simple. It’s as simple as cakes’. So I’m going to create a whole presentation about cakes and 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 history of agile, we’re going to come up some common examples of agile, 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’ve learned and we’re going to do a review. 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, the beginning” I always feel like there should be like that doo doo doo music we do this, so what happened was in 2001 all 17 guys which they were all guys – obviously the next one’s going to have some women as well. But 17 guys went to this amazing chalet (they really do call it a chalet I double checked it because I want 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 in this 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 been talked about this morning are kind of captured there. Like the principle 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 crazy thing that a lot of people think of when they think of agile methodology which isn’t so difficult. It really isn’t. 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 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 in every company I work at. If I follow those four core tenets if I focus on those four core things I’m always successful. And it also goes with this idea that 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 just 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 couple things here 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 gel. You know some people call it agile-fall; 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.

Agile Evaluation Criteria

But for the purpose of our presentation today we’re not going to focus on the right side. I’m going to focus on Spotify squat model and focus on lean, scrum, Kanban, and waterfall. These are the most common flavors of agile that you’re going to actually interact with on a regular basis. So 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 have to look at your team skill level and skill level can mean different things right. Because depending on your product depending on your type of company that you’re running, someone who would be low skilled in one company might be 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 dealing with.

The other thing is your maturity level. This is something that gets controversial. People think ‘what’s maturity?’. My mama would say “some grown ass folks know how to do what they’re doing”. Like are they grown? Can they act by themselves? Can they be autonomous? You know if you can’t answer yes to all those questions do 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.

As Mark mentioned, I work at Apple now, so like my risk tolerance is super high. When you have a lot of money behind you, you can try lots of different things. But I also acknowledge that depending on your company you may not be able to take that risk. You know you may not be able to survive deleting 12000 files. So it’s very very important to kind of take that into account and start thinking strategically about what it means to take risks with how your teams work. Because if you make changes and it doesn’t work and your company can’t accept the risk chances are you really will not have a company afterwards; like you might actually really put yourself in danger. And there’s team size now one of the things here is and this is something that I will talk till I am blue in the face. I fundamentally believe team shouldn’t be more than seven people. If there are more than seven people going to get into very complicated situations. In fact one of the management principles I really follow is for every single manager there should not be more than seven people they manage. It’s a really great ratio. It allows people to be heard be understood be successful. 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 seven people large 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 the product manager, program manager, the developers are working on it, the designers, the QA. If you’re an H.R. team it might be the chief people officer, their H.R. managers, and the talent recruiters and because again all these things kind of like apply to different types of organizations different types of teams all that type of stuff. So then it’s like okay we’ve got all this information how we can break it down.

Fruitcake

First of all we have cake – by the way this is a strawberry shortcake. It’s my favorite cake if you ever want to buy me cake. Feel free. So first principle we have waterfall and it’s fruitcake. Here is the thing that people don’t seem to like. They’re always just like “Oh my God, Bethany the fruitcake was so horrible! It was dry.” I’m just like well you know that’s because they do it so far in advance. A fruitcake with waterfall you’d have to do everything at the very beginning right. So you have to have all your designs and in the beginning you have to have your entire late development strategy in the beginning and then you know kind of gets dried up actually because by the time you start working on it you’re just like, wait, my customer actually didn’t want that thing and now already built it. Now I got to find some other customer who’ll buy 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 wholly makes sense to want fruitcake 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 on 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 patient system, essentially. And so every time we want to make a change or like okay, cool, we’ll make that change but it’s going to take exactly eight months. Every single time. We’re always just like ‘oh my god like why does these other companies do this and like we why do you have to wait eight months’ they’re like well actually we have to make sure that still 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 you know and so I’m against this idea though that 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 the types of skills that you have to have. So the cool thing about waterfall – because I’m going to talk positively about waterfall for an extended period of time I know no one’s used to this, but just get comfortable – I actually like 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 in 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 affect the business. You can also have lots of different levels of maturity. So again in my experience waterfall works best when you have some super junior people as well some super senior people, because the super senior people have certain amounts of knowledge, a certain amount of understanding that will make 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 have actually 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. Also waterfall is generally associated with very low risk. So look again waterfall even though it is fruitcake and we don’t always like fruit cake can actually be super wonderful depending on what industry you’re working in.

Let’s now go to Kanban.

Tiramisu

So when I was doing this presentation that was really great. So my work wife who’s my QA was like “Bethany, I’m going to help you figure out which cakes you going to do”. She’s like “I’m going to start Googling cakes and what they mean”. So she’s like Kanban has be tiramisu! And I was like “why does it have to be tiramisu?”. She’s like it literally means to pick up and that’s what can advantage you just pick up what’s written there. And I was just like you’re ‘girl 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 agile was because someone was just like I saw this thing called Kanban and you seem smart enough you go figure it out. And that just took me down the whole rabbit hole of what agile could be. Because with Kanban it’s so simple. Almost any type of team like any type of team. This conference is a team. You could throw a Kanban board up and instantly everyone will be able to understand what’s most important and in which order something should be done. I actually worked with an H.R. team at companies with 800 employees and they wanted to do a project on you know making sure everyone had a specific path to success. So it’s like okay you’re a product manager what is your potential. You know you know going from this job to this next jobs this next job after that and I’m just like well guys like we can’t do this the way you guys have been talking about it. I heard about this thing called Kanban let’s just use this board. You know let’s come up with all the tests we think we need to do over the next six months let’s put it in order let’s put it in the highest party order and let’s make sure that everyone knows that we only choose the highest priority first. It what was 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 the product manager I kind of hated it, because like it to a certain extent I’m just like Well but what if I really think I want to reprioritize like 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 it also feels 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 a very low skill level. Because you can do this with any team. You don’t actually have to have the most talented, most impressive people who are 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’ve really never seen Kanban 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 Kanban 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 Kanban. Now I have to talk about negative. So I mentioned to the product manager part of it. The second part of it is a lot of times company’s senior leadership don’t really like the idea. So I’ve gone to meetings I’ve been like Oh I’m just like we should just really do it came on board for this particular team like blah blah blah blah. And the senior person is just like but how do I know what’s happening. And I’m like well because the card goes from there to here. Like if the card goes there that is done like why you worried?

So a lot of times from like I think because it is so easy it’s such as 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 to 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

Chocolate Cake

Then we have everyone’s favorite scrum a.k.a. chocolate cake. They call it the chocolate cake it’s because everyone is probably wanting to 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 moving away from scrum. That’s why it’s actually 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. 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 rules 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 signed product owners. No most people who may have a product owner who’s done then doesn’t have like a scrum master. And if you don’t have a scrum master, you end up in a situation where like maybe the product owner is also scrum master or in one situation somehow the QA became a 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 means a product manager I can focus on the business outcome; the development team to focus on building the product; and the scrum master’s 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 those roles what ends up happening is the business person. I’m also supposed to be you know like if I’m also the Scrum Master 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 that’s not okay, It has to be built this way. We can’t miss this deadline etc.’ And so it creates 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 ran them was just so inefficient, and like I didn’t understand it, and we never actually did anything that we talked about in the retro. So I just don’t understand why we do scrum. I was just like you know what, I don’t know either! Maybe it’s not the right thing for us right. And so you know even though most software development teams run some form of scrum they actually generally mess up a lot. Because they don’t have the right roles. And actually I was reading this really great article, it was talking about the fact that more than 50% of teams that reported in this survey actually run waterfall and then another like 25-30% actually run 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 that’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: scrums great because you can have a lot of different skills right.

It doesn’t really make a difference what type skill levels you have seen maturity does really make a difference. Team size small to medium and company risk I put like medium because as I’ve kind of gone through this career thing what I’ve found is is that companies that can take a little bit of risk but are not low risk. Like they’re not like averse to risk. They generally do best with scrum. And I think it’s partially because of the 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 didn’t 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 I was like four sprints in like five sprints I don’t know has it does it have to be this specific”. And so it’s always kind of like this push pull between leadership and development teams.

Funfetti Cake

So then we get to my favorite, which is why it’s funfetti cake. And this is lean. So I called 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 that I could go to a whole new MVP again. I actually love that. I love just building stuff like all the time not even like looking back and be like oh I got enough to hit I’m 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 like kicking butt and taking names and doing it again and so I worked really well with really highly skilled developers and teams of expert knowledge and are getting filled. So one of my companies that it was like so shocking to me to be at a company that ran all lean like an entire company ran all lean. There was a billion dollar company and we did nothing like burned down and I was at cars.com the chief product officer just came in and he was like “guys like 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 continues basically the same thing that we had mainly differences is that they had way less code they had way less bureaucracy. And so he came in like the first day like it was like we’re going to do lean a lot of people said no. So he’s like okay well you’re all fired. We’re doing lean. And I was like well I will do some lean!

And it was one of the best career experiences of my life because one of the frustrations I’d had as a product manager program with 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. I’ve been here for two months. You’ve been here five years. 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 in my career I don’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’d really come in – well first lets be truthful I’m not a morning person and I’m also living on 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 – so normally at work I come into like nine forty five I’m like Hey how are you doing. And I’ve got to either be like Bethany we made all these five or six strategic decisions we think they’re going to do all these different type of stuff. Thumbs up or thumbs down. I mean you said it’s a lot of money. Thumbs up. Right? And it was such a great opportunity. It was such a happy team. It’s probably one of the most like one of the happiest teams I’ve ever worked with. It’s for the very first time they were empowered to make solutions right. If they weren’t just following behind me like waiting for me to give them some kind of response they said that they were allowed to be free like they just knew they could be free.

Secondly, all of a sudden I had developers who were like you’re the MVP has been off for two weeks. I went ahead and pull the dashboard. Look at what the data says. Like I’m not a businessperson like you Bethany but it looks like we should use more of this. And I’m like ‘Oh man’. I just got to go from the CEO and be like ‘yeah we’re making a lot of money because look at this dashboard this guy pulled for me’ in an image 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 you know the thing is, it’s kind of hard. Running lean is hard. And in fact when I left cars there are a couple teams that just weren’t ready for lean. 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 skill 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 really really willing to take risks. So what happens with infrastructure teams? 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 with Scrum or we’re going to continue to go with Kanban. 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 the Spotify squad model.

Ice-cream Cake

First of all this is my second favorite cake. It’s like an Oreo ice cream cake – because I like to have my cake and eat it too – ice cream isn’t cake, I don’t know I’m very complicated like that! So Spotify Squad Model. How many of you actually heard of the Spotify Squad Model? Okay, so we got like got some real people up in here! So, what I love about 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. With Spotify squad model this team over here can run Kanban, this team over here can run lean, this team over here can run scrum. And the only thing you have to do is when you work on products for instance at my last company when the last products I worked on I touched on four different teams. 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 something got put up on the board it was just like okay so which type of communication system we’re going to use when you slack, confluence, etc.? How are we going to document the work or really use Trello, or use Jira? And so we came off a working agreement on the fly in the first 12 minutes where I’m meeting on how we’re going to work on a six month project. Because we were free enough with the Spotify squad model to do whatever made sense for us. And it was like this really great moment because it goes like 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. And it’s something that I found when I was working in a different development team throughout my career, a lot of times people don’t make that active choice. Instead they’re like ‘well I’m the infrastructure team I’m going to do how I want, you have to do this…

And I’m just like girl we had to go make money, like why are we arguing over what border we’re going to use? Like why are we arguing over how many times we’re going to have meetings? Instead let’s just focus on freeing ourselves up from these processes and just do the work. And it just made a huge difference. But the thing about Spotify squad model is that you have to trust each other. And this is one that I mean I think that you know even through some of these conversations we’ve talked about how you know inspire employees to do their best work right. Like ultimately this kind of things we’re talking about like how can we unblock people. And one of the biggest blockers is trust. 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? When you go into these models you just have to just give it up. You have to say like I trusted every single person who works for 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 medium to large size and your company has to be able to take risks. I want to really hone in on the company taking risks. I mentioned lean, that’s where you also have to be comfortable taking risks, and now I’m doing Spotify squad model where you also have to be comfortable taking risks. So I think a great example, from my own career, I was working at this like really interesting not startup but startup you know like those ones 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 on those companies and it was so funny because the leader came and he wanted to be lean you just like all you like you know I’m like the coolest dude ever, I give up control so easily, and we had a conversation, he said:

“We’re going to do lean.”
“I don’t think that’s going to work at this company.”
“Why not?”
“Are you sure you could take that type of risk?”
“No, no we’re really good.”
“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.”
“We’ll just make them.”
“No let’s just do Spotify squad model. It’s like we have great trust, I mean we mess up all the time, I think we messed up together though. So we have great trust in each other but we need to acknowledge the fact 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 with all the different teams were kind of like doing their own thing. Then it 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’ll educate themselves. They will figure out the best strategies and they will come to you with that information. And that’s what the agile 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 ‘do I really want to make them answer questions?’ and I was like ‘yes, I do’! I’m a product manager I always make people do things. So I want to come off a few different examples because I’ve given you lots of information. That’s what you see you know if you guys can kind of figure out which principle or which process might work for the scenario that we have.

Putting it into practice

Example one, 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 fine if you guys come up and answer differently than what I would have thought about: “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 learnings quickly, and ultimately stifling our ability to innovate. Senior leadership has provided me a rockstar team to stop this slide and start pumping out MVPs consistently” What methodology might I implement?

Audience Member: Kanban

Bethany Pagels-Minor: You could. That’s not wrong.

Audience Member: Lean

Bethany Pagels-Minor: Yes lean. So the key here is the MVPs. But like I said you can’t because technically it’s about experimentation. Maybe I want to start off Kanban first. And that would’ve 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.

Example 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.

Audience: Waterfall

Bethany Pagels-Minor: Good job! I gave you the really easy one after the hard won. To makes you guys feel great. So example three: “I am a newer product manager at a pretty well-established startup. I have a team of five to seven developers who are a mixed bunch in terms of maturity and skill level. I would like to instil some sort of agile methodology, but want to ensure it is not too disruptive to our processes.”

Audience Member: Scrum

Bethany Pagels-Minor: Scrum! Yes, and actually my very first product manager job I come in and they were just like say we want to do a process can you learn.
And I was like I’ve never done this before like this my first job but scrum worked so easy.

Example four: “I am a senior manager at a successful tech company. I think our product is great as well as the 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.”

Audience Member: Spotify Squad Model

Bethany Pagels-Minor: You’re all getting this. I like this. I feel like I’m educating people. This is great.

Example five: “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. 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.”

Audience Member: Kanban

Bethany Pagels-Minor: Kanban. Perfect all right.

Example six: “We are a medium sized tech company with under 1000 employees. We are very comfortable of agile principles and want more freedom for product teams to build new features but need releases to go out at a reliable cadence”

Audience Member: Scrum?

Audience Member: Kanban?

Bethany Pagels-Minor: It’s a trick question! This is definitely one where you should try all the things and just figure out which one works best. Because they already know agile. So you think you could do some scrum, could do some Kanban you could do some lean, you could do everything right there. Just experiment. Because like you you’ve got to figure out which one your team is going to work best under. So in review, I totally lifted this from the Spotify squad model article because I just think it’s great. Because agile fits all different types of appetite and really all you’re really trying to figure out is whether we have alignment and how much autonomy we want to give our folks. And so you know, for me, I’m the person who’s in that top corner over there like that’s the only way I really like to operate in my companies. However you could be in any one of these other ones. Right. And 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.

In summary any organization or team can run some flavor of agile. I’ve done it with H.R. teams. I’ve done it with my board of directors for the health organization I work with. I do it at Apple everyday. You can do anything. Company and team maturity, team talent, and team size they dictate what type of agile you should work on. But you should experiment. I thought I was a scrum person. I haven’t started fights ground product owner and like all the other stuff like the stuff you get to make sure people hire you. I have all this stuff right. 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 love being able to tell someone I’m not going to do anything for like a month; I want to actually kind of see what people are doing. And I was like ‘well maybe we’ll do this after a month. But you know in three months I may change my mind. In six months I may really change my mind because maybe we’ve empowered people so much that like we can move straight into lean which is where I want to be all the time anyway. So those are different types of things. And I don’t know if I’ve said this enough but like process just really should not inhibit autonomy. No process is worth having a bunch of folks who don’t feel empowered to do the work. And waste is the enemy. This is an 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.

Q&A

Mark Littlewood: There was a reason we had you on before lunch as well.

Bethany Pagels-Minor: Oh yeah just to get you guys hungry. He tried to get cakes that I will say this.

Mark Littlewood: I thought cakes then lunch is even for BoS a little bit much. Right Questions.

Audience Member: First of all great talk, loved 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 and lean. You said the waterfalls for low risk tolerance companies and lean is for high risk tolerance companies. But isn’t waterfall actually really high risk from a desirability 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 that 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 really risky assumptions?

Bethany Pagels-Minor: Yes. 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 sustain.
Basically if a product doesn’t get done, if a project becomes incomplete, its 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 there. Suppose to get the MVP out there, you’re supposed to get the information, then 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. When I think waterfall is generally for companies that have various 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’re thinking of like some of the largest insurance companies. That type of thing.

Mark Littlewood: Great. Okay. John, here.

Audience Member: Bethany, thank you. You reinforce some things for me and you challenged some things that I probably hold dear. 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 we have teams that that have broad geographic distribution some in different time zones some that aren’t.

Bethany Pagels-Minor: So one of the first principles is that co-location is always the best way to do agile. So I always struggle with this. Because like ultimately that’s not how the world’s going to go. We’re going to continue to be spread out even further. So one of things I talk about is like you have to come up with a working agreement on how you communicate. Like so a great example is my last company before I switched companies. Half my team was based in the West Coast and I was based in Chicago. So we had to come up 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 than the Chicago team. And so it’s coming up with 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. 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. I’m just holding you accountable to it.

Audience Member: Specifically though as it relates to the process itself. Does one lend itself better? Does one stand out as don’t do this remotely?

Bethany Pagels-Minor: Yeah. So again it’s too hard to say universally because you could be a team that’s perfect for lean that’s a distributed team whereas most distributed teams probably would never work with lean. 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, the type of product that you’re building. Now if I had to like if you nailed me to a cross, like if I had to choose, I would actually say like something like Kanban 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

Audience Member: Hi Bethany, thanks for the talk. I have a question about the skill level especially for the lean and Spotify [squad model] when you assess those skills, does it only include the skills that are kind of within the framework of a profession or it doesn’t include adjacent skills. For example if developers are there making business decisions do you expect them to have more than just developing expertise.

Bethany Pagels-Minor: 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 QAs, like those situations then a developer doesn’t have to ever make a business decision. So in that situation all I’m looking for is a developer who has a high skill to be a developer. 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 while that person has to have a high skill if I wanted to do lean.

Audience Member: Another way to put it if I say we want to do lean do we need to send our developer team to some training that is not related to development skills.

Bethany Pagels-Minor: So, I think training is always good. So it just really depends on your skills right. So one of the things when I did my PMI ACP certification when things like that was so cool is this one company I was from a 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. 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.

Audience Member: Yes so I have an example for if you have ever tried mixing any of these methodologies? 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 thought or practiced mixing lean which the tech development team is going practice internally, however on the stakeholder side using something like Kanban so they stay on track for their products?

Bethany Pagels-Minor: Oh yeah. Totally 100%. And in fact some ways some of the methodologies are too far out of bounds for stakeholders. Like it’s too convoluted or complicated and so you would maybe have a Kanban board so they can just easily see this is Project 1. It’s now in progress and it’s done right. I definitely agree with that. You want to make it is as simple as possible for stakeholders.

Audience Member: 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?

Bethany Pagels-Minor: So any of these can be used for that. I’ve worked on completely different companies that use all of these different methodologies and we all do continuous deployment. So I think it again depends on your company. Depends on your team, depends on you 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. If they find a mistake in 9a.m. they can have it in the afternoon release and then we have a better experience for our customers.

Mark Littlewood: Thank you.

Audience Member: Good talk. It to my mind isn’t Kanban from lean like Kanban is a manifestation of lean?

Bethany Pagels-Minor: So the way I like to think about this is agile is a wrapper. And how you apply it, there’s like five degrees of separation between these, there’s like barely that much difference. It’s really just which ceremonies you have. Who needs to be involved. So Kanban and lean are cousins, but I would not say they are same thing.

Audience Member: What would be the characterizing difference between?

Bethany Pagels-Minor: Kanban is very simple principle which is what work do we need to do, what work are we currently working on, and what’s done? Lean can have the exact same principle but it’s way more about autonomy. So the thing is you don’t need to have a list of what needs to be done because your team could just decide that morning we want to race to this MVP to do this X Y Z thing and it may not be on the board. Because you’ve got new data that says it like this isn’t the way you should move.

Audience Member: Maybe I’m just a crazy redneck from Nevada that doesn’t know anything, but my vision of Apple is, the stuff that I get from Apple comes once a year which makes my brain say waterfall. Where’s the lean coming in?

Bethany Pagels-Minor: So, you notice I did not mention Apple.

Audience Member: Gotcha

Bethany Pagels-Minor: I will not mention Apple. So, there we go.

Audience Member Cheers.

Bethany Pagels-Minor: I mean if you want to catch me in a corner that’s not recorded, maybe we could talk. With cake!

Audience member: Hi Bethany. Thank you Chicago representing right here. 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?

Bethany Pagels-Minor: So constantly. It’s a constant issue. That’s why I mentioned like so many people have gone through terrible experiences with agile like 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 like I never want to go back I’m still scarred and then we get to be that person come in afterwards was just like ‘No but it really works’.

So it’s 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 I always ask is for a small pilot. It’s like Hey just give me like one team over here. We’re going to try it out. If I have more consistent results can we then expand it. And it’s worked pretty well for me because you do have to like show them to prove to them that it works. Another thing that’s worked pretty well there some like really great. Like agile coaches out there. So having someone come in and just do like a day of talking especially when they can talk about different examples like this one agile coach which I can’t name right now. But he was talking about like 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 put agile methodology in. He started off again with a small pilot who’s like let me just give me this one team. Suppose we focus on this one product and I’m going to show you that we’re going to hit our deadlines and that team became 40% more efficient and they also are leaving a five. And so then everyone is like well no we want to do agile too because we’re leaving at five. 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 is possible. And you know that’s the thing about agile principles. You have to love trust right.

And so sometimes I’ll go up to someone 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; I’m adorable!” And so that’s the thing you just really have to do is break them down.

Audience member: Thanks.

Audience member: Thank you so much for a wonderful talk. In your discussion of like your framework you talk about the relative skill set maturity. You talk about the tolerances of the company. I think we’re not really talking about the middle is the manager, really you.

Bethany Pagel-Minor: So that’s the thing. True agile. I’m not a manager. I’m just one team people. You know I’m just giving my expertise on the thing that I know about right there. There shouldn’t be because I mean the whole thing itself organizing teams. 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 planned for this thing but now I think it’s going to cost us way more we’re not going to get the value like every single person I like. That’s one of the things that in my career they haven’t figured out yet that I just don’t tell them things. I didn’t show up and go ‘This is the data. This is the research. This is what we probably should build. Guys helped me figure out how to break this down.’ and they start doing it even when scrum. I didn’t have to run ceremonies anymore. I was like ‘Well I really want to make sure we get stuff done from retro so I’m going to take I mean to take ownership of that know I want to make sure our daily stands a better someone take ownership of that.’ And I just got to again walk into 09:45 with my coffee and look cute, you know. Now that’s not always the perfect situation right. Like not everyone is good managers in fact we learned earlier today that the number one reason people quit is because their managers. Right. Is it sometimes in agile you have to fire the managers right. Because they’re the ones who are blocking the actual process.

Mark Littlewood: Thank you! Fantastic Bethany. Brilliant.

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

---