The Proactive Project Manager

What is Agile Project Management with Special Guest Kevin Sellers

November 15, 2020 Xavier Billingsley & Kevin Sellers Season 1 Episode 104
The Proactive Project Manager
What is Agile Project Management with Special Guest Kevin Sellers
Show Notes Transcript

Agile Project Management is an iterative approach to managing projects. It is a more collaborative approach of working with stakeholders, work is being delivered in smaller chunks, and offers a consistent feedback loop. On this episode we have Kevin Sellers joining us! Kevin is a consultant, certified Agile coach and Digital Program Manager. We will discuss the differences between agile vs. traditional project management, as well as the steps one can take to shift from traditional to agile project management.

Youtube: https://youtu.be/_1EjMhfzW5I
Website: www.ehhudson.com
LinkedIn: https://www.linkedin.com/company/e-h-hudson-consulting/?viewAsMember=true
Facebook: https://www.facebook.com/Eh-Hudson-Consulting-102445911393454
Email: xavierb@ehhudson.com

--------------------------------------------------------------------------------------------------------------------
Guest Info
Kevin Sellers
Email: ksellers@c2consultingllc.org
Website: http://www.c2consultingllc.org/

Speaker 1:

[inaudible]

Speaker 2:

Hello everyone. This is[inaudible] Billingsley from EA tuts and consulting. Welcome to another episode of the proactive project manager podcast. On today's episode, we're going to talk about agile project management. Yes, yes, yes. I'm excited about this one. So in this podcast, we have a special guest Kevin Sellers. Kevin is a CEO of[inaudible] consulting. Kevin has over 20 years in the field of project management. He has earned his degree in construction engineering management from Purdue, and he has earned almost every certification you can think of. I mean, really, um, he also has his MBA from Indiana Wesleyan university. Now, one of the things I admire most about Kevin is his zeal for knowledge and passion for helping others perform more efficiently. Um, just to read a few of his certifications, um, that, that he's armed. Uh, Kevin has his lean six Sigma black belt. He is a safe agile list. He has a safe dev ops certification. He is a certified product owner. He has his combine certification and he is a certified agile coach. Welcome to the show. Kevin, is there anything else you would like me to add?

Speaker 1:

Thank you. That was an awesome intro. Uh, very, uh, excited to be here.

Speaker 2:

Great. Great. All right. Um, so I'm just going to jump right in. Um, I do have some questions for you, Kevin. So the first question I have is the million dollar question. What is agile project management?

Speaker 1:

Um, that's a great question. Um, to talk about agile project management, you, can't not talk about traditional project management, right? Which we all know those in the industry know is the standard bearer for a great project management delivery. Um, when you think about agile project management, it's basically a general approach using software. It relies heavily on teamwork collaboration. Um, if you think of the agile manifesto in the meeting in Colorado in 2001, which birthed the agile manifesto in the term agile, um, it, it really got its beginning naming and nuance at that time, but there was a previous time where it wasn't called agile. It was called agility, which is sort of the broader term. Um, so that's where agile came from from a software perspective and kind of where we are today.

Speaker 2:

Okay, great. Thank you for that. Now what I'm curious about, I know you have agile, you have scrum, and then you have, I know you have your safe certification, which is scaled agile. What makes scaled agile different from scrum?

Speaker 1:

Um, well, scaled agile, um, different from scrum scrum has to do with one team working collaboratively, right in an iterative approach, um, to deliver some sort of product or project functionality per se. We're talking about, uh, coding safe is the ability to take multiple scrum teams and coordinate across multiple teams that delivery, and then edit a fashion. It also looks at not only the agile space and the different types of frameworks to deliver a software, it also takes into account lean, um, which lean gets into more traditional think of manufacturing and cars. Um, Toyota way back in the day, when people were talking about the efficiencies of cars that sort of changed the paradigm of how we make cars back in the day to now it takes both of those principles and practices emerges it into one way to deliver additive development in a quicker fashion than waterfall.

Speaker 2:

Okay. Now I do have a question. Now, some say that project managers do not have a place with when it comes to scaled agile. Can you help me understand that? Is, is that something that you agree with and, and, and what are you seeing? Cause I know you deliver agile projects and system that's that's, that's what, you're where you're an expert. What are you seeing in the industry as far as the project managers and where they actually fit when it comes to scaled agile?

Speaker 1:

No, not from a skill agile perspective. Um, there, there are two schools of thought. One school of thought is you typically would sort of take a traditional project manager and you almost have to repurpose his skillset, um, in, in a sense that that original skills that you learned in PMI and project management and pen box is still relevant in a lot of industries that need that, you know, sequential delivery. Those will always be around. So project management will always be around when it comes to safe. Project managers have to evolve. Um, being a traditional project manager is almost like flipping you three 60 on your head because you think of traditional project management, it is command and control. I, um, where you have a certain amount of resources they need to deliver, you get the monitor and track when they deliver it, you give them deadlines. You work with other matrix organizations. When you work with other resources to do certain things and safe and agile, you have scrum teams within those teams. Their only obligation is to deliver what they're specified to do. There is no multiple resource managers. There is no matrix organization. So when you say about traditional project management versus moving to safe, it's more so a culture shift and we'll have a paradigm shift of how you think of delivering something than it is about. PM's not being valued or not being used in safe. They're using safe. A lot of PMs become a quote, unquote, a senior scrum masters or scrum masters, and the sense where you're now working still with a team and you're delivering a product, but you're doing it at an incremental level, um, using different tools and techniques than your traditional scrub than your traditional project management values.

Speaker 2:

Okay. So that, that brings up, uh, uh, another question, Kevin. So you said that the PM will become somewhat of like a, a super scrum master source, so to speak. And that's kind of what I'm hearing, um, from, from leaders in, in the industry, but what, what about when it comes to like those project manager technical competencies that, that we're known for? Uh, for example, um, when, even though it's a scaled agile delivery, that that's our methodology. What about the budget, the forecasting, what about risk management? And I know that the scrum master is supposed to capture and work on impediments from the dev team, but what about those overall risks? What, what, what happened to those? What about a schedule? Can you help me explain some of those things? And when it comes to like agile projects, is there still a place for those traditional project management tools and deliverables?

Speaker 1:

So, um, you know, I'm glad that's a great question. Um, what'd you go to find it a lot of misnomers people think because you do agile that you use those a lot of that you don't, it's just different in the sense that, um, from a planning perspective, we still plan, even though we're practicing safe and sometimes extreme product delivery of planning is done, but it's, here's the delivery. And it takes me 15 months to plan out these next couple of months. And here's where I'm going to go on to deliver a certain piece. And the reason why that's important and why you don't do a long-term plan is because what agile does that traditional project management does? It is that agile allows for the ability to pivot, to change with the industry or with, um, external as well as internal forces that may force you to change. So for example, if you think of chase and most people know chase as a, a brick and mortar space, right, but also people know chase now as a mobile app right now, everywhere you hear the commercials about what they do. So traditional project management got chased to the brick and mortar, but if you talk about the moving to the app and being able to bank anywhere and not have to worry about having a storefront, which is, which allows you to gather more customers and capture a greater market share, that is where the agile piece goes. That traditionally can't go, right. Um, so it's like a leap off to the next level. Um, and that's where you you'll find where the planning still happens is just at a smaller level and for a smaller chunk of work, you still do risk. You know, I'm, I still document risks and issues. Um, we call them work items, we'll stick them, you know, in some sort of, um, tool for tracking and measuring risk and issues. Along with the development, we cover those on a weekly basis. We talk about them. Um, sometimes even on a daily basis in our daily stand-ups so risk and issues still happen. Planning still happens. Um, now budgets are a little bit different. Every organization is different when it comes to budget and, you know, there's exhibit being in the business for as long as you've been like me. Um, and what you're finding in some spaces now, um, when it comes to agile, they'll fund a team for the year and say, Hey, I have X amount of resources that I know who they are. I know what they can do. And I know what they're going. I don't know what they're going to work on, but I know for this year, I got 10 people to say these two people are going to do X amount of work for the next 12 months. And they fund that team for that year. They don't fund them by the project that they're delivering. They fund them by the number of work hours they're going to put into doing different types of work. And that's a fundamental shift in how project management traditionally has done versus agile. Because in traditional, you have a project, you have a business owner, you have a person who's sort of the major stakeholder who's spearheading that work. And is the voice for that project. You had the same thing happening in business today, but what's changing is you don't fund a project. You fund more of a product. And that product has incremental development that is being pushed out throughout the year or multiple years. And that team you have is a fixed team. It change that people don't come in and out, you don't deal with different managers. It is that team. And that team has within it, all the capabilities to do inception all the way through to production and operational support all within that team or that, or that serious series of teams are talking about safe. So that is the major shift from risk and issues planning, and as well as financing, the financing has been the last thing to try to catch up to agile because it's different. Um, for a long time companies couldn't figure out how to finance an agile team because you, you, you you're, you're funding people, not projects, you're funding products and you're funding, different incremental functionality that will be delivered throughout the year.

Speaker 2:

Hmm. Okay. That makes sense to me. Thank you for that. That, that has a great answer, Kevin. Uh, but what about, so what you just mentioned, you basically talked about agile and those project management activities from a development perspective, when it comes to it, if you have a skilled, um, you use an, a skilled or an agile methodology to deliver project, some projects, you have more than just an it component. Like for example, um, I've worked on plenty of product development projects where we're creating a product, a brand new product that involves both business, as well as an it component. What about those business activities? Uh, how do you streamline those activities into an agile plan?

Speaker 1:

Um, great, great, great question. So, um, that is what safe takes into account. So traditional scrum does not take into account the bigger picture, right? I call it the end to end. That's why I feel like, you know, in inception like business marketing comes up with an idea that came from the customers that gets formed into requirements that that requirement then gets pushed down to development teams to do the work development teams, do the coding test. It looks good, toss it over the wall to operations team kind of does some novice transfer to them to get them to be called quote unquote, what we call level one response is when is in production has been productionized and working. What you're finding now is, and that's why safe is even important than why have the ball and has put a foot hole, a great foothold into development of, of how we deliver in this and this age today is that safe take into account the business aspect of it. Um, so safe has different levels. It has kind of a team level, didn't have the program level, and then it has a portfolio level, right? And in those levels is where you start getting more business involvement. So at the, at the project level, you don't really get a lot with the businesses involved. You know, the businesses already kind of come up with the ingredients, right? And the development team is baking a cake. I, um, and then putting the icing on it when it moves over to operations, right. Kind of puts the icing on it. And here's this beautiful cake, right. That people are going to eat. And I love what you're finding is what they found is in agile is that was the piece that was missing development and give things out pretty quickly and putting teams together, using a different methodology in agile. What they found was that the business, the amount of input that they had wasn't as much. So what you find in safe is we do what we call, um, iterative planning or PR planning, right? That planning is like, it lasts about three or four days. Most organizations go as short as one day. Some go as long as four or five days is where everybody's in the room, marketing business County development, operations, even if, sometimes they'll even have, um, partners, stakeholders who are outside of our particular business, that may be early adapters of what we're going to be pushing out involved in this three-day meeting the last all day, there's an agenda put together and they literally map out what they're going to do. Who's responsible for what, and it use kind of this pinning, pinning, yarn sort of concept, where you basically put all your ideas on the board and you map them across with strings about who's going to do what, and when it's going to be needed, you not only look at and get all of the industries that have to be involved or all of the areas that are impacted. You also look at the tiny and the dependencies across, not just it, but business, right? That is where safe has, has, has sort of took it to another level from agile, right? It's, it's moved up another level up the game, because now they're saying, Hey, we can go from inception to production with business involvement through all of this and deliver you a quality product. And typically save does around anywhere from 10 to 12 sprints. And they're traditionally about two weeks on average, you know, uh, agile talks about going between one and four weeks. If you get into extreme it's one to six weeks, if you take that concept of the framework of how to deliver it and a cadence that they deliver on, they can deliver literally a new functionality, a new product within a three month timeframe, which is unheard of. Um, if you look at what we did 10 years ago, when we talk about delivering something in nine months, 15 months, no nine months with was, was seen as aggressive and, and, and, um, game changing. Now we can deliver new content literally. And we, and, and, and that's the advantage, and it's not just about software anymore. Businesses are starting to adapt agility as well, looking at their processes and how can they be more integrated with the process of delivering content to our customers?

Speaker 2:

Hmm. Okay. Thank you for that answer. Thank you. That makes sense. So a question, another question I do have for you, um, Kevin is, you know, when people think of project managers, they think of a schedule. Typically that should be one of the things that as a project manager, you should be proficient at, at doing where does a schedule fit when it comes to agile scaled agile? I mean, it does it disappear. Um, because I know at this point, you know, you have all of your requirements and everything is in the backlog and, and, and you creating user stories. And, you know, you're, you're, you're, you're doing that incremental development, as you mentioned earlier. W what, what does a project plan fit? Is, is it, is it something that you do at the, at the portfolio level, or do you just not do a project plan or project schedule at all when you're, when you delivering your project via an agile methodology?

Speaker 1:

So if you think about the traditional project plan that a traditional project manager would do for pretty massive project, right. Overall, then you're looking at the portfolio level, right. Um, because they're looking at long-term implications, long-term impacts of a product that they're going to put out when you look at it from the team level, right. Cause there's levels to this, is that at the team level, you still scheduling, just schedule is shorter, right? You're looking at pretty much about a three month window at the program level. They're looking at probably for the year. What are the things we're looking to work on? What are the things we're looking to deliver? Um, when do we think we can deliver it? That input comes from the development teams, um, because the thing about traditional project management and about agile that, um, I think a lot of people tend to kind of have a little bit of difficulty with understanding how it's changed is before we had somewhat a little bit of power as a project manager from a traditional standpoint, because you're in charge with the dollars and the budget and the schedules that you have to deliver for the business, right? That is your customer in agile, you as a project manager or quote unquote, a scrum master was senior scrum master are not really in charge of saying when something's going to be done from the standpoint of you, you work with the teams and those product owners in the scrum development teams to say, Hey, here's the functionality we're trying to do this year, go away to your, to your lab and figure out how you think we can do this. Right? Um, you more so telling them kind of when we need it and what we need from a schedule, but they're going to tell you when they're going to deliver it, you don't tell them when they're going to deliver it. And the reason why this is why that's like a paradigm shift, and you think about traditional project management is because we're not the ones doing work. Um, I just want to take tenements from, if you think of, and you know, much about lean and getting the green belt and black belt, they call it going to the gemba people who are at the hole on the ground, who are doing the work or the best to tell you when the work can be done, or even to innovate that work, to tell you how much battery could be when we deliver it. Um, what, what they found in all these studies in a lot of case studies and Harvard business review and other project management stuff. And you look at their website and look at a lot of the agile manifesto work. And also the PMI work combined. They're delivering content faster, doing agile than they are doing traditional waterfall. And that's not just an it space anymore. It's evolved, you know, even in manufacturing, you know, there's project management in manufacturing, you'll find that wherever project management has ever been, the agile space has come behind it and sort of revolutionized how you do it and what you do. So scheduling to your original question still happens. Um, it's just that, you know, a portfolio person in that safe format is looking at the long term, but it depends on what level you're at. You're going to be looking at a different schedule, whether it be a short three month period, a year period, or however long, the life cycle of the product.

Speaker 2:

Okay. So you mentioned that the team, instead of what, one of the differences is that in traditional project manager management, we tell the team when to have the work done. And when it comes to scale agile projects, the team tell us when the work will be done. So what about when you have integrations? That's that's when I see the complexity coming in, um, because let's say you have the mobile team development and they they're telling you that they can have this done in three sprints. Okay. Um, and that puts us well, they say they have two week sprints, so, so six weeks leg later we'll have the development done for our mobile piece. But what if there is a dependency on some other it system or business process that has to happen before then or after Dan w w w what we need those dependencies to match, or to link up this, the mobile team wouldn't have that type of insight. How do you handle situations like that?

Speaker 1:

Um, Oh, that's an awesome question. So, um, then we talked about the scrum team and the makeup of the team, and we did, we talked about safe and that sales meeting, the mobile team is already there. So in that original planning, it took that one to three or four days that was already baked, that was already baked into it when they would go and deliver it. So in this meeting, and literally, um, you know, that's a discussion for another day, like an actual planning, energy and synergy about those, right? Cause you have everybody involved in one place. Would it be all remote now, or whether it be traditionally when I actually do some of them, other, my other class that I had at the time, we'd do it all face to face. They fly people in from Europe, all the places where we have business with all who's all in fact with getting the room. And we walked through this and they map out dependencies. And because they were doing two week or three week intervals, they would say, Hey, this is what I need to have this. So that they're telling us when they go to habit, what you're going to find is you may say, Hey, I need this by this date. And as a project manager, a lot of times, because we are not coders or developers, I may not understand the complexity of it. Right. And that's when the technical people would tell you that it can't be done in two weeks. That's going to take like four weeks. And as a project manager, sometimes you come back and say, no, I need this in two weeks. Do whatever you gotta do, but I need this in two weeks. What, what, what, what are you going to find is an agile in the safe, they'll say, you know, I need to send in, in, um, two weeks all, but no, it felt like for what can you give me in two weeks, but what can I work with in two weeks? So what that team will do is give them something to start. So that, that other team doesn't have to wait four weeks, but they'll kind of be going to be coding in, in parallel. The biggest thing you'll find in agile is there's a lot of parallel tracks running at the same time. And traditional waterfall is sequential. You're waiting. There is no waiting in agile, literally you're working in different, um, areas. And then you're moving code in. And to your question about, well, wait a minute. What about interdependencies? Well, th that is accounted for in that planning, but also the part that a lot of people are starting to realize when it comes to traditional agile project management is the underpinning of technology, right? Has been the evolution of how agile is taking advantage of it. So for instance, one of the places I worked at, we had like different teams doing different things in the dev environment. They didn't promote it. Right? And that's what you tend to get your break. It's your books. You find issues within safe. There is a refactoring period, or they'll call it a hackathon, NOAA innovation period. Typically in that like four to five weeks of two weeks sprints, they call them, there is a, about three quarters of the way through an innovation or a hack where they actually take care of all the refactoring of coal and books and issues. But throughout that whole process, every two weeks, you are you pushing code like every day, literally our teams push code into dev and ENT on a daily basis and traditional project management, and then traditional delivery of functionality from a software perspective, you don't push code in until you've done all the coding, tested it, make sure nothing's wrong and then moved it in. So you literally will take, say six months when I've delivered something in six months, that has actually less bugs and less issues because it's the whole thing fell first, fail, fast thing and agile. If you've ever heard that term, it's a word thrown around a lot in agile, fail, fail, fail first, fail, fast, fail, fast, fail first because the faster I can find an issue and deal with it and fix it. Then the better I am moving on to the next thing versus I find it later on in the process, and you got to remember this too. All this is driven by the world we're in and the competition between different competitors in your industry and now competitors outside of your industry, right? Because now we have disruptors where other people coming from other technologies can come in and disrupt your business. And in order to be efficient and effective and to be agile and be fast at delivering quality content, you have to have the ability to incrementally push out products or functionality. If it's software or products, if it's a business, if you cannot do that, you will not be successful and you might not be around long. And I know that sounds harsh, but it is a true reality that we're going through right now is agility. And even that starting to become something of, um, old news, because now we have dev ops and we have digital transformations. Now I won't get into the details of that, but that is like the next evolution off of agile and safe. So traditional project management is always have a place, but if you're going to be evolving with how technology and the advent of AI and machine learning and autonomous vehicles and robotics, robotics, and all these things, because you can do things much faster and repetition and cut out waste and cut out defects and issues early on, because you can do a lot of automation and early testing of, um, ideas and functionality. That pace is so fast that traditional project management from a traditional standpoint, you'll see sequencing is so much faster than if you're a traditional PM. You may not be able to keep up how it's changing and how fast the change is coming.

Speaker 2:

Okay. And this actually is a perfect segue to my next question. So as a project manager who really doesn't have a lot of experience delivering agile projects, what can they do to be on the cutting edge, that to, to be able to come into an organization, add value right away, you know, what, what, what types of things do they need to be aware of what new technologies do they need to be aware of? Um, so that they can be a value add right off the bat?

Speaker 1:

Um, yes. So, um, so I'll, I'll, I'll, I guess I'll stay. Cause I think this is probably my third time seeing it's just because I just wanna make people, make sure people understand that traditional project management isn't going anywhere. You still want to need those. Right. They still operate a lot in like in construction, but traditional project management will always be around. It never will change because even in construction, even though they're delivering things a little bit faster, it's still traditionally suited for project management and, and the traditional sense of work and how work can be done. Because with technology, you can actually, you know, do multiple things at different times and construction you can't right. So from an industry standpoint, certain industries may always have a project management from a traditional standpoint, but certain industries, it may be a different if I'm talking about out of a hundred in software may be 80% agile, 20% traditional, but it construction that might be the opposite, 80% traditional 20% agile. So people will w we'll try to get faster where they can and whatever industry you're in. But I don't think that traditional project management will ever go away. So those tenements and getting that skill set, it's always going to be a value there. There's no question in my mind that always be a value now, to your point to your question about what can a traditional person who went through PMI. And that's what they've learned is what they know to kind of evolve and change. Um, they, for me, what I did was, um, I personally like did some free projects with like some nonprofit organizations on my own time, because, you know, for me, I kind of saw the writing on the wall when I was working, uh, with, uh, back in 2012. Um, I, when I was working at a particular company and I was doing traditional project management, but it was just a new thing going on. And I started reading about it and hearing about it. And I found a company introduced scrum masters to us, and I was like, Oh, okay, what's this about? And, uh, that was my way of getting into the agile space, but for those who are working in the traditional space and they don't have the ability to do that doing for non-profit or for organizations get into it, that is probably be your best way to kind of keep learning, doing what you're doing and getting that other skillset. The other part is doing a lot of reading, um, learning, uh, reading the agile manifesto, but about scrum, not that you want to become a scrum master, but just understanding what scrum is. Um, scrum is just one of the methodologies under agile, but it's the most widely used, right? Um, you also have extreme programming. You also have combine, you have some people call it a scrum bond. Some people started mixing methodologies, but there's all these different methodologies that help with delivering not only software, but products in general, because XP was used in the building of jet fighters for the military. So just learning and understanding the history of what agile came from and what it's about would be, I first and foremost is get the learning read on books, articles, and then you get your hand on, read it, learn it from the allowable sources. Um, maybe take some courses, um, one or two courses to get an understanding and scrum agile. Um, a lot of these courses are free. Now, a lot of content is free online that you can get, um, from PMI, from scrum Alliance, a lot of different places from that ink. I mean, it's so many different organizations that are doing now and the cotton is there. The second part, the third part of that one is getting the education. The knowledge second is getting some way to better practice it, right. Um, while you're still trying to obviously, you know, earn money and take care of your family, it's a job, right? You went and got a degree and a certification in your field for project management. You want to make sure that you're, you know, being able to use your skillset, but the other part would be eventually is to transition to one of those roles. And you still gonna apply a lot of things that you still learned in project management. Traditionally, that doesn't change. I still do budgeting. I still do schedules. I still do planning. I still do risk and issues. It just depends at a different level. Um, so those would be the three things I would say, um, books, get some training and, um, try to do some non-profit work. If you are working, full-time doing project management and the traditional setting, if there's any opportunities in your company that allows you to do it. Like I got when I was in 2012 and he offered up scrum and saying, Hey, this will help, you know, give you another arsenal. And you know, not another tool in your tool set to work with to deliver and be a value to the organization. I feel ablations doing that are willing to pay for you to get that I would do it. Um, and it's not about taking it to use it more. So some people I know have taken it and don't use it at all. And like, you know, Kevin, it was a waste. Some people take it and they'd be like, okay, it gives me another, another skill set. So let me go ahead and, you know, get some background in it so that now I have another selling point of what I can do. Not only can I do traditional project management also can do agile project management. So it actually gives you a more marketable skillset.

Speaker 2:

All right. It's great. Great answer. Thank you, Kevin. Okay. So my final question for you, you know, as you mentioned, you're, you're pretty much always on the cutting edge of what's new in the industry. What are you seeing happening in the market that can make PM's more marketable?

Speaker 1:

Well, definitely when we talked about, about, you know, just the, the scrum or, um, the agile certification are definitely going to make you more marketable. Um, because what you're finding now is, you know, the agile agility is where you hit now, a lot of times agility covers not just software, it's talking about any industry, uh, in all areas of your business, that agile is kind of the threshold, but to understand, uh, how to improve businesses, not only from a it perspective, but also from a business perspective, I think lean certifications are dead on for that you're spot on for that kind of stuff. Um,

Speaker 2:

What about things like, um, like digital transformation and those types of it is, are there like certifications or any type of training that a PM can pursue in order to be more knowledgeable about those types of things?

Speaker 1:

Yeah. Um, so digital transformations are kind of in its infancy stages from the center there aren't really very many certifications. Um, I've kind of looked around, there are classes you can take, but, um, I've seen no real certifications from like legitimate places, you know, that would be worth your while and, and carry value on your resume. Um, like, um, I just took a course, um, that I'm actually knowing the process of taking right now, um, with the, uh, MIT has, uh, like a few what they call it executive sort of a non traditional courses that you can take, um, because you're not a student around digital transformation, AI leadership. So a lot of stuff is out there for you to take. Um, you know, and it's more so like a course that you take over a six week period or eight week period. No, not, not to get certified, but it's more someone like a certificate to say, you understand, and you've learned kind of how it works in the industry. Those have been great. Um, university of California, Berkeley has one MIT, Harvard. It's like a consortium of like these Ivy league schools that offer, um, these, uh, executive courses and those types of things.

Speaker 2:

Got it. Thank you. Thank you. Okay, well, um, Kevin, I think this will conclude our interview for today. Um, is there anything else you would like to add before we adjourn?

Speaker 1:

Yeah. David, I'd like to, um, thank you for having me and maybe spend time with you and your audience. It has been a pleasure. Um, I've known you for quite a bit of time now and, uh, as usual you're always doing awesome, extraordinary things, and I'm just proud to be associated with, um, with the podcast and getting a chance to, um, share what I know with your audience.

Speaker 2:

Wow. Great. Thanks. Thank you so much, Kevin. I mean, the information that you brought to this podcast today has been extremely informative. Um, that is a, a great Testament to your skills and your ability and, and your zeal and zest for, for, for learning and helping others grow. And as you mentioned earlier, be the best sales at that, that they can possibly be. I really appreciate you coming on to the show today and spending time with me, um, without do, is I'll make sure that I put your information in the notes of the podcast so that, you know, if it's okay with you, if anybody would want to reach out to you as questions. Um, I'll definitely do that. Thank you. Thank you. Really appreciate it. All right. Thank you, Kevin and everyone. Thank you again for joining and listening to the podcast and everyone have a beautiful day. Thank you.