Quality Bits

DevOps Ideology & Testing in DevOps with Jani Haapala

• Lina Zubyte • Season 2 • Episode 11

Share episode

What is DevOps? Is it just continuous releases and speed? How do we test in teams embracing DevOps?

Jani Haapala is a DevOps Architect with a Quality Consultant title. In this episode, Lina talks to Jani about that fluffy word of "DevOps", the misconceptions about it, and testing in DevOps. You'll learn more about the concept, get some stories on what good quality there looks like, and gather further resources to deepen your knowledge.

Find Jani on:

Mentions and resources:

Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases

If you liked this episode, you may as well enjoy this past episode of Quality Bits:
Cloud, Infrastructure as Code and Testing IaC with Daniel Mohacsi
https://www.buzzsprout.com/2037134/11743019

Follow Quality Bits host Lina Zubyte on:


Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.

If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte

Thank you for listening! ✨

Lina Zubyte (00:05):
Hi everyone. Welcome to Quality Bits, a podcast about building high quality products and teams. I'm your host, Lina Zubyte. In this episode I'm talking to Jani Haapala. Jani recently gave a talk about DevSecOps and he really is into DevOps topics as a Quality Consultant. So I thought it's a great chance for us to talk about DevOps, what it is, what misconceptions we have about it. Spoiler alert is that you are not going to learn how to build a perfect pipeline, but you are going to learn more about this philosophy or ideology as Jani says, enjoy this conversation.

(00:57):
Hello Jani. Welcome to Quality Bits.

Jani Haapala (01:01):
Hello, really nice to be here.

Lina Zubyte (01:03):
Could you shortly introduce yourself?

Jani Haapala (01:06):
Yeah, my name is Jani Haapala and I come from Finland, actually a small town close to Helsinki called Lohja, and I work in a company called Gofore. We are a consulting company doing digital society and intelligent industry related consulting, and that's kind of my daily work also related into that area. I think that my title is just quality consultant, but I'm mainly focusing on these intelligent software development processes, new methods like DevOps and Agile. My daily work is about doing everything related to these DevOps processes, helping coaching our customers, assessing customers, and doing this actual thing.

Lina Zubyte (01:51):
So you're a quality consultant, the most fluffy title likely that you get. I enjoy that you actually explain what you're doing, which I think is adding an extra level that it's not just testing that you're doing right, you're helping out with different parts like DevOps.

Jani Haapala (02:09):
That's actually one thing why I love my title because that doesn't really tell anything. It's just some quality related consulting. But yeah, I have taken such a passion in the DevOps, so I have honed my skills towards DevOps and agile and that actually seems to be quite effective in many places. So customers are quite interested about those things also.

Lina Zubyte (02:32):
I also like the role of a QA and having something like "quality-something" exactly for this reason because you could go to many different directions and one of those I always saw as a possibility is something like infrastructure or DevOps. It's not only product or programming. There's so many different areas here. Talking about DevOps, what is DevOps? Let's explain it as if there's a kid who needs to understand it.

Jani Haapala (03:03):
This is like a continuation, that really fluffy thing. I think that DevOps is one of the fluffiest thing currently in the market because it means so many things for different people. And then too often I hear that being DevOps means that you have CI/CD or Jenkins or these kind of things. But for me, most of all DevOps is a philosophy or ideology, how to create these world-class products and that's something that means most for me in DevOps.

Lina Zubyte (03:32):
And how would you create a world-class product using DevOps? What does it mean?

Jani Haapala (03:38):
DevOps is actually really interesting because DevOps itself doesn't bring that much new. It borrows so much these philosophical things from the previous ideologies and to really know about DevOps I think that you should investigate lots of more about these previous ones. There are, for example, extreme programming. Extreme programming has given us, for example, pair codings and pair reviews and there's lean and agile. I think that most of people nowadays know what lean and agile has brought us. Then is also this Toyota production system is quite strong there. So this conveyor belt thinking that how to make things in a conveyor belt and how to stop the belt if there's problems. And also this theory of constraints is really big base ideology there. Eliyahu M. Goldratt's favorite child and also systems thinking. And I feel that when we combine all of these things, the learnings from these previous ideologies and implement those in the focus of dev and ops, then we get to the root that what DevOps is.

Lina Zubyte (04:47):
And just for the listeners dev is development, ops is operations.

Jani Haapala (04:55):
This is what happens when you live too deep in some things. You don't remember to explain those terminologies.

Lina Zubyte (05:01):
Yeah, abbreviations sound sometimes really scary but it hides very simple concepts very often. So I think the DevOps in general was about connecting development and operations even though maybe it should have been connected overall and good teams anyways were connecting it without a specific word for it.

Jani Haapala (05:21):
Yeah, the original author said that it's the kind of main focus is to breaking siloes. So bringing people together and making them work together and they actually, I listened one podcast from them and they were joking about this old joke that when developers are making code it's like having a cat. The cat is alive and then they're throwing it around the fence and then ops are seeing that the cat is dead and saying that the cat is dead, but devs are saying that no, it was alive when it left here. So I mean when we break that silo there and remove the wall, people can see that what is the real situation there. And I have understood that that's quite a situation that have been quite long time in the field that they are, especially developers and ops people are working in so strict silos that the communication is almost nonexisting there.

Lina Zubyte (06:07):
Yeah, when I think about DevOps, I think of that infinity kind of loop and I think of Dan Ashby's visual as well that we test everywhere. And when you explain it this way that it's collaboration, it's dev and ops. I would also say that you could add likely everything in this. Then you could say, for example, you had to talk DevSecOps.

Jani Haapala (06:31):
Yeah.

Lina Zubyte (06:32):
Could you have DevTestOps, DevSecTestOps, DevAccessibilityTestOps?

Jani Haapala (06:39):
You could do that and you can even try that, but the abbreviation gets really long if you had everything important there. I mean nobody can remember anymore that what was your ideology. And then testing is actually really interesting. I think that's not mentioned in any place in DevOps even though it plays a huge role there and has a huge responsibility for the whole ideology. You mentioned Dan there and the blog post that Dan had, it was really interesting and Dan was arguing that if nobody's talking about testing and if testing is not seen in any place there, should we even do testing? But the kind of real answer to that was that obviously yes we need to do testing, but in DevOps the quality should be built in. So you should be doing testing and having feedback in each action that you are doing there and what would be better way to get feedback than to do the testing? So that's why the obvious answer to that question is that no, we don't need testing as a phase anymore, but we need to do testing in all places when we are doing any kind of actions.

Lina Zubyte (07:44):
And how do we balance testing which frequently could be understood as something that slows us down, right? We are getting some feedback with a methodology or the way of working, which is so much about speed and just delivering, so how can we make sure that we both test enough and we also deliver that it's not slowed down?

Jani Haapala (08:10):
I think that testing also needs a bit rebranding because quality we see as a virtue, but testing we see as a burden, but we need to somehow start to think more that we are not doing testing but providing feedback and assuring quality there. And then you asked that how to balance that, how much to do testing? I don't believe in any coverage metrics at all. I think those are really bad. I don't believe in having a hundred percent coverage, but I still believe that coverage is a good tool for the developers and teams to see that where the testing is happening. But all in all to not sacrifice speed, I would say that the team needs to do that much testing that they comfortable of making changes because this whole quality assurance should be a safety net. So it should provide a safety net for the people working on the team. So whenever the team feels that they are really secure and comfortable making any kind of changes for their application, then I would say that there's enough testing.

Lina Zubyte (09:13):
I think a lot of people when they think of CI/CD or DevOps, they imagine these Amazon examples that they push code to production every what, 15 seconds? What was the second count? I'm not even sure. And they get scared because some companies maybe they have regression cycles that are run manually. It takes two weeks for them to launch something fastest and then when they get compared with some company that releases now, releases now, then they're like it's unachievable. What could be the first steps for any company wanting to switch from quite long releases to faster ones?

Jani Haapala (09:57):
Yeah, I would say that you need to first visualize your work and then you need to kind of see on the paper that what happens when you're doing the release, what things are happening and on what time and what place. And then maybe utilize this Goldratt's theory of constraint methods and understand what is the thing that prevents you most of being faster. There's really cool quote in one agile book about improving this flow and they were explaining the flow like a river and you reduce the water amount the river constantly and whenever you see a rock in the bed, you remove the rock and when the flow is really narrow and you don't see rocks, then you can put the whole flow back to the river and then you have ensure that it actually flows the water there. So I mean in the same way I would say that in every system you need to first understand that what is taking your back in your work and what is taking time in your work and what is something that you might be able to remove from there and then gradually ramp it up.

Lina Zubyte (11:00):
I like the idea of small steps. I also always try to maybe reduce the noise that we have in order to understand what are other things we could improve. And sometimes during a tiny change there may be people saying, oh no, this means this and that. And I'm like, it's okay, let's have a conversation when this happens because it unravels some different problem that was there and that maybe hinders us a little bit or makes us slower because people just got used to it And then changing it is also, it's really challenging actually sometimes to uncover some of those bottlenecks and tackle them because people are used to it and then it's like what, it's no longer there. How will I work? And they get a little bit resistant. How would you deal with the change or resistance?

Jani Haapala (11:53):
Yeah, I would say that like you said already, the small changes. I mean if you try to introduce too big change at one time and then you were mentioning this Amazon's example, if I remember correctly, they were doing many thousand commits per day in the repository if you like, for a company doing releases, let say once in a month or once in a quarter. If you go and say to them that Hey, you need to be Amazon now do 2000 comments. I mean nobody would like to do that. So just like you said, do this gradual small experiments and through these experiments learn something constantly. I mean the kind of end result that you would like to get is not the goal there. The 2000 commits, I think that the thing that you want to achieve is the learning during your journey to understand what you're doing and how you're doing. It might not be even possible or even a wanted thing to have 2000 releases per day, but just the learning is the most valuable thing.

Lina Zubyte (12:52):
I also think it's nice to just gather our progress because sometimes looking at some companies that are doing much better, it gets demotivating. You're like, we're not there yet, but when you're like, okay, a month ago we would release once in three months, now we can release once in two months, that's a big improvement. And sometimes those changes are really small and maybe they're not even about the release speed, but something else that in the team we had a huge noise in our Jira workflow or something and now we reduced it and now I know what I'm looking at at least and then I'm faster because of that. I think it's very, very important to celebrate these things. You said that you don't really like certain metrics like numbers, right? Going for the numbers. What could be celebratory nice metrics to use when you're approaching DevOps philosophy and you would like to sort of measure your progress? Are there some that you would recommend?

Jani Haapala (13:59):
Yeah, that's really interesting question. I am a measuring guy, so I really much love numbers, but not all kinds of numbers, like the coverage number, but what would I measure?

Lina Zubyte (14:13):
Yeah, usually it would be like Accelerate's metrics or DORA metrics which are what cycle time, time to recover, change, fail percentage...

Jani Haapala (14:23):
For the company, not doing anything like that, I usually feel that that's still too much too early. I mean those are really well-defined.

Lina Zubyte (14:31):
Yeah, you cannot grasp them very easily either because some CI tools may have it but most don't.

Jani Haapala (14:39):
Yeah, and there are lots of assumptions behind of those metrics that you need to work certain way to get those metrics and you need to do things certain way to get those metrics. But I would maybe start from these three pillars that the DevOps, I mean the basic pillars I forgot to mention is the ideology pillars are: flow, feedback and continuous learning. So I would maybe measure those. I would just measure that how much our delivery speed has improved, how fast we can put something in the production and also feedback that how early we get feedbacks, let's say that they have failure so we can measure that how fast we can notice that failure from when the code was created or learning so we can measure that how many experiments we are doing and then what we are learning from those. We actually in one customer case, we actually had the celebratory party when we failed because we now learned one thing wasn't the right solution for that. So basically we celebrated that we found the wrong answer to the question and that was then one answer less defined in the future. So I definitely feel that we should always celebrate the failures also if we are failing fast, of course not if it's taking one year to fail, so that's not good thing.

Lina Zubyte (15:52):
Yeah, I like the idea of celebration a lot. Do you have any examples of how timely feedback has positively impacted product quality?

Jani Haapala (16:03):
Not maybe an exact example. I think that whenever you can see something before it happens, it's a good feedback, but if I need to pick one, I would say that the most interesting cases has been when this feedback has changed the people's mind and changed the product so that let's say for example, we were developing web shop and always it was like a huge ritual to get ready to the Black Friday sales. But when we got into the mood that we for example added all the testing, performance testing and these kind of things to our flow, so basically we were always testing these things and we were always understanding how the product scales and so on. It wasn't that much a big thing anymore to have the Black Friday, it just came.

Lina Zubyte (16:52):
I think this is an example of how good quality very often is invisible as when something is bad, you notice it immediately, but when it's business as usual and it's good and it's functioning, you're like, okay, nothing bad happened. There were no alerts, nothing.

Jani Haapala (17:09):
And I think that the contrast has been even bigger in this intelligence industry side that I have been like, let's say that you have some physical control boards and if you make a mistake, it means that you need to refl all those cards maybe in the field and that's a huge job. But when we start to notice those problems, we notice the problems before we need to put the software even in the cards or we might actually have that mindset change that what if we make that card updateable through web or something like that. I mean the customer experience would be much better. We can release much faster and we can also gather the feedback from the customer so it's even bigger contrast in this physical world. I mean it's easy to do this in the website mostly because it's just bits in the cloud, but you actually can also affect the quality of physical hardware during this thinking.

Lina Zubyte (18:01):
Yeah, I think that's a very nice example that everywhere there's feedback loops, whatever product we have, it's not just software. I guess those ideologies have so many thoughts and ideas we can apply in every field of our lives. What strategies or tools do you recommend for fostering collaboration between development, operations and let's add QA teams? Any other extra teams?

Jani Haapala (18:27):
First of all, I started to think that why those are different teams.

Lina Zubyte (18:32):
Oh yeah, sorry... DevOps!

Jani Haapala (18:35):
But I have to say that in reality that's still the reality. You can do DevOps things, but especially the ops is usually at least some part of the ops is an own team and also QA is mostly an own team and that's kind of part of the issue, but that's still the reality. That's true.

Lina Zubyte (18:51):
Yeah. I guess I would rephrase this question to collaborate between different roles because ideally would you say that those different skillset people are in one team and then how do they work together to make a great product?

Jani Haapala (19:08):
I mostly believe that we need to get much more collaboration and communication. I mean the communication is the one single hardest thing maybe still left there that people don't talk enough together. They don't get the same idea what should be done and when. But of course, let's say the QA in DevOps, a good communication means also test automation. I'm a huge fan of talking test automation to be not testing but runable specification. So if you have well-written runable specification, you at least can provide something to Dev and ops people to argue about. So they have physical thing to argue about and have different opinions and that's also a communication and bringing them together to care about same thing and have different opinions about it.

Lina Zubyte (19:57):
How do you see the role of a QA or a tester in a team? Is it the regular I check things that I testing column if we're working in DevOps or not?

Jani Haapala (20:08):
I mean they should improve a bit their role, the QA people themselves, they have been too much going into their own silo and focusing only on their testing. But like I said in the beginning that the QA is kind of the enable role for the whole DevOps. So I would love to see the QA people to rise into some championship role so that they are champions of quality and they help other peoples to see the quality also and to kind of think the quality in every place where they're making decisions. And that's like building the quality inside the product.

Lina Zubyte (20:42):
And how do you transition to that kind of QA champion from your role? Maybe testing kind of role.

Jani Haapala (20:50):
We somehow need to get the QA people interested about other things also. They need to take an interest about what does it mean to develop a code or what does it take to operate the code or for example, what does security mean? There are lots of things in the tech side also that are really easy to implement if you just have the mindset like don't put plain text passwords in any place or these kind of things. And that also hugely improves the security. To be a champion, I think that they need to take an interest out of those things and start to contribute on those.

Lina Zubyte (21:23):
So would you say that it's some kind of team responsibility to grow people into this role or you would rather see it as a personal kind of thing that a person by themselves could also do that? Because it could be you're in a team and then they just expect you to test and then you start asking about the pipeline and they're like, what are you doing? You should sit in your corner.

Jani Haapala (21:44):
That's really bad. I mean it would be interesting to hear from that team that why they want one guy just test because DevOps is about one team and usually our ideal team size is something like five to eight people. And if I start to list all kind of roles or things that needs to be addressed in DevOps, I easily get into 20 or 30 different kind of things. And if the developers are saying that out of these 30 things, the testers should only focus on one. So it means that the cognitive load on the developers needs to be huge then because they need to address the other things. So it would be really interesting to hear that dev guys don't want to share any of their burden to the testers.

Lina Zubyte (22:24):
I like this idea that it takes a lot of different things to have a team successful to build a good product and why don't we just share responsibility and maybe I'm interested in this and that and maybe someone else is like, I can do these things and then we can work together as a team and it's not a one person show.

Jani Haapala (22:43):
And there's huge amount of talent and knowledge in the QA people also and they need to use also same solutions. They need to create these containers for example. They need to maintain testing infrastructures and so on. So they already have huge amount of talent and knowledge that they could utilize for the benefit of whole team. So definitely, I mean that would be a really nice use case to utilize that knowledge also and share all the load that the team has.

Lina Zubyte (23:10):
What are some of the challenges you have seen, especially in organizations that want to embrace DevOps but something's not going as well as they expected?

Jani Haapala (23:22):
The kind of biggest anti-pattern maybe that I have seen is that we apply the DevOps in the dev team and only focus on the dev team. Then it leads to the situation that dev team is producing three or five times more stories. So testing gets fully clogged about new things they need to constantly test and test and test. So they don't have any time for growing the testing side because they just need to test more features. So they cannot experiment, they cannot learn, they just need to focus even more on the testing. And on the same time, the devs are just doing this bare minimum of the Ops side also. And ditching the ops guys, I feel that you can get it most wrong if you try is to start from the dev teams and let them lead everything.

Lina Zubyte (24:13):
How would you tackle this challenge? Would you just get everyone in one place or what?

Jani Haapala (24:18):
I think that right from the beginning it should be written down somewhere or agreed that what are the roles that we are sharing, what are the tasks that we are being doing? So QA people needs to also bring in the table that we need to do test automation. We need to do testing, for example, performance testing or any kind of testing we need to be sure about releases and those things need to be on the same table than any other thing. And then you just start to divide the responsibilities or the championship of those things and agree also that nothing is on one person's responsibility. I feel that devs should also test and then maybe QA people should also do ops tasks there or these kind of things, but it should be from the beginning clear that everything should be shared between the team because team owns the product team operates, the product team is responsible about the quality of product, not the tester or the ops guys.

Lina Zubyte (25:15):
I like this sharing of activities or actions that we do in the team because that can help us prevent this bus factor or that I get sick and that nobody else can do it. I think that is a very common bottleneck and maybe any company or team doing a transformation, they may catch this. Exactly. This is I think that we can catch as a first step even when the team is working and then someone goes on holiday and then they're like, oh, these got stuck. Why did they get stuck? We shouldn't wait for a person to come back from holiday to move our work. And even if they go on holiday, they should hand it over to someone else. We shouldn't just keep things waiting there. And that is a sign for us to maybe spread the knowledge or understand better what this person is doing so that they're not just the only person that can do this.

Jani Haapala (26:06):
That's actually one thing that comes for the championing of something. I would say that when we notice in the team that every time certain kind of action goes to one person, I think that we should name that person as a champion of that thing and prevent him or her to do anything regarding that. They can be only coaching and teaching and reviewing, but not actually doing anything with that. I mean, we should recognize that this is now a bad thing and you are the champion and you teach us to do that thing.

Lina Zubyte (26:36):
Wow. That is the opposite of the usual work in the company. If you're the champion, they're like, oh, you're so good, do that.

Jani Haapala (26:45):
But because in the beginning it takes more time and people are so shortsighted that they don't understand that in the long run it'll speed up things.

Lina Zubyte (26:53):
Yeah, exactly.

Jani Haapala (26:54):
I mean it might take one minute for the champion to do that and a couple of hours for others to do it or even days, and that sounds bad in the beginning, but then when this holiday comes, then all hell breaks loose.

Lina Zubyte (27:07):
And I guess here the extreme programming practices like pairing are extremely useful because then you can pair this champion with someone else who has a little bit less knowledge and get them to the level of a champion as well. Practice I've seen in some teams is a skills matrix where everyone would write out what they know, what they can teach, what they are okay to do with support and what they're a novice at. And then we can see who has what knowledge in the team. And in the long run we're growing the team and we're saying, okay, I don't know much about this. I should pair more on the tasks which are related with that and I don't need to do it alone so I can actually work with the champion or the person that has quite good knowledge on this topic and learn more.

Jani Haapala (27:59):
And I believe that pairing people, I mean it always means that both ones are learning new things. Let's say that you pair a developer and tester to do something. I bet that the developer is as scared as the tester about testing tools. Let's say test automation. It's a new language, it's completely new world. I mean if you ask developer to do testing or test automation, I really understand why the developer might say that no, because it means that he also needs to learn so many new things and so many new concepts. So that's a burden for the developers also.

Lina Zubyte (28:33):
It's a very scary thing to pair because people see what you don't know. And when we know something, we feel like, oh, everyone knows this. But actually no, not everyone knows it. I think one of the most surprising things in my career was when I was pairing with a tech lead during an outage to build a dashboard on what happened there. And I was so excited and the tech lead was freaking out and I was like, what are you doing? How are you doing this? I don't understand. We're having an outage. How can you be so calm? And I'm like, it's fine, let's see what's happening. And then I was like, wow, I'm useful.

Jani Haapala (29:13):
That's actually a completely new topic at all but I would say that the bad epics are mostly the reason because the ones that are writing the epics are feeling that everybody knows these things. I don't need to write them down. So this is just thing that everybody knows and then somebody else reads that epic and is clueless as to what's happening here.

Lina Zubyte (29:34):
Exactly. And I think us asking questions about it and saying, Hey, I don't really understand it, it also enables others to ask the same questions and not live on assumptions, which I think is a part of DevOps. It's a part of collaboration and communication, which is so hard. It's hard to communicate well as humans and then someone asking and say, Hey, actually I didn't get it. Could you explain it? It's very brave because most people don't ask. They assume because they're like, oh, I'm stupid, I don't get this, but maybe it's this. Let's take a look. And then they spend three hours trying to find something and then they don't because they don't know instead of just asking a person to clarify.

Jani Haapala (30:16):
And that's actually a huge thing in DevOps. I didn't mention it earlier, but psychological safety is something that is really big theme in DevOps. They're usually mentioning it with postmortem. So let's say that something bad happens, so don't blame anybody about the incident. But I would say that as a big theme, this psychological safety is also a huge thing. So it's safe to ask these questions in the team or safe to try something out even though you feel that you don't know things. So teams should always be helpful for you and teach you and guide forward. So that's a huge thing in DevOps. Also in the ideology.

Lina Zubyte (30:55):
I think I like the most, the teams that are humble and ask lots of questions because otherwise, I dunno, I feel like I'm the stupid one, but when everyone is very open, they're learning something that they don't know things, I think it's such an amazing growth environment and people actually learn a lot.

Jani Haapala (31:14):
I have this one colleague that I used to work with and he was the guru of our team having huge complicated tasks and I was then training how to code and these kind of things. And whenever I got a really tough story and ask a question from him, he dropped everything that he did and he could spend the whole day with me explaining those concepts and getting me forward. I was like, wow, that was the biggest contribution that the guy gave for the whole team because he was always willing to help and always willing to explain these things and the team learned so much.

Lina Zubyte (31:49):
That is definitely something that we all should appreciate much more the learning and these people that help us learn. That's an amazing sign of a team. Talking about learning, what are the resources, blogs, I dunno, YouTube channels, podcasts, whatever you would recommend for people wanting to learn more about DevOps?

Jani Haapala (32:12):
I would mostly maybe recommend reading some books. I'm bit reserved about all the material in the web from DevOps because like I said in the beginning, the DevOps used to be so many different things. People didn't have good idea that what the DevOps is, and nowadays people are trying to twist the DevOps into their own needs and saying that this is DevOps because of something like Scaled Agile framework is saying that DevOps is this because it fits into our process like these and these kind of things. So really reading this DevOps handbook or digging deeper into these philosophies. For example, this Phoenix project, it's a really good book or this Dr. Goldratt's "The Goal", those are the foundations for the guys who wrote the DevOps handbooks or those two books they read first and then they decided that yeah, we need to write the DevOps handbook. But of course there are good blog sites also on the web. So I usually read something like Medium or DevOps.com or the New Stack. There are quite good blog posts, but nowadays to write the blog post, you need to argue something or have a radically different opinion. So that kind of takes something away from the philosophy I feel.

Lina Zubyte (33:24):
Thank you so much. So to wrap up this conversation and the topics we've talked about here, what is the one piece of advice you would give for building high quality products and teams?

Jani Haapala (33:38):
I would say that no matter what method you are using or what process you are using, everything always boils down to communication. So if you keep in mind that there's communication, collaboration, and cooperation and when those three things are handled, you'll definitely create the high quality products.

Lina Zubyte (33:58):
Wonderful. Thank you so much for your time, Jani.

Jani Haapala (34:00):
Thank you very much and really happy to be here.

Lina Zubyte (34:04):
Thank you so much for listening. If you enjoyed this conversation, please leave a review, subscribe, tell your friends about it. And until the next time, do not forget to continue caring about and building those high quality products and teams. Bye.


People on this episode

Head Shot

Lina Zubyte

Host