New Year’s Resolutions For Addressing Agile Pitfalls and Adopting AI Innovations

Kick off the new year with actionable insights on overcoming Agile challenges and embracing AI-driven innovations in software testing! In this episode of Testing 1-2-3, brought to you by Parasoft, Arthur Hicken (the Code Curmudgeon) and Joanna Schloss (Chief Marketing Officer at Parasoft) dive into practical New Year’s resolutions for software teams.

From improving collaboration between developers and testers to tackling flaky test automation and mastering test data management, Arthur and Joanna share strategies to help your team thrive in Agile environments. They also explore the growing role of AI in software testing and why continuous learning is essential to stay ahead in today’s fast-evolving tech landscape.

Whether you’re a seasoned Agile practitioner or just starting your journey, this episode is packed with tips to help you deliver higher-quality software in 2025 and beyond. Tune in and make this year your most efficient and innovative yet!

Testing 1-2-3 is your go-to podcast for all things software testing, performance, and security—brought to you by the experts at Parasoft. Don’t miss it!

Transcript

0:00

Foreign. This is Parasoft. Testing 1, 2, 3. Let's get started. Hello, everyone. Welcome back to testing 123, brought to you by Parasoft. I'm Arthur Hicken, also known as the code Curmudgeon, and with me is Joanna Schloss from Parasoft. Also. Hello, Joanna. Hey, Arthur. How's it going? All right. Happy Friday. Okay, weather after all the craziness going on in California. Yeah, that's right. Parasoft is located in Pasadena, so it's been quite nutty for the last couple days or a couple weeks, practically. So if you're new, we welcome you to this podcast. If you're an old subscriber coming back, we're glad to have you here again. We talk about all things software testing its performance, its security, its tools. It's AI. It's just about anything in software development and anywhere from banking to the stuff that's inside your car. So today, I was thinking the other day, because it's the first of the year, and so people are trying to force you to think about your New Year's resolutions. And I was like, man, the important resolutions. Although it's all eat right and exercise and all that, like, professionally, what can we do to be in a better place a year from now? To not have the same stinking resolution every year. Right. And to, like, make good on some of those things that we really are. Not so aspirational, but just really practical. Right. So instead of us aspiring to drive an entire sea change of culture and, you know, new technology, adoption, and I agree with you, it's the first month of the year, and I've been thinking about all the things that I wish to be able to achieve in the next 11 months and then be able to look back with you next year and say, hey, we got that done. That's so awesome. You mean I can't go from this to bodybuilder in one year? You know what? I don't want to comment on that, Arthur. But probably not. Not safely, at least. One of the things interesting, because people try to do this, like, they drop these things February 2nd, right. Or January 2nd, right. Like, boom. And no one's ready for it. And Everybody quits by January 5th. Like, that's an officially quitter day. Right. Or something like that. There's a name for the fifth is past us. It's now safe to have a resolution. You can't. If you want to quit it on the next fifth, I'm okay with it. Yep. Because that technically is a month in so you gave it, you know, a 30 day try. Oh, I don't mean February 5th, I mean next January 5th. January 5th is Quitters Day. You missed it already. You're committed. What we're talking about, you're committed. Well, so I think the first thing we talked about was this idea of agile development pitfalls. I know you had some thoughts and I have some thoughts. What are we going to do next year that will help us realize or maybe start to execute against these agile goals? Yeah. Agile is really interesting because it used to just be this wonky little weird methodology that some software people used and now it's pervasive. And I don't just mean that all software companies use. People use it for all kinds of things. The idea of small components iteration is. It's an ancient one. Right. It's an old one and it works really, really well. So there are certainly things in Agile that can make life work much better, that can help us be more productive. And there are things in agile where they're more philosophical. Yes. And aspirational. And sometimes you need to think about is this, is this really going to help me get where I'm going? And that's important. And a lot of things have become sort of synonymous with agile. Right. So is DevOps agile or agile and DevOps two things or is one part of the other? Which one's the superset? Which one's the subset? The fail fast forward is another of. Yeah, I was about to say that the growth mindset that so many people aspire to have is that fail fail fast, fail forward concept is part of Agile, which it really isn't, but it is a mechanism that can help you be more bold. Right. It's all about being bold. And I think like you said, it's precisely the opposite. Failing fast is not part of Agile. Agile is required if you want to do fail fast. Yes, exactly. Right. Because there's no way you can fail fast without iterative. Right. And the funny thing is people lose track of that growth mindset, which is the idea that you are fostering experimentation. And agile is really just that. As a chemical engineer, we've always used agile. You don't just go out and build an entire stripping column at 100ft tall without actually trying all the little steps beforehand to make sure that when you add it together, it's going to work. This is why I find it so interesting that people are like, oh, it's, it's just a process. You know, you just try these things. And I'm like, no, it's a process, it's a mindset and it's, it's a cultural change. Right. But that doesn't mean you have to do it all at once. Right. You can employ and deploy agile in an agile fashion, which I've seen successful organizations do. Right. Instead of trying to do it all at once, they do it in small pieces, which is for me. I'm the marketing person here at Parasoft, and one of my New Year's resolutions is to help my team experiment more so they can become more of an agile marketing team. And I, I'm giving them the license to think outside the box, think in small segments, not big segments. So yeah, I think like with failing fast, there are areas where you absolutely want to do it, you know, in marketing for sure. Right. Like you got to jump fast if you're in a competitive market or you have a brand new idea or you're reacting to something. We'll talk about security in a minute. Where, where unfortunately right now, much of the market reacts to security incidents rather than prepares for them. But if you're in other industries, failing fast is maybe, you know, very, very, very bad. Like, if you're doing autonomous driving, then failing fast is not really the way to do things. Right, Right. We had the greatest example this week and okay, everybody knows I'm a rocket nerd, right? So. Oh, you mean the involuntary disassembly? Rapid unscheduled dis. Yes, rapid unscheduled disassembly. And I don't want to pick winners between companies, but we do see very different methodologies. We have SpaceX, who's been perceived as the leader because of their agile methodology and partly because of their social media presence, constantly showing us what they're doing. It's kind of cool, right? As a rocket fan, you get to see the pieces of the rocket, it gets assembled. Great marketing, right? Absolutely. And, and the, the message until 48 hours ago was always that they were going to be the first ones to put something to orbit. That, that stodgy old Blue Origin. And I don't know how you call a company that's building their first rocket stodgy, but stodgy old blue Origin was doing things the old fashioned way. Now, I don't know how much iterative they do internally, but it was like get everything perfect, stand it up. Arguably that is a slow path, but it might be sometimes still faster. It might be that you didn't see all the steps, but they delivered a payload successfully this week. Right. And SpaceX burned up a payload this week? Yes. They had a rapid unscheduled disassembly. Yes. So while up until a week ago, everyone thought SpaceX was ahead. So the lesson isn't don't do agile. It's not that at all. It's do agile where it makes sense and don't do it where it doesn't make sense. And that's part of the New Year's resolution. Look at your agile where should you be doing more of it? Right. Should you be a little more careful about what you're doing in terms of failing fast? Maybe you want to fail slow in certain cases. Right. And for me, like I wanted to share, the message of our New Year's resolution is be bold, try small things, experiment. And the personal message that I have for all of our listeners is some of our greatest learnings isn't from the success that you derive from trying something. It's from all those, you know, unsuccessful things. My favorite quote is from Thomas Edison, who said, who, upon asked, how do you feel about the thousands of failed light bulb attempts? His response was, I now know thousands of ways of how not to build a light bulb. And those are really insightful. So be bold with your agile adoption and hopefully you'll learn something and make you, your team and your whole experience better and more fun. Well, onto our next resolution, which both Arthur and I are very keen advocates of AI and keen watchers of how AI is unfolding in our landscape. We're both technical folks, and for me, AI is just the next version of math. Right? That's like my simplified view of AI, so. But I wanted to give Arthur a chance to talk a little bit about how AI has become use. One of our goals is to see AI become useful. But he has a great quote, so I'm going to let him share with you his thoughts. Yeah, it is fascinating to see how far AI has come, because for decades we've been watching tools where you could take a random person and get them to produce an application, and we watch them fail miserably because they just required specialized training and knowledge and education. And even then they did a poor job. And now we're not there yet, where you can just ask the computer to do any arbitrary thing and it'll create the code and the infrastructure and off it'll go. But we are at a place where, in the hands of actually trained people, AI is super, super useful, super effective. But we're also at the point where AI in the hands of the uninitiated is extremely deadly. And what Joanne was referring to. There's an old quote, and I'm pretty sure it was Bill Gates in the early 90s about computers should be as easy to use as chainsaws, but much safer. And I feel like that's the same thing with AI and in my discussions with people, I'm finding that people who have a lot of experience doing what they're doing, whether it's coding or testing or security or performance, they become way more effective. Think that you can grab somebody off the street and say, hey, guess what, you're now a tester. We're going to turn you loose. Here's a chatbot, right? Go create tests that they're going to do the right thing and do it constantly and consistently in a way that is meaningful. We'll get into that more one day when we talk about testing deeper. It is exactly like a chainsaw right now. Super powerful, super useful. And you're going to cut your foot off. Yep, absolutely. I think. And whenever Arthur says that, I have that image of a kindergartner in class running with scissors, right? Like they are blithely brandishing the scissors because they know it's useful, but they're actually endangering themselves and everyone around them. But Arthur and I will have more segments on AI as Parasoft has been an early innovator in the AI space. So stay tuned, tune in next time or when we start pushing these AI opinion pieces at you. In our next set of podcasts, you'll learn more about how to prevent yourself from hurting others with the scissors and with the chainsaws. But the idea of safety and security is very much top of mind for both of us. And our last New year's resolution is focused on cybersecurity. For me, the resolution really focuses on paying attention to cybersecurity. 2024 as a small retrospective had a lot of different vulnerabilities that were exposed that actually endangered people. In fact, did an entire segment on how CrowdStrike, albeit was never intended to be a piece of safety critical software, but it actually potentially killed people that we don't even know about. And we without being super morbid, we know the use cases of hospitals being impacted, 911 calling centers being impacted. And it doesn't, it's not a small leap, it's a very tiny leap to go from those impacted systems to people being hurt and people being injured. So from my perspective, this, our new year's resolution for being responsible technology owners is to really start to look at how software, which is pervasive needs to have an angle towards security in every aspect because you never how your software might impact others. But Arthur also had thoughts. So Arthur, what are your New Year's resolution look like when it comes to cyber security? I was just going to add on to yours. Maybe it's time we just started building software. Right. Like I didn't have this as one of my resolutions. Maybe the software should just be built. Right. Because like you mentioned with CrowdStrike, people didn't think about the fact that CrowdStrike ended up being deployed in a first responder environment and therefore it was unacceptable to be used in that kind of an environment. Right. Even though it's supposed to make their lives better. So yeah, maybe that's what I. And I'll circle back to that in a second. But every year people ask me for, you know, predictions for the year. Yep. And I have my, like my first prediction is always this year there will be a major cyber security incident and it affect a bunch of people and it will cost a lot of money and it will be based on software and bad practices and be completely avoidable. And by the end of the year, year, nothing will have changed. That's my prediction. Now when I was thinking from a New Year's resolution perspective, if I could, my resolution would be that's not going to happen anymore. I can't do that. It's not going to happen to me. And I would say that cybersecurity is the exercise of all software resolutions. Right. I'm going to go to the gym this year. I'm going to work out. This is constant. So if you think it's time, do it right now. Like make a commitment that you're going to do a better job at it. And because that's too vague, there's two or three things that you can do. Right. One is make sure that you're checking your supply chain. It's absolutely critical. It's not the software you wrote, but you stuck it inside what you're doing. And, and you're responsible for the problems it causes. Right. And, and another is start really effectively using static analysis. Don't rely just on pen testing. Start catching the stuff earlier. Earlier and, and third, and perhaps most important, secure by design. Like I said to your thing, we have to start building software that is more reliable, more safe and more secure. And the way to get there isn't testing, it's to build it better. And, and a bunch of people right now are going, what the heck is the difference? We're going to cover that very soon. In the near future. Because what we don't have time to talk about today is that a, a new directive, an executive order from the White House in the United States just dropped, and the large part of it is cybersecurity. And of course, a chunk of that bunch of it's weird IT stuff. Right? Right, guys? Right. But a bunch of it is very, very semi specific, but at least directed toward trying to improve at least visibility and transparency on best practices in software. And that's a good start. Right? We're not going to get there in one big monolithic leap. We're going to get there iteratively. Right. Circle back on you. Right. Small chunks, experimenting and being responsible and be bold while you're doing all that. Well, I think that brings us to the close of our podcast today. Our New Year's resolutions are out there and I'm keen on seeing how we do in January 5, in 2025. Thanks, Arthur, for chatting with me today and we'll see you guys back here next time. So long, everyone.