The role of agile in developing digital customer experiences in financial services

During this episode, we explore what agile means within the context of financial services and the role that agile methodology has to play in the design and delivery of digital experiences and why agile is more than just a buzzword used in software development. 


During this interview, we also covered:

• Why agile is more than just a buzzword 
• The debate between waterfall and agile and the pro and cons of each
• Why large FS institutions find agile so challenging to implement 
• A breakdown of the building blocks that go into the rollout of an agile approach to digital experiences 
• How an agile approach can help FS brands to deliver faster improvements to the customer experience 

To get in touch with future questions or to be interviewed for a future episode, email info@ratiofs.com or visit us at www.ratiofs.com

Transcript

RATIO Partners Re-imagining customer experiences in financial services Ep 1 - Transcript

[00:00:00] Mario Kyriacou: [00:00:00] Welcome to another episode of our podcast, Re-imagining customer experiences in financial services. I'm your host, Mario Kyriacou co-founder of Ratio Fs, the marketing data and customer experience consultancy. This is the show where we try to analyze how Fs brands can leverage digital to deliver experiences built to solve your customer's day-to-day challenges.

[00:00:37] On today's episode, I'm pleased to be joined by Cassia Thompson and Gael Garcia from Ratio Fs as they walk us through their experience of why agile in financial services is more than just enough, a buzzword. We discuss why branch looked to build an agile mindset beyond just software development. Along with some helpful advice from their years of managing agile projects on [00:01:00] how Fs brands can start to build agile into their ways of working.

[00:01:05] Thank you, Gail and thank you, Cassie, for joining me on today's episode, been looking forward to this interview for a while, since we started talking about this, what feels like eight years ago now? So, it's finally having the chance to, well, quiz you over the next 30 - 40 minutes. So, onto the first question;

[00:01:23] So agile has become very much a bit of a buzz word over the last couple of years. And in terms of financial services, do businesses in this space want to be agile and really from their perspective, what is in it for them? 

[00:01:41] Gael Garcia: [00:01:41] I think, um, I'd have to think that when banks like Monzo, who were on the rise, um, the new for agile in bigger financial institutions was driven by them seeing these experiences, these challenger banks were producing and essentially wanting to emulate that.

[00:01:55] So, this is probably going back a few years now, and I have to say that many banks have very sleek [00:02:00] apps. Um, but taking that mobile apps as an example, when I first moved to the UK, my first bank account was with a high street bank. Um, the app was very basic. You could see your money; you could move it around.

[00:02:12] Um, the app stayed like that for about three to four years. In fact, it might still be the same. Um, I don't know, because I actually stopped banking with them. Um, because in that time I also set up a Starling and Revolute accounts and the app experience was vastly different. Um, they had so many useful features like creating spaces for saving goals, um, or being able to use a virtual card that would only last for a certain amount of time.

[00:02:35] De-risk your online purchases? Um, I'm sure a lot of banks would have seen these kinds of features in us. How have they, how have they been able to produce this quality of UX and probably realize that agile is a part of the answer.

[00:02:52] Cassia Thompson: [00:02:52] Yeah. And I think, um, users in general are a lot more demanding of good experiences now than they might've been even five years ago. And if [00:03:00] you are slow to fulfill those requirements, then the younger challenger banks that can move more quickly and can utilize agile to at speed, improve their experience and change their experience with the, of the needs of their users.

[00:03:13] Then there's a very, very high risk of deed of these Chandra banks actually pursuing your clients and your customers away from you. I think a lot of these banks, they want their, their users to have the best experience possible, but if they have an intrinsic slowness in terms of the ability to enact change and get things propagated out into various digital services.

[00:03:33] And they could find the, if they launch a program to try and make these improvements, by the time it's done, they may find that the needs have changed or they, you know, the next level has already been addressed by some of the challenger banks. And it gets even more complicated when you have a huge portfolio of products, which many of these more organic older businesses have.

[00:03:53] So it just makes it much more difficult to manage changes in general. But if you are going to have a series of small changes as a [00:04:00] result of that portfolio, then managing that via waterfall can be really, really challenging. Any changes that you do make um, need to account for a huge variety of products and services and user types.

[00:04:10] So they have to go through a much more rigorous process to even get started, let alone finish propagating it out. So, change management just gets exponentially harder, the more varied your products get and the larger that you are. 

[00:04:21] Gael Garcia: [00:04:21] Yeah. And the complexity that large banks have to deal with is probably a huge reason as to why waterfall has been their go-to methodology.

[00:04:28] Um, it gives you a generous amount of analysis time. So, you can assess what the overall effect is going to be before you actually make any changes. Um, and this is obviously a huge bonus If you're a business that's risk averse, which I think it's fair to assume most banks will be. Um, compare this to challenger banks who are also risk adverse, but their portfolio or customer types may be not as large.

[00:04:49] Um, they're able to adapt more quickly and easily to the changing needs of their customers. Um, which means they can go a really simple app to a full banking service over a period of time, that's small [00:05:00] when compared to one large bank. 

[00:05:01] Cassia Thompson: [00:05:01] Yeah. And then when you added the additional complexity of how globalized and lots of the bigger banks are.

[00:05:07] They're um, they have complex needs, they have a long requirement process and to be frank, you could spend your entire budget on just discussing what you want to do and agreeing what you're going to do and not actually have delivered anything tangible. If you've got this long line of consultants, business analysts, designers.

[00:05:22] Feeding into a process to make sure that you have the perfect requirements, the drain on your resources, just to get to that point, um, can be very difficult to justify and well waterfall kind of just demands that because you have to do that upfront analysis and agree exactly what you're going to do from the very beginning.

[00:05:41] And then even considering the time investment for people across a complex organization. So, if you think about how many people need to be in any average stakeholder meeting in financial services, um, that is already a huge drain on the time of probably already time, poor resources. So, if you think about someone who's already got a full time [00:06:00] job within whatever is that they're doing, and then you want to pull them into a long requirements process, it can be really hard to even get the time with those people.

[00:06:08] And then if you don't that then also drags out the time on the other people that you might have, they're actually charging you on a day rate or something like that. 

[00:06:16] Mario Kyriacou: [00:06:16] Okay. It's interesting that you referenced the challenge of brands at the start actually have, um, today's interview because it's been a recurring theme throughout actually every episode so far has podcasts.

[00:06:27] I mean, the purpose of this podcast is to understand how we can improve customer experiences for in effect, legacy financial services institutions. Um, but everyone references challenger brands, challenger banks, for example, but in a positive way, they're not seen as, um, an existential threat to these businesses, but they kind of analyze in, well, okay.

[00:06:50] We've now had a new bar for what good looks like and kind of analyze from the inside out, you know, what goes into making those businesses, you know, [00:07:00] Seeing great in the eyes of consumers and some things you referenced just now about agile as a methodology to deliver these experiences is, is, is interesting.

[00:07:09] So leads me onto my next question, which is: agile is perceived as something which is perhaps unfairly as difficult or perhaps no, not necessarily worth the effort involved. I know you mentioned, you know, waterfall and the comfort, of been able to articulate upfront, you know, your needs and requirements.

[00:07:30] I'm just curious to understand from, from your side, is it something which you think is, is difficult, you know, in lacks the benefits for these types of organizations? 

[00:07:37] Cassia Thompson: [00:07:37] I think agile is hard for larger organizations for a number of reasons. The first is size, so, I mean, depending on the bank, for example, you could be looking at an organization that employs hundreds of thousands of people all over the world and different, you know, in different disciplines, in different countries and all kinds of different teams.

[00:07:56] And that naturally has challenges in collaboration, which is kind of the key. [00:08:00] Component to agile. Um, and if you don't have a very strong communication structure built in to that, you could even find that you have teams in different departments that are working on the same feature only to find that they then doubled up on work, or they could find that those two teams working on features that are completely [00:08:17] Uh, they clash with one another, so that they're at odds with one another, and you could find that you have various different teams who need help, who just have different needs, who need different requirements that you need different considerations, but it's very difficult to try and centralize that information gathering in that sharing of information in the first place.

[00:08:36] So if you have a business that's grown organically and has a focus on local needs. So, for example, local markets or specific product teams, et cetera. You could find that trying to retroactively shoehorn in a centralized design and development team or process could be really disruptive and difficult to get there and then again

[00:08:54] It, kind of automatically requires some kind of restructuring, If you were going to try and [00:09:00] take all of agile and just shove it into the business without kind of considering the organic change over time. 

[00:09:06] Gael Garcia: [00:09:06] I think, um, another thing to add with regards to people working in silos, that when you work in silos, you tend to develop solutions in silos that are tailored to your specific needs.

[00:09:16] Um, and this tends to create complex ecosystems and solutions, I guess, which end up being very intertwined. So, let's say you want to make a quick change to improve a particular feature but then you find that changing it on Z affects X and Y in an ABC way and then all of a sudden something that was meant to be a quick change, becomes not so quick after all.

[00:09:36] Cassia Thompson: [00:09:36] Yeah. And then something that's very specifically specific to financial services is the regulation and compliance aspect as well. You, you're talking about an industry that's heavily, heavily regulated, there's all kinds of legal considerations around, um, you know, even just like the basic texts that you have to put on a page, that's completely explained something very specific about product.

[00:09:54] There's also going to be, uh, all kinds of compliance review processes and a lot of [00:10:00] these businesses. So even changing how something has been coded could go through a review process that follows a specific set of guidelines, which could just be about internal risk management. But essentially, you're creating layer upon layer of review and sign off and so on.

[00:10:17] And the kind of the reality of that is that we've seen many businesses which have a real bottleneck in terms of anything that gets done, no matter what it is, has to go through legal team, financial assessment team, et cetera. And if you don't scale that up to match the size of your delivery team can be a real challenge to get anything pushed through.

[00:10:36] And I think all of this comes from financial services in general, having a tendency to be quite risk averse. So, you kind of end up with, okay, this thing went wrong over here might not even be within this business, but essentially to make sure that that never happens to us either at all, or again, uh, we need to make sure that any changes have, uh, checked by this person, that the list is sounded. [00:10:57] Um, therefore tick these boxes and get that through to [00:11:00] live. When you kind of compound that across a huge organization, when you have all of this regulation on top of that, the reality is you're creating this really long, complicated process to do, to get anything done. So, if you're not able to allow self-regulation within delivery teams.

[00:11:16] So for example, someone delivering something can also review it and sign it off. Um, and then you choose to centralize the kind of review portion of the process. Then you have to make sure that the review team is at the kind of level that doesn't hamper any kind of delivery elsewhere in the business.

[00:11:32] And I think that's something where a lot of organizations kind of struggle at the moment, it’s quite hard to justify and doing anything else, It's going to give you bottlenecks the only full, further behind the time. And we've seen that this can lead to a real reluctance to put anything unfinished into the process because it just doubles up on a potentially very long waiting period.

[00:11:50] So it kind of defeats the point of agile in the first place. So why would you save two weeks of development by putting something through that is maybe almost finished that has an extra [00:12:00] feature that you want to play on top, but then have to wait a month for that to be reviewed, to then take another chunk and put that full review and have to wait another month.

[00:12:08] So you end up in a situation where, these teams will not submit anything to get pushed through, to live, unless it's completely finished and they don't have anything else they want to do with it. And the thing with agile is that iterated change Is its biggest strengths from these kinds of teams. So, if you don't scale up that review process, then essentially agile kind of is negated, um, in that regard.

[00:12:33] Gael Garcia: [00:12:33] That's the thing. Um, sometimes going live in an MVP is just a really hard sell for business. Um, one of the reasons why waterfall so great is that obviously it gives you some level of guarantee of results. Um, you have a list of agreed items and there's usually a contract that states someone has to deliver.

[00:12:50] Um, agile on the, on the other hand, as you said, has, um, it's kind of like a black box, it's based on iteratively, improving a basic version [00:13:00] using evidence. So that means you have to accept that you won't know everything at the start, and you also have to accept that things can and should change when you've sent it out into the wild.

[00:13:10] Um, the freedom of this unknown is one of the reasons why agile is so great though, because its flexibility makes that, okay, you don't need to have all the answers upfront, but if a business isn't willing to accept the risk that comes with that, then they'll struggle to see any benefits in doing things in an agile way.

[00:13:28] And also think the procurement of funds could be an issue for large banks. Um, if you have a we don’t know everything approach, um, in a lot of these institutions, the process to get money is long and inflexible usually need to know exactly what you're getting for that money. Um, so they prefer contracts that are fixed scope rather than fixed schedule or fixed resources [00:13:48] and that can be hard to correlate with agile. 

[00:13:50] Cassia Thompson: [00:13:50] Yeah. And they also have to consider communication out into the wider team, we've already talked about the effects of having these huge organizations with all these teams across the world. [00:14:00] But the bigger the organization is, the harder it is to collaborate and propagate information out.

[00:14:04] So it could be that there is a feature that would really, really benefit a local market, and if they can utilize it, they might find, find that they get really good return. But if there's no one making sure that market knows what you're delivering, when it's coming and how to utilize it, and when is a good idea to utilize it, you could find that that effort is somewhat wasted.

[00:14:23] So if you don't have a centralized source, that source of truth, that showcases what's happening across your digital program and this being reliably used and reliably reviewed, and that you can showcase some of the successes in one market and kind of help inspire some actions in other markets, you may find that your return on investment is just really minimal.

[00:14:43] And I think this also ties into a general culture that we've often seen with some of these larger organizations. So, when you have, when you work in an agency, your kind of used to people popping in and popping out. And generally, people are quite quick to switch to the next role and move on and do new things.

[00:14:58] But when you're working in an [00:15:00] environment where people maybe have been there for 10 years or 20 years or even longer, I know I've met people in financial services who have worked very long time in some of these places. I think that this can lead to a general culture of preserving the things that they know work, even if the idea of something else might work better.

[00:15:19] So when you kind of have people who are invested in the status quo, change can be kind of seen as disruptive or unnecessary, especially if things are working, they could just be more working better. And I think if you combine this with a culture where there's a real demand for return on investment, on everything that gets done, every project, every sign off, if you need to be able to deliver a result, no matter what [00:15:39] In order to get that funding, then you might find that people are less likely to innovate and experiment because if you have people who are focused on, okay, we'll just keep, keep the machine moving as opposed to experimenting with the acceptance of a certain level of risk that to the experiment failing, you might miss out on the next big idea.

[00:15:58] It could be that there was someone in your [00:16:00] team who with the right funding and the right time gives you the big idea that kind of revitalizes the industry or changes things completely. But if they don't have the space and the culture within to experiment and try things out, you'll never really going to find anything other than a slightly better way of doing what you're already doing.

[00:16:19] Mario Kyriacou: [00:16:19] It's interesting what you just said. I mean, I think it's true to say that in these businesses, they employ lots and lots of super, super smart people, and what holds them back, isn’t it a lack of understanding what customers need or what the market needs, or, you know, what even good looks like from the customer's perspective, you know, half the challenges [00:16:40] is knowing where to start, how to start when, when you have so many different things per use so many different directions. So, in terms of agile, it always feels like one of those things, which is a methodology, which is probably people buy into, you know, they would [00:17:00] understand that if they could do it right, it would generate value for them as a business.

[00:17:03] And you know, it affects their customers as well. But my question is so where and how does one start this agile journey? And do you typically see these types of transformations follow the same sort of route? 

[00:17:21] Gael Garcia: [00:17:21] I think for me, the first step is to have an honest conversation when you want to go with [00:17:25] and move into an agile way of working. Um, so, you know, ask yourself, what do you want to do and what can you actually do? And are they the same thing? Because I think you'll find it's not always the same thing. Um, it should also just be recognized and accepted that the transition to agile, isn't a simple or quick ask.

[00:17:43] Um, and also just because you deliver something in sprints, it doesn't mean it's agile, but also it doesn't mean that it's wrong for the business. You have to kind of do what makes sense.

[00:17:51] Cassia Thompson: [00:17:51] Yeah. And there's a real. There's a real need to understand what the difference is between an aspiration and realism. I mean, the number of people who have come to me with [00:18:00] the video from Spotify, that kind of explains the way that they work and sort of say, Oh, we really want to do this.

[00:18:04] And you kind of look at this and you go, okay. But this is the model that was created by Spotify for Spotify, would it really work for anyone other than Spotify? You can certainly take elements from it and you can certainly aspire to it, but just creating that team in the middle of, of a completely different structured is not going to get the best answer.

[00:18:25] That's one of the reasons we've kind of already discussed. So, you kind of got to create a model that works for the business rather than shoehorning in a process that works against it. And then you iteratively make changes over time. So, you only need a few small successes to be able to start saying, okay, well, look, this is clearly working, so let's take it a step further.

[00:18:44] And I think that that can really give you some leeway to make more changes in the long-term. And I think that doing this in a slightly more iterative manner can mean that people can get brought along for that journey and brought along in that process. And it can be seen as less [00:19:00] disruptive. It can be seen as less scary because you're not just sort of saying, okay, the entire world is different. [00:19:04] You're saying, okay, this whole thing is different. You are happy with that? Good. Let's move on and change another small thing. I think that can be a lot less disruptive. 

[00:19:11] Gael Garcia: [00:19:11] Um, another thing that you kind of need to look at is your culture as a business. Um, so agile is all about evidence and users and the culture kind of needs to match that, the focus needs to be on the end user and not the politics. [00:19:24] Um, as it sometimes is, It feels like anytime a new feature is requested, you should ask yourself who benefits from this, and if the answer isn't the user or the business as a whole, then you shouldn't really question if it's needed. Um, and I also think you need to adapt the way that you deliver projects or user testing and user validation needs to be core to the whole process and delivery if you're going to work in agile.

[00:19:46] Cassia Thompson: [00:19:46] Yeah. I think there's a lot of interesting stuff happening in the, in the industry around centralizing a lot of the things that kind of tie into your digital program. So. If you were going to try and embark on something like that, I think it's always worth [00:20:00] trying and asking the general key questions of, okay [00:20:02] From a tech perspective, how many systems are we using that could potentially be doing the same thing? If you did an audit, I would guess that most people would be surprised to see how many different tools are using within the organization. Um, and then from a design perspective, is that being regularly reviewed?

[00:20:17] Is it, is it up to date? Does it work with accessibility guidelines and how does it look when you compare it to your competitors? that’s something that should always be happening, uh, because you can find that people get so stuck in adhering to the brand guidelines and the brand guidelines don't change for years [00:20:31] and that's another way that your, your challenger banks might really distinguish themselves from you.

[00:20:37] I think, um, it is always really important to make sure that your process doesn't end at the point of delivery. You've got to make sure that it's adopted. So how easy is it for your local markets and then well other systems you're using at the moment to actually utilize local components or designs? [00:20:54] or data, if you are going to go and conduct an interview with someone in market A know [00:21:00] what someone in market B is working on, even if person in market A is working on something that can really benefit market B. Try and you could even just conduct interviews to find this out and try and understand what's happening across the business and whether those communication channels exist or could be built, because those could be some really quick wins.

[00:21:17] Gael Garcia: [00:21:17] It's a really good example of a measure of success. And I guess that kind of segues into the fact that the KPIs should be aligned to the delivery method as well. So, I think traditional way of thinking of KPIs works well with a waterfall projects because the outputs are clear and agreed at the start and you've spent all the analysis time upfront.

[00:21:35] So you can, get a level of results, but with agile, you're putting something out that's basic and we'll iterate over time based on actual evidence. So, your KPIs need the level of flexibility to reflect this. Um, they should be focused on general goals of the organization or users rather than deliver X Y Z.

[00:21:53] Um, and the focus should be on optimizing notes, have we knocked it out of the park with a big bang launch?

 [00:21:59] Cassia Thompson: [00:21:59] So I think that [00:22:00] the big key points of everything that we've covered, and we've kind of covered a lot of subjects in a certain level of detail, but I think the key points being, if you want, if you want to transport organizations and it can work with agile, first of all, work with it, not against it.

[00:22:14] You've got to be able to accept a certain level of risk. Um, you've got to be able to encourage experimentation that could come from anywhere focused on breaking down the bottlenecks to the ones who are actually delivering stuff. It doesn't get held up by layer upon layer of review. And then on that same subject, streamline the processes where you can, is something happening that should, that should be easy [00:22:34] Is that very hard, almost any person in any level of your teams and see if they have anything that really drives them crazy. And kind of finally the whole business needs to be working towards a common goal, and that can be at different levels and different levels of seniority. But essentially if you have a very specific goal at the top of an organization, then every single goal beneath that, every team beneath the very top levels of the organization should in some way, be [00:23:00] able to see their goals and the things that they are measured upon tie into that common goal.

[00:23:06] So rather than saying, as Gael kind of already pointed out, um, did you deliver this specific feature that I wanted by this specific date, which has all kinds of arbitrary? It could be much more based around, okay, have we increased user retention? have we brought in any new users in this area of the site?

[00:23:21] Have we sold in more of this product? So, making sure that everything ties into one central ideal could mean that people feel a lot more invested in that long-term progress to actually delivering against it. 

[00:23:35] Mario Kyriacou: [00:23:35] Okay. Well, a couple of things, you mentioned culture a couple of times and I, and I think I totally get that. [00:23:42] I understand how agile just isn't something which you pop to the shops and buy and start using it. It's, it's something which has to filter across every different level of the organization. So, my question is what [00:24:00] role does education around the value that agile can bring to a business and just put into context? [00:24:07] I think there's still a perception that agile is that thing that people in software do in terms of software development. And a lot of the things I've taken away from today is it's how agile can spread beyond just, you know, delivering a cool app or a new website, you know, the role it plays in, you know, any type of project. [00:24:29] So if part of this is, you're trying to get buy in, what role does education play?

[00:24:36] Gael Garcia: [00:24:36] Education plays a huge role, and that's why you have professionals who call themselves agile coaches, essentially. So that's basically their whole gig. Um, so what their role is, is to educate a business on agile ways of working, not just from say a project management point of view, where it's like, you need to a deliver it in scrum, and this is how you do scrum.

[00:24:57] It's more like, okay, well, these are the, [00:25:00] the roles that people play in the whole agile world. Um, and these are the various things that you as this role need to do, or you as this role needs to do. So essentially that whole role is educating and I think there are some roles within the whole agile world, such as a scrum master, for example, um, who part of their role is championing that agile way of working. [00:25:22] But I think initially, when you want to move towards, um, Agile ways of working, having that agile coach or someone sort of give you the ins and outs of what needs to change, not just with delivery, but with your culture as well, It's really important. 

[00:25:35] Cassia Thompson: [00:25:35] I mean, I have a few examples of where someone's asked me what agile is because they don't work specifically in digital. [00:25:41] And when I've explained the general core concepts of it, they kind of go, Oh, I kind of already do that. So, I've got all these posted notes and I just picked the most important thing and I do this first and I break down my tasks and we work on this way and I think people are scared of the general idea of this very big structure that you know, is kind of [00:26:00] mysterious, no one quite knows what it is.[00:26:02] And I think that it could, it can be really, really useful to a wide variety of roles and I think people are probably closer to it in many scenarios and they think they might be. 

[00:26:13] Mario Kyriacou: [00:26:13] it's interesting, what you've just said about, um, you know, when you've explained this to the concept of people in the past, they said, oh yes, [00:26:21] um, you know, we do, you know, I'm kind of doing that. And I've got a question around that, which is, as a bit of background, I remember taking, taking a marketing course with the Institute of marketing director of the IDM years ago. Um, and um, what I found interesting was the working models in terms of, you know, how you build out, you know, digital trashy plans, marketing campaign plans was very convoluted.

[00:26:51] It had all these different steps, but then how you applied it in reality, it was very different. You ended up, you know, looking at your own business [00:27:00] and just figuring out what works for your business and your campaign in our specific instance, and looking at how do you deliver something quickly, the best value, not necessarily going through a massive checklist of a hundred different things.

[00:27:14] And I was curious whether the same thing applies to agile in that if you was to treat it like religion and look at, you know, I suppose what the gospel is for agile and then looked at applying that to know business, they could be put off by perhaps the, I suppose, the intensity or the, the amount of things involved in trying to do, I suppose, whatever true agile is, is there a hybrid model of [00:27:48] Businesses adapting just the, the framework of agile to their own unique needs because you know, Legal, Genuine and Aviva, uh, similar in the products they sell, but they're very different businesses in terms of they can't [00:28:00] necessarily just apply the same thing and expect the same sort of result. 

[00:28:05] Gael Garcia: [00:28:05] I think some people will tell you if you are delivering work in sprints, then you're working a job. [00:28:10] And some people will tell you that if you're not having daily, stand-ups that follow this exact structure but if you're not having daily stand-ups, and you're not following a very specific agenda and you don't have a specific team makeup, then you're not properly agile, you are something else. And there's a kind of nasty word [00:28:25] that's probably around agile with lots of people, sort of shuts me. Um, but at the end of the day, even if what you're doing, wouldn't technically be called agile by certain people who works in the business, It's not wrong, If it delivers and it delivers quickly and the team are not completely overworked, then I think that's a pretty big success regardless of what you call it. [00:28:47] But there are certainly groups out there who thinks the agile must adhere to very strict rules and that you only achieve agile if you're following every single point on those rules. 

[00:28:58] Cassia Thompson: [00:28:58] Yeah, there's a really [00:29:00] good article to look up called the corruption of agile written a while ago. Um, but it just talks about how, you know, agile started off in full values, um, to sort of guide you in [00:29:11] doing things in a way that makes sense for you and that was basically agile. Um, but I guess that's being taken now and a lot of structure, um, and commercialism I guess, has been put around it. Um, and now it's starting to, I guess, in some ways resemble prints, uh, where you've got a whole set of rules and you need to do things in a certain set of way [00:29:31] otherwise it's not really capital A agile 

[00:29:34] Mario Kyriacou: [00:29:34] Because you've mentioned MVP. I'd like to finish with one final question. So, you mentioned, you know, minimal, viable product and MVP, um, you know, getting something out the door. And I suppose on the things I've heard in the past is, and I think perhaps this is something which is, a hangover from technology company’s [00:29:53] definition of MVPs is that there's a level of compromise in any form [00:30:00] of MVP that, you know, you've got out the door, great. You've made some sort of serious compromise perhaps to the business or for your customers, Is that fair to say? 

[00:30:11] Gael Garcia: [00:30:11] Yeah, definitely, but that's why you have product owners who assign business values to features. [00:30:17] So, um, so you know, you have something that guides you in terms of what that compromise is. Uh, so if you're launching an MVP, then theoretically, then the features that you should be launching with are the ones that bring you the most business value. Um, and I think. A lot of people forget that with tech projects, particularly once you send something live, that's not it.

[00:30:38] Um, and especially that's the case with agile. Once you send something live, then it needs to evolve and change based on how users see it. So, I think it's important to know that yes, you might be compromising, um, with going live with only a certain set of features. But on the other side of that, you should be adding more features or changing the features once the product is live.

[00:31:01] Mario Kyriacou: [00:31:00] I think I’d buy into that, there’s nothing worse than, um, launching something and it never changes for the next couple of years. Well, thank you. Uh, Gael, thank you, Cassia. I really enjoyed today's chat. And so, thank you for joining me today. 

[00:31:18] Gael Garcia x Cassia Thompson: [00:31:18] Thanks for having us. No worries.