In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by Scott Riley, a delivery leader at AgileThought. As a delivery leader, Scott wears multiple hats and is responsible for the successful delivery or implementation of projects. If anything goes wrong during a project, it is Scott’s job to be able to identify what that issue is and remedy it.
In this episode, Dan and Scott are discussing the challenges of bringing agile into a non-agile environment. They talk about the challenges they generally see in work environments transitioned to agile, misconceptions they often hear around agility, the concerns and struggles they often see as organizations are in their agile journey, how to overcome these challenges, what makes for a successful agile organization and how AgileThought works with organizations that are getting started on their agile journey.
- Misconceptions Scott often hears around agility:
- That being creative, quick or clever is all it takes to be agile
- If there are no rules in place that means you’re being agile
- That agile should be implemented because “it’s just the new way of doing things” rather than to solve a problem the organization is facing
- Challenges Scott sees in organizations that are in a place of pre-agile adoption:
- That there’s no foresight into scalability
- They’re not paying attention to how they can sustain things long-term
- Challenges of bringing agile into a non-agile environment:
- Fear of change from the organization
- That they only bring in aspects of the framework without implementing it fully
- That the organization is confused about what agility is from having multiple consultants from different organizations
- How to overcome these challenges:
- Help the organization and its members to become extremely familiar with the principles of agile
- Make sure it’s the path this organization actually wants to go down by asking the important questions (such as, “Why agile?” and “What problem are we addressing?”)
- Do the coordination but not to the detriment of people’s sanity
- Concerns and struggles Scott often sees as organizations are in their agile journey:
- Struggles with cross-team communication that turns into a game of telephone
- Building something with an assumption rather than the true knowledge of what it should be
- The uncertainty of self-organizing teams
- For a successful agile organization:
- It’s important to have a true understanding of the Agile Manifesto and all of its principles
- You need open channels of communications between business people and developers who work together daily
- Make sure that conversations don’t lead to misdirection
- Teach members how to collaborate and bring every decision into a team process
- How AgileThought works with organizations that approach them to have a conversation about their agile journey or to improve their agility:
- We help by facilitating conversations
- We determine where their baseline is and where they want to go
- We provide an assessment and then move forward with that
Mentioned in this Episode
- Scott Riley (LinkedIn)
- The Agile Manifesto
- Eric Landes (LinkedIn)
- Agile Coaches’ Corner Ep. 19: “Eric Landes on Kanban Metrics in the Scrum Framework”
- Agile Coaches’ Corner Ep. 22: “The Role of Managers in Agile Organizations with Esther Derby”
- Agile + DevOps East (in Orlando, FL)
Scott Riley’s Book Picks:
Intro: [00:01] Welcome to 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] All right, welcome to this episode of the Agile Coaches’ Corner. I’m your host Dan Neumann and today we’re going to be exploring the challenges of bringing agile into a non agile environment and my collaborator today is Scott Riley, a delivery lead at AgileThought. So welcome. Thanks for joining Scott.
Scott Riley: [00:34] Hey Dan. Thanks for having me here.
Dan Neumann: [00:34] Yeah, maybe the first question is what’s a delivery lead for folks who might not be familiar with that term? How AgileThought uses it?
Scott Riley: [00:42] Good question. So delivery lead is a little bit of a practice of an engagement manager, quasi-product owner, basically it is the one person that wears multiple hats within a project that’s there. So ultimately I’m responsible for the successful delivery or implementation of the project, so if anything goes wrong, if anything runs sideways during that project, I’m the one that’s ultimately responsible for identifying it for remediation of it. And then working through.
Dan Neumann: [01:09] Very cool. Yeah. And as you and I’ve worked together. I don’t feel like you approach that in a tyrannical way, you know? Yes you are. Yes. You are responsible for those things. But I feel like it’s a good collaboration on the delivery.
Scott Riley: [01:21] Thank you. You are, you do catch more flies with honey than you do with vinegar. That is true.
Dan Neumann: [01:26] That’s what I’ve heard. Excellent. Well good. Well thanks for taking some time. One of the things we run into you work a lot with the build practice, that AgileThought and you’re also working with the transform practice, which I’m a part of. And so we’re going into a lot of organizations either to deliver a solution that they’ve asked for either specifically or generally, or to work with them on their agile transformation journey. And then the degree to which those organizations are or are not agile of course varies pretty wildly. So what are some of those challenges that you tend to see?
Scott Riley: [01:58] Yeah, well it’s interesting, you know, because working with different clients working different engagements, um, I think people in the it community or in the operational community have different opinions on what they view agile is being, um, whether it’s different types of agile that’s there, which is very valid or whether it’s taking their agile adoption as a very piecemeal approach, which is less than ideal. So one of the things that we have to contend with when we walk into an organization is to identify what are they doing, what do they think agile is? Um, you know, have they tried to implement it in the past and it just didn’t take root? Have they tried to implement their version of it? Have they taken pieces of it? Um, and then being able to discern where we stand and then being able to identify where ultimately they want to be in that agile transformation that’s there and that helps lead them into that direction.
Dan Neumann: [02:52] Yeah. I think talking about different types or a piecemeal approach, I know a lot of times I hear confusion about agility versus Scrum. So agility is values and principles. And Scrum is a framework that when done well is quite agile. Um, we, you know, we also see instances where someone in the organization wants to be very predictive in what they want. So their requirements and then they just want you to iterate through it and to expense, but you never really inspect and adapt. And so we see kind of these different flavors of um, interpretations of what it means to be agile.
Scott Riley: [03:30] That’s very true. And in fact, I have an example where I was working with an organization and had met with a gentleman that was working through their agile readiness approach and he met with somebody in their break room and they made some popcorn for a break and this person was looking through the break room, could not find any bowls for the popcorn. So they pulled out a coffee filter, which we’ve all done in the past and pop some popcorn, throw it into a coffee filter and said, look, I’ve got a bowl. I’m quite agile, smiled and walked off. So, you know, and at the time the organization was going through working with a consultancy firm and then going through an agile readiness assessment and then ultimately an implementation of it. So the takeaway from that is, you know, there is a misconception that being created or being quick or clever, um, means all through that you’re agile or that you don’t have any rules right now. So we’re an agile environment, we’re doing everything agile and that’s not, you know, that’s doing a disservice to the agile manifesto. And that’s not, you know, playing responsible with the values and the principles that agile speaks to.
Dan Neumann: [04:39] Actually today that topic came up when I was talking to one of my colleagues, Eric Landes, who’s been on some previous episodes about the discipline involved in doing agile well. And the one of the principles behind the manifesto is continuous attention to technical excellence. And you know, there’s the technical excellence part yet, you know, if a, if your technical metaphor for a coffee filter can give you business value, maybe that’s not a bad place to start. But really the secret is don’t run out of bowls, like have disciplined rigor in place so that you don’t run out of bowls in the first place.
Scott Riley: [05:14] Absolutely. And you know, it’s one of the things that I see in an organization that it’s in its infancy in agile adoption or you know, a pre agile adoption place is, there is no foresight to scalability in that. There’s no foresight into what happens long term of what we’re doing. You know, the organization may go through some practices and some white framework of what they’re doing now, but they’re not paying attention to detail on how they can sustain that long term. And that’s anything from, you know, lack of creation of a backlog or um, you know, not playing responsible when it comes to technical debt or anything else that have to contend with later on because it all just gets buried into the gray cloud of, oh, we’re agile, we’ll figure it out in the future. And again, that plays a disservice to the values, the principles and the manifesto of what, you know, agile is.
Dan Neumann: [06:01] Yeah, I see those, those types of things as well. With the backlog. I think one of the big challenges I see is the organization not identifying the person. If you’re doing Scrum, who is the product owner? So responsible for the value and responsible for distilling all the different voices of the customers and the stakeholders into a backlog that’s optimized for value. You know, maybe they have the role in name and then they make some decisions and later get vetoed or they aren’t even able to make those decisions. So really that’s one of the challenges I see in organizations who aren’t agile, who are shifting towards is really the decision making processes need to become leaner and faster and the organization needs to support the person making those decisions.
Scott Riley: [06:50] Well said. And you know, the other piece of it too is, you know, when we work through a transformational process or waterfall into some flavor of agile, you know, we tend to evangelize the process, the framework, um, the rituals, the artifacts, memorializing things, you know, you know, terminology and process that we use on a regular basis for an organization that is heavily steeped in a waterfall framework, that waterfall methodology that’s there. There’s a lot more at stake. You know, I mean these are organizations that use traditional waterfall roles and artifacts is, is, is milestones within the organization to measure success. Um, you know, organizations that’ll take a business requirements document a BRD, um, and then use that to evangelize the process. I mean, the, the product that’s there, they’ll use that document for sign off. You know, they use that for accountability going forward. So when we’re in an agile world and we don’t have this comprehensive document that’s 400 pages long that spells out every aspect of this project. It’s very daunting for stakeholders to say, I don’t, I don’t get that. You know, I can’t see it, but yet I’m ultimately as possible for that. That doesn’t make sense. But you know, the other side of that is there’s an entire group of folks that worry, well am I going to have a role in the new world of agile that’s there? Whether they’re business analysts, whether they are project managers, you know, these are folks that build out, you know, Microsoft project project timelines that are there. You know, these are business analysts that go through traditional BA tasks to again create this monumental document that’s there, pass that on to the powers that be and that and then push it through the process. So I know you have leadership that’s asking where do these people fit within our new world organization? You have project members like these BAs project managers that go, well, what do I do? Because if, when I look through the overall project scope that’s here, you know, I may not see a role for a project manager, product owner, Scrum Master. Sure. But what is that and how I build a timeline around that. So I think there’s a lot of fear and to change that, that we to deal with when we work the transformation.
Dan Neumann: [08:57] Agreed. And I had a conversation with Esther Derby on one of the podcasts that we talked about what a disservice some of the agile lists did clumsily kind of saying things like, oh, we don’t need project management anymore. We don’t need project managers or we don’t need functional managers or whatever these kind of dismissive, oh, your roles no longer important because we are agile now. Um, and you know, if I really encouraged folks and we do this anytime we’re doing an introduction, an agile fundamentals training, here’s the values, here’s the statement of what the agile manifesto is. By the way, then here are the 12 principles behind that. We do some exercises around those because really getting people to stop kind of confusing the any particular framework with agility. So, hey, here’s, here is what is defined as agile. By the way, a lot of this stuff we spend time talking about isn’t defined in this agile thing. So you can deliver value for your customers as your highest priority. And you can do that with BAs and project managers and specifications of some kind and but you do want to be responsive and, and really improve your process over time, whether you do Scrum or safe or less or dad or you know, any of those alphabet soup of, of framework.
Scott Riley: [10:17] Yeah. And you’ll hear the piece of that too is you know, when as consultants, we go into an organization and we’re evangelizing, you know, agility in the entire process, the framework, that discipline that’s there around it. We start explaining like while we have Kanban that’s available, we have lean or scaled safe, all of this stuff. And it brings an entire different level of confusion too to what this framework is and how we go about not just implementing this but evangelizing it as well too. And I think the difficulty or the confusion that exists out in the marketplace today is you’ll have a practitioner that comes from one organization into another with what they believe is agile, their flavor, their understanding of that. And then again, they try to evangelize it from a grassroots effort from within. We then come in as a consultancy firm to be able to say, look, this is what we should be doing along that. And then you know, there there’s a power play at stake. There’s, you know, to which is the best process, which is the truest or which should we be following.
Dan Neumann: [11:15] Yeah. One of the questions I love to ask folks is what’s the problem you’re trying to solve? And that applies organizationally. That can be down to the team level when they’re trying to task out as a backlog item. All kinds of places. But like what’s the problem we’re trying to solve? Oh, we can’t release a software product to market faster than x amount of time. You know, and that’s too slow. One place, you know, they would order the hardware and it would sit on the loading dock literally for six months. So you’ve got capital spent, you’ve got capital sitting on a loading dock, not deployed doing anything. That’s a problem. So how do, how do you look at what the problems are and then, you know, a lot of times agility can help solve those problems.
Scott Riley: [11:57] Yeah, one of the questions I always ask is when I step foot into an organization for the first time and I’m doing that, that agile assessment is why, why Agile? You know, why are we talking today? You know, what was the impetus to have you reach out to this organization and have us sit down and chat today? And it’s, it’s frightening how many times I hear, well, it’s the new way of doing things. So we have to do that. And you know, that doesn’t address any of their business problems or why they’re doing it. I think they’re just looking at agile as being, Hey, this is a change of course, and that’s going to fix all the ills that we’re dealing with now. And that’s when, you know, I put on my sales consultancy hat and say, Hey, by the way, this is the myriad of things that an agile framework, that an agile process can help you within your organization. You know, whether it’s with operations or IT or any other line of business that you have that’s there and then at that point we start to serving like yes, like this is an issue that we can deal with or this is something that we’re looking to correct stuff along those lines.
Dan Neumann: [12:54] I’ve encountered probably more people than I can think of off the top of my head who when the agile transition is announced or pilot teams are forming or whatever kind of activities are going on to relate it to a transition. One of the resistance points we get is, well this is just the flavor of the week, month, year when the leadership team changes, if, especially if it’s a company that’s been acquired, expects to be acquired. Again, a lot of times the resistance is just waiting out the leadership team and so making sure that no, this really is a path we want to go down and there’s stickto it iveness to it.
Scott Riley: [13:34] Yeah, and I think the flip side of that as well is there’s a lot of consultancy out there that caters to just that as well. And you know, organizations that come into an IT shop or an operational workplace and they put up some PowerPoint slides, they give a day long presentation. Like this is what agile is like. You guys should do this, you know, charge an exorbitant consultancy fee and then move on their merry way afterwards. And I think that’s what happens when we, we as professionals walk into a shop and they’ve gone, well we’ve already had two consultant groups that come through here and we know what agile is, so can you fix it for us? I’m like, sure. But what was the follow through for that? You know, what was the, the explanation behind it? You know, people don’t want to be preached to, you know, people need to be educated, they want to be educated and they, they, they want to know what you’re actually getting for the dollar on this as opposed to, Hey, new leadership, new budget, new change.
Dan Neumann: [14:38] You’d mentioned earlier on the roles and the artifacts. And, and I think some of the activities or the rituals that go on around, you know, I’ll talk about Scrum and not to pick on Scrum, I love, but you what you were alluding to, people will stand around a board for 15 to 45 minutes a day and look we are, we’re now agile because we’re standing around a board instead of instead of doing something else. And for me really helping folks understand the value of the events in Scrum and internalize the values that underly it. So we’re trying to get focus and we’re trying to create transparency. We want collaboration. It’s not because you stood up for 15 minutes that something’s going to magically be a different kind of avoiding the cargo cult of the, the agile transition.
Scott Riley: [15:33] Yeah. And it’s interesting because that and the backlog I think are the two focused agile terms that I hear thrown around that say, hey, we’re now an agile shop because we do a stand up and it’s 15 minutes and you know, we do stand up because you talk faster when you’re standing up and have a backlog and our backlog is everything that we need to do and we have it in a very nice pivot table for you and there you go. That’s your backlog. Yeah, but that doesn’t make your shop agile. You know? Again, you can’t pick and choose any of the process or the framework that’s around that to say, look, we’re, we’re agile just because we’ve heard this, you know, it doesn’t work that way.
Dan Neumann: [16:10] And I can hear my Scrum trainer friends going to, there is no standup in Scrum then there, right. It’s a daily Scrum. You can sit, you can stand, you can do a handstand. Yeah. Lay down on the floor if you want it. But it’s the daily planning event and super valuable. But people have, you write code of conflated standing up with some kind of kind of magic sometimes.
Scott Riley: [16:36] Oh yeah. And you know, I’ve walked into, you know, as you mentioned earlier, you know I’ve walked into organizations that are, are heavily rooted in agile but their daily stand up is a 45 minute daily event where they talk about, you know, what’s going on and then they start talking through design stuff. And it’s not until I can raise my, my delivery leader project manager hat and say, Hey, by the way, you do understand that we’re billing for this. Like this is billable time. So do we need to have an entire development team sitting here on these discussions that, you know, may or may not be relevant to them just because they have to be privy to a daily 15 minute stand up
Dan Neumann: [17:15] And it’s, you know, it’s whether your, you’ve got an external billing rate or it’s an internal billing rate or just, oh my gosh, yeah, I am a human. I am only going to live so long. I don’t want to know. I want to do valuable stuff. So do the coordination but not, um, not to the detriment of kind of people’s sanity.
Scott Riley: [17:37] Well said. Absolutely. No, I concur with that. Definitely. Yeah.
Dan Neumann: [17:41] So Scott, we’ve talked about some of the, the role challenges, kind of picking out little bits of the process and some of the challenges as organizations want to move from where they are now to a more agile stance. What are some of the other concerns that you tend to see as folks are exploring this agile journey?
Scott Riley: [18:03] Well, one of the things we have to remember is a waterfall framework is something that’s been around for awhile and it really helps to perpetuate a very tiered approach and how we go about software development and it’s very much, you know, work through the requirements, begin development on it, finished development, go through a testing piece of it, anticipate there’s going to be a monumental amount of rework, rework it, put it in front of the client, hope the client accepts it, hopefully the market hasn’t changed in the interim. Go ahead and release it to production. And then because there’s been, you know, a vast amount of time that usually occurs between the beginning of this process to the, the implementation of this product that’s there, there’s always going to be adjustments that occur around the way. So it’s an evolving process. Obviously it’s just never run a cycle of developing, building and releasing. Um, you know, the agile approach is different. Obviously, you know, the agile approach, as we all know, it’s an iterative process. It’s a scaled approach and how we go about doing this and part of that is breaking down some of those tiered walls that are there and doing things like cross team communication. It’s cross discipline communication that’s there. You know, the old adage of not being able to have a developer work with the business because the developer can’t talk operations and business and business can’t understand technology. You know, a lot of those walls are beginning to crumble. And when we move into an agile framework, that’s there. You know, we’re able to facilitate that communication to really lessen that game. A telephone from one person talking to another and then relaying that message to a third person and then actually, you know, learning real time, what does the business need and how can we fix that or how can we work through that from a technological perspective. And I think that this, this helps really to alleviate a lot of that internal rework or that wasted time that we spend on between building something with an assumption as opposed to a knowledge, true understanding of what it should be.
Dan Neumann: [19:57] Yeah. And again, for folks go read all the principles behind the agile manifesto, you know, business people and developers working together daily. We need the open channels of communication and we also need the rigor in the disciplines so that not every conversation changes the trajectory in a, in a major and unhelpful way. Right. So, um, if a business person just kind of thinking pie in the sky pic features or an idea or brainstorm with a developer and then they run off and build that instead of the thing that they already started, like that’s, that’s a destructive engagement in the sense that they’re not really able to build consistently limit work in process or deliver working software and that. So yeah, we want to, we ought to make sure that like not every conversation turns into, you know, a misdirection play of some kind. But yeah, the like and teach people how to collaborate in helpful ways. What, what do you do with the conversation? How do you bring that into a team decision making process? How do you add that to the backlog or not?
Scott Riley: [21:00] And that’s part of my role as a delivery lead within the AgileThought organization is to help facilitate those conversations that are there, um, to put those correct people in the right form of communication. And that if need be, I mean admittedly there is a translation piece that may need to occur but to be able to work through a lot of that stuff. But the thing that’s interesting is we have to remember that technology is constantly evolving. The market is constantly evolving as well. So with two very different focuses going through a lot of change simultaneously, we need to have that very real time communication that’s there to be able to say, Hey, what can we accomplish now? Or what’s better to maybe put off a little bit and accomplish in the future? Or you know, what can we handle from a technological standpoint or what’s better to handle from an operational perspective instead? And then being able to work through that and then make adjustments as needed.
Dan Neumann: [21:48] Yeah. And so we both, we both see that you’re in the delivery lead as as we’re delivering software solutions, we see it on the transform practices where we are engaging with customers about, hey, let’s enable the interactions and let’s make sure they’re happening in a productive and valuable way. And then self organizing teams is another facet that I think can scare business people and particularly I think it’s misunderstood. Um, well it’s misunderstood generally, but the middle managers especially maybe whose entire job description, their sense of being in the organization has been around directing activities for individuals that report to them. And so now we’re like wait self organizing teams. What?
Scott Riley: [22:34] Yeah, I mean I don’t think any IT group out there is looking at a form of mutiny at any point in time. You know, um, the idea of a self organizing team as you said, can, can be fearful to, to a middle manager. That sole purpose is to be aligned lead for folks that are there and to be able to direct focus to direct attention on all the practitioners that are part of that project that’s there. But one of the benefits of an agile framework that I personally really appreciate is the idea of a self organizing team. It’s the ability to have practitioners pull in together and really work among each others strengths and weaknesses as they go through. Um, again, these are very positive and beneficial characteristics that get lost in a waterfall approach when you just tell people you you’re great at that. So just do it and keep doing it until I tell you not to anymore. And you, that’s a weakness. So just don’t do that. But with the idea of a self organizing team, you have all these practitioners that that begin to congregate together and then they can identify like, Hey, who’s good at what, who’s not? And then play back and forth off of that. And then ultimately, you know, you end up being collectively more than just a sum of the parts of what you had to begin with.
Dan Neumann: [23:46] Yes. And it brings to mind a Scrum Master that I worked with out east a while back and the people he was working with were in a habit of just kind of waiting to be told what to do. And the trick, if you will, that he applied was you just stopped telling him what to do and waited and the silence was awkward and it took a long time. But eventually they, it’s kind of like an animal leaving the cage for the first time. It kinda like reached its paw out and started tapping the grass. It’s like, oh, it is okay to decide what I’m going to do for myself to help the team. And it was, it was really marvelous. His teammates so much more progress because he stopped directing the activity. Um, and a lot of times people when there’s that awkward silence about, okay, who wants to, you know, who’s gonna take on this story? Who wants to take on this task or the activity, we need the silence waits for about half a second. They go, okay, uh, Sally, maybe you want to build that thing and just kind of let it hang there. And um, at the same time, the managers can focus on how do I improve the environment in which my teams are operating, my people are, and how do I remove things that are in their way as opposed to directing tasks.
Scott Riley: [24:58] It’s interesting you mentioned that, you know, my background before I moved into this particular position was in consultancy and I would go into an organization and then try to discern what are you looking for, what can we build for you, elicit requirements, things along those lines. And one of the techniques that, that I utilize quite a bit was just that. It was, you know, sit there, ask the questions, you know, direct the conversation to where it needs to be, but then don’t always jump in and, and you know, create a silence, create a wall, create a vacuum or vacancy, um, a voice that’s there for a moment and people will ultimately, we’ll add additional bit of detail into that. And then oftentimes like that’s the key. Like that’s what we were missing. That’s the really important detail that I wouldn’t be able to have elicited just by asking a direct question.
Dan Neumann: [25:46] Yeah, it’s a marvelous trick. It just counted slow to eight to 10 to five, whatever you need. Yeah. Scott, we’ve talked about some of the challenges that folks have, some of the misunderstandings they have about agility, some of the benefits of shifting mindset and behaviors. And so can you talk a little bit about how AgileThought works with organizations that are approaching us to have a conversation about their agile journey and improving their agility?
Scott Riley: [26:17] Yeah, absolutely. So you know, obviously it’s determining where that, that baseline is, you know, what is par for that organization and then you know, also determine where they want to go. But more importantly, where are we today within that organization? And you know, some of the points that we had spoken to earlier in this discussion was where does that organization stand? Are they novice to agile? Are they completely unfamiliar with it? You know, is it a blank slate that we’re working with? Or have we had other consultancy firms that have come in and tried to implement their version of agile either unsuccessfully or because there is a resistance within that organization’s corporate culture that’s there. And then knowing what those pitfalls, knowing what those challenges are, that’s what AgileThought as an organization works to correct works to discern what is that issue and then move forward with that. And we do that by you know, a myriad of ways, you know, whether it is shadowing people within that organization, whether it’s asking very direct and frank questions, um, or you know, reviewing some of the processes that are currently in place. And then, you know, being able to provide our assessment on that and then being able to move forward with it.
Dan Neumann: [27:25] Very cool. Yeah, I’ve actually got a conference talk, I’ll be excited to give a down in, um, agile and DevOps east down in Orlando. I think it’s in November. I’d have to check my calendar October or November. And it’s about agile assessments and some of the things we’ve learned through that process over, uh, over some number of years. And one of the things, before you go, I would like you to share maybe what you’re reading as part of your continuous improvement journey. What’s got you inspired these days?
Scott Riley: [27:57] Absolutely. So part of the current work that we’re doing with transformation now obviously it’s changed and it’s going in and it’s reviewing an organization and seeing where they stand and then trying to review that, that situation from a different perspective. You know, perhaps one that a previous organization couldn’t see perhaps one that the internal organization can’t see within themselves. So part of that is I’m reading a book by Dave Barry called “Best. Date. Ever.” Um, I reside in Florida and I admittedly with all of the beauty and all of the absurdity that the state of Florida has available that’s here, I tend to to miss it because I live it day in and day out. And this book gives me an opportunity to kind of read about somebody else’s vantage point of Florida. Um, you know, seeing some of the absurdity through a different lens of that and then being able to appreciate it. And that’s anything from a tourist trap that’s here, like, like Weeki Wachee, which has swimming mermaids, to some of the crazy things that happen, you know, you know, with hurricanes or within Miami and all of that stuff that’s there. It’s lighthearted. On one hand it’s humorous, but it is surprisingly deeply insightful and definitely helpful for what I’m currently doing now and not just my current engagement but my role as a delivery lead.
Dan Neumann: [29:13] it’s interesting to think, you know, as employees at places sometimes, you know, you just, you get so steeped in the traditions and the way things happen that you don’t kind of think, gosh, that’s odd. And you know, one, one particular thing comes to mind, they do not put rocks in the garbage disposal.
Scott Riley: [29:30] Yeah. Which makes you think that there had been a time in the past when someone did that
Dan Neumann: [29:34] Somebody thought that was a good idea and I’m sure, you know at AgileThought we’ve got some of those as well, where somebody from the outside would be like, Huh, that’s kind of interesting. But yeah. And that’s the benefit a lot of times of getting somebody in from the outside if it’s a fresh eye and a chance to question some unquestioned, um, things that are happening. And sometimes they’re worth changing. Sometimes they’re not worth changing or shouldn’t be changed because they’re detrimental. But yes, and I might have to go find this mermaid place that you’re talking about. That sounds fascinating.
Scott Riley: [30:07] It is a throwback to the 1950s roadside attraction that still exist today in 2019.
Dan Neumann: [30:13] That’s awesome. Well, good. Some things haven’t changed. All right, well, thank you for joining today, Scott. Really appreciate it.
Scott Riley: [30:20] Yeah, this has been a great conversation. Thanks, Dan. I appreciate your time today.
Outro: [30:23] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.