In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by his collaborator, Sam Falco. Together they’re going to be tackling three Scrum-related questions that they dug up on Quora.
Sam finds himself running into these particular questions fairly frequently. In fact, every new client seems to have a set of similar questions. So, if you’ve ever pondered, “What is better: one-week or two-week Sprints?” “What is the Scrum Master’s role?” “What are the tasks that a Scrum Master has to perform?” or “What are the first things a Scrum Master should do when starting at a new organization?”…Tune in.
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann: [00:17] Welcome to this episode of the Agile Coaches’ Corner, I’m Dan Neumann and again joined by my collaborator, Sam Falco. And today we’re going to be tackling three Scrum related questions that we dug up on Quora. So hopefully providing some value to the people that asked those and they tend to be somewhat common questions.
Sam Falco: [00:37] Yup. We run into the same questions. Almost every client, uh, has very similar questions. How do I get started? Can I change things? You know, what, what should I do in my daily stand up, which is the one that makes me cringe? And I have to say that what’s called a daily Scrum, there’s a difference. Uh, so one of the things that I learned, I, I started out in Scrum in sort of a siloed organization. Uh, didn’t realize that there was a Tampa Bay agile community. Actually, it was kind of fledgling when I was uh, getting started. I didn’t know about it. And then when I left that organization and I started looking for other jobs, got involved with the Tampa Bay agile community and discovered that most of the problems I’d had, everyone else had. Most of the questions I had everyone else had. And it was a relief to realize that, Oh, it’s not that I suck at this. Everybody has these problems. So it’s kinda cool to go out to Quora, see these questions. They’re very similar to the ones we see at clients. And let’s talk about some answers then maybe give some people some help.
Dan Neumann: [01:44] That sounds great. So let’s start with the first one. Do you prefer one week or two week Sprints and why?
Sam Falco: [01:50] Well the Scrum guide says up to a month and so I don’t have a particular preference of one or two week Sprints. It depends on what the, what the situation calls for, what the organization calls for. We want to balance the how much time it will take for a development team to do the work that it needs to do with the risk the organization is willing to absorb by not releasing. So if an organization can wait three weeks without messing with the Scrum teams Sprint goal or asking for changes, then three weeks is a good length. If they are going to be interrupting every week because of production support or the market is just that hot, then maybe one week Sprints are the answer. But again, mitigated against how fast can the Scrum team deliver because if the Scrum team struggles to break its work down into that small of a chunk, then it won’t do to put that extra pressure on them.
Dan Neumann: [02:54] Yeah. I think the concept of can the Scrum team deliver in a one week Sprint is one of the constraints is an interesting one because to me that that seems a little bit like an opportunity. Yeah, it’s hard. It’s hard to deliver in two weeks Sprints. And the reason I maybe pull on that one a little bit is because delivering in two weeks is hard and I tend to encourage people not to extend the Sprint length just because getting something done is hard. Um, that to me is an interesting opportunity to go figure out what makes it hard and see if we can’t make some of those things easy.
Sam Falco: [03:28] Right. And I’m talking from an assumption of you’re getting started with the a new Scrum team or Sprinting in a new organization, a new product perhaps, and trying to decide what, what it’s going to be. And so I will often encourage teams in that situation to come up with our definition of done, brainstorm, talk about it, and then look at their backlog with the first couple of items. And can we do all this? Can we get UAT if UAT is, is needed, can that be done inside of a certain timeframe where we’re going to have to chase down people, et cetera. Okay, well maybe we need a little more time. Um, I don’t put too much weight on that. Like it’s not, I, I will push back against the team that is trying to extend it because they’re a little nervous because my suggestion is usually bring less into the Sprint. But I have occasionally run into situations where the complexity of the work is really difficult to break down into small enough chunks that you can say, all right, we’re going to do, you know, four things this Sprint or five things that Sprint and they say, no, we just got these big honkin problems to solve and they take a couple of weeks and we want to have three week Sprints because we really want to make sure we deliver a good product. Okay. That’s a good answer. But then if the business comes back and says, no, we need it in two weeks and we have a, we have to hammer that difference out.
Dan Neumann: [04:48] Yeah. The ability for the team in the organization to maintain focus for the Sprint duration, whatever it is, one, two, three, four weeks is really important. I worked with a team that, um, it was a distributed team, so we had the developer in Eastern time zone UI, I’m sorry, we had the Product Owner in Eastern times on us and a team in China and we had a very challenging time. Complex business domain and articulating enough of that, given the need to do Sprint planning over the phone and massive time zone differences. So one side of the phone call was always ready to go to bed. By the time Sprint planning was starting. Biologically their body was declaring that and we ended up going to one week Sprints because the domain was complex enough. The language barrier was steep enough that we just couldn’t plan two weeks to save our lives and have any kind of predictability that we can achieve a Sprint goal in these two weeks. So we went to one week Sprints and the success rate went way up. Of course, they were a little tiny, tiny increment every Sprint. Um, our challenge we ran into there was, uh, more of a cultural one where other teams were looking at this one and going, Mmm, you babies, you can only do a one week Sprint. And so the fact that we were being really successful but didn’t really fit in with the rest of the groups and how they were operating, it made it a big deal. And they, uh, despite the success at one week Sprints went back to two. Um, because of the, uh, kind of the peer pressure, it was a fascinating little cultural experiment there.
Sam Falco: [06:27] Yeah. Interesting. The idea that that one week Sprints is a baby step. To me it seems, it has always seemed to me that the shorter Sprint lengths feel more pressure and more hectic than the longer Sprint lengths. Even though proportionally you’re probably spending about the same amount of time in overhead and, and, and meetings, you know, lower roughly 10% of your time is spent doing Sprint events and another 10% for refinement, but just has always felt like therw more pressured and they’re more frenetic. So interesting perspective that, Oh, that’s, that’s a baby step.
Dan Neumann: [07:06] Yeah. I want to go touch on that overhead thing because one of the reasons I don’t think either of us would articulate is well, there’s more overhead for this duration versus that one. So a shorter Sprint planning a shorter Sprint, we’re going to have less to plan, we’re going to have less to review. There’s a shorter retrospective. And so for me it scales rather linearly.
Sam Falco: [07:28] Right. And, and I raise that because I will sometimes hear clients say, well, we want to go to a three week Sprint because all of the meetings and there’s all of those meetings. And so I’ll ask a couple of questions there. One is, how much time do you think these Sprint events will take? And I’ll work it out and show them that that’s why I was able to say it’s roughly 10% of a, of a team’s time. If you scale those events down proportionally. Only one, of course that doesn’t shrink. It’s time boxes, the daily Scrum. Um, so it’s roughly the same. And then I’ll say, what do you mean by all of these meetings? And very frequently to find out is it’s all of the meetings that the organization has layered in or that never got replaced. They are there, they’re not serving any purpose different than Sprint events. And so that’s often an opportunity to say, do you really need all of these meetings because maybe it’s not all of these meetings in Scrum, it is all of these meetings that you are wasting your organization’s time and money on that don’t provide value when you could just do these four instead.
Dan Neumann: [08:38] I have had a similar experience with the all these meetings and have asked similar questions and, and uh, the fact that we’re both at AgileThought is nice, but we didn’t collaborate on the answers here, but right. It’s, it’s, well the status meeting. Okay, well that’s in the Sprint review. Well, the, you know, the creation of this report, the backlog refinement meeting. Well, Scrum guide doesn’t say you have to have meetings for that and you don’t have to run multiple times a week and you didn’t worry. You like the backlog just has to be refined. And so I do find that it’s meetings that maybe even once served a purpose in Scrum but have stopped serving a purpose and they’re just time sucks now.
Sam Falco: [09:16] So I think the final answer to do you prefer one week or two week Sprints is the classic consultant answer. It depends.
Dan Neumann: [09:22] Nah, I like to experience, I’m just kidding. Actually, I love one week Sprints. I love one week Sprints. I just haven’t found another team where they’d been willing to do them or where it’s provided that much more value. But in this, in that one instance, we really were, um, feeling a ton of value from a one week Sprint. So let’s move on to question number two. What is a Scrum Master role and what are the tasks that a Scrum Master has to perform? So I feel like it’s loaded because it’s so definitive. What must a Scrum Master do?
Sam Falco: [09:58] Right. Um, yeah, and I get that question too. Like what, especially what are the tasks? Um, I had someone ask me how to help them write a job description for Scrum Master. And through talking to them, it became quite clear that what they really wanted was a classic project manager. And that was an interesting conversation because they wanted to do Scrum, but they just didn’t grasp why that was a different role. And so we had to have a deeper conversation. But also I’m just thinking of how many times I have seen job postings that the Scrum Master role facilitates these meetings, schedules these meetings, make sure that, uh, and it’s very command and control. And there have been a few where I’ve thought, you know, I’d like to apply for that job just so I can go to the interview and tell them how, how they’re doing Scrum wrong.
Dan Neumann: [10:50] And then send them the bill. But so, so I have to put on my, so that was a little devil that pops up on my shoulder once in a while, just makes me say stuff. So there’s, there is the challenge of meeting somebody where they are. And so, you know, as a Scrum Master, right, they are responsible for coaching the Product Owner and the development in the organization. And there will be times where the organization’s trying to have them do things that aren’t in line with the Scrum framework or maybe aren’t helpful to Scrum team. And so I would think they do then have a duty to help coach that business along. And sometimes that does mean kind of holding your nose and doing the thing for a while, even though it’s maybe distasteful, but hopefully then through empiricism. So transparency, inspection, adaptation, working to improve the system over time. So I would say that’s, that’s a “has to perform” task.
Sam Falco: [11:46] Right. So asking the question, what value are we getting out of this activity? I went in as a Scrum Master to an organization and they handed me this stack of, well it was a virtual stack because it was all electronic, but just this list of things I had to do that were basically ITPM tasks. And I look through it and I said, well, I’m, I don’t want to do this. This is not why I joined. And I had to talk to my manager and we went through what are the things we could actually do without. I had to swallow it, do some of the things that I really didn’t want to do, but continually ask and through her, uh, ask the organization, why are we doing this? How is this giving value and putting numbers on it. I spent this much of my time and you’re paying me this much to do this. Are we getting value out of it? That is equivalent of that? But I think we’re going a far field from the actual question, which are, what should we do that’s there? What are the tasks.
Dan Neumann: [12:44] What do they have to do? What do they have to do?
Sam Falco: [12:47] They have to do so they have to remove impediments for the Scrum team with the caveat that impediment means the things that a team has tried to self organize around solving and literally cannot. It’s not whatever little thing a is a roadblock in their way. So really digging in and raising those organizational or technical challenges. You know, we literally don’t have a piece of equipment we need. We need funding for that. Go to the organization and say if you want your product, you need to buy us this gizmo. Um, so that’s a has to do, has to clear impediments. Once it’s clear that the team cannot clear them. Coaching the team and protecting the team, helping people outside of the team understand how to interact with the team. I believe the Scrum guides phrase for that is helping others to understand what interactions are helpful and which are not and how to change the ones that are not helpful. So coaching the team and coaching the organization, how to work in Scrum as a team matures that I would expect the Scrum Master then to start moving away from direct team service, still helping them when needed, but the team will begin to be better and better at handling its own stuff and be working with the organization on how to spread Scrum, how to spread agile values and principles.
Dan Neumann: [14:13] Yeah, that so the, I think the half too is you have to coach the Product Owner. You have to coach the dev team, you have to coach the organization into your point. Yeah. Maybe the dev team, hopefully the dev team at some point gets into this groove where they have really embraced the Scrum values and they are continuously improving more autonomously all the time. And then then the weight shifts to kind of higher order types of engagement with the Product Owner or how to do good product management things and to the organization how to more fully adopt Scrum and get more value out of that.
Sam Falco: [14:48] So I think it’s maybe not as definitive as someone would like the answer to be, but what does the Scrum Master have to do? The Scrum Master has to do whatever is necessary to help the team be successful.
Dan Neumann: [15:03] And then that’s it. And that’s it. I mean, that’s all they have to do. Yeah. So that is right. And so that, that is the hard part of the Scrum Master role. So that is a nice segue then to our third question is what are the first things a Scrum Master should do when starting at a new organization?
Sam Falco: [15:33] All right, well let’s, um, let’s identify some assumptions here.
Dan Neumann: [15:37] We get to imagine our context. Yes, yes. We’ll, we’ll set our own context.
Sam Falco: [15:41] Reading the question. Literally word for word, uh, should do when starting at a new organization, uh, are we assuming this as literally a new organization or the Scrum Master is new to this organization?
Dan Neumann: [15:54] Let’s assume new to an organization doing Scrum, because I’m assuming all this because I’ll assume that they were hiring a Scrum Master and that it wasn’t just somebody who showed up and for day one was like, I am a Scrum Master and surprised people.
Sam Falco: [16:10] Well, well the reason why I thought of other angle would be interesting is if a startup or a new company is saying, all right, we’re going to start and we’re explicitly going to start by using Scrum. What would you do? What would you do in that situation? Because you are, you’ve got a Greenfield and presumably you’ve got someone who’s already really bought into the concept. I would hope that would be easier in many ways than coming into an organization that you’re trying to change.
Dan Neumann: [16:38] Well, let’s circle back on that one after we, uh, they’re jumping into the pot of warm water already.
Sam Falco: [16:44] So the first I think I want to do when I’m coming into a new organization as a Scrum Master is give the team that I’m going to work with a reason to trust me. You come in cold, they don’t know you. They have no necessarily a reason to distrust you, but they also don’t have a reason to trust you. And there may be some trust issues that have nothing to do with you. I came into one place and they had had in the space of six months two different Scrum Masters who they’d come in, started making changes and telling them things to do and then moved on. So what I do in that situation, and I’ve used this in multiple organizations, is I create a mind map of me. Um, essentially I’ll have me in the center and then a branch for career, a branch for hobbies, a branch for family, a branch for where I’ve lived, that sort of thing. And I fill it out and I just project it and I do a half an hour ask me anything. They can ask me any question they want based on what they’re seeing and that it really builds raport very quickly because they are going to ask you the questions that they’re interested in, not what you feel like telling them or what you assume that you’re going to tell them. And they quickly see that you are being honest and open with them. You know, assuming you’re being honest and open with them.
Dan Neumann: [18:04] Well which, which is you’re kind of hopefully a prerequisite for this thing. So yeah, you, you need to establish a reason for them to trust you. And what you’re talking about is one way of modeling some vulnerability. Hey, here’s, here’s me and to, um, kind of yes and that I did that with a Scrum team that I was coaching where there’s just, there’s weird vibes on the team. There were arguments over how much we should document and there was the Scrum and agile don’t work person on the team. And um, so we did, we did a, um, a journey line which started from left to right over time and kind of as the line would be up if it was a good experience, if it was a negative and they kind of drew out their timeframe and well, the person who wanted to document everything was from a highly regulated background, financial institutions and such. So it made total sense that level of documentation made sense in that context. We had to have then a conversation, does it add as much value now? And the agile won’t work person was in a company that was quote doing agile, but anytime they had to fix a bug, they had to go into like six or seven instances of the app and fix the same bug in the same code because it was just, so I’m like, yeah, I’d hate agile to that. Makes sense. Let’s, you know, yeah. So let’s not do that. And so the vulnerability and getting people to share their perspectives created some opportunity for coaching.
Sam Falco: [19:27] Right. And that’s another way that I do that. So after I do the ask me anything, I will do one on one interviews with the team, 15 minutes tops, someplace away from their normal work environment as private as I can make it and just ask them to tell me a little bit about your background and your experience with agile, your feelings about it. I’ve already made it clear through the ask me anything by now that they’re not going to hurt my feelings, that I’m willing to listen. I don’t take notes during these because that tends to look like you’re making records. Um, you know, afterwards I may jot down a few notes to myself of things that I want to cover or you know that came out, but while they’re talking I just listen and do that with the whole team and reveal none of it to anyone. Again, builds that trust and ask the team what their challenges are. Have them tell me. I went into one place and they said, here’s your team. There are 18 people on it. And my thinking was, well that’s the first thing I’m going to have to tackle is this team is too big. And if I had done that, I would have damaged the team and my reputation from the get go because they figured out how to make an 18 person team work really well. They had another problem. And because I kept my mouth shut and listened, they told me what the problem was and I helped them figure out a solution to that problem. Later on they decided, Hey, we’d like to split up into three small teams and we worked on that. But if I’d come in and said that’s it, this is too big, you guys don’t know what you’re doing. That would have been worse than not coming in at all, I suppose.
Dan Neumann: [21:11] Yeah. So listening for where the team sees those opportunities to make adjustments is a huge place. Right? You don’t, you don’t have to come in and be the answer giver. In fact, it’s probably best if you don’t come in and be the answer giver. Um, with the exception I think of if somebody is asking you about the Scrum Framework specifically. So if it’s a, an unambiguous question, what does Scrum say the role of the Product Owner is, or what’s a product backlog or those kinds of, um, important, uh, they call them trivia, but they’re really important trivia that you should know what those things are if you’re a Scrum Master and that’s a great place to be really definitive, but other than that really absorbing the context that the team is doing without, without absorbing it to the point where you’re like, yeah, everything, we’re just going to keep doing all this stuff, right? We still have to, you still have to put in place a continuous improvement mechanism, a way to inspect and adapt, but starting to understand what’s there first.
Sam Falco: [22:10] Yeah. And once I’ve begun building that rapport with the development team, of course, I’m also doing this with the Product Owner and because it often gets overlooked the Scrum Masters duty to serve the organization. Uh, I want to touch on, you should be networking within your organization. You should be learning the politics. You should be learning who’s who, uh, you should be learning who can get funding for things. Who’s the, um, who’s the, the Corporal Klinger of your organization, who knows just who to call in some other unit to get resources or, uh, equipment, that sort of thing.
Dan Neumann: [22:50] So, so for millennials, Sam, can you translate who Klinger is?
Sam Falco: [22:55] So Corporal Klinger was the company clerk who in the later seasons became very effective and efficient and he, he, as I said, he would know right where he could get a particular piece of equipment, what unit had it, and he would be able to bargain for it and get it, uh, get it for the 407 7th.
Dan Neumann: [23:18] Thank you. Sam. I don’t know if there’s a model modern equivalent to Corporal Klinger but uh, yes, so we digress. I digress. That was my fault. Um, so building relationship with the Product Owner, the Scrum team, and also the stakeholders and those in the organization. I do find that the, the Scrum Master has a really interesting opportunity because a lot of times development team members get so focused in on what they’re doing that can lead neglecting the relationships across the organization. And so as a Scrum Master, you’re going to hear, Oh wait, I know I heard a team over there was doing something that sounded a lot like this, either from a technology or for a business problem standpoint, and they can play connectors in the organization and, um, help reduce or reduce redundancy where appropriate. Yeah. So starting to, you know, there’s the trust piece and building the one on one relationships as well as asking the team for their challenges and then building relationships with those outside of the team. I think that’s a really excellent place to start in a new Scrum Master, into an existing organization. And then the other, close our eyes and pretend. What if the context of the question is a Scrum Master on a brand new greenfield, let’s say bootstrapped type of organization?
Sam Falco: [24:38] Yeah. Uh, I think that would be a amazing challenge. You want to establish good Scrum practice from the get go, you have that opportunity to start with what is true Scrum not having to adapt to whatever weird little wrinkles that have crept in or been given to it. Um, so making it clear, not just what the Scrum guide says but why you do things this way and proceeding with really deliberate attention to making sure that the team you’re assembling, the team that is forming is doing good Scrum practice. You know engaging in good Scrum practice. So that, and this hearkens back to our very first episode of this podcast when scaling comes around, and it will, you are already doing Scrum well and then you are scaling good behavior instead of scaling bad behaviors.
Dan Neumann: [25:41] Absolutely and starting from scratch gives you the opportunity to do things like get a working increment in the first Sprint, not a Sprint zero, not a design Sprint, not a whatever other kind of Scrum but type of Sprint but a Sprint. And yeah, a lot of that might be plumbing and back end things, but you’re going to make sure that it works because you are actually doing something of value with it. You’re validating the software. It is done. It might not have much of a UI to it, it might not have much of all the fancy stuff, but you have a working increment in something and so you’ve got a really great opportunity to start without technical debt. You have a vision. I think that’s one of the places as a Scrum Master, um, really making sure that the Product Owners clearly articulated a vision and has the start of the product backlog so that the team can begin running with that in Sprinting. But yeah. All right. So on the episode today we answered three questions related to do you prefer one or two weeks Sprints and why? So we talked about the Scrum Masters role and what tasks the Scrum Master has to perform. And then what’s the first thing a Scrum Master would do when starting at a new organization. Then decided to take that from from two different angles. So that brings us to the what’s Sam reading because I apparently feel like a slacker and have not been consuming books at your pace. So what is Sam reading?
Sam Falco: [27:07] Two things. Two books. I tried to not have two books in progress at any given time, but I accidentally grabbed the wrong book when I got on the plane this week. And what was I going to do? Not read. So at home on my couch is a copy of Arcade Perfect: How Pac-Man, Mortal Combat and other Coin-op Classics Invaded the Living Room by David Craddick and this is a, a history of how PAC man came to be on the Atari 2,600 and it’s fascinating because I’m not very far into it, but I’m seeing a lot of how essentially this was not a professional environment. Like it was very wild West. One of the developers said, you guys, first day on the job, he was told, go make a game. That was the direction. Go make a game. And he did whatever he want. And the guy who brought pac-man to the Atari 2,600, he talked about the various assumptions he made, the changes he made. And uh, and I remember getting PAC man for the Atari 2,600 and just being like eager to get this thing and it bore no resemblance to the screen layouts that were in the arcade thing. And he talks about why he made the choices he did. He assumed that the, uh, the tunnels that led you from one side of the screen to the other, that it was important to have the tunnels, but it wasn’t important to have them in the middle of the screen, which is why they are at the bottom of the screen. Um, he assumed that having the screen filled was more important than having the vertical orientation that the coin-op version had. He, uh, I could go on, but it’s fascinating to see these, how these decisions were made. Uh, fascinating. And then the one I’ve got with me is called Digital Minimalism by Cal Newport. Digital Minimalism: Choosing a Focused Life in a Noisy World. And I had read his book deep work last year, which was about the need for focus in working and how you can get the really, you have to build space for that. And this book is more about how noise from technology, whether it’s the phones we carry or the streaming services we consume, et cetera, really keep us from thinking and how we can adapt away from that. And it’s fascinating to me. I’ve been thinking about this equation a great at the Agile2019 conference, the keynote speaker, one of them told a story about how his wife was sad every time she got done using Instagram, realized it was actually making her sad. And as he was talking I thought, you know, I really hate Twitter and when I get done with a session on Twitter I don’t like myself very much. And I signed out and got rid of it and I haven’t been back since. Um, and Newport is talking about much that same impulse but on a grander scale. So he recommends a digital decluttering where you get rid of all of these things that are not essential to doing your job. Consider what you value in your life, rediscover what you value in your life and then only let technologies back in that actually support the things you value in your life.
Dan Neumann: [30:28] That’s an interesting concept. I remember as a young, fresh out of college consultant, I ended up talking to one of the partners in charge of the consultancy was at and I think I just, I dunno, I needed to talk something about something to them. And so I just kind of asked him, what do you listened to while he was driving? Cause he traveled a bunch and he said nothing. That’s my thinking time. And I was like, Whoa, weirdo. And now and now also of course then, you know, as a much older person now I find myself driving around in the car with the radio off because I can’t stand the radio at times. Just again, you’re being inflicted with the noise of the named Babel of whatever show happens to be on and just, yeah, the quiet creates some interesting opportunities for reflection, so, right. Yeah. Digital minimalism.
Sam Falco: [31:14] Yeah. When I read Susan Kane’s book Quiet a few years back and a lot of people really were moved by that book, um, about introverts and, and what they can give to the world. And I’m an extrovert. I’m very outgoing. I, I’ve never seen a stage. I didn’t want to be on our a camera. I didn’t want to be in front of a, or someone whose hand I didn’t want to shake. But I read it and something bothered me about it because it didn’t quite line up with what I was thinking. Her definition of introvert was very wide and she talked a lot about how the world is designed for extroverts, who you know like to be around people. I thought that’s not quite it. The world is designed at this point to keep us distracted and that is what Cal Newport is saying, that there is so much noise in our lives that we don’t have time to think. We don’t have time to consider what really is valuable in life.
Dan Neumann: [32:14] Yeah, and I think, you know, it’s much like we talk about empiricism. People could try it and if you hate it, you could always go back. Right? You could try minimalist approach and if you hate it, you don’t have to keep it. So definitely a safe fail experiment. Once again, thanks for joining today, Sam.
Sam Falco: [32:31] You’re welcome. Thanks for having me again.
Outro: [32:34] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views and information expressed in this podcast are solely those of the host and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.