Episode 217 – Unstoppable Scrum Enthusiast with Rodrigo Quezada

Scrum, you ask. Are we talking here about Rugby? Not at all. My guest on this episode is Rodrigo Quezada. Rod says he grew up with a pretty normal childhood until, during college, he was in a serious automobile accident that effected his ability to easily draw on childhood memories. I leave it to Rod to tell you about this.

He went to college and graduated after which he entered the workforce. In 2015 Rod discovered a book entitled “Scrum, The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland. I will not attempt here to describe what “Scrum” is. Rod is much more articulate about it than I. What I will say is that the art of Scrum takes creating and enabling teamwork to a new level. Scrum is all about teams working as cohesive units. I personally can see why one can say that using the Scrum model well may be a cause for more efficiency.

This episode is to me quite engaging and worth the hearing. I think you will learn more about teamwork and perhaps you will discover a way to enhance how you work on projects.

About the Guest:

My name is Rodrigo Quezada from Mexico and I currently work as Principal Project Management at AT&T.

During high school had a near-death experience at a car accident that compressed most of my childhood memories. They are there and can be retrieved by external triggers yet not by myself. Overall have awareness that had a childhood and within normal parameters as far as I can remember.

Started my career path at the century start in procurement and was having a good time yet by 2015 a pivotal event happened when I ran across a book by Jeff Sutherland called Scrum, The Art of Doing Twice the Work in Half the Time.

As failing at implementing traveled to the USA for training by Scrum.org and a new career path emerged. Implemented in the most empiric and lean way possible which aligns with the pillar of the Scrum system. Began a new undergraduate as computer engineering which was followed by a masters in data science and now a Phd in progress along with several professional certifications and a lot of learning.

At this point in time would like to share this out as find it very beneficial to both individuals and organizations as, per the Scrum guide definition, it aims at “adaptive solutions for complex problems”.

Ways to connect with Rodrigo:

Linkedin: www.linkedin.com/in/rodrigoquezadareyes

About the Host: Michael Hingson is a New York Times best-selling author, international lecturer, and Chief Vision Officer for accessiBe. Michael, blind since birth, survived the 9/11 attacks with the help of his guide dog Roselle. This story is the subject of his best-selling book, Thunder Dog.

Michael gives over 100 presentations around the world each year speaking to influential groups such as Exxon Mobile, AT&T, Federal Express, Scripps College, Rutgers University, Children’s Hospital, and the American Red Cross just to name a few. He is Ambassador for the National Braille Literacy Campaign for the National Federation of the Blind and also serves as Ambassador for the American Humane Association’s 2012 Hero Dog Awards.

https://michaelhingson.com https://www.facebook.com/michael.hingson.author.speaker/ https://twitter.com/mhingson https://www.youtube.com/user/mhingson https://www.linkedin.com/in/michaelhingson/

accessiBe Links https://accessibe.com/ https://www.youtube.com/c/accessiBe https://www.linkedin.com/company/accessibe/mycompany/

https://www.facebook.com/accessibe/

Thanks for listening!

Thanks so much for listening to our podcast! If you enjoyed this episode and think that others could benefit from listening, please share it using the social media buttons on this page. Do you have some feedback or questions about this episode? Leave a comment in the section below!

Subscribe to the podcast

If you would like to get automatic updates of new podcast episodes, you can subscribe to the podcast on Apple Podcasts or Stitcher. You can also subscribe in your favorite podcast app.

Leave us an Apple Podcasts review

Ratings and reviews from our listeners are extremely valuable to us and greatly appreciated. They help our podcast rank higher on Apple Podcasts, which exposes our show to more awesome listeners like you. If you have a minute, please leave an honest review on Apple Podcasts.

Transcription Notes

Michael Hingson ** 00:00 Access Cast and accessiBe Initiative presents Unstoppable Mindset. The podcast where inclusion, diversity and the unexpected meet. Hi, I'm Michael Hingson, Chief Vision Officer for accessiBe and the author of the number one New York Times bestselling book, Thunder dog, the story of a blind man, his guide dog and the triumph of trust. Thanks for joining me on my podcast as we explore our own blinding fears of inclusion unacceptance and our resistance to change. We will discover the idea that no matter the situation, or the people we encounter, our own fears, and prejudices often are our strongest barriers to moving forward. The unstoppable mindset podcast is sponsored by accessiBe, that's a c c e s s i capital B e. Visit www.accessibe.com to learn how you can make your website accessible for persons with disabilities. And to help make the internet fully inclusive by the year 2025. Glad you dropped by we're happy to meet you and to have you here with us.   Michael Hingson ** 01:21 Welcome to another episode of unstoppable mindset. Thanks for being here. And for listening. We really appreciate it. Today, we get to introduce and interview Rodrigo Quezada. But we're gonna call him Rod and he said, That's okay. He asked me if I preferred Mike or Michael. And I said absolutely. So he's going to call me Mike. And I'm going to call him Rod. And I guess that works out pretty well. Rod has an interesting story to tell both about life in in his childhood and what he's doing now. And he's going to talk to us a lot about Scrum. And I'm not talking about rugby, necessarily. But we'll get to that. Anyway. Rod, I want to welcome you to and thank you for joining us here on unstoppable mindset.   Rodrigo Quezada ** 02:05 Thank you so much for inviting me, Mike. I'm very excited to be here, I think this opportunity to be able to share this out with with the team at large. I'm super excited about it. So then again, thank you. Well, absolutely.   Michael Hingson ** 02:19 And you're You're most welcome. And we're really glad that you're here. Rod, by the way, is in Mexico City. So I get to learn new things and refine old things every day. So Mexico City is an hour ahead of us. So it is about 1134 in the morning where I am and it's 12:34pm where he is so he's he's doing this during lunch. So I don't know whether you had lunch? Or we'll have to get through this. So you can go eat lunch, but we'll get there. Sure. Well, let's start by kind of going back and talking like I love to do about you growing up the early rod. So tell us about childhood and kind of what your experiences were like and and a little bit about you growing up?   Rodrigo Quezada ** 03:09 Absolutely. I think of myself as a fairly normal childhood. I however, during college, I had a car accident where most of my memories were, I'm not gonna say wipe out because they're there. They're just word kind of compressed somewhere in my mind. So I'm able to access memories of my childhood as long as somebody else triggers them. And happens a similar situation with music, I'm able to pretty much sing a song as long as the music starts. But as soon as the music ends, I cannot go ahead and play it again. And I cannot sing it. But if the music starts again, I can see it again completely. So it's very similar with my memories from my childhood. So as far as I know, it was a normal, happy childhood childhood. And that's as far as I can go.   Michael Hingson ** 03:58 Yeah. Did you so were you always in Mexico City? Is that where you grew up? Or where did you grow up? Yes,   Rodrigo Quezada ** 04:04 I was born. Yes, I was born and I live in Mexico City. Most of my life. There have been a few projects for work where I have been in the in the US for a couple of it was a couple of weeks and every now and then a couple of months. But but basically that and coming back. Yes. remote work for a long time. But but you based basically in Mexico City. Yes.   Michael Hingson ** 04:27 So you're pretty used to doing remote work already?   Rodrigo Quezada ** 04:31 Yes, actually, I was long before the pandemic that we had the COVID in the year. I believe that was 2020. Right? Before that as communications start to become more accessible. It was becoming much much more easier to talk around people around the globe at a fairly unexpensive way. So because of that it was fairly easy to work from pretty much anywhere. So I had the I guess I was lucky He enough to consider myself a knowledge worker and start doing that since probably say about year 2020 10 When I was working in the automotive industry,   Michael Hingson ** 05:10 what did you do in the automotive industry,   Rodrigo Quezada ** 05:12 I used to be a buyer, which later turned into a global responsibility bility becoming a Category Manager, specifically for rubber, later on adding plastics and gaskets. So I was in charge of global supply in order to make sure our facilities in Mexico in the US had the materials they needed in order for us to assemble the products for for commercial vehicles. Right.   Michael Hingson ** 05:42 Okay. And that kept you busy. What, when you were in college, what was your degree? And what were you studying? Well,   Rodrigo Quezada ** 05:49 my original major was in international business. Back then, by the time that I was just about to select my major, the we start getting some of these agreements like NAFTA, where we were able to start sending goods back and forth, because before that, there was not a lot of trading among at least not along among Mexican other countries. After that, it opened what it is wide open. And now we have globalization is a whole different landscape right now. But back then, there were not as many commercial agreements, and it was pretty trendy. And I thought that was interesting. And it started out in that route.   Michael Hingson ** 06:29 So did you end up getting your bachelor's degree in that?   Rodrigo Quezada ** 06:32 Originally? Yes. And once we unfold the story on Scrum, then everything changed. And I see a very different career path. Yes,   Michael Hingson ** 06:42 I gather and we'll we'll definitely get to that. But so when did you graduate? What year did you graduate from college?   Rodrigo Quezada ** 06:48 That was me in year 2000.   Michael Hingson ** 06:54 That was around the time you had your auto accident?   Rodrigo Quezada ** 06:57 Yeah, like, before I graduated, like it's probably happened somewhere along the lines of 9697.   Michael Hingson ** 07:04 All right, so it was a little bit before you graduated anyway. But yes, that was certainly a major change in your life. Where you were you laid up for a while, or our, how did it affect you other than suppressing memories? Well,   Rodrigo Quezada ** 07:22 I think on the bright side, it allowed me to have a visitor give life a much broader meaning I was I was super grateful that I was able to make it. The heat came in my on my side, I was driving, it was my fault. I started moving forward in order to cross and then a car was coming, and there was no way that he can be avoided. And it was interesting, because I look into this person, that driver, it was I look at her eyes. And it was almost like communication, that it's I think of it out of this world. It was like talking through through without talking if you know what I mean, there was like a moment where I was pretty much saying please, please, I want to I want to still be here a little longer. And I start watching a movie. Before that I start watching a movie of my life, like a lot of kind of pictures in a super fast space. And and that's when I realized that I was just about to no longer be here in this world. And that's when I was like, oh, no, please, I read a Ruby. And that's when I make these super quick communication and eat work and and she seared the wheels. And it still hit me for sure. But not not in my door. If he had been in my door, I would not be fortunate enough to be talking to a and sharing all of this. So once once they helped me realize what happened, I realized how fortunate I am to having a second chance in this life to make the best out of it and and validate and savor as much as possible. Of course, it's not always easy, but but definitely worth attempting to to enjoy it.   Michael Hingson ** 08:58 Well, and it's interesting, I've talked to a number of people who have had major crises in their lives, and have had to, to deal with that. And so many people have said, sort of the same thing, that having a second chance and really having the opportunity to go back and think about it. They realize that the second chance gives them the opportunity to try to do more meaningful things and to be hopefully better people but certainly gives them the opportunity to go off and better value life and what it brings.   Rodrigo Quezada ** 09:39 Yes, fully agree.   Michael Hingson ** 09:41 Yeah. And you know, I'm, of course, I had my own experience with that, needless to say, surviving being in the World Trade Center on September 11. And, and we had discussions about it my wife and I, especially when the press started getting our story and the decision that that I'm made and my wife agreed was that if we could help people move on from September 11, by me doing interviews and, and also, eventually also starting a speaking career. And if we could teach people a little bit more about blindness and disabilities and guide dogs and other things, and it was worthwhile. And I love to tell people now being in large part of keynote speaker traveling the world to speak. It's much more fun to sell philosophy of life than it is to sell computer hardware. So   Rodrigo Quezada ** 10:36 yes, it's   Michael Hingson ** 10:37 a whole lot more fun to do that. So I will always do that if I can. It's much more fun to do computer stuff. So I can't complain a bit. Well, so I'm, well, I'm very much glad that you're here. So we could do this podcast. So I really appreciate it, though, that you have learned to value life more. And that's a good thing to do. But you went into the to the automotive world, and how long were you doing that? I   Rodrigo Quezada ** 11:07 was in that industry for 13 years. Wow. And then what happened? Okay, he gets interesting, I was into project management handling these different kinds of prod projects. And I was looking for ways to be a little bit more productive. So I was doing that. And then I spotted a name, a title of a book that was called doing twice the work in half the time by the author, Jeff Sutherland. And I was like, Oh, this sounds like a book that I need to get into. Right. So I started reading it. And I was a pivotal moment in my life, or at least, yeah, no, it was in many different ways. So I start reading the book. And I was I have, I had almost, I have to try it at least. So I tried to implement it. And I wasn't not being lucky enough to say that I was successful. So I realized I needed additional understanding of it, and then I seek out for training back then, right now is certain it's a bit more accessible to have training online. But back then it was not in like late year 2015. But I was able to find a place called scrum.org that had this workshop. And that was lovely. That sounds about perfect. And so So I did, I traveled to the US got this training. And it was it was amazing that the environment was very energizing. And I was like, oh, gosh, this is so definitely it. And I was able to connect the dots that I was missing prior to just reading the book. And I came back super excited. And I told my boss, I know this is gonna sound really, really weird, but I want to go ahead and implement it even I still not an expert on this, but I want to give it a try. And if you don't mind, we're gonna play roles. And we can make it happen if you're willing to allow me to. And that's the way I started pioneering on using Scrum. So where were you working at the time? Yeah, I was working for Bendix, commercial vehicle systems. Bendix, I was based on Mexico City would enough is here. But eventually, I also got an office in our corporate facility. Back then it was located in Elyria, Ohio, very close to the Cleveland airport, about 30 minutes from there. And now they move over to Avon the corporate move over. So back then I was like, why don't, why don't we don't have a kind of like a team like the scrum team that I can refer to, but I was like, let me make you the product owner. And I'm going to be a little bit of a mix of a developer and a scrum master. Because our organization, I don't know if has changed ever since. But it used to be kind of like a matrix. So the the way the teams were set up, were very dynamic. So it was not a this is a specific team that we can call scrum team. But even then, that was enough raw material where to get started. And it was the most empirical way to do it. I was back then I was even using Excel as a way to visually track the work that was meant to be done.   Michael Hingson ** 14:10 Well, so far, first of all, what did your boss say when you said I want to try to put this into effect and so on? What was your boss's position?   Rodrigo Quezada ** 14:23 He was one of the directors for purchasing and aside of the fact of thinking that I was kind of crazy of doing something so something and nobody else seemed to be doing around us. I think he was more of why not? You already went through this training. So let's let's give it a shot. And interesting enough later on. I don't think I don't know if it was because of me or pretty disconnected. But the company has eventually moved over to using Scrum, which I was super happy when I heard they were about you about then I was at that point in time. I was no longer with the company but but it was I was super excited to hear that they weren't going to do that.   Michael Hingson ** 14:59 So, why Scrum? That is? Why, why that word. Give us a little bit of the origins and kind of maybe start to fill us in a little bit about what this is all about.   Rodrigo Quezada ** 15:14 Absolutely. A scrum comms. Scrum is the framework right? grandslam to atheris, with our Kench, whoever and Jeff Sutherland. So they together created this framework, and they have refine it and make it better and better over time. Were these idea of giving these a specific name, they describe it as referring to the game of rugby, rugby, where the team is very cross functional in that like, you go like here and I go here and we stay in an each position is more alpha, we transition into whatever needs to happen in order to make this work. So that's what they thought this is almost like, like, like doing Scrum when you when you're playing rugby. And that's the reason why they gave his name off a scrum to the framework. And what it happens is that within this framework, you set up yourself in small teams, but each team has everything it needs in order to accomplish its goals. So basically, is a small unit of people 10 or less, usually, that set up a scope and, and become or are allowed to become self organized in order to make everything work.   Michael Hingson ** 16:29 So does that team then work on a specific job a specific function? Or is it more general, kind of trying to understand a little bit about what the framework is and the whole process? Absolutely,   Rodrigo Quezada ** 16:44 the team is meant to be cross functional, because it has to handle the order or has to have all the resources needed to accomplish the goals that are set for for that specific team. Now, there will be times where a project is extremely complex, and one single team is not going to be able to do everything. So that's where you're able to what is called as scale or scaling, which basically means different teams are working on a small portion of a larger goal. But the outputs of the different teams combined allow for these one big thing for a company to be able to go happen. Maybe Maybe if I go ahead and describe how the framework breaks down into its components, that could be helpful to share. Let's do that. Okay, sounds good. So So basically, there's three roles, three artifacts, and five, it has changed names over time, sometimes we call them events, we call them ceremonies, or commitments, I think the most recent way to to frame them. And basically, within a team, you're going to have three roles. And there's going to be a product owner, who is the person in charge of maximizing value for the team. And that is a person that is a bridge between the customers or stakeholders and the team that is actually doing the work. So So that's more related to what we usually think of as a project manager. But this position in the scrum team becomes quite complex. And that's why there's a second role that is created that is called the scrum master. The scrum master accountability is efficiency of the team. So it's more geared towards the inside of the team, which is the communication with the product owner and the auditor role, which is the developer. So when we think of developer, it can pretty much be any function. Because scrum can be used in any industry, although it has a natural, a natural fit with anything related to technology and software and all of that, however, it can be expanded to pretty much any industry. So that will change the scope and therefore the composition of of a team. So for instance, let's say in a non tech kind of team, you could have somebody from marketing and somebody from accounting and somebody from I don't know, some sort of operations and that team combined is going to go and reach a given amount of goals. And and then that's kind of like the three roles of the team. The product owner, the scrum master and developer and the developer are the the people that actually make the work happen. The the go getters, let's think of it that way. And the team works as a cohesive unit, which means there's got to be a clear direction of what needs to be done. The supporting coaching by the scrum master and the team actually making that work happen. Once we transition from the roles to the artifacts, that's where pretty much how the work gets managed. You create what we call a backlog of work or product backlog items within this product backlog which is everything you can build or create or accomplish. Basically your list of goals are Wish List. And so far, I'm not going to find that you want me to elaborate on any of the points that already talked about?   Michael Hingson ** 20:07 No, I think you're, you're doing fine. Let me let me ask you a question though. Typically, in a team environment, there's a team leader, is that the scrum master in this case?   Rodrigo Quezada ** 20:18 Ah, that's a? That's a great question. It's a complicated question, by the way, that's fair, as us as a scrum master and product owner sharing that leadership accountability. But if you think of, if a stakeholder or a customer has a question, Who were they gonna direct their question to, that's gonna be the product owner. So in that classic regard, I think I'm gonna have to lean more towards the product owner would be that lead. However, from a team standpoint, kind of like the leadership tends to gravitate more towards the scrum master, because the scrum master is is willing and able to help the team, figure out or solve, actually understand which which impediments you might have, and find a way to solve them. Now, in a great scenario, when you're coaching as a Scrum Master, you're not trying to solve the problem for the team, you're just trying to help the team being able to solve it by themselves. So it's more of a facilitator. But it's also a leadership role. Okay,   Michael Hingson ** 21:22 so if the scrum master is more of a coach and a facilitator, in sort of the typical language of teams, and so on, then what is the product corner person,   Rodrigo Quezada ** 21:38 it's also a leader. But the broker will be more centered around the product itself than than the team or the team efficiency, because that's where the support from the scrum master comes from. So the product owner will be more more related to to figuring out the requirements and needs from the customers slash stakeholders, and translate that into a team in order for the team to work on that value maximizing goal. Okay.   Michael Hingson ** 22:08 All right, well, go ahead and continue sort of the explanation of how the whole the whole process works, then?   Rodrigo Quezada ** 22:14 Absolutely. So from the goals, we go to what are called the artifacts, and there are three, one of them is the product backlog, which is basically your inventory of everything that that we can go ahead and build related to a given product. From there, what you're going to do is that you're going to break him down in a small in a smaller chunk, which is where from everything that we could do, where are we actually going to commit to do and that's when you go into what we call the sprint backlog, which is basically a smaller one, wait a given timeframe in order to be accomplished. And once it is that will usually refer in in traditional project management as deliverable. We call it an increment in Scrum, which is the outcome of work from the team within a given timeframe. Now, that will take us over to the ceremonies because that timeframe happens to be one of those. But before I move over to the events or ceremonies, any any questions you might have regarding the in the artifacts, or the rolls?   Michael Hingson ** 23:20 I don't think so at this point. I'll keep thinking about it. But I'm just fascinated to hear this explanation.   Rodrigo Quezada ** 23:28 Thank you so much. So moving into the ceremonies, there's there's the container for the word, it's called a sprint. And it comes from from racing, right like like a short race called Sprint. So what you're going to do is that you're going to work on something, and it's going to be a month or less, usually in increments of weeks. So usually you're going to use the sprint stuff one week, two weeks, three weeks, or up to four weeks. But no more than four reason being you want to keep it a as a scope of work that is no longer than that. In order for you to make sure you collect feedback, which is one of the I think biggest benefits of using Scrum. You're not working on something for a long time. And then in the end, come back and say a marketplace live, what I got is more of I work in a little something and I collect feedback. And based on that feedback, I'm able to inspect and adapt. So the team is always working on the highest customer priority or value, value or valuable item. So that being said, you set up a cadence of your sprint, which can go from one week up until four. And that's it. Once you have the spring. You start your spring with a sprint planning meeting, which basically do us collectively as a team commit to a given amount of work and therefore an increment or increments by the end of the sprint. Once that happens, you have a daily meeting which too it's wondering it's worth it happens On a daily basis, and it's a meeting where you're going to synchronize with a team, you want to make sure that everybody is working towards the goal, and basically keeping the eyes on the ball. And then by the end, the close to the end of the sprint, you're going to have what is called a sprint review, which is where you showcase the work that has been completed to the customers largest stakeholders. And it's a great place for interaction and collaboration, because basically, you're promising something, then you are showing what you have committed to what you promise, and then you get understanding of the path moving forward. Sometimes the customer know exactly what they want. And sometimes they think they want something but then once they start to seeing that as something they can actually inspect, they might want something different. And that's great timing, because this chrome allows for rapid changes or ongoing changes. So I might go one a given route, but I want to change route. Absolutely, let's do it. And that's what these sessions are for is kind of like a working session where collaborate the team or the scrum team and the people that are going to be using the outcome of the work, meet to review and, and provide feedback to each other. And the last event, once that happens is a what is called a retrospective or retro where basically just the scrum team gathers and understand what are the what is the team doing right? What is the team, that what the team can improve, and basically include those small improvements. And that's where the continuous improvement portion comes in. Because every single sprint, if the team is working properly, the team is growing better and better over time.   Michael Hingson ** 26:44 Well, okay, so this is clearly a very structured organizational process, which I can appreciate. But you said a lot earlier that that what you really got intrigued about and what intrigued you with the the whole idea of Scrum, even before you necessarily knew the name was do twice the work in half the time. So why does this process really increase workflow?   Rodrigo Quezada ** 27:13 Great question. One, one of the answers is because of the communication flow, the fact that you are keeping keeping teams small enough allows every team member to be able to understand each other, if the team is too weak, like when you go to a party, right? If there's too many people in the table, you can talk to a few that are close to you, but you cannot understand what is happening by the end of the table. So it's very similar, because the team is small enough communication flows properly. And therefore you avoid misunderstandings. And you're able to communicate faster and better. Therefore, you become far more productive. The other thing that I think is a part of the answer is the level of autonomy of a scrum team is fairly large. So that allows the team to organize to better suit their own needs, which allows each of the team members to bring in the best of them, and then combine them into the pool of resources. So the fact that everybody is able to work in such a pace, and the team either failing or succeeding as one. I think that's part of the reason why it makes a team so productive. And last but not least, you you every spring, you work towards the goal. So there's no misunderstanding of Yeah, everybody's doing a little something. Now, by the end of the sprint, we're going to show the work that we have completed. So so we keep focused, and we make sure it happens.   Michael Hingson ** 28:46 So it sounds like in any company, where you have a fairly decent number of people, you're going to have a number of different Scrum teams. And each one is is working on a project or maybe a few teams are working on different parts of the same project. But who coordinates all of that. So it sounds like there could be essentially a scrum within a scrum then that you've got somebody who is overseeing what the various teams are doing.   Rodrigo Quezada ** 29:21 Yeah, interesting question that's probably gonna change from from company to company or industry to industry. Think probably should explain that. A Scrum is a framework is meant to work as a whole. I mean, you don't escape roles or escape ceremonies or increments, you use all of those elements. But once you have that basic foundation, which is basically the framework, pretty much the rest of the field is very flexible. It allows for us I was explaining like scaling for instance, if I have a larger project, one team is not going to be able to accomplish everything then we can Scale to two teams or three teams or four teams. Now, if we are to go that route, then yes, your point, we're probably going to need to use as an organization, some additional tools for managing that complexity across different teams. But as long as the teams are not working on the exact same thing, potentially, you're pretty much just setting goals, and letting them go work towards those goals. So so the self organization of the teams allows a lot of flexibility for the organizations as well, they just need to set the goals. And then the teams go work to make those goals happen.   Michael Hingson ** 30:34 Well, let me maybe phrased the question slightly differently, who sets the goals?   Rodrigo Quezada ** 30:41 Well, that's what we usually refer to as the stakeholders, but stakeholder can be pretty much usually is going to be like senior leadership levels, that are saying this is what we need. So depending on the size of the company, that's kind of like which level is setting which goals, but I think is gonna probably cascade down, it's going to be most likely many of these pros is going to be top down. Eventually, if there are some mature Scrum teams, you can actually let them run wild with Can you set up your own goals of what you can actually accomplish and make that kind of proposals bottoms up? That's definitely something that can be done as well.   Michael Hingson ** 31:17 Sure that and I can appreciate that. But in general, what you're saying is that there, there is someone or there is some part of the organization, as you said that the top leadership that essentially stakeholders sets the goals. And that's where the process begins, and then assigns or works with the people below them to decide what team is responsible for what goals?   Rodrigo Quezada ** 31:49 Yes, and that's where the communication takes place between these stakeholders and the product owner, in order to break it down for the team to work in that. Right.   Michael Hingson ** 32:00 Okay. And so, once the goals are assigned, then is it also true that someone keeps the the leadership informed as to how the team is going? Or is the idea you have to trust the team and let them do their job for a month, and not interfere with the dynamic of the team?   Rodrigo Quezada ** 32:25 What I'm saying? Absolutely, yes, I guess potentially, that sometimes that can actually happen, in my experience is more of less ongoing communication between the product owner and the stakeholders, even though we're working on a given set goal for each sprint, yeah, is usually potentially having these communication helps towards the same point in time, good practice to have a roadmap of what you're doing. And eventually the roadmap can as I said, it can change because of what we think of discoveries, right, or validated learning and, and kind of think of, there's an amazing book about that by Eric, oh, gosh, he's like, I almost could swear it's Reyes, it's called the lean startup. And there's something concept that brings that comes from this book called validated learning, which is sometimes and the reason why the scope of this team says is small, is because there's a lot of unknowns when you start a project. So there's things and assumptions that that kind of like could hold true over time. But the more the larger the project, the less likely they are. So you have a certain degree of assumptions, and you want to go try to test them as fast and early as you can. Which leads to a concept that we refer to in this Agile world as your fail fast, which doesn't mean you're trying to intentionally fail. But if you are going to fail, it's better to do it as fast as you can and get your lesson learn and move forward. Because that allows you to experiment a little bit, which pairs well with the empirical nature of this process. And it also helps on the Lean thinking, because you don't want to waste resources. So if a project is going to be canceled six months from now, I rather know what would not let leave that padding to that project and cancel six months from now and cancel it, let's say two weeks after getting started, right. And I'm thinking worst case scenario, right with a project canceled, more often than not, your project is gonna change paths in order to arrive to one that is actually your successful path. So you go from something good to I guess I'm learning this from a title of a book, right? But what kind of going from good to great, right? Because you are understanding your product better as you are building it. And that takes me over to a concept which I think is in the core of everything we're talking, which is the iterative and incremental nature of Scrum. So what you're doing is building a little something, you do an iteration, and then you stop. You inspect and adapt and based on your findings, and Next time around your next iteration is going to build on top of that. So that's what we call the incremental nature because you're always delivering something. And it's always better than the, the version you delivered before. Can   Michael Hingson ** 35:15 you give us an example and tell maybe a story of, of a project and how Scrum, really enhanced getting the project done? Can you actually, is it easy enough to tell an actual story and talk about your experiences with it?   Rodrigo Quezada ** 35:35 Yeah, absolutely. I'm kind of thinking across I know, I'd see for an example is like, oh, gosh, it's been a couple of years. So I mean, I've collecting experiences. Sure. And, yeah, plus the NDAs. Right, what I can and can't share about Sure.   Michael Hingson ** 35:54 When you just sort of in general.   Rodrigo Quezada ** 35:58 Okay, got it. Yeah, well, let me share this example. It happened in one team, where we had these cross functional setup of the team members. So each of them having a speciality or kind of like being a specialist with one thing. And what happened, eventually, when we started doing the work, there were a couple of team members that were doing a lot of work. And there were some of them that we, we see working every now and then. And that makes it kind of complex, because as long as every, you have like two options, right? If you're going to be cross functional allele, everybody, there's a little bit of everything now, that for sure, nobody's going to be as proficient as the specialist. But the whole idea is that we can rely on each other. So for example, if our our programmer gets a stock, and he can get some help from the tester, then the tester gets the program a little bit with some shadowing are helped by the programmer, and then they can both program a little bit. And that's an example of clean Croc cross function. But if you're not able to do that kind of thing, because of whatever risk management policies or even willingness by the team members to go outside of their usual line of work. And that was the case here. There were team members that said, this is what I do, this is what I want to keep doing. So what we end up doing is if if these team members are don't have some tech skills that we need, but there's this other activities that they can do, as long as they don't have to mess up with the complexity, complexity of programming, or managing certain technology tools, what we did was simplify that and create a web application for for low to no code, tech team members to be able to produce work in that application. And that helped because now they can do work in an ongoing basis, as opposed to having to wait until there was some no tech work for them. And that helped the team increases the throughput dramatically, because now different team members could actually be producing work in parallel, kind of like everybody working on something at the same time, and the output was increased significantly. So   Michael Hingson ** 38:14 with those team members that really were not very technically inclined in the process, it sounds like they may not have really embraced the whole scrum idea at the beginning. But what did they think by the end of the project?   Rodrigo Quezada ** 38:30 Well, I think by providing them tools and make their life easier, and they can actually contribute to the whole, I think that that was a pretty amazing experience for us all because it is great if everybody can like go ahead and do different functions, but it's not always possible. So if it is not, how can we think outside of the box and seal provide a solution that allows the team to be more productive? And that's what we did. And it was an amazing experience.   Michael Hingson ** 38:55 And I think that's really the issue here isn't that what you're really promoting is people thinking and innovative in different ways, collectively, so that you are able to fashion and create a solution may be where you didn't think there was one. But by working together by functioning as a team, and by valuing the team, you figured out? Well, we've got to do these additional kinds of tasks to make it possible for everybody to be productive. But that's what it's really all about, isn't it is everybody needs to be involved in the team and be be productive? And the team has to be concerned about that and really work to make that happen.   Rodrigo Quezada ** 39:39 Yes, I'm glad you mentioned that. It's almost like as simple as saving the best for last. The definition of a scrum includes the fact that it is creating adaptive solutions to complex problems. And where it connects very well. What you just mentioned is that it is more of a mindset. It works within a framework. Yes. But but all the pieces working together, it is really about a mindset of problem solving in a way that that, let's say sets up the field in order for you to be very successful. So it is a tool that embraces change and innovation and problem solving, I think to a whole new level, and that's what I think we need in this day and age. Because as we have evolved as a human species, we have also been facing challenges that we didn't have before, like, like, like global warming, and are things that that are like, gosh, how are we going to solve that, right? But we gotta find a solution. Because if we don't, our our, our future is compromised. So how do we manage and handle all these projects, and I think this might not be the only way to do it. But it's definitely one way to do it. And that's the reason what I consider myself such an advocate for Scrum. I think once you do it and understand what it's coming from, you cannot stop using it, I can't.   Michael Hingson ** 41:05 So you use it in, in work and everything that you do, what do you do now? Or are you working for a company now? Or, or what's your current job environment like?   Rodrigo Quezada ** 41:15 Yes, eventually, as I started gravitating towards technology related words and phrasing and things like that, I start exploring into a new career path. And by year 2018, I started a new undergraduate program for computer engineering. And I finished that when in 2020. And then I got into a master's in data science. And about that same timeframe, I was lucky enough to join at&t, where I currently work as a principal project manager working with Scrum teams. And And most recently, I also getting engaged pursuing a PhD in computer science as well. So once I started gravitating towards technology, I realized my passion for it. And that process Grom. And it started ignited me into a very different career path, which is what I currently do.   Michael Hingson ** 42:12 So did you bring scrum to a TNT or was AT and T already embracing that as a concept?   Rodrigo Quezada ** 42:18 Because fine, I think they're really for this specific project is something that was about to get started. So pretty much. There were a few people getting started with it with a project. And then eventually, there was a significant amount of additional of team members that were hired. When I started with them, I started actually as a scrum master. And eventually, by doing the work, I transition over to product owner. So I'm fairly familiar with with with all the roles as I was leaving doing development when I got started on a very empirical way since early 2015. Yes,   Michael Hingson ** 42:56 so as a product owner or as a scrum master. When I mean that, that isn't a full time job as such, that is, you don't just sit in monitor other people, you're directly involved in doing a lot of the work yourself, right?   Rodrigo Quezada ** 43:14 Yes, absolutely. Regardless of the role, yes. Right. And   Michael Hingson ** 43:18 so you are just as much a part of the working team as anyone else. Even though you have the additional responsibilities of being the product owner, the scrum master, which is understandable when a project is done. This is a question I've always found interesting with different kinds of teams, because a lot of times when there is a team effort to do something, when it's all over and it comes time to recognize the teams, the team leader gets recognition and the rest of the team doesn't necessarily get the same amount of visibility. How does that work in a scrum environment? Is it just the project owner, product owner or the scrum master that gets recognized or is is the company or the process such that it's understood that it's really the whole team that needs to get recognized not just one or one or two people,   Rodrigo Quezada ** 44:12 it has to be the whole team if you ask me, because everybody is pushing towards this successful outcome that is a team outcome. So So collaboration and teamwork is is kind of like the glue that binds everything together. So even though the product owner is representing the team and helping the requirements and understanding and communicating with stakeholders, interestingly enough, as we are used to traditional management positions, item kind of think of off meter or scrum master or product owner as we can think of them as managers, however, from my view is almost like not giving yourself that managerial title. In some words, maybe you're doing it but you are so part of a team that is hard to tell apart. I'm kind of like, am I am I like, like overseeing? Or am I actually kind of like silly and bold, but I feel that I'm part of the team. If the scrum team is working properly, you are part of the team. So so it's not like different layers of people managing and people doing even though Yeah, true developers are doing. But you're so close to them that that that line gets kind of blurry, if you know what I mean. It's like, there's no way I could accomplish this by myself, I needed the team to backup whatever I'm supporting as a product owner. And similar thing with with the scrum master, if I'm helping a team become more efficient over time, the team is better than better. And that serves a higher purpose for both the team and the whole organization. Maybe   Michael Hingson ** 45:44 more like viewing yourself as if you will, a senior member of the team in terms of experience or knowledge level subject matter expert that you're bringing to it. But that doesn't make you better, or a a person who is separate from the team. And I think that's a wonderful concept that you're still really part of the team. And it's all about how you best add value to the team. Yes,   Rodrigo Quezada ** 46:06 it's all about maximizing value as a team. Yes.   Michael Hingson ** 46:12 Yeah, that's, that's extremely important. Because in so many teams, in so many job situations, the boss regards themselves as the boss and everybody works for them. The team leaders, the team leader, everybody works for them. But they're not in a sense, as much a part of the team is they really ought to be   Rodrigo Quezada ** 46:33 Yes, true indeed. And actually, that remember that, when they, when they created this framework, they they took away titles, they didn't want to say you're the senior de surgir, the junior dad, because that's more related to a hierarchical kind of structure. They wanted to make it as if you're a developer, you're helping with creating and crafting and adding value to the product. So you are a developer. And that's it, you don't need to have a specific title as you are a QA or you are a software engineer, or you are a site reliability engineer, SRE is like you're part of the team. And that's it, you might have a speciality. And there's something that I almost forgot to mention. Within this world, we're very used to I do one thing, and I do that one thing very well. But there's this concept of a T and are m shaped professional, which basically means you're extremely good at more than one thing. So So you have a broad understanding of several things, but you're good at at one or more things. So in that regard, there's no limit also to your potential as somebody doing the work. So kind of, is kind of like a path to mastery and fulfillment. So if you're doing these just like well, then then eventually that takes you to higher levels. And that in turn, moves over to your personal life. And then suddenly you have a virtuous, virtuous, virtuous cycle. I believe there's a right way to say it, Mike. Yeah, so so it's kind of like, like, it's fun. And then work doesn't feel as well, kind of like the way we think of work, right? Because work becomes far more fun, and you enjoy it. And then you do what you like. And then you happen to do even better, because now you aren't kind of like, completely nursing what you're doing. But aren't   Michael Hingson ** 48:24 scrum master and product owner titles in of themselves? Or how, how is that in the scheme of things different than then having some other kind of title?   Rodrigo Quezada ** 48:37 No, no, that's fair enough. That's where I think Trump is making an exception. We have these two, these two positions that are having kind of like extremely specific accountabilities within the team, because, for example, right, we only want one point of contact with the team to talk to stakeholders, because otherwise it could be 10 people sense from a stakeholder standpoint, right? You want to talk with one person from the team? And that's why it's specific to the scrum I'm sorry, to the product owner. Right.   Michael Hingson ** 49:08 Okay. And, again, I think that gets back to what I said before, which is really, although they are titles, it's really talking more about your level of experience and some of the expertise that you bring to the team.   Rodrigo Quezada ** 49:24 Yes, absolutely. It's a cohesive, cohesive unit of professionals working together, which breaks down silos, right, because you're trying to collectively achieve something opposed to this is my part of the word. And that's the only part I care for. And this is more of approach of this is what we are working towards building together.   Michael Hingson ** 49:43 Right. And that's what teamwork is really all about, or should be really all about. And so often we we tend to really miss the whole point of what the value of the team is, and we pay more lip service to teamwork. then actually doing things to embody it and make it really a part of what we do. I know that when I hired salespeople and worked with salespeople, one of the things that I always said is my job is not to boss you around, because I hired you expecting that you already know what to do and how to do it. But my job is to add value to make you more successful. And it sounds like that is what you're really seeking in the whole scrum process as well. And why you have a scrum master and product owner.   Rodrigo Quezada ** 50:33 Yes, indeed. And previously, you mentioned something about when the project ends. And I think that comes to a different concept that I found extremely interesting, which is, with your teams being kind of like a group of people working together, and the longer they can work together better, they can read each other's mind and, and, and talk to each other without even talking. If you happen to have a team like that, that is happy working together. The other thing that happens is, your cost and time is pretty much fixed. So so the team from a company standpoint has the keeping costs, right. And time is pretty much going going in a pretty linear way. What I'm trying to explain is, the scope is what's changing over time with the team. So you can you can start adding new or different things to the teams. And if one project ends, a new one can begin. As long as you have a problem to solve. You can leverage on on on a scrum team or several Scrum teams in order to make sure you keep addressing the problems that you want to tackle as a as an organization or as a group, right. It doesn't have to be a company always. But we can certainly use companies as a quick reference point for Scrum teams.   Michael Hingson ** 51:47 You mentioned to me in the past that Scrum teams don't in Scrum and doesn't embrace as much some of the traditional tools like Gantt charts and so on, why is that?   Rodrigo Quezada ** 52:00 Correct. The Gantt charts are mainly used within traditional project management when you are considering that all your assumptions are gonna are going to hold true through the whole lifecycle of your project. And therefore your planning is perfect at the beginning. But as soon as US bottlenecks that were not foreseen in time, or, or potentially, let's say technical difficulties that you find along the way. And those were not accounted for in the original Gantt chart. So usually what ends up happening is that the Gantt chart starts to deviate along from the actual planning or actual action in place. So eventually you depart from somewhere very different from where you intended to arrive. So what what is scrum does, there's there's some metrics that are used, usually referred to as velocity, which is very subjective, because it means something different to different teams. So one team have a 50 story points velocity, and our team can have a 500 story points velocity, which might seem that 501 is much faster than the team which 50 points but it's so subjective that from a working standpoint, that one was 50 points can be actually delivering more work to the to the to the organization. But anyway, you can have these kind of like burn downs, or burn up charts that you can use to track sort of metrics of how the team is doing against the planning. But remember, that is based on short spans of time, so no more than four weeks. So even if you're meeting or missing your targets, it just meant to be contained within a small or short timeframe for you to understand, learn, adjust, and do it again. But do it better.   Michael Hingson ** 53:36 If you don't get a project done in the four week time that you originally set based on the scrum rules.   Rodrigo Quezada ** 53:44 That would be a problem. Most of the time, what you do is you break down into small chunks that are achievable within a sprint, we we can think of and then again, this might come back to if I remember correctly, this Eric Ries and the Lean Startup, there's something called an MVP or minimum viable product, which is basically from everything we can do, what is the minimum we can achieve. So if you plan yourself to at least achieve a little something, and then everything you can add on top of that before the sprint is over, I think there's a safe path to always have something to show for you as a team accomplishing something because if you if you kind of lean towards the all or nothing approach, either I believe or everything or I don't have nothing to show, there could be points in time where the risk is high. And you're going to show up to the review saying I didn't complete it my work, right? There's nothing to show. So what I'll probably suggest is, is take the MVP path, always have a little something that is something you can guarantee as a team that you can deliver. And then if you happen to have extra time within your sprint, go build on top of that and add more things to here's what we have completed by the sprint review.   Michael Hingson ** 54:53 So if something doesn't get done in the appropriate time, you really We have two potential reasons for that, that I can think of one is, you made the goal too large, or too, the team isn't functioning nearly as well as it should be. And that's an in both cases, that's something for someone to go back and reevaluate.   Rodrigo Quezada ** 55:20 And that's where the rhetoric comes in. Because every by the end of every sprint, you need to collectively as a team say, Okay, where do we miss? Where do we waste? And what do we knew earlier? What do we need to do a little bit different to fix that in the future? So you're always looking for ways to becoming better and better as a team, which is one of the things that I definitely love about this framework.   Michael Hingson ** 55:41 Yeah. And that was why I asked the question, because, again, it's all about the team making a collective decision or creating a collective understanding. And again, is all about the team. Yes, it is, which then can communicate with the stakeholders and so on. In case it's the stakeholder that screwed up. And the stakeholder hopefully understands what the scrum team is all about. And we'll accept the observations when that happens as well. Yes.   Rodrigo Quezada ** 56:18 And there was something else that you mentioned that it triggered. Yeah, at one point in time, you mentioned about the team recognition. The sprint review is not only between this, the product owner and the stakeholders for the sprint review, you have to have the whole team. So the product owner can be presenting. Yes. But the team is there. So there's kind of like very specific questions about things on the, of how the product was built, or how the product is working, or any What if coming from the either end users, customers or stakeholders. That's where the team can bring in their expertise, because they build it together. Right? So the team has a voice as well within the Sprint Review isn't is not necessarily only a steal your point like like just who is managing the team, it's more off. Here's the whole team that builds together. And any questions, here's a whole team in order to be able to answer as a team.   Michael Hingson ** 57:10 And that's what really makes this such an exciting concept, because it's all about the team. And and hopefully, when the team completes a project, if they really work together, then no one tries to separate the team and put different people from one team on to another team. They allow the team to continue to operate and be a cohesive unit. Yes.   Rodrigo Quezada ** 57:35 And there's one more thing that also Bond's things together, which is one of the pillars of Scrum, which is called transparency. The process is extremely visible to everybody in the organization. So what the team is working on what progress are having, everybody can actually go see. So whether the team is working these working items, which you should refer to, or at least I'm used to referring to them as PBIS, or product backlog items. Everybody can go see what the team is working on and how they're communicating and their evidences of work completed and everything else. So stakeholders don't always have to rely on whatever the product owner says. They can actually go and see what the team is doing. Because the process is extremely transparent to everybody. And for sure, the team as well. So So usually the work is not a sign that work is is kind of taken, right? How can I help? How can I contribute? So I go to the to the sprint backlog, and I grab a working item. And let's say me as a developer, I go work on that. And every now and then it's not, it's not. It's not recommended that it's done. But every now and then even other roles such as a scrum master can go ahead and take a little bit of work, even though it's not recommended can be done. So. Yeah.   Michael Hingson ** 58:49 Why should more people embrace the scrum concept of doing work?   Rodrigo Quezada ** 58:55 God, gosh, first and foremost, because, aside from the fact that it, it's fosters teamwork, and increases happiness levels on and promotes mastery from team members, which makes it ever more exciting, it helps you deal with that the solutions to complex problems borrowing from the definition of Scrum. So as long as you have complex problems to solve it, what you want to solve is pretty repetitive and fairly and linear and straightforward. Yearning, you're probably not going to need Scrum. But as long as it starts to deviate from something that is that predictable. You can rely on group of professionals working together as a unit in order to tackle together those those problems and come out with adaptive solutions. Cool.   Michael Hingson ** 59:46 If people want to learn more about Scrum and the process, how can they do that?   Rodrigo Quezada ** 59:54 I'll probably say start out with information that is already provided. it on the scrum guide. You look at it as that the scrum guide. It was created by Ken Ken Shriver and Jeff Sutherland, the creators of Scrum. It's out there on the internet. So so I'll probably say start there, because that's the guideline for the whole framework. And   Michael Hingson ** 1:00:16 what is it called   Rodrigo Quezada ** 1:00:18 the scrum guideline, okay. It's even trademarked. But it is open to the public, you don't have to even pay to in order to be able to read or things like that. And it's been translated to different languages as well. So I'll probably say start there, because that's, that's pretty much the epicenter from for the whole framework. However, if you want to learn a little more, there's different books out there and different organizations that can help in the process, including certifications and everything else. Guess one of them, for sure, is this book that started me with Scrum, which is called doing twice the work and half the time by Jeff Sutherland is definitely one of my top recommendations for Scrum. There's also two websites that I think of that are that are scrum.org. And there's other ways to that is called Scrum Alliance. Dot I believe that.com. But if I'm incorrect that.org Both both promote a lot of conversations and best practices on Scrum. So a lot, those are great resources. There's a lot more out there. But those are the ones that come top of mind.   Michael Hingson ** 1:01:23 And is there a way if people want to talk to you and kind of get more thoughts from you about all this or just get to meet you? Is there a way for them to do that?   Rodrigo Quezada ** 1:01:32 Yeah, we could probably use LinkedIn for that. I haven't had a lot of civility. But I don't mind if I do because the whole purpose of this podcast was sharing this out loud with more people. I know what I know what up what I want that to be spread out, because I'm definitely a scrum enthusiast. So if there's way that I can help somebody else I'll I'll be happy to. So   Michael Hingson ** 1:01:59 how can they reach you on LinkedIn? What? What do they look for?   Rodrigo Quezada ** 1:02:06 Let me go seek my gosh, would it be okay if I sent it to you, I don't have it handy. Kind of like but but you can look for my name, Rodrigo. Queszada Queszada with a Z and Reyes with a Y in the end. And it's I think it's fairly accessible. Once you're into Lincoln system. Go ahead and spell all that for me. So sure, no problem. Rodrigo says spelled R o d r i g o, my first life name. Last name is Queszada. Which is Q u e z as in Zebra a d as in Daddy a. My other last name it which is Reyes R e y e s   Michael Hingson ** 1:02:51 There we go. So we can search for you on LinkedIn with that. So what are you doing? You're not working?   Rodrigo Quezada ** 1:03:00 Guys, I would rather work I'm usually doing some training. And aside of that, for sure. It's spending time with friends and family. It's a mix of of those. I have these reckless pursuit of understanding and training and eventually I'll find my purpose in life. I'm still in debt that I cannot say I have it. What I always feel I'm getting a little bit closer. So I hope I get there before. Before my end of   Michael Hingson ** 1:03:24 life. There you go. Do you do you have a family? Are you married or anything like that? Yes.   Rodrigo Quezada ** 1:03:28 I'm married. Two kids. Almost 10. Actually, they're just about to be 10. And, yeah, and also two bucks. So So yeah, I think.   Michael Hingson ** 1:03:41 Yeah, so So that's six in the family. If you get four more, you can have a scrum team.   Rodrigo Quezada ** 1:03:48 Yeah, getting close. Yeah, keep   Michael Hingson ** 1:03:50 keep working on that. Well, Rod, this has really been very much fun and enjoyable. And I really appreciate you coming on and talking about Scrum. It's a concept I have not been familiar with. But I'm going to go learn more about it. I think it's fascinating. I think there are parts of it that as I listen to you tell it that I have used in the course of my life, although I never understood it and call it Scrum. But I appreciate it. And I think it's an extremely valuable thing. Anything to promote teamwork is always a good thing. So I want to thank you once again for being here. And I want to thank you for listening to us. I hope you found rod's explanations and comments worthwhile and useful. Love to hear your thoughts please feel free to reach out to Rod and on LinkedIn and I want to hear from you please email me at Michael m i c h a e l h i at accessiBe A C C E S S I B E.com. Also, you can go to our podcast page www dot Michael hingson.com/podcast hingson is h i n g s o n? You can obviously as you've already discovered, find us wherever podcasts are available and I would love I have to ask you please to give us a five star rating. Wherever you're listening to us, give us a five star rating we we appreciate those. But we do want to hear your thoughts and your comments and anything we can do to make this better and rod for you and for all of you listening. If you know of anyone else, who you think we ought to bring on as a guest on unstoppable mindset, please let us know. We're always looking for more people who have stories to tell and things to talk about. And we want to hear from you. So one last time again, Rod, I want to thank you for being here and talking with us today.   Rodrigo Quezada ** 1:05:33 It was quite an honor for me to be invited. So thank you so much, Mike.   Michael Hingson ** 1:05:40 You have been listening to the Unstoppable Mindset podcast. Thanks for dropping by. I hope that you'll join us again next week, and in future weeks for upcoming episodes. To subscribe to our podcast and to learn about upcoming episodes, please visit www dot Michael hingson.com slash podcast. Michael Hingson is spelled m i c h a e l h i n g s o n. While you're on the site., please use the form there to recommend people who we ought to interview in upcoming editions of the show. And also, we ask you and urge you to invite your friends to join us in the future. If you know of any one or any organization needing a speaker for an event, please email me at speaker at Michael hingson.com. I appreciate it very much. To learn more about the concept of blinded by fear, please visit www dot Michael hingson.com forward slash blinded by fear and while you're there, feel free to pick up a copy of my free eBook entitled blinded by fear. The unstoppable mindset podcast is provided by access cast an initiative of accessiBe and is sponsored by accessiBe. Please visit www.accessibe.com . AccessiBe is spelled a c c e s s i b e. There you can learn all about how you can make your website inclusive for all persons with disabilities and how you can help make the internet fully inclusive by 2025. Thanks again for Listening. Please come back and visit us again next week.