 Good morning. So let's get started. Welcome to our presentation. Our presentation is about how our team redesigned the old RESTL.FI from a corporate website to a user-friendly outward-facing portal. But the most important thing is that this presentation that we're now having isn't actually technical. It's more of a story of how the project happened. But the story is more from the human point of view because this project was made by humans for humans. So that's me, my name is Yonati Ainen, and I am from Finland. In Finland, we have all these crazy cultural things that you guys might want to know about. For example, awkward silence is more of a way of life than just an awkward silence. We are taught at an early age that if you don't have anything important to say, you don't say anything at all. So just keep it silent and it's better than just talk. Another funny thing is that when a baby is born in Finland, government gives them a box, cardboard box full of tools so they can get started in life. Actually, babies sleep in the cardboard boxes for the first months of their life. When I was born, I actually slept for eight months in a cardboard box. That's how my life got started. There are also other funny things or quirky things about the fins. The picture on top is actually taken from Helsinki. This was in the newspaper in Finland. The fins love their personal space. That's why we're so far apart here. I don't want far too near me. But that does not apply when we go to sauna, take off our clothes and just hang our skin to skin. It doesn't matter. That's the exception. We're given a set of rules to live by that you have to know and obey if you are a fin. Number one rule, if you want to be a true and a proper fin is that you must never, ever brag about what you do. So me standing here just talking about this project would be bragging in a Finnish book. So my passport will not probably work when I try to go home tomorrow. But what do I actually do besides come from Finland? I am a holistic agile coach. A scrum master and a goat newbie working with Java and JavaScript. I am also a very proud Houstonian. I work at Houston Inc. We are specialized in agile software development. We are Helsinki Finland-based agency and have 52 people working at us. We have done 140 successful project in our lifetime. About triple and me. I've been a triple user for a year and a half and this is actually my first time ever speaking in public. Me standing here with Bart would be like Luke Skywalker standing here with Jar Jar Binks. That's the difference between us. I'm Jar Jar. Me so nervous. I'm here with my friend Bart. I am the friend Bart. Hello, good morning. I am the odd one around here because I'm not Finnish. I'm Dutch. I work for the Amsterdam branch of jurid. And I've been part of the team as one of the developers that together with Jona revamped the entire rest of the ecosystem on the web. And my side of the story today will be how things like remote working and an agile approach helped us from a developer's perspective as you know to compliment her experiences from the client's point of view. I'm an engineer. I'm a nerd. I'm a coder. Name of what you wanted. I know a couple of languages. I like them. The differences, the similarities. They teach me a lot. I like solving problems with them. I love things like automation, testing quality assurance, deployments. It takes the pain away from a lot of things. It makes it a lot easier to do larger things with a small team, which is what we're all trying to do. I speak in public on occasion, as you might have noticed. This is a photo from the last Drupal Jam in the Netherlands, which is our national Drupal camp, basically. And my clicker doesn't work. See, now it does. And I've been with the Drupal community for a few years now. I've done some conferences in the Netherlands until a couple hundred people. I've helped with Drupal cons. I've seen a lot of different sides of the community of business. I'm the founder of the Dutch Drupal Foundation, when we, after a while, realized that having several thousands of euros go through private accounts might not be the best idea in the world. And step by step, we'll learn, we'll grow. And as someone who came to Drupal for the code, I pretty much stayed with the community just like the motto says. I'm also a mentor at Drupal events that basically means that someone who's been around for a few years who's worked on issues helps new people on board to an open source project. In our case, mainly during the Friday Coat Sprints at DrupalCon, so this Friday again, we've got a couple dozen people like this group. I think this is from New Orleans early this year, yeah. They come together, and next to the main sprints where hundreds of experienced contributors work, there is space for new people, and we onboard them. And not because we're not gonna teach them things like HTML and PHP, because they already know that. We're gonna teach them how to navigate through the process of contribution, of finding an issue, working on it, making a patch, writing a patch, reviewing other people's patches, implementing other people's feedback, and eventually getting to a working solution that will be included in DrupalCore. And it's an extremely rewarding job. Mentors at this DrupalCon will walk around in a purple t-shirt with the conference logo at the front. Give them a big thank you if they see them. They're all volunteers. If you are one of these new people, come to the Mentor Sprints on Friday, and we'll help you work on your first DrupalCore commits. And the button doesn't work again. I am also Adrian. We have offices in Finland and in Amsterdam. Really unfortunately Dublin is just over there somewhere. We were nervously looking for a solution last night when we realized that we reused this fancy, fancy picture from an older presentation, and then couldn't point a marker on the map for this particular conference. We've got offices. We started in Helsinki a couple of years ago and last year with me in Amsterdam. We've got a couple of full-time remote employees, and we've got a lot of employees who work remotely part-time, are on an irregular basis, which is partly what this presentation is going to be about, like our point of view on that. Anestel is, in this case, the client that you all know us with. It's Finland's largest operator of hotels, restaurants. They run entire chains on it, like one-off hotels. They run, I think, the ice skating arena in Helsinki that do a wide variety of hospitality business, and their web presence reflected that at the time. And because of the growth and the changes in the business model, they were like, let's consolidate these things. Let's modernize our web presence. And with that, I want to hand it off to Yana, too. Drag you down the rabbit hole. Yeah. So I was the product owner in this project, although I'm no longer with Restel, but I'm here to still talk about the project. So let's get down to business. A long time ago, in a galaxy far, far away at Restel, there was a war of the worlds going on. And when I talk about war of the worlds, they were actually worlds that were fighting. At some point in history at Restel, it was decided that having brand websites just wasn't enough, but they wanted to make it easier for the customer not to have hop from another site to another site to look for information. They wanted to build these brand distribution brands. So they created actual new brands, made a website, and then put in collected content from different brands. And somebody get this genius idea to name them after worlds. So there were a hotel world where you could book hotel nights, but nothing else. Then they were event world where you could look for events, but nothing else, a restaurant world where you could look for a place to go eat, but nothing else. And there were also Christmas party world, a couple of other worlds. So the world just, the universe keep on expanding. And at some point it was, the idea was good, but it started to turn on itself. The worlds were very siloed. They didn't communicate. They weren't integrations. So it actually was a sort of war because they were ripping off resources from each other. There were also the content chaos that came with the different worlds because you cannot fit a whole brand website into a portal. You have to take some of the information and leave something behind. So there were bits and pieces of information sprinkled around these worlds. And of course, that is really confusing to the customers. You get some of the information, but not all. So now you have to go to the worlds, to the brand websites, and to the other worlds. And suddenly you're really confused. And it was really expensive to maintain all these worlds, of course. So it was decided that the end of the worlds must come, the Big Bang. And it was decided that we would fusion the worlds into the new RESTLE.FI. So we had to take all of the worlds and smash them together into one portal. And the end goal was to have control content, easy to get information, and of course buy because of that. And the feeling of safety. When you buy from an online store, the number one thing that you have to make sure is that your customers feel safe. When there's no human contact, the transactions have to feel safe. And with Finnish people, that is actually even more important. Well, I was a new product owner when I took on this project. And from my point of view, when they handed over to me this is what you have to do, it felt like entering a battlefield. Like, looking at a battlefield where there's arrows going on and worlds are fighting. And what I just like to do when I get into this situation is that I define my strategy. So I took a look at it, what it was, what I had to do, how do I get there? There was a lot of rubbles because of the worlds. So there was baggage from the previous projects, but just don't mind the baggage, just don't mind the rubbles. Just go ahead, move forward. And the most important thing is that if you're a new product owner or new doing big projects, or I would say anything, just be brave and take on the challenge, even though it is really scary. Well, so great. Now we are looking at a battlefield, which is the project for me, but it isn't enough that there is fighting going on or arrows flying. There are always surprises when entering a battle or an adventure. And for me, the real surprise was that there was this big green monster, the gajira, meaning that I had the fear of doing this big, great project for the first time ever. And I think it is really important that you can say out loud the feelings that come with starting new monumental tasks or starting a big project. I feel scared, but you just have to push through the fear and be willing to cage the monster. You have to cage the fear in order to get things done. You cannot cage a monster by yourself, can you? Nobody can. You need a kick-ass sidekick, like Batman has Robin, right? So at this point of the project at RESTL, we decided that we need a partner who could do the smashing of the world together. And we started looking at different software companies, and we went through multiple good ones. They weren't better or some weren't better or worse. They were just, it was about when we sat down with the Druids, it was the first time ever, and it just felt right. They had the right attitude. The whites were right. They knew about Triple-A, which was one of the specs that the company had to fill that we wanted to work with them. And really important was that we wanted to work at RESTL with Scrum and move our thinking into a more agile way. So the Druids offered a training for the whole corporation. So the sidekicks were chosen, the Druids, yay. So going through a project or at the starting point of the project, to me it feels like when you go rafting a river, you are in the beginning of the river, looking at it, let's say an Amazon river, a big scary river that you have to go through. Like you have to go through the project. You have to get on that raft with your teammates and paddle through the whole hallway. And the most important thing, actually I have to say this painting that is behind, it's pity that you cannot see, but there was a laser pointer somewhere. But here is a bonfire and there are figures sitting next to the fire. And I will actually say that this could have been a picture when we started working, there was the bonfire, there were the Druids with me on the bonfire, I was sitting there and almost crying and they were patting my head, it's going to be okay. We're going to make it, we're not going to die. And I believed them and then we started the journey. And the timeline for this project was really tight, it was doable, but it was still really, really tight. So there were room for any errors and we had to know where we were going. There was also the thing that Restall had used to be working with waterfall method. I think most of you know what it is. And there were different departments and different sort of waterfalls. So we had to just paddle around those waterfalls or just try to sneak in and scrum to those departments. And the number one thing is that you have to trust your partner. If you don't form the trust with your partner, you just, you cannot make it through. Well, how do we get through this? I was a goat at this moment, that's like me in that specific moment, how do we get through it? Well, this is the TV shop moment. The solution, scrum fit. So as I said before, this was the first time that we started working with scrum and thinking agile. And it wasn't easy at first. Have you guys ever taken a break from working out? Yeah? All right. I did during the summer, I didn't go to the gym or running. And then I went back to the gym in the fall and I went to the treadmill and started running, like, yeah, I'm gonna get fit. And then I thought I was going to die. And I looked at the clock and I had been running for 15 seconds. So that is basically how it felt when I started working with scrum. But how do you get through that first burn and how do you get fit again? You just have to repeat it over and over again until you get more fit and can run more long distances. And it starts to feel natural, you know? You don't even feel that you're running anymore. And that's what we did with the druids. We just stick to this really strict form of scrum and repeated it, although it was, it was pain in the ass. Bart drove me crazy so many times, but I love you for it, Bart. But still, it was hard in the beginning. But after a while, we didn't even notice that we were working with scrum. And that's the magic moment when you can have cake, have cheat days. It is the same when you're working out and you're working with scrum. When it feels natural, when you're in a secure place with your exercise or eating right, you can have cheat days. You can start modifying the scrum process to your team's needs, just like you can eat cake when you're getting fit and you're in the secure place, the steady place after about nine weeks of working out. And you have to reward yourself. I want to remind people when they start working with new project framework that when you get to this point that you got it, you have to reward yourself and say, yeah, good job, have some cake. And then there were the last surprise. At a critical point of this project, it was a make it or break it moment. We got the news that one of our teammates got really, really ill, like ill as in we didn't know that would he make it to the rest of the project or not at all. And the first thing that I thought when I got the news was, oh my God, how is he doing? Can I do anything for him? And now you might wonder like, why she say that? That's obvious. Do you think about the person first, right? Well, actually that's when it hit me. If this would have happened to me a year and a half ago before I had changed my thinking to more agile way and working with Scrum, I would have thought a whole bunch of different things. I would have thought about the project, how, what will happen to this expensive project? I would have thought about money with my focus on surviving. I would have thought about my team member, of course, but it wouldn't be the first thing that I would have thought because I would have been scared what will happen to the project. But I wasn't afraid anymore. And that is actually the moment of enlightenment that I had. I was no longer afraid. Everything was under control. I had adapted a new way of thinking how change should be taken. If changes happen, it's natural. It's okay, just go with the flow. Isn't anything special? And that is like, that was the moment when I realized what this all was about. It wasn't about a project framework. Anybody can learn a project framework and do things in a certain way. But what happens inside your head, that is a whole different story. You can get yourself enlightened or just keep on working without changing your thinking, but you can benefit so much from thinking differently. And that is actually how you do it. We talked about battles where you need to be not afraid and we talked about the monsters, how it was a surprise that there was fear and how things changed. And when you're not no longer afraid, you can cage the monster, you can win battles, and you can get enlightened. And that was basically the moment that was really significant for me personally during this project. So does anybody recognize this? No, nobody? No, nobody knows what this is. This is the druid op, it's some days of the week. This is like, you get in, you look around, you're like, what the fuck is everybody? Is everybody still in bed? No, no, no, no, no, no. Someone is maybe sick. There's a whole team working at the university on site. People are working from home temporarily because they have to take care of their children in the meantime. We've learned, especially through this project because I was the first non-fin, like being at the office, but then the office in the other country, that what remote working and what a distributed team actually means for us. And that you don't have to have an office that is buzzing with people to be able to work together really well. So what it means to distribute is really just to spread out. You can, if you throw candy in the air, you distribute it. If you take a map, you put a few pins on it, like that's where our people work. It's distributed. It doesn't really mean a way of working necessarily. It means that you're not together. But it does mean that you have to have a different way of working than humanities classically being used to. Like we all show up at the office at eight, 30 or nine in the morning. We all leave at five. We have lunch together because between those moments, we all have to be at the same place at the same time. And we had to reinvent ourselves a little bit. We already employed some of these practices. We did more. It became more intense for us. And that's basically how we learned as a development team during this project. You can be remote or distributed for many different reasons from people actually living somewhere. We've got the three full-time remote employees, one of whom actually has a fancy pants office, shared with 80 other developers of other companies. People can be working from home because they just have a mandate. People can be sick, sick children, sick partners, have to run around, maybe drive their parents around in between work. They can have other appointments. Like, I'm not gonna go to office on that side of town. I have to be there an hour afterwards. This is the ways of my time. Up until the point where someone's like, I'm just gonna sit at home and work from there today so I can just do groceries and laundry because I've been forgetting that for the longest time. And that is fine. It doesn't really matter why someone works remotely. It's become almost entirely irrelevant for us because the point is, are you connected? Are you available where you have to? We've gotten to this point where we've got a way of communicating, or oh, I'll be, can I be out of the office for a few hours there and then because there's not. What needs to be done? Would I be missing anything? Might anyone need me during that time? And that's just like a very quick bit of communication between the team members to align, to synchronize, and then people go that separate ways. So our work days are not entirely lined up, but we do try to sort of align ourselves with each other to make sure that when we do work, we don't block each other accidentally, and we're available to help each other out, to mentor each other. Because we do that, we have these freedoms as development teams. So these are a couple of very, very old pretty Dutch windmills. This is where I came in. I was the weird foreigner who didn't speak Finnish, so even when things were written down on paper, I was like, that's not documentation. Pain in the ass, pain in the ass. It might be a nursery rhyme for all, I know, but it's Finnish, I have no idea what it is. So things had to change and everybody was fine with that, but we were trying to figure out how we were supposed to do this. We're becoming more international, we're becoming more distributed, and we're like, all right, let's tackle this. Like, what do we need? And we're taking this one step at a time. Like, if we need something right now and it doesn't exist on paper at all, let's start creating it. If it exists in Finnish, let's start translating it. And from that moment on, based on a needs basis, the company slowly, gradually started modernizing a little bit to the point where we have fancy wind turbines, modern, green, highly efficient. This is a nice picture also from our Dutch water management systems, in case the North Sea tries to drown us again. We were speaking about waterfalls and rivers and everything, that's how we do it. It's public domain, so you can copy it for your countries if you want to. But the main thing we learned is you have to modernize and essentially that means the things that you do, they usually have to be electronic. As I mentioned, you have to be connected, you have to be available. It doesn't really matter where. If you want to be on a semi-beach with a cocktail in your hand while working, if you have a kick-ass Wi-Fi connection and a wired connection back in the office a little further in town as a backup, you're fine, you can do your job. If you have phone reception, you can be reached. You can upload to Git repositories. You're available for people to help. If you have a quiet spot, you can do conference calls. So it doesn't matter where you are as long as things are electronic. Documentation has to be available electronically, discussions electronically, log things. And it works fine without that in many cases if you don't, if you're not distributed, if you're at the same office, you work to the other person's desk, hey, I'm stuck with this one thing. Nobody else in the company's gonna see that. Maybe three other coworkers were at the same time struggling with the same problem. So it creates transparency as well. It benefits more than just you and that one person you're talking to and working with at that particular time. And it's been a great move. It's been a struggle for us internally as well because it's quite demanding. People have to change workflows. You start to, you know, people start doing it the old way. You're like, no, I can't do anything with that. How do we change it? And it works through openness and collaboration and mentoring each other. We've achieved a state where this has become a second nature to us and a more modern nature than we had a year ago. Another thing is that this was our second big Drupal 8 project. And it was, we started working on it less than two months after Drupal 8 has come out on November 19 last year. We started January 6th. It was a kickoff meeting. And I think we started doing the first coat the week after, slowly. So it was really new. And I'm a core contributor. And then you haven't even seen all of it by far. And there were so many things that were Drupal 8, but you only see them when you use them in a client project. When you started deploying larger things, for instance, Composer was really new to us. We had multilingual issues at some point. Some bugs, some things like, oh, how are we gonna have to adapt our workflow? Like we used to do it like this in Drupal 7. So that was really challenging for us in a really fun way. But you also inevitably run into bugs. Like I said, Drupal 8 still is brand new. At the time it was just like right off the shell. There wasn't even a dust on it. But under this service, there are always a few things wrong here and there. That's fine. Where people work, things go wrong, we can't, we're not perfect. So what do we do? Like we need to fix them. But we don't wanna have the other team fix it as well. So you collaborate. You contribute to fix back to the project not only so the rest of the team can use it without having to bother them, because by the time they pull in the next Drupal update, they'll have, they won't even know that there was a problem to begin with. But you contribute. And we realize that all these small things that we encounter, these small problems, like there's a little bug here, there's an oddity there, or tiny missing checkbox here that would, a little toggle that would help us do what we need. But how does it make Drupal better? It's actually part of a marketing a bit, or a company policy, like we use this project, we wanna give back to it. But it also shows what we can do. It sometimes feels though that you're walking into a wall. Well, the people in Berlin sure felt like that a while ago. And this is an old African saying. I really like the German version of it though because of that wall feeling. And it goes, if viele kleine Leute in vielen kleinen Orten, viele kleine Dinge tun, können das Gesicht der Welt verenden. When many small people in many small places do a lot of small things that can alter the face of the world, you can do a few small things, and it has an impact. Drupal is installed on, of runs millions of websites. It's what I said with the mentoring earlier. The idea is that you, that you or you contribute a small fix, a small improvement, which will then be used by millions of websites. So how small is it really? You know, such a small change. How, how, like, put a chisel on a wall, hammer on it once. What if a thousand people do that? Wall's gone before you know it. And you have to collaborate. You can't do it on your own. We have an internal peer review process with the druid, so code is almost never committed or deployed without at least two druids looking at it, sometimes even more depending on the type of problem. And it's a very common process in open source software. You have, you have peer reviews in Drupal. There is a heart requirement that at least three people look at the code before it is committed. The original author, at least one reviewer, and then there's a core committer doing a final global review, and then that person commits it. But they can be like, nah, this is, this touch is such fundamental subsystem I want at least four people to review this, or I want those specific people to review it because they were the original architects. So the benefit of this is that if we want to contribute problems or solutions to problems back to Drupal, it's not just a way of distributing it back to ourselves and to the rest of the world, but we also benefit from this highly intense collaboration process that results in a high quality fix because if we do it ourselves, we might overlook something. We might not know that it is the right solution. We might think it is. Well, actually it has some side effect that the test didn't catch. So when we do it in public, yes, we open ourselves up to scrutiny, which is exactly what we want. We want someone to say, nice try, do it slightly differently because otherwise it's gonna break that way. Okay, cool. Someone has just prevented us from falling in that pit and potentially millions of other Drupal sites to follow, to get the same fate. You don't want that. All right. Guns, lots of them. Yeah, in every project, there is that one amazing, at least one amazing team night out and last May we had a discussion with the Druids that maybe we should take that time outside the project and go and just have some fun together because we had fun working together but still do something outside the project and workplace. So the Druids, because I was the client, asked me what do I want to do when I team night out and as a fancy lady, I said I want to go and shoot guns and eat good food. So we went to Helsinki Shooting Club and they indulged me with buying this amazing gun buffet thingy that we went shooting with. Dero, if you're seeing this, thank you for the gold package. Yeah, thank you. That's Dero. And this is from the place that we went to eat and I have to say that it's rare to have such a good time with the people that you are working with or I've had worse nights with my friends that I have this team night out. It was really good because it included people that were only sideways involved in the project as well, both from your side and from our side. The core team, the people that we work with daily was what, five people? Yeah. And we went out with eight or nine, some support staff on her side, on our side and you get to know the whole group of people. It explains. You get to know people like, oh, you're the person we've been emailing with. Now I get also what your requests were about the way that people ask things. It's even though we were a remote team for the largest part, that was really good because you get to know people so much better. You can anticipate how they will respond. You understand the responses so much better. Which I think is if you do work remotely, this is one of the requirements. Yeah, you discover shocking details about your coworkers. Like many daily conference calls do a lot of things, but yeah, the shocking details are usually left out of the office. So on a wonderful, wonderful Monday, June 20th this year, after a long night at like two, three a.m. at night, I went to the veranda of the house, the friend's house that I was staying at in Montreal. Not really to enjoy the sunshine, but it was the day of our lunch, so. So I was there enjoying the Montreal sunshine until the rest of the team came online. And I was thinking, oh, this is actually hilarious. Just goes, where the hell is Yuna? She was doing grocery shopping in Hong Kong at the time. Yeah, should she mention the good food? And I'm like, all right, all right, we know where she is. Has anyone seen UC? Where? Where is UC? UC was up in Northern Finland in his holiday cabin. Like, all right, shit, what if that goes wrong? Well, UC was connected, UC was available, so not really a problem. And someone might as well stare at a lovely, beautiful lake and enjoy the birds chirping, right? Because if something goes wrong, a bit of therapy in the background is usually helpful. So because we'd learned to work together remotely as a distributed, semi-distributed team, we learned to coordinate. We learned to work together remotely. We planned things in advance. You tap the rep person on the shoulder when you're done. And the process goes really smoothly at that point. You don't need to be at a desk to do something that could be as risky as a lunch. It's worked fine. We knew what we were doing. When things went wrong, when things were unsure, we knew exactly who to contact. Everybody was available. And then that resulted in the launch of the new Tesla website. That for them, as an organization, marked the start of a change in their business model, they could do the things that they really wanted to do now that they had to do. And we've seen a massive increase in people booking hotels and restaurants, going out for weekends away with partners, because we launched a nice product together. And that is really satisfactory. Even at 6 a.m. in the morning, when your deployment has finally ended and you're like, I can go to bed, which is the most awkward thing to think. You haven't come home from a bar. You're going to bed when everybody else is getting into the cars to get to the office. But it's a good feeling. It's great. We've loved working together with Rastel. I think one of the nicest things is that when we've been really open to each other, that we've admitted mistakes. We've stopped pointing fingers. We've started looking at the problems, like, okay, as things that need solving, that we need to learn from. We've learned what the other people learned, like how this was for them. We've changed our workflows based on how we've seen clients do things. And it has made us a richer team. It has made us appreciate communication a lot more, like clear communication, caring for each other. We've had a lot of sicknesses from a couple of days to long term, as described. And we've remained human. We're not distant. We're just physically away from each other. This is the end of our slide deck. Depending on you, it's the end of the presentation. If you want to look us up, these are our Twitter handles. Do you have any questions about our experiences? Which gun did I like the best? I liked the biggest one, but I could only shoot the smallest gun because the noise was so loud that I couldn't handle the big one. But I liked the big one the most. It was the best. Actually, the smaller ones were quite nice. Yeah. That was also really fun. I mean, the big one's quite nice, but if you're down there with sweaty hands, it's a kind of, if you haven't been to a shooting range, a decent shooting range that's not outdoor in the middle of nowhere, tends to be underground and you're surrounded by a lot of concrete. So it's kind of a bunker. And this particular one was sort of a bunker inside of a bunker. Inside of a bunker, yeah. So I'm not sure what invasion they were still afraid of, but so if you're there with these long gun and sweaty hands, like I'm not training this stuff, but the smaller ones tend to be a little bit more fun at that point. Yeah, yeah. And the food was delicious afterwards. So you forget the noise. The music was surprisingly soft. Later that night. Yeah, yeah. Yeah. Very good one. We use FlowDoc as a team chat. We recently migrated to Slack. We really miss the FlowDoc threading features we realized. And it goes all the way to things like WhatsApp, SMS. Hangouts. You hangouts for conference calls, even one-on-one calls. We pick up the phone. Like, oh, shit, I need to talk to this person right now. It's a difficult problem. So having a richer medium to describe something that you're not even sure how to ask, pick up the damn phone and call that person. Roaming charges in Europe are increasingly friendly to people. So it's very accessible to just pick up the phone and call someone. Here's someone's voice. If someone sounds like they're having a shit time, pick up the phone. I've worked in offices where you're like, should I ask this person how they're doing? I'm not entirely sure. If you're in the chat, you're like, all right, you could either be having a fucking terrible time and trying to throw yourself off a building, or maybe not, but I'll just try that call. I'll just see how it's going with you. Yes. Have you ever driven a car in the Netherlands? It's as smooth as driving a car in the Netherlands, like residential areas. It's quite nice until you realize it's full of speed bumps. So, yes, it was a fairly nice process, but yeah, it comes and goes in little steps sometimes. It was worse in the beginning, or worse in the sense that more important information was at the time still in finish. It hardly ever happens anymore. Even general meetings that I'm not a part of necessarily are just by default done in English. Notes are done in English. So, it's, yeah. And everyone can speak English, but are you beyond as a kind of prerequisite? Yes, well, she's kind of representative for the rest of Finland, so it's been, that part has been hardly a problem at all, I have to say. You had a question? Yeah. I think this is maybe for you, because Finland has some interesting multilingual things culturally. Yeah, we started out with the English, Finnish, and Swedish. We decided if we have time, we will put the Swedish version also out. I don't think that there were any problems, and after I've left Bristol, they have added Chinese and Russian also, so we have quite a lot of language versions of the customer portal. Well, Finland has, as Swedish as a second language, it's right next to Russia, so a lot of people coming in from there. There's a lot of travel to Asia, because it's more north, it's very well connected. So hence these requirements. From a technical perspective, it was a bliss to work with. The people who worked on the multilingual features did a massive job bringing it up, unifying all these features across Drupal. The problems we had, technically speaking, were mostly due to immaturity, like a bug here and there, and the, I think multilingual, we never really had any big issues that fundamentally badly designed multilingual support that blocked us from doing what we needed to do. It is the same website. The content on the website is just translated. So the system is identical, and it depends on the language that is picked, and it is picked based on several criteria. There's an actual language selector, but it depends on URL prefixes, browser preferences, and based on the language that is picked, you get a certain version of the content, and then the rest of the staff, they have editorial staff, they are responsible for the actual translations, and they very purposefully also sometimes choose not to translate a certain section of content, because we don't, this is from another department of ours, they don't target to a non-Finnish audience, so they just do it in Finnish and Swedish, maybe. So that's an interesting balance between also business requirements and doing it technically, but again, technically, we haven't seen any problems so far with things that Drupal didn't support that we needed to do. No, we used, for the interface, we used the default translations combined with custom ones. I think, did you hire translators? We had outsourced translators, yeah. But no automation other than pulling in the default translations from Drupal.org. I had a question. We, I think this is maybe, is Kareesa still here? Did he get out of the room? Kareesa is our designated big boy scrum master in the company. He has, he trains the clients, he is, I think he's also a trained product owner and all that. He sometimes checks up, like, is everything going? That's one of the things that we deviate from actual scrum a little bit with, that we don't have a permanent scrum master, semi-full-time on the team. We very much unblock ourselves. So, the slightly increased independence is one of the ways that we deviate from scrum. That's how we like working. It does require, it is a bit more intense because it does require that everybody's on their feet and recognizes this themselves. To support that, though, like, 80, 90% of the Druids are actual certified scrum masters. So they know about a lot of these things. They know what to pay attention to. So that's how we do it. Yeah, maybe we modified a bit, like the documentation was more specific. Although it isn't mainly about scrum, but we did more documentation on the stories and the grooming sessions were modified. So we modified, we kept the frame, but modified the ceremonies a bit to fit our distributed teams' needs better. I think the... To go back to scrum, actually, what you said in the beginning, like the intensity of sprints that you have to get used to it, you decided to go with one week's sprints from the beginning and we're like, oh. Yeah, I inspired in that way. You're like, well, we have all these uncertainties, we have other parties that we need to coordinate. Like, at this point, we can't commit to two week cycles yet. In the end, though, because you have so many meetings, it's so fast-paced, you really become aware of the need to time box it and that's why you start to understand why scrum harrows this, like, down, like you have to time box it. If your daily is, like, half a minute longer than 50 minutes, you're probably doing it wrong because at a scale like this, it becomes very clear that it does hurt you. It does, because long meetings, like, hurt morale. People start yawning like, oh, god, I have other shit to do because that person wants me to meet this deadline. It's part of what helped us do this in a much more fast-paced and intense way. Yeah, and we knew what we were coming because we had the weeks were all the same. The meetings were on the same time. We knew what the content was. So no surprises. We could focus on other things that just maintaining the process. It was just rolling itself and we were just doing other stuff, not focusing on the scrum process itself. We still actually have, in this project, weekly sprints, like, one-week sprints, even though Yona is not no longer a part owner of this project, we still do it because as she said, we got into this habit of being fit of exercising weekly in this case and it's just become automatic. If, for instance, due to sickness or something, like, we miss a couple of meetings, it's fine, we'll organize ourselves. There's another sprint next week. It's really easy to recover from the deviations in the scrum plan as well. But permanently? Yeah, well, I was the product owner, the dedicated product owner and, of course, we had the online team to people plus me who were a great help, of course, but I was the only one that was working on solely this. That was part of the fun of how that team made out and everything. We met some of the other people as well. Again, you have people in support roles on both sides. We have designers or info people. We don't need to set up servers every single day of the week. What scrum actually allows you to do, you pull in experts from outside temporarily. One of the things that the weekly sprints also turn out to be nice because it was much easier to plan them in for a certain set of time for a whole week, like a couple of hours every day because if you have a two or three week sprint, you just need them for 10 hours. Like, how are you gonna plan that in? Because you can't do it for the full sprint, so you have to mess a lot more with your schedule to get that to work. We find out. All right, then this is a wrap, I think. Thank you for coming. Thank you.