PurePerformance - 052 Quality is more than Testing: Baking Quality into your Product with Finn Lorbeer

Episode Date: January 1, 2018

Have heard about “Shifting Left”? Well – get prepared to hear that Shift-Left is not the only solution to building a high quality products. Finn Lorbeer ( http://www.lor.beer/ ) is a Product Quality Specialist working for Thoughtworks. In a recent presentation given at Quest4Quality ( http://questforquality.eu/speakers/finn-lorbeer/ ) in Dublin he explained how being a quality engineer is no longer about being seen as a quality gate (and sometimes bottleneck) in the deliver cycle. Finn is sharing his experience from a recent project with a large German automobile company where he helped transform the development teams to shift-left on quality but not only for the software they develop and test, but also for the type of features they implemented and how they see quality as a whole in their end-to-end delivery cycle. Interesting lessons learned on how to speed up delivery, increase quality and make everyone part of the game!

It's time for Pure Performance. Get your stopwatches ready. It's time of Pure Performance. Now I know I've been using the word special in terms of the episodes a lot lately, but that is because we've had a lot of special episodes lately. The last one was our 50th episode and this one is double special because when I say hi to Andy, you're going to hear him sound very different today. He's actually recording from the headquarters of Perfbyte.

So he has a professional audio setup. So everyone hold on and listen to the real Andy voice. Hello, Andy. Hello, Brian. This is Andy using professional microphone equipment. I hope it does not only improve the quality of my voice, but also the quality of the content that we produce. We'll see about that, right? Right, right. Well, you know, I think the content today is going to be excellent as well. We have a great guest. And Andy, why don't we, unless you have

anything you wanted to preface before, why don't you go ahead and introduce them yeah sure so it was I think like a couple of weeks ago I was invited to speak at Quest for Quality in Dublin in Ireland and besides having a lot of Guinness there we had some great conversations and I

ran into an old friend of mine again who I met last year at a German testing conference. And the guy I'm talking about is Finn, Finn Lorbeer from ThoughtWorks. And I was very excited about seeing him speak again and especially about the topic that he was talking about, which was building a high-quality product. But what I really liked more, kind of baking quality into the product. Without further ado, Finn, thanks for being –'s for there's further ado finn you forgot everything so finn the other reason it's special right not just because finn's on but because finn is on again

he is joining our two-timer club that's true. Sometimes the episodes are long and we split it. It's the amount of times we have a new session and record a new talk with them. So that's another special reason why having Finn on, besides him being a great guest, when he's part of our two-timer club. So anyway, that was the big thing. So welcome, Finn. Hello. Thank you for your hospitality again. I think, yeah, Andy, we met in Dublin again.

We were talking about metaph metaphors um i like the metaphor that you presented um how how taking photographs can be an analogy for agile or waterfall developments um what i always think of my favorite metaphor when i talk about building a high quality product so caring about quality is is the easiest or most fun product I can think of, which is a muffin that I really like to eat a lot. And when I think about quality, many people only talk about testing and testing is like putting some chocolate chunks on top of the muffin, you know, then it's a bit better and it tastes a bit better

and that's a bit better quality. But it would only mean that there's some chocolate on top and the real awesome muffins they have chocolate all over and inside or they have different flavors and colors and they are really really great but to get this started you need to you need to be involved before you start baking your product you have to start from the very beginning and just throw chocolate in. You know, if you test and put 17 chunks on top, you can count them and that's really awesome and you can document this.

And this is maybe important if you have diabetes. But in general, if you just throw a good gut feeling chunk of chocolate into the raw material and then bake quality into your product, I think then it will turn out much, much, much more awesome. That's a delicious concept.

And I just need to, is Metapher, you said Metapher, I believe, before. Is that a, what is a Metapher? Metapher, saying, talking about a muffin, but actually meaning software, right? Is that similar like an analogy okay all right i never heard that term before so i just wanted to i imagine a lot of just a german it sounds so english maybe maybe it's just it's the german german word that we use maybe maybe it's a false friends between german and english so an analogy yeah so so for everyone you just learned something extra new today you can use that word word, metapher. Excellent. Go on. So, yes, I think that's an awesome analogy, too.

I was staring at that slide for quite a while, thinking about all the different ways I can interpret it. And every way you can interpret that slide in terms of baking quality is just a great metapher. I want to provide a little feedback loop here. I just Googled metap uh metaphor and actually the english word would be metaphor ah metaphor so even better exactly even better exactly so i i love you know the obviously the analogy or the metaphor i thought when you presented that metaphor you know one of the things i mean i like muffins too but i think i like i like beer more uh so i thought about if you are brewing beer and i've brewed beer before you know it takes

between you know four to six eight weeks depending on how long uh the fermentation process takes depending on the beer but if you are producing beer and you don't do it right along the way then you may end up with a beer but then you taste it and then you think, wow, this doesn't have the right alcohol amount or, wow, I thought it's going to be a stout, but what I got is a lager. And you cannot just convert a lager to a stout by adding color to kind of brewing it into the process because you want to, on every step along the way in the brewing process, you have to measure, you have to get feedback, you have to taste, you have to figure out how much sugar is in there right now. So is the sugar enough to convert it to the right amount of alcohol so uh i may uh finn just asking you for permission i will ask you for permission now to use your muffin analogy but maybe convert it into my brewing analogy but i will give you credit for coming up with the idea if that's okay with you yeah if we can do it two ways because i really love the beer analogy it does not only mean yeah mine has some some pitfalls

just throwing some chocolate in somewhere right right, is still too easy. If you say brewing beer and you need specific things at specific steps of the process, that's even better, right? Yeah. The beer has all the continuous feedback because you have to keep checking as it goes. Exactly. Yeah. And, yeah, so, yeah, feel free. It's good that we just share.

And that's the awesome thing about our community. Now, coming back to your presentation that you did in Dublin, and by the way, we can put the links up online to the podcast. Besides the metaphor that you had, the metaphor, the analogy with the muffin, what is it that you've recently done? I know you talked about one project in particular. I'm not sure if you are allowed to give the name of the company you worked with. You were not allowed in Dublin, as I remember, but it was a large automobile company. And I thought there were some interesting things you did there. And can you talk a little bit more about that, what it actually means to bake quality into the product and what it is that you actually do with these projects

that you are getting involved in? Yes. So, yeah, I still can't talk about it. It's still not an undisclosed project. It's one of the big automobile companies in Germany that we build software for. But that doesn't matter so much who it is because it's not only what I presented,

where the way is how we bake quality in and we talked a lot with different qas that in germany we are four in total not very much but we worked a lot on what we actually do other than testing the software and we identified four things or four groups which deal with the process of the project we are on. They deal obviously with the software and monitoring part. They deal with the business and with the team setup or team moral and all of these things. And whenever I'm on some project, it doesn't matter if it's the current one

or any other, so I've worked for Mito as well. Last time we talked a lot about this auto company in Germany. I try to find the right balance between these four, I don't know, four dimensions that I can work with. Not only focusing on business, not only focusing on the tech side, but trying to find the right balance and trying to find where we have the biggest troubles, where we have the biggest problems to start baking. If you want. So, you know, and help us. So when you get into, I think one of the, if I read your abstract of the quest for quality talk that you had, and as you just mentioned, you know, when we think about quality,

it should not just be testing. It should start early on. But I think you had a very nice timeline, actually, where you say, besides focusing on quality only in testing, there's a lot of other stuff we can do along the process. There's a lot of wasted time. Can you talk just a little bit more about helping our listeners understand how you – what are the first steps to help people think about quality in a different way? So the way we approached this idea was there's a big word, the best word again, saying we want to shift left in the process. We want to get involved earlier in order to be able to bake quality in. And the idea is that the first step is to reduce waste in our process so if i think about my my wall that i have just on the opposite side of the wall of the zoom here and there are a lot of columns where

our stories may go through and some of them are basically parking lanes like a ready for development column where stories may be a week or two weeks depending on what iteration model you run or if you have scrum and stories lie there and they degenerate at best they are still valid when you want to play them and at worst they are like you need 17 updates on it already because it's all out of date and you have new priorities or new information and you have to rework them anyway so if you reduce a lot of waste, you automatically shift left even if you just stay in your testing column because the feedback loops already get shorter just because the moment where you start playing a story

and the moment where you start testing a story, they get closer to each other. So that's very briefly one of the things that we try. And then we could say if we saved a bit of time, we can use this time to look further into how we write our tests. And this is what I did not a lot on the current project. So when this project here began nine months ago, we had a lack of business analysts. So I joined the business side very, very much. And just two or three weeks ago, I had a lack of business analysts. So I joined the business side very, very much. And just two or three weeks ago, I shifted into my original role again. And it's,

it's so cool to see how different perspectives and different roles can can act differently. So when I was a business analyst on this project, I tried to get things done to get business value out. And I just briefly thought about all these quality concepts because there is no no time and no focus if you have another role and i just talked to the tech leads here and to the other people and said did you consider this and this and just like in the whole way passing by and and always just a small conversation they said yeah we kind of got it covered and so on and so on now that i'm looking into tests again i see that we want to throw end-to-end functional tests on all kinds of problems that we have. While there are a lot of integration tests that we can write,

there's a lot of logging that we can do, there's a lot of monitoring that we can do instead. And this is something that I, when I'm a real fully stuffed QA, really love to do. And that was the second part that we identified. So then I moved into the dev column already. If I'm part of the development of the story, if I'm part of the conversation of how the story is developed, I moved left again. And then I only get involved a bit in the analysis lane maybe. And I talk to the business analysts or product owners or product managers or whatever name you want to give them. Because basically we have the same stakeholders. If I look at our product, I know exactly what it's doing today.

If a dev looks at the product, the dev knows exactly how it will look tomorrow or the day after, and analyst people usually know how it will look in a week or a month, or maybe if they are really visionaries, they will know how it will look in the far future. And then I'm involved basically everywhere a bit. And then I'm involved with every person in every role, which gives me a good overview over my team. And I can see if my team is performing, if we get along with each other or not. If we have problems, I can encourage them to work in test-driven, to do test-driven development, I can encourage them to pairing. And I can see if we do too many mistakes, we can mitigate that.

And this is then the last peak of the iceberg, maybe, that we as QAs in Germany, in ThoughtWorks Germany, identified as what we can do and what we can provide as value to a project. In a brief summary, first of all. Yeah. So would you, the way you explained it, I and what testing is doing, what development is doing, and how product management is actually thinking about the next features. But isn't this, in an agile world, kind of a role that a product owner should have,

kind of knowing everything end-to-end, like knowing which features are out there, what people want, and kind of being that mentor role also a little bit is or or is it more how would you how would you describe this the role that you were playing in that project because i think it's a great role to have and it's a great chance that you had in this project to see all the different aspects and help them optimize the process and bring them together how what can what can companies do to say hey you know this type of role if it doesn't exist yet maybe it's the product owner but maybe i'm totally wrong what kind of role do we need in teams to to do this so i think the the easier one so product only let me come back to that in a moment that's interesting

to think about it one more frequent reaction is that people ask me what the scrum master agile coach is doing because i think there is a much bigger overlap in talking about the process identifying ways identifying bottlenecks speeding up the development trying to get in a state of flow so i think there is much much more overlap if you have a scrum master or if you have an agile coach or if you if you think you you may need them um for the product owner um i don't know i don't think there's overlap i think there's more that we that it really works well together we complement each other because the product owner is more, I think, directed forward and should tell the team

what he envisions for the product and maybe have a good overview over where we are. But the product owner will never get in-depth into the testing strategy, into the code base or something like that. And usually the product owner has to do a lot of stakeholder management, getting requirements ready, which is really time consuming. So I think this is, or I just experienced it again, this is a full-time job just to stay on top of the backlog

and have a brief overview over where you are with your application at the moment. But getting into details and getting into details of testing, of monitoring, of logging, of releasing. So we didn't talk about feature toggles, for example, in all of this, which is some hidden prerequisite in some of the claims here. I think it's rather, yeah, we will work well together. But there's little overlap. It's complementary. Okay. No, I just thought the product owner, obviously, I mean, it's helpful in the job and the role that you explained that you do to have some domain knowledge.

And I guess the product owner brings the domain knowledge in. So you're totally right. It's a nice overlap. So you just segu it into another area. I mean, obviously, I'm looking at one of the slides that you actually had where you exactly show the different columns. I think you mentioned those in your presentation. You know, it's like the wall or you have a Kanban board

and you have basically the different columns with the different stages and you wanted to remove the ready for dev, the ready for QA column. Now, you just mentioned something, some other prerequisites. In order for this to work, the software that you're building, the architecture, certain methodologies have to be in place. You mentioned feature toggles. Can you talk a little bit more about not only feature toggles, but I'm sure feature toggles will be part of it, but what are the things that you have to make sure in the project, in the code that you build

are in there in order for this to work? So feature toggles is one, and please elaborate on that. Anything else? Yeah, I mean, and what is the overall goal? Maybe I didn't explain that as well. What I want to achieve is that as a quality person, I want to make sure that I can quickly fix my application. I know that I will not find all bugs, and I know that we will have some bugs in production. And once we identified them, I want to be able to react as quickly as possible.

So the quicker I can move a bug through my process, the better. If for some emergency I have some really urgent bug fix and the entire team is in panic already because of the bug, then I don't want people to be distracted by a special extra process that we need for hotfix releases. I would rather like them to focus on the bug and release with the normal process so if the normal process also for stories is to just push everything through the pipeline very quickly and deploy any commit to production which is one of the things then i'm then i'm much much more then i can focus much more on a bug when i need to fix it and i just push it like

all the other days so this is one of the things that i really always try to establish in the teams that we deploy every commit to production wow so you know every every commit to production so that's something that i think a lot of people are afraid of that are in that transition phase. Because how do you, I mean, you have, I mean, it assumes, obviously, that you have a fully automated pipeline with a lot of tests. And every commit sounds, I believe, very, very dangerous for many people. And a lot of people have fear that every commit goes in. And also the disruption it has on the production environment, because every deployment obviously,

potentially has impacts on current operations. So can you talk a little bit about how, if you've experienced that fear in the beginning when you approached these projects and what had to be done in order to actually get there? We are there at the moment again. So we are for some month in the project. We built a bigger product and it's now being released to the very first users. It's not even a beta. We are way before that,

but we are also already curious if this will work for us as well. So we're having exactly those discussions because you need a bit more of a mature team where everybody is fully aware of what happens if you push your code from your local machine. You need to be a bit more careful in testing your stuff locally that you can make sure it works. You need a fully automated pipeline to begin with, and you need the concept of feature toggles

so that you won't introduce new features or accidental changes by a commit that is then deployed to production. So the idea is that a fully automated pipeline deploys every single commit with the toggled- of functionality to production. Therefore, the risk for operations for every single deploy is much, much, much smaller than before because you don't have some dependencies between the commits and you don't have the

dependency to the functional stuff that could also break or bad performance because you built something wrong in your caching, I don't know. And if you then toggle the features separately, you have decoupled the technical risk of a deployment from the release or risk of a release of a new feature. Therefore, the risk of every single item is much smaller, but you have to have a high test coverage, a very well-shaped test pyramid, a fully automated pipeline, feature toggles, and a mature team who knows how to handle all those four things.

So it's not something you can just apply. And we are just now discussing if we have the right level of maturity here on the project some people say we don't i think we have we will figure out in the next week so if you invite me for a third episode so that i can join a new club then i can tell you maybe in a month or two let me ask this i and i'm i'm wrapping my head around this idea of, you know, quality product. And I know there's been a lot of talk about shift left. There's been a lot of talk about leveling up. And especially in the leveling up realm, we're talking about the folks in the QA and performance testing roles who basically in order to fit into the modern release cycle really need to level up. But part of that leveling up is learning more about development, learning more about operations, learning more

about business, becoming like the Renaissance person, right? Someone who knows a little bit about everything and has a concentration in quality, let's say. Are you kind of with all this proposing, and maybe you're not formally proposing it, or the way I'm kind of reading into this is that the idea of quality assurance might no longer just be this idea of testing. Are we running our tests? Are the functions working? It's more about looking at quality of not just does the code work, but what's the quality of our pipeline? What's the quality of our feedback? What's the quality of our performance metrics? What's the quality of the product in

the user's hands? Meaning, are they enjoying it there? Are you kind of proposing that there's a role within quality or quality assurance? Maybe if you want to stretch it to say, looking at quality, the entire process from beginning to end and bringing and with the end customer, whether or not it's a useful and quality product expanding the scope of quality to encompass all that yes as a short answer okay if you say if you say the role of the quality analyst i mean this is where we can start the conversation already i don't think quality quality assurance yeah i'm really trying to avoid that word because i can't assure anything um to be honest i can i can test as good as i can but i'm the single one person beside the

the business people who has no no stake in increasing the quality so when i'm testing when i'm only testing i have a system under test somewhere on a on a stage environment i get a new piece of code as long as i test that piece of code that piece of code won't change i can maybe make it all melt i can find errors in it i can i can tear i can destroy the database or whatever but the quality of this piece won't improve and that's that's a shame and then i I claim that I assure quality. Maybe I assure some level, but that is the minimum level that it had anyway. So I try to get away from this and saying I think that my little Excel spreadsheet where I have a plan and just execute one step after another qualifies me to judge, if two bugs in a feature justify not

releasing a much bigger value, I think that doesn't work anymore in a fast-paced environment where you say you have a cross-functional team that cooperates a lot and therefore yes i think you have to be involved in in other things i think it's not the the qas so the abbreviation stays if i say quality analyst that's easier to convert than right so if i'm as a qa have my own column and if i'm the last step of the process then i'm a natural bottleneck already and then i'm defined by this process step. But if I remove that and if I say I'm involved everywhere, then it's a very stretched role. I know a bit of everything. I know nothing really can be good, can be bad.

But I think we need to learn much more for each of these steps. Yes, I don't think that people who will only test at the end and say, no, not good enough, do it again. Maybe next time I'll let this piece of code through. I don't think that this will be the future. I think it's a very – opens up a phenomenal opportunity for people in this realm, right? Because if you are leveling up, if you are researching and learning about all these new things, there's like the role as you describe it sounds extremely invaluable, right? It's, you can't,

it almost seems like an essential role because you have somebody who is now ensuring qualities along the entire process from beginning and baking it into the muffin or into the beer process, as you're saying. And that's something, you know, that you can't take a developer to do that because they're not going to have enough knowledge of stuff outside the development role. The operations team is going to know mostly about the operations. The QA team has that opportunity because by nature in their position, they have to learn a little bit about everything. So I just, yeah, from the leveling up idea and where growth can go, because there's a lot of scare, right?

There's a lot of fear in the QA world that, you know, is QA going to become obsolete because testers are starting to write automated tests and all this kind of stuff. But I think this kind of presents an opportunity to take it to a much higher level than it's ever been before. I think it's a great opportunity for quality aware people that have been in a testing role maybe before to become a mentor in the whole pipeline process and basically say, how can I teach, how can I share my knowledge with developers early on so that they can think more about quality up front? How can I help whoever writes the test automation to build smarter test automation? And how can I help the people that run operations or the platform where my software runs in helping them to maybe collect better data, as you mentioned earlier, logging and monitoring data so that we can feed back more information, both to development and to tester roles and

also the business role about the stuff that we deployed. So I think people that have a quality mindset, as you said, become essential, but more like mentors or quality as a service, they provide quality as a service, whatever that means, to the complete end-to-end pipeline team or the teams that are involved in pushing stuff through the pipeline. If you think about it like that. And that may even take some of the fear away right because if i say yeah you have to work with developers all day then the first fear is oh damn i have to learn to code fully i think that's not true either i we're currently on a closure project as i said since nine months i was a business analyst since two weeks i'm i'm looking into the quality realm again that doesn't mean mean I'm a Clojure expert.

Not at all. I'm not even close. But I can read the basic idea. I mean, code these days is written very similar to English. So with the person next to you, he's a full-skill developer. It's no problem to quickly go through it, grasp the idea of what is going on. And my contribution is not to be the even better coder. Not at all all because i have so many people here who can do this much better than i can my contribution is to analyze the the business case and the business value inside the code and

make sure that we deliver this in the future and then we discuss test scenarios maybe and then i leave the the pair or the person again to implement all of this alongside the story and then afterwards i'm already sure that i bake the quality in that i don't have to test every scenario anymore of this story so i there's another uh another great um analogy or metaphor um which is when you clap your hand, right, that makes a sound. But it's neither the attribute of the left nor of the right hand. It's just if the two of them come together. So that's always what I use to explain this as well. I don't have to bring all the experience into the pair, not all the coding experience.

And the dev doesn't have to know too much about test analytics if you want but if we bring both of it together there there comes a loud a loud noise from it right yeah and there's an old question what is the sound of one hand clapping that somebody solved by going like this but then somebody solved it by going like this with their one hand you know you can do it but yeah no i think that's a that's a great uh metaphan is it metaphor or metaphor metaphan though right that's the word i want to make sure i learn it properly analogy analogy i'm just trying to learn it make sure i want to throw it in somewhere when i'm speaking to some random person maybe if i'm at like picking up my kids

from school and some kid says something to me i can tell some six-year-old oh that's a great matavin and they'll stare at me strangely so i think what i wanted to say in the end the takeaway don't don't don't fear don't fear to be involved more in development what i've experienced were people who were in fear of it. And we worked for one and a half years on trying to get more, involve more people into the development and so on. And on both sides, on the people who consider themselves as tester only and the people who were developers, I mean,

if two people of different perspectives talk about the same thing, share something and learn from each other, it's a nice experience for both. And once people or former testers experienced that and saw how rewarding it is, I haven't met a person who said that didn't work for me. I've just met people who claimed it wouldn't work and they would either quit or I've seen the other thing as well where a company said okay we don't see the value testers so we fire all the QAs now that's the the other side so this is only where people didn't try they said it wouldn't work and they didn't even start this is what I've seen but for everyone who tried so far I've met only one person out of a few dozen who said no that's not that's not my way.

And this is maybe fair enough as well. And I think that goes to another point just in general, that if you're at an organization where you're trying to do this kind of stuff and you're just hitting those brick walls and everyone's telling you no, no, no, go somewhere else. It's obviously not a good fit for you because you're trying to level up, make everything better. And you're working within an old mindset culture that's refusing to change. I mean, I think the better success story there would be to get that culture to change and be a leader in that change. But if you just, if there's no movement and no support to get it done, you know, don't give up on the idea, go somewhere else. There are plenty of places out there that are embracing this culture and go to them. And on the flip side of this, I mean, we know there are people and companies probably that are just not ready for change.

And we don't know how long they will be around. But what I've also seen for the people that don't want to change instead of being an obstacle with those teams that want to change you know there might be an opportunity for you to go also to a company that still fits your more traditional mindset um and i know i have this discussion a lot with mark whom i'm sharing uh the office today uh where he says you know there are some people where the change is not the right thing for them and maybe they are they're comfortable they're too comfortable where they are and maybe they just want to find a place where they can you know kind of slowly you know age out let's say that way yeah yeah yeah yeah and i think we have enough of those companies or environments and maybe maybe this fast-paced agile is um i don't think it's the right thing for each

and every company without um without exception in the entire world so i i don't believe that anything applies always and everywhere um that means there will always be some companies in my now i say always but there will be some companies probably for for whom a slow-paced um business is an advantage so that you don't change too fast in the wrong direction and that you don't follow short-lived trends too fast and maybe that's the right place for those people then maybe it's the right place for me at some point of time in 30 years or something when you're ready to age out when you're ready to age out right i got five years to retirement yeah and uh as you said you know for some of these companies maybe i guess it depends on the customer base and the product that you deliver right you may have an industry or products that you deliver and you want don't want to freak out your end users of changing too frequently. So interesting.

But one more point on that, though, I'm not going to belabor the point and say, and be fanatical and say, yes, it is a fit for everybody, because I do agree with you that there are cases where it might not be a great fit. But I think a lot of companies who might think that it's not a fit might not be, it just might be a fear thing. Because if we think about what can't change, what has to be rock solid, and you take a look at, let's say, the banking industry, right? There's the idea if anything screws up in the banking industry, it's going to be chaos. There's going to be huge money loss by the bank and all, right?

You would think that the banking industry would be one where they would not want to necessarily adapt, right? However, as we've seen, they're embracing it tremendously to great payoff. So I do think the caveat to the idea that it's not a fit for everybody is, it's not a fit for everybody so long as you've done a real long, hard look at the pros and cons of it. And it's not just a, well, we just don't want to change. And that's the reason we're making that decision. But I think for the banking industry, I mean, they have to change because they – I think what I learned in a recent presentation since the financial crisis, there was some deregulation or some changes in regulation which allowed a lot of new tech startups and fintech startups to come up. And they basically produced better services faster for the very lucrative things that

banks are offering. So they were eating away, I think the term that was used in the presentation, so they're eating away the golden nuggets for the banks. And so the banks that are offering, that have been around for a long, long time, they're offering a lot of services and these golden nuggets are eaten away by these new startups. And obviously that leaves the banks, if they don't change, to only those services that are not that lucrative. But they still have a lot of staff and whatever else to support. So that's why I believe banks have to change. Otherwise, they will be—

I just mean that I'm using them as an example of when you might have thought before all that would be one that would change right there's always there always might be an opportunity and i just think it's important to evaluate whether or not it makes sense and if you if you go through a full-on analysis and say no this doesn't make sense because the risk is too high well then you then you may you know you have your case and you can continue with where you're going but just don't just turn a blind eye to it is all I'm getting at, really. Yeah. No, I haven't found the one where I'm super sure. The ones that I have in mind are more maybe medical equipments

or what I could think about as well. I would be a bit more hesitant to do propaganda about deploying every commit into a flying airplane, possibly, or something like that. So there I would maybe also be a bit more conservative not saying that that traditional waterfall uh one-year release cycles are the way to go there but but it's it's what i'm proposing here is not a silver bullet either right yeah um so finn i would actually love to talk about another topic in more detail which is the feature flagging and how that works and how you start it.

But I was wondering if we should wrap up this episode and make a shorter one on actually some of the technicalities on feature flagging, how to start lessons learned. Because I think that's a very interesting topic. Yes, I think it's a very, very short one, but maybe it fits better in the different episodes for the people who are really interested yeah yeah all right so before we before you summarize i just want to tell finn that this will not qualify you for number for number for number three because i guess so but we're doing it all in the same sitting session right so it's all the same sitting session so don't get excited you're like yeah let's do another uh so andy do you want to go ahead and uh summon the summerator let's do it Sure. So here's what I learned today. And again, thanks, Finn, for taking the time

and talk to us. But what I really loved about your presentation, also what you said today, is quality, the way we used to understand it, is not just about testing and being an obstacle in a faster becoming process. Quality is really something that we have to spread across the process. So we as the quality aware people have to talk with the business side, with the development side and obviously influence the testing cycle. But really from transforming from becoming a potential bottleneck by just doing testing of something into providing a service to everyone

that is involved in the process to think about quality early on, both from a technical perspective and the code that we write, but also the features we deliver to our customers, building the right thing with the right quality. And people that have been traditionally in the quality role, I think have a great role to play here. And those that are ready for the change and, you know, are willing to work with the business side and with the development side, I think they have a great change, a great chance to change companies in a positive way to build better software with better quality. And my last thought on this is, you know, in a similar vein that, you know, quality, if you're in that quality role, there's a lot more places you can go, a lot more ways you can think. And you can start thinking outside of just the quality of testing and look at the entire process from end to end and try to think where else can quality be inserted, right?

Are the feedback loops, do those have quality? Right. Our own, you know, our own setup over in Austria, we have a team who their product is the pipeline. So you could even then say, well, are we thinking about quality in the pipeline itself? You know, get on that team. So it's a never-ending cycle and the opportunities to level up and expand that role are fascinating. Like Finn, every time we talk with you, I'm fascinated by your job because I don't get out to the speaking circuits really very much. So I don't know how common what you do is, but I'm just absolutely fascinated about hearing what you do when you go to places. It's an amazing kind of a role. I wish I heard more examples of other people doing it, but it kind of highlights where you can take quality. And I think that's really amazing. And thank you for coming on and sharing with us today. Thank you as usual for the invitation here and your hospitality yes all right all right so let's roll over yes we'll be back people with another episode

uh thank you for listening any comments or questions you can tweet us that's it that's the word i my coffee did kick in um so you tweet us at uh pure underscore dt or and i won't say grab Neander this time that was a make I keep on thinking about Grabner Andy or Emperor Wilson or Finn you have and you have www.lor.ber is

Finn's website a lot of basic stuff you can find the slides here we'll have a link Finn do you also tweet and all that yes at Finn Lawbury we can maybe include it as well slides here we'll have a link finn do you also tweet and all that yes at finn lawbury okay that's the that's we can maybe include it as well yes we will all right excellent thank you everybody thank you thank you