"If that site was to go down, then that's your money value on that, because you're not selling products and if the site is down for, you know, a day or a couple of hours, you've lost X amount of pounds or dollars or whatever, you know, because that is down. If you'd have invested all that time up front into writing things like tests, then that would have stopped that happening."

Intro:
Welcome to the Agile Digital Transformation Podcast, where we explore different aspects of digital transformation and digital experience with your host, Tim Butara, Content and Community Manager at Agiledrop.

Tim Butara: Hello everyone. Thanks for tuning in. I'm joined today by Oliver Davies, software developer and consultant with 16 years of professional Drupal development experience, including working on drupal.org for the Drupal Association and being an Acquia Triple Certified Drupal Expert. In today's episode, we'll discuss making the business case for test driven software development and automated software testing.

And Oliver, welcome to the show. It's great having you here. And it's great to discuss this with you. Before we jump into our conversation, would you like to add anything to the intro? 

Oliver Davies: Hi, no, not at the moment. I was really excited to be on a podcast again. It's been a little while since I did a podcast last, but this is one of my favorite topics to speak about, automated testing and TDD. So I'm interested to give you a bit more of a business focus rather than a technical focus for this podcast. 

Tim Butara: Yeah, I think that the business side will be very interesting for a lot of our listeners, especially like with the rise in the need for software development because of, you know, the prevalence of digital experiences and kind of this acceleration in digital transformation. So definitely an important topic to discuss with you, Oliver. And so the first thing that we need to clear up is what is test-driven development and what is automated testing? 

Oliver Davies: Okay, so they're not the same thing, first of all, they do tend to get used interchangeably, maybe more so for the developer audience or by developers who tend to consider them to be the same thing, but they're quite different. So what usually I find happens with testing is, with my developer hat on, we'll get requirements for a feature or a bug fix and we'd like go in, write the code, make it work, we might test it by testing in a browser by reloading a page, resubmitting a form, doing these tasks manually, or maybe running like a drush command or some sort of console command to make the thing work.

Once we're happy that it's working, we'll then converge the code or submit it for a review and it will get tested manually usually by somebody either by another developer or if you've got a QA team or maybe by the client themselves, but it's turned out to manual testing step and then they'll say yes, it's good. Hopefully they'll say yes, it's good to go, and then it goes into production. 

The problem with that Is you only test that feature at that time. So when you move on to the next feature, you don't test the old feature again And when you're maybe 6 months or 12 months into a project you don't test the same features you wrote right at the beginning again. You're only ever testing the most recent changes 

So that's fundamentally the problem with manual testing, whereas with automated testing, we're writing code that tests our code. It's probably the best way of putting it. So developers, we usually do this sort of anyway, by doing like var dumps or console logs to sort of output the text onto a page or do those sort of comparisons. But we can use actual testing frameworks in languages like PHP and Drupal and also things like JavaScript to do that comparison for us, and we can run them whenever we want. So as long as we've got, once we've built up a test suite, maybe we run the whole test suite before you do any deployments to live. So you get that repeatability that you wouldn't get with normal manual testing. 

Test driven development is a bit different. So it's the action of running, writing the test before you write any code. So you're writing, which is going to be a bit odd, certainly, to begin with, but yeah, just, you don't need to do TDD to do testing. It's quite common for people to sort of write the code first and then maybe write the tests afterwards. There's pros and cons to that. It's how I started. I was working at an agency and I was writing some code for a feature during the day whilst I was on sort of "company time". And then I was writing tests for the code in the evening on my own time because I was learning. I didn't want to affect estimates or anything. 

So, but then I found a bug in something I'd written during the day. And I was able to fix it very quickly so it didn't need to go for review and submit it to QA and then it gets up. I could fix it then and not have to go through the whole process again. So I was hooked on it at that point.

So I can't really work without testing these notes, but that's the main advantage is that repeatability that you can run the whole test suite at any time and check things still work as you expect. 

Tim Butara: So is this something that engineers and developers can point to when they try to convince leadership or like higher ups or just non-developers at a business that automated testing and TDD is something that's really valuable to the business and will have a positive long term impact or ROI.

Oliver Davies: Definitely, and I think especially for longer projects, you know that you're going to want that repeatability and you're going to want things to work and you're not breaking feature A by writing feature B or breaking A and B by writing X, you know, if it's a longer project. 

So maybe you've got a, just a small little microsite with three pages, then you can do that through some Drupal's admin UI. And so then you're not going to get much benefit, but the bigger, more complex projects, where you've got lots of custom modules and things it's definitely going to be beneficial. 

It takes time to get good at it. And it takes time for you to write them to begin with, but the time saved overall is a big, because you're not spending that time bug fixing, you're not spending that time redoing tickets from three sprints ago. You're not upsetting your future sprint planning by having to redo tickets again that you did previously and you're getting a better sort of reputation with a client because you're not shipping bugs to production They're getting a better product and better application at the end of the day.

Tim Butara: This is definitely something that business users at a company or more business people at a company should also care deeply about, it's not just something that, you know, we leave this to the developers and it's kind of in their domain. 

Oliver Davies: I think so. I think it's interesting sort of lines to draw. So I've worked on teams, both for some agencies and in house teams, and developers are sort of waiting to be told that they can do tests or the users have asked that they can do tests. And the other side is that as a developer, I'm sort of expected to make sure my things work anyway, whether that's automated way or a manual way, company or the management just want to know that things are working, right? So it's just, it's more to me how I would validate it in that way. Like if you take your car to a garage, you'd expect them to road test it and make sure it still works. 

And the other one I've heard people say is you wouldn't expect the surgeon to ask permission to wash their hands, you know, it's just part of the job before they do the thing. So it's not a line item as such, you don't need to give a separate estimate for testing of TDD. I would just include it as part of the task, personally, but it's definitely something to be aware of. And yeah, by doing it then, you know, management or clients should see better software with fewer bugs at the end of it.

I've definitely worked on projects we've started with tests and then we've sort of stopped for some reason, and then the number of bugs went up. After a while, we said, okay, we'll start writing tests again. So I've seen it sort of happening both ways, but it's not something that's done. everywhere and it's as much as you can go to conferences and see people speaking and saying, everybody's writing tests, right, wink? 

You know, it's common in some communities and more coming with some languages, but it's definitely not done by every developer on every project where you should be more. I'm saying this from a company perspective, but also it's an open-source perspective as well. 

So I maintain quite a few Drupal modules. The most popular one is probably Override Node Options module. I think it's just checked it in this one about 38,000 sites at the moment. So I want to make sure that I don't break 38,000 websites when I do when I do an update. So, yeah, it's just again me knowing that things work As expected and I guess in that case the community is the customer, in that case I'm not shipping bugs to everybody in there and their clients as well. It's about confidence in there. Are we confident that the code does what we think it does, and testing is the way of doing that. 

Tim Butara: So does automated testing make it longer to deliver a project or is the upfront investment then kind of balanced out with the time saved by not having to do that many bug fixes and stuff like that?

Oliver Davies: Yeah, it can produce a type of an investment, and it definitely is a time investment, particularly if you're learning, you know, you're going to need to learn how to write tests, maybe to begin with. Some people have never written tests before. 

And I did a workshop for DrupalCamp London just before COVID, and that was very much, like, start people writing tests because they hadn't written them before. And it was just going to, like, testing Drupal Core functionality, actually, just going there to begin with, like, go to the admin page, as an anonymous user, you should get a 403 response. So "It's forbidden" rather than "The page exists". And you can see people, the switch starting to flick in their brain as they were starting to write these tests and seeing what they did.

So it's definitely an investment. That said, once you get into the hang of it and you know what you're testing, and you get good at it, it will probably save time because you're not always writing a bit of code. Writing a bit of code, stopping, thinking about the next bit, stopping, writing some more code. Like, you write the test and you are deferring the thinking to the test almost 'cause you, you've written the test and then you're just following what the errors say and what the... especially if you're doing TDD. So, if you test first, you start with a test that's failing. So I want to go to this page and say we should get this response, so this page should exist, and we should see this bit of text on it.

So I don't need, now I've written the test, it tells me there's an error, so the response code might be wrong. So we're expecting a 200 OK response code, so the page exists, but we're getting a 404, the page doesn't exist. So it tells me what to do next. And I go, oh, I need to change the code, so I'll make the page, or it's missing that bit of text. So it's, the tests are telling me what to do, I can go through these things very quickly once you get used to that process.

I think the other part, I think I mentioned it and you just mentioned it as well, is that once you've got those tests in place, then you're not going to get that regression of features. You're not going to get tickets back from QA. You're not going to get tickets back from a client that says this is broken.

Or if you do, then it's a really good thing to have, to say things should still be working. I had a situation a couple of years ago on a project. It was, when you think back, it was a while ago, there was a system they were putting job adverts into. It was a third party system that sent the data to the website and they wanted these jobs to display on the website, even though they were a different system.

So we built a pay, like an end point they could go to slash something. We gave them a URL to send this data to when they made a new job. And then we said, okay, well, if we get the data in this format and with these values, it will make a job on the page and the job to be published. And there were other things about, it's only valid for X number of days, and it would unpublish after a certain number of days and things as well.

But at some point, we did the test for this, they were all passing, the feature was deployed. Probably a few months later they came back and said, it's broken. And we said, well, we haven't changed it and it's still fine. And we, but we weren't completely sure that we hadn't broken it, but we had tests so we could run the tests for that module and go, they're still passing.

So as long as we're getting the data in the format we expect, it should work because the tests tell us that this should work. And what had happened is the first system they would put the job ad in to do had broken something on their side. So they weren't sending us data in the right format anymore. So it was a really nice clear line just to sort of say, if it's this side of the line, it's us, if it's that side of the line, it's this person. So in that case, it really shortened our debugging time because we were able to just give them the thing and say this is how it should work And you need to send us this and they said, oh, actually yeah, we've broken that. 

So yeah, there might be this perception that it takes longer to do tests, to do a project with tests or TDD, which is probably true in some cases, especially... anything things tend to learn I guess to begin with, testing or anything else, but the advantage is over the long term, especially, like, so I work on an in house team, so I don't, we don't get to the end of a project, hand it over to a client and then move on to the next thing. We're potentially supporting this project for years still to come, so for us it's very valuable to make sure that we know things are still working over the long term and not just over the short term. 

Tim Butara: Well, what about in the context of working on projects for a client? How do you communicate with them? How do you get approval from them to spend a certain amount of time and probably a certain amount of the budget writing tests? Do they even need to know the complete workflow? What's your take on this? 

Oliver Davies: It can be a tricky one because I've only touched the pricing side of things, but sometimes it tends to be an issue where a lot of agencies have done like billing hourly or daily, so you need to be careful about what time you're spending and what, how much you're spending on where and you've got to give estimates for everything. 

So as soon as you say, well, this ticket will take me a day to do but it'll take me another two days to write the tests, what always then happens is people say, well, don't write the test then and don't... and save the time. It turns out it happens a lot. 

Yeah, this is what I said earlier on. It's not a line item that you need to add or test. So if somebody asked me for an estimate to do a task, they would just get one estimate, which includes the testing to do it. I wouldn't break it down for them in that way. Someone actually said, I saw post one of my emails and then somebody had sent this to a client and the client asked them not to do it. And they were playing with the idea of charging them more to not write the test, which I thought was an interesting idea because then it's like, when does the risk go? So how much more would I want to get paid knowing I'm going to have to fix all these bugs and everything else. 

So it's definitely a good thing for management or for like an agency executive or a client to know that they're there. But yeah, it's, again, like you say, you wouldn't, if I took my car to a garage, you'd expect them to road test it and you'd expect them to know it was there and all working when they give it back, how they do that, you maybe don't know.

And there are people that sort of said, you aren't a "real developer" if you don't write tests, or "professional developer", if you don't write tests. So it's not that black and white, definitely, but it's definitely, once you start and you've got that sort of safety net and that confidence that things work because you've got the tests there and you can go in and you can do a Drupal 8 to 9 or an 8 to 10 or 9 to 10 upgrade, or you can do a big refactor of that giant control that you've got in that big bit of coding or... 

You know, people won't ever go, once you've written that feature, there's always things like, oh, we'll go back and we'll make that better. And maybe the code isn't brilliant or we need to go and amend it and add some more features to it later on. People are scared of doing that because they worry about breaking it. So knowing you've got tests that will tell you whether you've broken something are invaluable. So it's very hard to get out of once you've started getting used to this way of working. 

But yeah, it's definitely a conversation to have with sort of management, but I try to not let them detect me, whether I could or couldn't, that's sort of part of my role and how I would approach it personally, but that could be, yeah, it could be a tricky situation if I don't do that because we need the time or something, then it's maybe some, you know, maybe you need to budget more or maybe you need to estimate higher or something. There's probably some other issue for that. 

Similarly, once you deliver a project or you see a project go through with, with tests and fewer bugs and delivering things faster, then the agency wouldn't want to do it any other way either or the company wouldn't want to do it any other way either. 

Tim Butara: And I guess that also, like, with, you know, digital products and websites and digital applications, there's maybe a higher tendency to go, yeah, just, you know, don't spend time writing tests and don't spend time on tests if it takes too long. 

But then if you go to like developing something like, I don't know, a health care application or an airplane landing system, I imagine that in that case, you can't really afford to go, oh, yeah, just don't spend time writing safety tests. I mean, if you do that, then, you know, in the latter case, people can literally die because the plane crashes, the system is not developed properly. So, yeah.

Oliver Davies: This is true. Yeah, I mean, I guess, yeah, if someone was built, like, say, if you were working on a commerce application, for example, I've done quite a lot of Drupal commerce applications, if that site was to go down, then that's your money value on that because you're not selling products and if the site is down for, you know, a day or a couple of hours and you've lost X amount of pounds or dollars or whatever, you know, because that is down. If you'd have invested all that time up front into writing things like tests, then that would have would have stopped that problem. 

So when you can sort of tie it to something that's actual, like, actual a number, then that's a bit easier. But yeah, for companies who, or clients who maybe it's not going to be a transactional website, but if your website is down, then, you know, for us, my day job is working for a transport company for Transport for Wales. 

So if the website is down, people can't buy tickets from us, so they'll go somewhere else and buy the tickets instead. So they're not making the transaction on our site because ours is sort of a marketing site, but yeah, they'll just go elsewhere. So you're still losing customers and revenue from not having it there or if you're going and you know, something isn't working potentially again, that's still going to be a blocker.

I think like I said earlier, I was able to fix something that I found very quickly because I had a test that was failing. Every step takes longer and costs more, is more expensive to fix. So if I submit it for a pull request or for a code review, that takes longer to fix because I've also got to include somebody else in the process as well, stop what I was doing, go back to that and go through that again. 

Same thing if you go through like an internal QA testing scenario and then to the client and then once it's on production, it'll take longer and have the most impact. And also who knows what else it's doing. Maybe it's generating vouchers for people with the wrong amount, or you're going to have to do some sort of remedial work then as well to undo the changes of the thing and clean up the thing that the bug has maybe done. 

So, yeah, it's that investment in time again, maybe a small investment to begin with compared to potentially longer term. If it's, again, a site that's going to be there for three months and it's for a little marketing campaign that's different to a company or a client whose site is, or the company's relying on this website working for maybe three, five, ten years, especially with the way the Drupal things work now, the releases work.

So like 8 to 9 to 10 to 11, like, we're constantly upgrading some applications and code bases now across these major versions and add modules. The Override Node Options module is on the 8.x2.x branch, which was the original Drupal 8 branch, but now it's Drupal 9 and 10 compatible, even though it's 8. So yeah, if it's a long term, but again, you want that repeatability. You want that comfort to know that it's working over a longer period of time. 

Tim Butara: So, are there any cases, based on all this, are there any cases where automated testing or TDD isn't the optimal approach? If so, why and what are those cases and what different approach would be more appropriate in those situations?

Oliver Davies: Let's see, I'm definitely thinking about this more as a, like, if I'm doing a project and there's a lot of custom code, a lot of custom functionality being built into it. I want to make sure that works as I would expect and then to catch any regressions or any failures in that code. 

If we're not doing that, then yeah, maybe, if you're building a Drupal site and you're a sort of Drupal site builder, you sort of fit in that persona, and you're just building maybe a small site, building a site by, you know, installing extra modules and building content types in the UI, then you're not sort going to write those types of tests 'cause you're not writing custom functionality.

If you're adding a module, like a WebForm, for example, to add that, that will come with its own tests. WebForm does, but not all of them do. But that you can assume is already tested elsewhere. So in that scenario, you could do still, you still do something like test. You go to this page and it exists, there's, there's tools and there's SaaS products that do that, but you wouldn't be writing them as part of the development process, cause you're not doing a development process in the same sort of way. You don't start from the writing code to add to functionality. 

If you were doing maybe a, let's say, a small marketing website or something that's only going to be live for three months or something, again, then it comes down to is the time investment worth it for a short term benefit for a project?

If you're going to be working on a project for 12 months or more, a longer term project that is definitely going to be worth it. My workload, any development work that I do as a consultant or thing, I do all fixed price work and I do a bug free guarantee on everything. So for me, it's like, if someone comes back to me with a bug, then I'll have to go and fix it anyway.

So it's in my interest to write the tests anyway, but if it was going to be a short term, then I would be like, then I'd think maybe about it. It really depends on the complexity of what we're building. But yeah, anything you're going to need to work on over time, potentially, you know, change, maybe add more features to your time, then it's, and maintain over time, is definitely going to sort of need, or I would suggest would need testing. 

So there's anything else? Yeah, if you're doing the clicking around, you're not going to need it. Cause you say you're not writing, writing code in that way. Modules would usually, or definitely can come with their own tests included as part of it. That's probably the best thing I can think of really.

Things where you would, we wouldn't want to use it. Yeah, they might say, we just don't need, you just don't need or want that confidence for some reason, you know, I said timeline is the one that comes to mind and maybe it's a short term project, but that's the only one I can... so, so maybe you are on a really, really, really tight deadline. It's kind of, I think it's got to be done this week. Cause maybe you do want to put it in. Yeah. That's, that's a discussion on a per situation basis, I suppose. 

Tim Butara: Well, but those are some great examples, right? You know, if we established earlier that, yes, automated testing will add a certain amount of time upfront that needs to be, you know, that needs to be invested into the development, but then that will get kind of balanced out with long term time saved. But if you have a website, a marketing website, that's only live for three months, and then you, you prolong the development of that by maybe one month because you want to do everything by the book and do it properly with automated testing and TDD. Then it's very logical to me how that might not make sense.

And also tying back to our point about kind of the criticality of the code that you're testing. So probably a marketing one pager is less business critical than, you know, an airplane landing system. So also from that perspective, you probably don't need to invest that much time into testing, especially if it's shorter lived.

Oliver Davies: Yeah, that's one of Drupal's main advantages is that the people who are non-coders can install it, can create content types, can create their own pages and listing pages and everything. So, if you then went and said, oh, everything needs to be written in this way and with a test, that's one of the advantages of using Drupal as a CMS rather than, you know, a framework or something that doesn't have that. 

In the workshop that I've done, I did it for London just before COVID and I did it online for DrupalCamp NYC remotely, during all lockdowns and COVID and everything. So going through like the different types of tests that there are and where do you want to use one over the other and that type of thing. 

And then we start building, we did some Drupal Core, as I said first, but then we started building a blog, as part of, it was something I could think of, like, what can people relate to? Like, again, like, you could do that in the way that, like, we were doing it in the course, and so, like, you could make a custom route, and we could create a controller, and we could create a view, we could do it very code... you could do it the code way and write the tests for it. Or in that case, I'd probably just do it the Drupal Views way and just do it in the UI. 

You could, you can export it and make it into a module if you wanted to, but for something like that, as it is other, I try to think of examples, but there's things you can go on. And there's one new project I use but I can't remember what it's called, but you can sort of do it on the website. You can do tools on the website, like Drupal can, where you can click around and you can build your content types. There are ones that you sort of set, you click this and then this happens.

So it sort of writes the test for you in a way, but they're more sort of high level sort of functional feature tests. Like ,does this page exist? Does it have this text on it? That type of test rather than, the page is gone, or the page is erroring, which is, yeah, that's one of the types of tests we can do in Drupal as well.

But there's also like lower level functions, like we want to add two and two equals four, but we're going to write a test for that as well. So if you're going to do it the UI way and the site builder way, then you could probably use one of these other tools to accomplish the same thing for that level, because you don't need to get too low a level for that.

Tim Butara: And the last thing that I wanted to discuss, and I feel that we need to discuss because it's one of the hotttest things right now is the use of generative AI tools in this context. I know that, like, a lot of developers are using these tools to kind of, to take care of these more tedious tasks in their roles. So I'm guessing that, you know, is this something that generative AI can help with as well? So tools like GPT and Copilot and stuff like that. 

Oliver Davies: Possibly. Oh yeah. Quite probably. I think syndrome as a conference earlier in the year, and somebody had mentioned, there's quite a bit, a lot of topics around the AI and like ChatGPT in particular and other things.

And I think it comes down to. It can generate code for you and things, but someone needs to test it's right and somebody needs to verify it and go, is it correct? I did see, I can't remember if it was at the conference, whether it was on Twitter or somewhere, and somebody had said you could use it to generate the tests, which are the most, it wasn't "boring" part, there was some sort of word there. 

But I'd say that's the part I wouldn't want it to do, because I wanted, I want to make sure that the tests are correct and testing the right thing. You wouldn't necessarily want to just have a test where the pass is to begin with, like, straight away, because you don't really know there what it's testing or not testing.

The important part of doing test driven development is seeing the failure first, then seeing it pass and then being able to make it fail when you want to. So, you know, it's not just passing by accident, essentially, whereas if you've got this generated test suite of things, then yeah, it might not be that great.

If you do sort of like unit testing for this concept of mocking, so you could be in a situation where you mock something rather than use the real thing and then just testing the mock. I've done that myself quite and I've just gone, I'm not actually testing anything of value. I'm just testing the mock that I did.

So something, yeah, somebody, ideally somebody, should be able to review that, like, get it to generate tests for you if you wanted to, but you still need to verify that they're right, they're testing the right thing and then maybe, can you make it fail by making a page unpublished that was published? Like, does it fail then when you expect it to? I tend to use it as a, yeah, where you need it to put, sometimes it just generates things for me and then goes, that doesn't exist. And I go, and it goes, oh yes, I'm sorry about that. 

So, it's a good idea. I think it can be a, I think it's still key to, yeah, know it's testing the right thing and to understand what it's generating and not just completely take it at face value. The passive developer that I think is like people copying and pasting Stack Overflow or drupal.org or it's just like fine. But then if it works, then great. Then take that extra time and learn and understand what it's doing and trying to learn from that. I wouldn't just copy and paste, copy and blindly paste things in. 

That's the concern for people, I guess, from a developer perspective, like. It's, it's something you're just going to go into ChatGPT and say, build me an app that does this, and it's going to give you all the code. Like, I wouldn't take that at face value. So I want somebody to know it's testing the right thing. 

Tim Butara: Yeah, definitely a lot of great points. I love the point about people going, oh yeah, we'll just have the GPT or this AI tool, we'll have that write our tests, but as you pointed out, this is exactly what you shouldn't do because, you know, because everything that AI produces basically needs to be tested by a human. So if you just wrote tests with the help of AI, a developer would also need to invest time into like checking them and testing the tests. You know, it's a case of who watches the watchman kind of thing.

Oliver Davies: Exactly. This is, yeah, this is very true. And yeah, it also depends as well, like how, even if you generate tests for you, that were brilliant and that worked perfectly, like, they might not be the most... another benefit of having these tests is that they're there as documentation for other people.

So if I'm a developer and I want to see how this thing works, I can go into the test and go, okay, well I need node of this type and I need to then do this with it, et cetera, et cetera. Like if an AI tool has generated that, it might not be the most, easiest to read or follow compared to somebody, you know, who the feature who wrote it at the time. So, yeah, that's one of the big benefits as well we haven't mentioned. 

Tim Butara: Well, Oliver, thank you so much for joining us today and for sharing your expertise with our more business oriented listeners. Before we wrap up the conversation, if listeners would like to reach out to you, connect with you, or learn more about you, where would you point them to?

Oliver Davies: My website is probably the best place. It's oliverdavies.uk, D A V I E S. U K. That's where things like my daily email list is, products and things about, I'm doing a email course, a free seven day email course on introduction to automated testing and how people get started with it. I'm doing a talk at DrupalCon Lille next week on automated testing and TDD.

So the slides and the videos and everything will be there as well. There's some links to things like my Twitter account and everything on there. That's sort of the hub where everything sort of lives. That's the opdavies online, drupal.org and pretty easy to find for the most part, I think. And yeah, always happy in the Drupal Slack as well. So there's always testing channels in the Drupal Slack. So I'm definitely around the community as well. 

Tim Butara: Well, thanks again, Oliver. As I said, we were very happy to have you on the show. 

Oliver Davies: Thank you very much. 

Tim Butara: And well, to our listeners, that's all for this episode. Have a great day, everyone, and stay safe.

Outro:
Thanks for tuning in. If you'd like to check out our other episodes, you can find all of them at agiledrop.com/podcast, as well as on all the most popular podcasting platforms. Make sure to subscribe so you don't miss any new episodes and don't forget to share the podcast with your friends and colleagues.