You are listening to QA talks, a podcast for quality assurance executives implementing digital transformation in their organizations. In this show, we focus on the unique pitfalls inherent in quality assurance and quality engineering and how these executives are navigating them to position their organization for the future. Let’s get into the show. 

Logan: Welcome back to QA talks. I’m your host for today’s episode, Logan Lyles with Sweet Fish Media. I’m joined today by two very experienced guests. We’ve got Jermaine Oldham, Vice President of Engineering and Technology at J B hunt. And as he has in many sessions of this podcast, I’m joined again by Cigniti speaker. Jermaine, welcome to the show, sir. 

Jermaine: Hey, Logan, Thank you for having me today. 

Logan: Absolutely. Well with that, I want to give a little bit of background for our new guest today. Jermaine is an IT executive with over 20 years of IT experience, and he specializes in leading data, infrastructure, and application teams and initiatives for large complex organizations. His passion is to make technology the tool to support and enhance business processes. And more than that, the vehicle to make data accessible to all organizational levels and really helping to produce faster and more accurate results. I love to hear IT leaders that are so passionate about driving business outcomes for the units that they serve. So, Jermaine, I love that about your background. Cigniti speaker, welcome to the show. It’s great to have you again.

Cigniti speaker: Thank you so much, Logan, and looking forward to be in the session along with my key expert, Jermaine. Thank you for having us.

Logan: Awesome. Gentlemen, I know that you have done some speaking engagements together, so I’m excited to kick off a great conversation. So let’s start with you Jermaine, a question that we’ve been thinking on here that I’d love to get your perspective on. What are some of the key characteristics that you would suggest that quality engineering leaders really have to adopt right now in the digital space to navigate not only innovation, but embracing the change that’s happening all around them at an even faster pace this year than ever before? 

Jermaine: Yeah, I think quality engineers need to look at it from a holistic point of view. When you think about innovation and embracing change, this is in that level. There is change that’s happening around us and innovation will continue to happen. There’s kind of five key things that I would recommend. One, lead with confidence. Confidence is the key to know that innovation and change are out there, and you need to embrace it. I’ll say two, as a QE leader, you need to be willing to adapt and learn and grow. So, the key thing there is just being flexible to be able to adapt, learn, and grow so that you can evolve as a leader. Three, be willing to challenge your previous exceptions and understandings. Things may not be the status quo. So, you’ll have to certainly challenge your previous assumptions and understandings of what you thought you knew. And then finally you need to be open to failing. But the key with failing in this space is failing and failing very fast.

Logan: Tell us a little bit more about that. Jermaine, you know, you mentioned four great things there that QE leaders need to be thinking about for themselves – confidence, adaptability, challenging their existing assumptions, and failing, but not just failing, but failing fast, not just failing for failing sake. We don’t want to do that, but tell us a little bit about how you see that playing out well, either in your own teams or others that you admire, how did they fail fast and actually see that as a benefit for their teams? 

Jermaine: The key thing here is, as I attributed before, was failing very fast. It needs to be a kind of a fast feedback loop and a fast kind of evolution of how you work through problems and situations. So, I’ve seen leaders before you get myself and my teams where we failed on something, we try to implement something, we tried to adopt a new technology. We thought we had the use cases and documentation to support the business, but we didn’t actually hit the nail on the head the first time around. So, in those instances where I’ve seen that we failed in the beginning, we went back, and we iterate it to understand what we needed to do to improve on. We came back with a working model in order to solve the problem. So I would say just that there’s a continuous evolution where you may deliver a solution per the use cases and requirements that you gathered, but you may fail the first time, but don’t be swayed from the overall goal of trying to solve business problems. You want to fail fast and you want to come back and you want to be persistent. 

Logan: Yeah, it makes sense that it doesn’t stop with that failure. It makes perfect sense to me. Jermaine, you know, we’ve been talking about digital transformation on this podcast for a good bit. Digital transformation has caused disruptions throughout every industry. It seems like it’s been coming faster and faster this year like a wrecking ball with the COVID-19 pandemic. In light of all of this, it seems like DevOps is becoming more than just a nice to have component of any digital transformation strategy. What are some of your recommendations for enterprises trying to embrace this change that’s coming out them so quickly right now?

Jermaine: Yeah. I would say one of the things that are important is preparing your team for the cultural change. When I think about DevOps and I think about quality, I think about really how you are developing the tool chain and a methodology. The first thing you need to think about is culture, the culture of the team, the team, how you need to evolve from a culture perspective. I would say a second point I’d make was prepare the team and yourself to embrace a cross or working model. When you think about the implementation of DevOps in the digital age, it’s about a team it’s about a cross functional team that consists of not only just developers and IT operations, but quality experts as well. So quality engineers and quality leaders and quality analysts to make that kind of working model. In addition, you need to prepare your team to own the quality as a key pillar to delivering software. Personally, what I’m doing today and what I’ve done in the past. I’ve seen teams not own quality. Quality is extremely important. And in order to ensure that you’re going to deliver value fast and often to the business, you’ve got to own your own quality. And the last thing I would say on this is you also need to prepare the business to embrace getting valued to software delivery early and often. So it does you no good to have a very stringent pipeline where you’ve got dev and you’ve got operations working together, where you’re able to build, where you’re able to test and release, and you’ve got continuous testing inside of the pipeline, but the business doesn’t have the capacity to consume that. So, you need to also prepare your business in order to receive this value on a frequent basis as well. 

Logan: Man, I love that. It’s about the communication throughout the other functions within the business and communication within your team. Going back to your first point there, talking about embracing this change and making your team ready for that culture shift. I think we can talk a lot about the technology and the processes, but if that doesn’t actually play itself out because of the way that people are able to take advantage of this technology, then it’s somewhat all for not. And I think that’s coming through in multiple things you’re saying there, Jermaine. Cigniti speaker, I’ve got a question for you here. You know, we mentioned in your bio, you’ve got a lot of experience in setting up testing centers of excellence. And you know, when agile and DevOps started becoming more widely adopted, testing centers of excellence took a back seat, or so it’s kind of seemed at least. Do you think that testing centers of excellence are still relevant and important? And if so or not, you know, give us a little bit of your thinking on this right now. 

Cigniti speaker: That’s a great question, Logan. And as Jermaine pointed out that there is a lot of shift in the overall IT itself is happening, and that includes the quality as well. So, the testing center of excellence is becoming a challenging spot right now, and it’s getting into a next evolution, I would say. Quality and testing is not going to go away. It will exist in different format, right? It could be a quality engineering. And that’s where the industry shift is happening. Shift left, which is like, I want to get my testers ahead of the game to start working from the requirement itself, in the definition itself. I want each of my test engineers to be certified with the quality engineering concept or scaled agile framework concept. In the agile and DevOps model, the whole of the shift is towards building out pockets of excellence, which could be a quality engineering center of excellence, or digital center of excellence, or it could be automation, or it could be DevOps center of excellence. 
There are a lot of pockets of center of excellence is happening. Like the way, how agile is split into multiple parts and you call it as a story, or you call it as a scrum and execute them. Quality is also shift into each of those pockets, testing underneath the IT domain itself. Like for example, if I’m creating an IT life cycle with respect to agile or DevOps, you form a small scrum team or you form a small pot team, right? So, they may call it in different words. And within that, you are bringing in this test-driven development concept, and bringing in the quality engineers, or bringing in the software development engineer in test, and part of that team itself and creating that CoE within that in sprint, no development life cycle. So, this part of shift is happening at this point. So as TCoE evolving into the next stages of the excellence with respect to quality, we are repositioning the entire IT with respect to continuous testing in the name of quality engineering. And then we are creating this skill gap among the TCoE and having them to up-skill with respect to software development engineer in test or get them involved in a scaled agile framework and many of those upskill of certification that’s happening. So that’s going to be the new market that all our testers within the TCoE need to equip themselves in order to meet the IT transformation. 

Logan: I love your perspective on that Cigniti speaker. Jermaine, I want to circle back to something you mentioned earlier about really delivering value with this next question. You’ve been in the industry for more than two decades as we mentioned during your bio. In that time, you’ve worked with a number of different organizations and taken measures to initiate the agile and DevOps transformation. In your opinion, how does DevOps impact digital transformation and make it more valuable to customers talk, going back to that point about really delivering quality and delivering value that you were talking about earlier?

Jermaine: Sure, absolutely. So, when you think about DevOps, the impact of Digital Transformation driving customer value, first of all, you need to create a structured model and methodology for how you deliver software with quality through automation. And we’re not thinking about automation that’s essentially hands-off automation. And when I think about hands-off automation, I’m thinking about automation of builds, automation of test, automation of deploys, automation of monitoring. When I think about the impact as well, I’m also thinking about creating a software delivery model that provides a quick feedback loop. So in the DevOps world in relation to digital transformation driving customer value, you’ve got to have a system checks and balances that allow you to fail and fail fast as I was mentioning before, but it’s got to be a continuous feedback. So if my bill failed, because I didn’t pass the security check, I get notification as a developer and I’m able to adjust on the fly and reinitiate that bill to ultimately get that value, which is the code that I’m developing and the features and functions that I’m trying to iterate on the software and deliver a new functions and functionality to the business as fast as possible. 

I would say integration of testing as a practice needs to be first and foremost and embracing continuous testing is a requirement to success. I’ll tell you that a DevOps methodology in order to deliver software is just as good as testing that’s integrated. So, when I think about tests that I’m thinking about some unit testing of the code, I’m thinking about testing multiple modules together, I’m thinking about doing service calls and service testing. I’m thinking about a functional testing. I’m thinking about non-functional testing, performance testing. In the perfect world, this would be integrated as a product of your delivery pipeline, which is your DevOps pipeline. And then the fourth point I would make is you need to create a method to deliver software to the business fast and when they want it, but with higher quality. One of the things I’ve learned over the course of my career is that you never compromise quality for speed, but you want to do a little bit of both. You want to deliver it fast, which is the value proposition, but you want to do it with higher quality. So that’s essentially how I would summarize how DevOps impacts digital transformation and really ultimately how it drives customer value.

Logan: I love what you said there about quality and speed. And ideally you want a little bit of both, and that’s just such a quotable little moment there, Jermaine. I love your take on that. You mentioned earlier about getting your team ready for the shift to a DevOps culture, which really a key component is this aspect of shared responsibility. Can you talk about specifically that cultural aspect in the teams that you’ve led, how you’ve implemented that or shifted mindsets or gotten people ready for this idea of shared responsibility that’s so integral to a DevOps culture? 

Jermaine: Sure, absolutely. When I think about DevOps culture, DevOps culture is so important because without culture, you have no DevOps. So, when I think about DevOps culture drives the following things – better communication. You’re very intentional about how you communicate. You’re very intentional. You’re driven to communicate because that’s the cross or working model that I referred to earlier. It drives better collaboration between development, IT operations, and QA teams. So that’s really working, not in a silo, but working across the organization in order to deliver software fast, but with higher quality. We’re not thinking about the culture and kind of that shared responsibility, you have shared accountability. So shared accountability because there’s different parts and pieces that people play and teams play, and the leaders play within the DevOps kind of delivery model. It also drives increased transparency. So when you think about the culture, you’ve got to work with others and you’ve got to work with others very frequently, and you can’t get in a situation where you’re hiding something or trying to suppress something on the development side, or on the IT operations side, or when you’re doing the testing aspects of it. You’ve got to be a hundred percent transparent. And one of the final points I’m making this is that with culture, You’ve got to trust. So in the DevOps culture, one of the underlying factors that you’ve got to have is you got to trust one another. So you’ve got to bring people together, you’ve got to communicate, you’ve got to trust one another. If you get that and things start clicking, then that’s when you’re able to really deliver software faster with higher quality.

Logan: Yeah, absolutely. And then you achieve those results that you were just talking about, where you’re able to do a little bit of speed and a little bit of quality at the same time, but while not sacrificing quality for speed. Cigniti speaker, I want to kick it back over to you. Jermaine has been talking a lot about the people aspect of DevOps and running teams. You’ve seen a lot of changes in your over 20-year career in the QA space. Let’s take a little bit of a pivot, but you know, it is been a common theme on the show to talk at least briefly about AI here and there. Can you talk to us a little bit about some of the changes you’re seeing right now and those that you see coming with the role of AI in quality assurance? 

Cigniti speaker: Absolutely. Yes. The AI, that means the artificial intelligence. Yes. I know we are seeing that as a shift pattern towards embracing that AI into the quality engineering in two aspects. So one of them is from a pure play, scripting aspect of it, where the automation tools company are bringing AI into their tools pack by doing script-less testing or code-less testing by having the automation tools, learn the code, learn the entire concept of it, learn the business process, and come up with scripts automatically through the AI concept and also go through the data and find out how the end user data are and coming up at the data combination and included as part of the AI model itself, along with the automation tools. So that’s on the scripting side of it. So that’s going to happen continuously across all the tools spectrum, be it open source tools or commercial tools.

There are several companies that have come today and with the concept of AI in automation, AI in the testing space. So that’s something is going to happen from the technology side of the AI with respect to QA. The other side is to bring in the AI as part of the testing in the domain itself. So let’s say if I take one of the domains – airline industry or hotel industry. The AI is going to play a vital role in understanding the entire test process and coming up with concept of how to automate through the AI model, with respect to each of those business domains, that’s one area of it. And also come up with some prediction through the AI and then see how you can optimize your entire test process by introducing the AI technologies. So the domain side, the business process side also, it’s going to take you all in a big way.

So we are seeing that in technology with respect to automation tools, we are seeing this shift in the domain and the business process and introducing the AI techniques in efficiently automating or writing the test processes for you to execute end-to-end. That’s another area that we are seeing. In two years from now, the entire AI concept will get into really a high matured state. When that happens, you’re going to see a lot of efficiency in the test life cycle. You will see a lot of release to market at a higher value, and you will start to see lower defect in production as well. So those are some of the outcomes that you would start to see in the next two years with respect to this AI journey and the QA space. 

Logan: I love the way you’ve taken that big concept and breaking it down to some very specific applications for folks to start thinking about Cigniti speaker, as well as, just looking logically at some of the impacts that are going to start happening here in the near future. Jermaine, you know, I know that in previous content collaborations and other talks that you do, you’ve shared that AI is really the next exponential technology trends. So, I want to give you a chance to kind of piggyback off of what Cigniti speaker is talking about here when it comes to the role of AI.

Jermaine: Yeah. So when I think about kind of what I’ll focus on was kind of the business benefits of AI and as Cigniti speaker alluded to, and kind of spoke to. From my perspective, AI drives more predictable outcomes with data, because then when you think about artificial intelligence, you think about the amount of data that you need to process. AI allows you to do that in a smarter way. AI also allows you to lose use machines versus people to analyze complex data sets and information. So if I think about the capabilities I have to analyze petabytes of data and really taking that data, analyze it, and turning into insights is really the business benefit of AI. And then I alluded to this in my previous point, but I’ll say it more directly here. Your use with AI, you’re able to use information and you are you able to turn it into knowledge. So, data is no good without insights and taking that insight and turn it into knowledge. And with artificial intelligence, AI, that’s the premise of it. That’s what allows you to do and allows you to work smarter. And ultimately from there, you’re able to integrate these. The next step would be to integrate these into business processes so that you’re making smarter decisions for your business.

Logan: I love that. I really appreciate that perspective, Jermaine. As we round out the conversation, gentlemen, I’d love to get both of you to weigh in on this last question. And, you know, I think some of the most applicable things for listeners are what they can either look at doing or what metrics that they can hold themselves accountable to as an organization. So, Jermaine, I’ll start with you first and then Cigniti speaker, I’d love to have you tack on any thoughts here as well. Jermaine, could you speak to some of the key metrics that enterprises should be evaluating for their own DevOps maturity? If you’ve got a short list of things that you think about there, I’d love to hear those and then from you as well, Cigniti speaker

Jermaine: Yeah, sure. That’s a great question. Because when you think about DevOps, you want to be able to measure, right. And when you say metrics, I have my mind automatically going to KPIs, key performance indicators. So, from my experience, you have to have a key set of defined KPIs. And from my experience that consists of a couple of them. One is deployment frequency. So how able, how fast, and how frequent am I able to deploy to production, to lay binaries to production services and servers, and what’s the frequency of that? Another key one in a DevOps from a metrics perspective is lead time. So, lead time really measures the amount of time that occurs between starting a work item until it’s deployed. So that really allows you to measure the time of value from the time that you’ve logged that user story using your scrum or Kanban methodologies. And from the time that it’s logged to the time it’s deployed. Another key KPI and metric in this space is change failure rate. So,  you want to deploy frequently, but you don’t want to deploy for frequently if you’re failing. You want to be able to measure your change failure rate. From a time that I’ve deployed, what’s my failure rate with that because that’s going to give you that quick feedback loop in order to change to make your deployments more seamless. And the last thing I would say is meantime to recovery from the time that you do deploy and you do have a failure, this metric really helps you track. How long does it take to recover from failures? And that’s important because not all deployments, not all the solutions deployment will be successful. So, measuring meantime recovery will allow you to measure how long it took for you to recover so that you can get faster and faster and faster, and ultimately really delivering value to the business at a fast rate with higher quality with the least amount of thought as possible.

Cigniti speaker: Yep, absolutely. To add onto that, some of the metrics, the key metrics that Jermaine had mentioned, he pretty much covered most of the metrics. So, one, if I may want to add, which is the total cost of quality in the DevOps world. So, you want to see how you’re improving it, right? And like the way Jermaine mentioned meantime to recover. How quickly I fixed it, how quickly I tested it and released it to production, and that have your quality as the metrics, actually. The total cost of quality is going to be the key metrics in addition to what Jermaine outlined some of the metrics that he had mentioned. 

Logan:  I love that, Cigniti speaker. Thank you for that addition. Just to recap those for listeners, because I love thee sort of actionable list, and in case you weren’t in a spot to be able to take notes and you don’t want to hit the back button too many times, those metrics were deployment frequency, lead time, change failure rate, meantime to recovery, and total cost of quality. Am I getting those all, all five of those right there, Cigniti speaker?

Cigniti speaker: Absolutely. Yes. Yeah. Those are the top metrics in the DevOps where you’re spot on. 

Logan: Awesome. All right. Well gentlemen, this has been a fantastic conversation. I love being able to pick your brains. So many years of experience between the two of you. If anyone listening to this would like to take next steps, ask any follow up questions of either one of you on what you shared today, I’d love to give them the easiest ways to reach out or stay connected with you online.

Jermaine: Yeah, so people can connect with me directly on LinkedIn.  So if you just searched Jermaine Oldham, I’m probably, I think I’m the only Jermaine on there. I’d be open to connecting. I’m a lion on LinkedIn, constantly. I’m sharing content and engaging with that platform. And I would be open to connecting and having additional conversations.

Logan: I love it. Thank you so much for making it easy for folks, Jermaine. And Cigniti speaker, how about you, if folks are just now listening to this and haven’t heard from you in the past and they want to reach out after hearing this. 

Cigniti speaker: Absolutely. You know, the same LinkedIn. I am a competitor to Jermaine in the LinkedIn. We always stay live and I’ll be happy to share any feedback or any comments or any help that is required through the platform.  

Logan: Absolutely. So as always folks, thank you so much for listening. Some next steps there, if you want to reach out and ask some follow up questions of either Jermaine or Cigniti speaker. If you’re not yet subscribed, hit that subscribe button. So, you never miss out on future episodes here of QA talks. You can also go the resources section of cigniti.com to find all the podcast episodes there and be able to search some other content here within the QATalks podcast. Gentlemen, thank you so much for joining me on the show today. It’s a pleasure. 

Jermaine: It’s a pleasure being here as well. Thank you, Logan. Thank you, Cigniti speaker. 

Cigniti speaker: Thank you, Jermaine. And thank you Logan. 

Logan: Absolutely. If you’re enjoying the show, leave a rating and review as always. Thank you so much for listening. 

Quality assurance is vital to the success of an organization’s digital transformation. Lack of control can quickly derail a company’s technological presence, costing thousands. At Cigniti, our resolution is to build a better world with better quality software. Renowned for the global quality thought leadership in the industry, we draw expertise from over a decade of test engineering experience across verticals. To learn how we do it, visit cigniti.com.   

You have been listening to QA talks. To ensure that you never miss ay episode, subscribe to the show in your favorite podcast player. Thank you so much for listening, until next time.