 All right, good afternoon and welcome to using Scrum Agile in remote development. So hopefully a lot of Scrum fans and remote fans. My name is Kasper and I've been working with IT as a DevOps and a sales engineer for around 20 years. I've been working with open source for around 16 years. I've been building sites, infrastructure, I've done sales and development training and so forth and I've been into Drupal since 2009. I work for a company called Xteam, we're very discreet down here in the bottom. We are a 100% remote company, we don't have any offices at all and we are 100% global. I want to thank you for coming and listening to this little talk. I don't know how many were the previous Scrum talk, let's keep fighting, that was fun. I brought an agenda, but I want to know how many of you know and all work with Scrum today by a show of hands. Okay, great. How many work remote? Oh, wow. Those who didn't raise their hand there who wants to work remote. Everybody wants that. That's great, fantastic. I want to just create a simple baseline where we all agree on what Scrum Agile is. The ones who were at the previous session will notice there's a few different opinions about it. What it is we need out of Scrum for doing our remote work, what are the advantages and what are the drawbacks because I also want to air some, not dirty laundry, but I want to make sure that you understand if you don't work remote or give you a big group park and say we all share the same paints and then if we have some time at the end, we can look at a few tools and everything I will talk about is super opinionated just so you know. So please don't throw too many chairs or rotten fruit. One disclaimer I will make is if I use the phrase, it's easy or that simple, you may storm up here and kick me or something, or you all beers or something because that's a huge mistake. And for the purists, when I say Scrum, I mean Scrum Agile. So everybody is on the same page. So what it is, the methodology, manifesto, the means to achieve greatness, I think if we try to break down the manifesto we can see where we can add some Scrum source and here we have it. Have you seen it before? You can just shout out. No way. Individuals and interactions over processes and tools. Wow, organically grown teams of individuals. I think it sounds really, really good. Does someone disagree? I heard someone who worked in an agile company actually know I disagree with the manifesto. Working software over comprehensive documentation, delivery, ship. If it works, that's great. Although I think that if we forget documentation altogether, we are screwed. I said a bit lost. We are screwed. Customer collaboration over contract negotiation. Who wants to do all those pesky and boring negotiations? We work together. I know everybody who talks about Scrum will say, meet up, get together. We'll talk about it. But we do need a contract, I think. There needs to be a little bit of legalese. But a few of you were the previous session. I won't go too deep into it right now, but it seems that sizing and scoping is quite a pain in many organizations. Is this going to take three months or six months? And I have no idea. Time tracking, hours, billings, all that. I can understand that the customer collaboration precedes the contract negotiation because if we're bogged down in this boring bureaucracy, we're taking away time from making great products. But we can go into that. Now, of course, what I think is the most important thing is that we are responding to change over following a plan. And that sounds a little bit like anarchy. But for me, what I get out of it is, let's get rid of the waterfall. It doesn't work. We have to iterate over things. So, I know a project never starts perfect. We do need to be adaptable. And Agile is for projects where we don't know exactly what the outcome will be. We know that there will be, let's say, a site and application or something. We don't know exactly because there's time and things will change under the duration of that. There's also deadlines that are defined as we go along because who hasn't been in a project where suddenly you get, yeah, you know, that deployment we have in three months, that's next week. That's putting a fine point to it. But things change from upstairs. And we do need to adjust. See, in a perfect world, every project starts out like this. It's all clearly defined. We know exactly what the product is. We know the responsibilities. That's for sure. Everybody is in place. We know the process. We know that when Joe hands it over to Emma and it goes to Tom, whatever, that's a clear as daylight for everyone. And we know how to measure it. We have our time tracking in ours and also for prevention. We know exactly what to do when something goes wrong, right? Well, no, of course not. And the manifesto does not cover this. There is nothing. We have to define that ourselves. Or we can add some scrum sauce. There was a lot of hands up. So all of you know this, right? Yeah. You know the backlog, the sprint backlog, or the other artifacts, a team scrum master product donor. That's all totally clear, right? Yeah. No one disagrees. And the ceremonies, we all have that. Stand up, grooming, retro, et cetera. Anyone does anything else? You have your measurements. I mentioned story points, burn downs, et cetera. So that's a great thing. That actually helps us in our day-to-day work. But it's a framework. I don't think that too many who talk about scrum actually mentioned this. This is really, really important for me. It is something that we can add to. I won't say change, but we can add to it. And if we're really, really good, we can, in fact, also change it. In a project I'm in right now, we have several different backlogs. That's not very scrum-ish, you could say. But it really helps us. There was a question about, how do you do support in scrum? Scrum doesn't cover support. Well, we have all our support in a different backlog. We have all our technical depth in a different backlog. We have improvements that derive from the developers in a different backlog. And that will then eventually make it into the sprint backlog. The roles, we have release management. Also, that's not a scrum role. We have QA. QA is a huge part of it. It's very, very important in our project, but it's not really a defined role in scrum. And one of the last things we did was, to the ceremonies, we added a developer checkpoint. Because our stand-up is a lot of people, all the stakeholders, all the product donors. It's a large team. So we wanted something. You don't talk tech on a stand-up. It's what did you do yesterday, what are you doing today, and what are your impediments? And the more technical stuff we have at a separate ceremony. But it is a ceremony. It's not a water cooler thing. So it is scheduled. Scrum talks a lot about the team. We have the roles as the team. The other individual roles are the scrum master and the product owner. And I like it, but a team is also made up of individuals. And that's where I see it really becoming very, very important when you're doing remote work. I will say again, we are 100% remote. We're not distributed. It's not like an office in India or something like that that you hear about often. It is people spread out globally. And everybody may have these challenges. But I think that when we work remote, it becomes more apparent, much more apparent. And it is defining proxies and goals. And when you do it organically, you can't have corridor talks about this. You can't have informal sessions where you just sit around and talk about it. I was at another session where they talked a lot about, I think it was T-Breaks, a UK company. I won't hang anybody to dry so they can come slap me. But I disagree that you have to have all these meetings, meetings, meetings, meetings, especially when you work remote, you have to define who are the product owners. They will then do their job. The scrum master do their job so that the developers can do their job. This is what I think signifies remote developers. This only works if you've seen the movie. So hopefully you have. Anybody don't recognize this guy? He was a freedom fighter a long time ago. Braveheart, I can go all violin and say I think remote developers are a little bit of the freedom fighters in IT today. What I think remote developers tend to be like, especially the ones I work with, because those are almost the only ones I know, is that they are extremely skilled and competent. And both the generalists and the domain specialists, it's super high quality. They are excellent communicators in any way and form. And they are focused on work and not politics. They are very able and eager to plan work themselves. So the whole part about the self-managing team, it's not only the self-managing team. It's the self-managing developer. And they are curious. And they are always looking to evolve and learn new stuff. And one of the most important things is that they are found globally. Who says that the best talent is in the city that you live in? There's absolutely no reason to think that today people are spread all over the globe. But most importantly, I think that the best thing about remote developers is that they have a life outside of work. They have things they care for, are motivated by, that are not strictly work. But I will say, and I can say in this assembly, it's not for everyone. It's definitely not for everyone. What does not signify remote developers? This, again, only works if you've seen the movie. This is the terrible manager, the project manager hovering over your desk. It's the simple antithesis to remote work and freedom. Where are those TPA reports? Well, go F yourself. I don't need you to micromanage me all the time. And you are there. You're interrupting me all the time, and you are bringing me out of my balance, and you are interrupting me, and you are making my work bad. If you want the very, very best talent to excel, you need to get out of their way. But we do have something that helps us in scrum to achieve that. There is, of course, the freedom part. A sprint is like your space of freedom, and that helps a lot. You can plan within your sprint. For us, as a remote company where the teams are spanning many time zones, there are some assembly required, and you have to be very, very adaptive. I won't go into it right now. But I think that, again, you can see the freedom part is really, really important. It is necessary for people to be able to plan their work life and to plan their private life and have that balance. I think that the people we see in X Team are absolute masters at that. And it's not only on a daily basis. I mean, over time, you have live events happening. You have moved to another city, go traveling, start a family, whatever. But what I think scrum helps us is that if you look at the constant tracking of progress, the documentation is always updated and accessible for the team. It's not something extra, like time tracking that goes beyond the work. When a developer checks in his code, it starts, well, in most environments, it starts a whole host of automatic tasks that updates documentation and so on. So essentially, the developer is doing exactly the same. But all the documentation, all the progress updates are done automatically. And if you work in scrum, you will hopefully change the status of your ticket to in progress. And then it goes into QA or whatever your process looks like, what the different swim lanes are you have in your scrum board. And I would say, depending on the tool, the communication is on demand. Later on, I call it asynchronously. So if everybody uses Slack, who uses Slack? Everybody knows Slack. The ones who doesn't use it know it. It is very asynchronously. You have your channels for discussing whatever technology or whatever topic it is with your team and with the rest of the company, with the client even. And you can post whatever you have to say at any hour convenient to you. And then you get a response later, or immediately. It's not like picking up the phone and expecting someone to be there at the other end at that exact time. And that really helps to relieve stress. I mean, it's not for everybody. But I think that if you have the expectation of not getting the immediate response, then it really can be a stress reliever. And like I mentioned before, you have the freedom within, let's say, most work with two week sprints. Well, within those two weeks, you know exactly what your workload is, hopefully. And then you can plan out, OK, I got this kind of ticket and I got this kind of ticket and this kind of ticket. Maybe I want to go to that thing on a Wednesday and I can do it on a Sunday, whatever. No one should care. It's you as a developer who has to make sure that you plan your work, or some people work best at night. So why should you be enslaved and sitting at your desk in that 9 to 5 grind? That's insane. I don't recall how many times I've driven home on a Friday afternoon, I thought, this is a previous life. And thought, oh my god, there it is, on the car back home and one and a half hour commute, terrible. And then you spend your Friday night getting that thing down that you spend all week trying to solve. There's tools that help us do all of this. Again, asterisk, there is nothing here that's easy or simple, but it's absolutely doable, that's for sure. And when I say globally, I really mean globally the last time, it's a couple of months ago, the team has been dissolved right now, but it was spread from Uruguay, Argentina, Brazil, Spain, Norway, myself in Sweden, Russia, and I never can remember. Was it Singapore, Kuala Lumpur, somewhere out there? And then half the team was traveling all the time. So I mean, most Mondays start-up-wises, so where in the world are you? Which was pretty cool, but it really works. And it's all these kinds of, it's different kind of developers, it's different kind of cultures, different kinds of backgrounds, and it really works globally. And you can have one team. Because it is, what I believe is, it's very culturally agnostic. When I move, I come from Denmark, so anybody from Sweden? OK, so listen, this is what's wrong with Sweden. No one's here. So I moved to Sweden and got this office job, and it's nice, and I won't say anything about it. Negative, 10.45, everybody got up and left their desk. And I was like, 10.45, what's going on? Well, they have this, in the UK it's a tea break, and in Sweden it's fika. And it's like, you don't mess with it. It's as important as Christmas and mid-summer all combined. In the morning, 10.45, it may be 10.30, but there's a bit of a civil war going on. Is it 10.30, is it 10.45? You get up and you have coffee and some kind of cake. I was like, I did not know this. But we're sitting here, we're discussing this. Yeah, well, 10.45, we get up. I was never used to that. None of these fixed times. And it was the same with lunch. Yes, we didn't get the bashing today. You could sit in a meeting and discussing the most important things. 12 o'clock, everybody got up and left the room. I was like, are you kidding me? Could you just wait like 15, 30 minutes more? No. So that was a culture that you would have to adapt to. I think that Scrum helps us take away some of the cultural bias and helps us create a new culture. Yeah, it's not all unicorns and rainbows. There are some pitfalls. There are some assembly required. All this freedom, it really requires you to be responsible. You have to manage yourself. Because if you haven't worked in a remote company and you're looking to do it, you will find out no one is going to tap you on your shoulder and say, so what's going on? If you are not participating, if you are not showing the engagement, if you are not posting whatever kittens on Slack or whatever your company prefers, then it will not work. There is a little bit of, I think, loneliness is the word that most people talk about. And if you come straight out of years and years in an office, it will probably seem lonely. And it's not only the developers. It's also the managers, especially in Scrum. That doesn't mean not only in remote, but also in located, geographically located arrangement. The managers have to take a backseat. I don't know how many managers can go from the traditional role of managing people to just making sure that people are able to manage themselves. What helps is all the reports, like the burn down charts and the daily stand-ups, that can set some managers hard of these. But it's a challenge. It really is. So I would say there's a lot, again, like the manifesto. It sounds good in principle. But in real life, you really have to be able to take on the responsibility. Another thing with Scrum, it has nothing to do with code. And many developers, not this room, but other developers who are not here, seems to have this notion that now we get better quality product. But yes, hopefully you will do that. But it doesn't tell you how. This is where some of the assembly comes in. And there's tons of other frameworks that deals with code quality. Asterisk DD, go look at that. And you're going to have a whole con about that. It doesn't talk about deployment. It doesn't talk about what all the operations-wise challenges you have. And that can be a challenge to someone. And especially, the most importantly is that you do Scrum, and you do it right. There was this water Scrum in the previous session. I've never heard about it before, but it sounded like something I've been exposed to. Doing sprints in a GAMP chart, it doesn't work. And when things go sour, Scrum really doesn't have the perfect explanation. But it's often a derivative of you haven't done it right. Like, yes, we want to do Scrum, but we don't want sprints, or we do sprints ad hoc. I'm sure some of you have seen some disastrous examples of this. One of the things that also a great pitfall is that when management support goes cold, then it's really, really hard to move forward. It's essential that when you implement it, if you do Scrum, everybody has to be on board, and on board for the long haul. Lack of knowledge. Like I said in the beginning, some managers said, yeah, we are an agile company, but I don't really care about the manifesto. And then the guy who told the story said, well, this is the manifesto, and the manager had to admit, this was the first time we've ever seen it. And I'm not saying that you have to wake up 3 AM and know the manifesto, but at least know some basics. Like with Scrum, if you have the basics in place and you actually adhere to it. And different people will focus on different things like the retro, the retro is the most important thing, or something else, the daily stand-ups. I think the daily stand-ups are among some of the most important things. And then the lack of resources. Lack of resources is what leads to incompetent people being Scrum master just because we need someone. Yeah, now you're the Scrum master, and you can be product owner, and you can be Scrum owner. And you can be, I don't know, product master. Bad implementation. And let's cut some corners. Scrum master, for instance, it is a full-time job. It's actually more than a full-time job, but let's not pity all the Scrum masters too much. Product owners, it's really hard. You have to do it right, especially when you do it remote. You can't just write a ticket that says, yeah, go do this. Let's have that shiny spinner in place. No, there's a user story, and there's acceptance criteria. There's a lot of formal stuff. And when you reach a level at around sprint 50, then we can talk about you can scale it down. But it's essential, especially if your time zones don't overlap that much. Write that GDE user story perfect the first time. It's really, really important. One of the things I like to call Scrum, any Irish? I trusted Google Translate, and it says that Scrum is a cheese. Scrum needs to mature, and it needs time to permeate through the organization. And it's not done just by saying, now we implement it. That's not even the beginning. You have to do it for a while to really do it right. And that, especially, is the case when you're doing it remote. Here at the end, I want to talk a little bit about some tools. What is really, really important is that you have good tools. Good tools means everything in remote work. I hope you all know these brands. They have their own small twerks and specialties. Trello is a campan tool, but it can with some additional modules be made into a sort of Scrum backlog, sprint backlog tool. It manages it. You can add story points and so on. It's not a super solution, but it's free. Atlassian's Prague Suite, on the other hand, is not free. But it's very, very good. Basecamp, well, for historic reasons. GitHub, if you throw waffle I.O. on it, you can actually use the issues pretty well. Story points and so on, all the necessities are there. It's different strokes and so on. I want to say something about a code repository. I still meet organizations that don't use a code repository. So whatever you do, use it. So that is it. You have these to choose from. You can use your own. It's open source. And here are some of the other tools we use on our work for communicating within the team and with the customer. Of course, since I put this slide together, Slack seems to have exploded even more. I'll keep Skype in as an honorable mention, just because it's made by a guy from Denmark and Sweden. Google Hangouts, when it works, it works really great. Appearance is a tool. Join me, Google Docs, there's tons of tools that you can probably add many more. But choose one and stick to it. And all these, especially with Slack, they have so many integrations. And there are so many other tools. So I kept it as short as possible and skipped through a lot, because what I really liked in the last one is that we have a dialogue and we have a discussion. And with so many remote workers, I didn't even think it was possible. So that's fantastic. I want to hear a lot about what you have to say. And I will take questions. And if you don't have a question right now, find me, tap me on the shoulder, knock me over. No, don't do that. Or Twitter, or email. And that's it for now. Any questions? Yes. And this time, use the mic and cue up there. And I will answer anything. It'd be interesting to know what a day in your company looks like and how big your scrum teams are and how you resolve the challenge of being on different times. Right. Yeah, as for a team pulse, that's normally around the time when the scrum starts. So let me give you an example of the team where I was a team lead. I live in Sweden. The customer is on the west coast of the US in Los Angeles. So that's a nine hour time difference. My day starts around 6 o'clock at night. And before that, you have chats with various people on Slack, depending on where in the world they are. If they're in Europe, you can start during the morning. How's it going? How's that thing working out? And so on. Yeah, so you get up to the point. And the South American people is up around 2, 3 in the afternoon. And then you have your first meeting around 6, and then few meetings the rest of the evening. Yeah, and in periods, yeah. How do you do the reviews? How do you do the reviews? I mean, everybody is in a different country, different time zones. Do some have to wake up at 3 o'clock at night to be at review, or how do you handle it? We had one guy who was in the Far East. And yes, he worked most nights. Another guy in Poland just likes working at night. So he starts late afternoon, early evening, and works through the night. And all ceremonies are remote, of course. And that's the stand-up. Actually, we have also asynced the stand-ups. So I think it's around 2 or 3 in the afternoon. There's a bot. You know slackbots? There's a slackbot that kicks in and asks you the questions. And if you for some reason are not able to make it to the stand-up in the evening, then you at least have posted that. But sometimes it's just great to have that report, because then that's documented. And you get some face or ear-to-mouth time with the rest of the team on the stand-up. And the same with the retro, the same with the grooming. We get worksheets about what tickets are getting groomed. And then you can in peace and quiet just sit and go through the tickets and score them yourself. And then if you're not able to make it, again it's an evening thing if you're European, then you can either just send off to the scrum master here's my point suggestion, or you can participate and just read it off your notes. And the same with the retro as well. We really need to use the microphone. Otherwise, I will never be allowed back. I also work 100% remote as a scrum master. We work actually mornings. And I just feel from what you've said, there's a lot of disconnect, yes, we can all do our daily stand-up individually and send it through Slack. But then there's no team. And so I make a point. I mean, yes, sometimes I had a project where they wanted the scrum master in the States. I'm based in Israel. And it worked better that I became the scrum master. So there will be a team, a unity. You sound so disconnected from each other that you're all individually running scrum and doing your stand-up just before you go out. You talk about the flexibility, it sounds to me like you're working all day. Do you mean work all day concentrated? No, it is intermittent. I understand this. I work 5, 6 hours in the morning, 7.30 till about 1. I have a massive break with my kids and then back on in the evening. But there is that break. And there's many things that actually come up. You talk about the flexibility. But sometimes it does the opposite. It makes you work constantly. You're constantly, you're on your phone, you're on your this, you're on your, if you're at home, you just have to walk 100 meters when you get to your desk. So you're being pulled back all the time on one hand. And on the other hand, you've got this disconnect because, oh, I can't make it today like I haven't made it for the week. I'll just update my stand-up notes and what I did. But where's the listening? Where's listening to the team? You're disconnected. I will say just on that, everybody gets each other's notes. So everybody, you can read it. Everyone updates the types of their updates. The Slack box will assemble all these and send it out as a note. So now everybody can read what everybody is working on. But isn't the beauty of the scrum kind of enthusiastic about scrum as well? And there's no team. I have a team. We're a unit. We're one. We go forward together. And that's because we speak every day. We're in communication on the project. Slack as well. I just feel it's lacking that personal touch. So that's true. I just want to emphasize that we have this flexibility. What is reality is that 99% always shows up for everything. The disconnect, I don't feel disconnected. I feel very connected to the team. The thing is you have other means of communicating. In Slack now, you can pick up the phone. You can video conference. That's one-to-one. You can have hangouts with the entire team where everybody sees each other. We don't use the ceremonies as a point of creating the team. We have so many other activities. But that's as a company and also with the client that is sort of extracurricular. So we're not driven by what is the scrum ceremonies. That should be derived. That we talk well together on a stand-up is derived from other communications that we have. I don't try and be the arbitration between the two. But I think you've both got really valid points. But we're mostly going to look at the inclusivity around this. So you may have members of your team who you can't hear or see in your stand-up. Even if you're in the same office, there could be some people with disabilities who aren't able to perform in that particular way. So they're still able to take part. So a text version of a stand-up meeting is fine for your team. But ideally, yeah, you'd all be in the same place. But ideally, you'd be all co-located. I'm not ideally. Well, ideally for scrum. And this is what you're saying. Scrum doesn't dictate that. But it suggests that that's a better way of working. But it doesn't say that you can't work in the other way. Exactly. There's no way of saying. I know there's a lot of descriptions about stand-up. The scrum stand-up is where we all meet daily. I know. But meeting daily, does that mean that it has to be? I know it's about stand-up. We sit down most of the time if you don't have a desk. But it's not a law. And that's where I say, I think that scrum actually allows for this, the way we do it. But again, I said, there's a whole lot of discipline. And it's not for everybody. I mean, feeling the disconnect, I almost started a sob story. But I feel disconnected at a job I had once. Because I was the only one in the entire IT department working with web. And no one else understood, because they worked with gracious of Java. And I was doing Drupal. And no one understood anything. And we could meet maybe at the coffee break. That was mandatory. So what are you doing? Yeah, I got this great optimization so I can do something with views much faster. It's like, huh? And they were sitting with 25-year-old technology that really sucks. You know, it's Java. So there was no one there. And the project manager didn't even care about it. And he was sort of a scrum master as well. Very bad implementation. I'm just making the point that scrum can also have room for this way of doing it. I just wanted to say that I can identify with what you're saying about feeling a bit disconnected. And I found that the stand-ups were one way to connect the team on kind of a cohesive, like, we always do this, we always connect. And that always felt really good to the team. Like, there was a kind of camaraderie. And one of the other sessions that I saw during this PM track talked about how people liked that, but that it wasn't particularly useful. And I had felt that on our projects, we're just kind of, OK, now he's talking. Do I care? The scrum master cares. The project manager cares. The product owner cares. Because we're getting information that pertains to status and things we need to report and track and understand. But the rest of the team doesn't always tune in. And I'm wondering if anyone or you have suggestions of how we can turn that daily stand-up round robin, whatever you want to call it, into something that's more focused on self-management and team-generating usefulness? Like, is there a list of questions that we can come up with that will be more informational to the team and not just the scrum master and project manager and product owner? Because otherwise, it's a great way to stay in touch and to keep the team cohesive. But it's not giving the entire team good information that they always want to know. If the designer has finished a comp that they need to work on, that's interesting. They need to know that. But if it's just them saying, oh, I'm gathering information, blah, blah, blah, and we already know that because of one other meeting we've had, then it's wasted time, essentially. So I'm trying to find, what's the balance between wasting time or not wasting time and creating cohesiveness? Like, how can we find that middle ground? For me, the stand-up, the daily stand-up is not the holy grail. Actually, in another team, same client, we are really discussing the meeting-free environment, doing everything asynchronously, and keeping the stand-up down to a bare minimum. Still have it every day, sort of. It's a bit sad because it's the old managerial way of doing it, just checking. Are people still awake and so on? And maybe they know a joke or something. But it's really about, do you need to be unblocked? If not, move on to the next one. Who needs unblocking? And I would say, get your team-building in something else than the ceremonies. The retros. I have a question. Are you using chat or something like IRC, some of the Slack specifically, really keep in touch? Slack is. You're using that for your team development. They're cohesive growth as a team and the forming, storming business. That's done via chat instead of call, for example. As a company, we do a whole lot of other things that are social. Because it's a remote company, the newest initiative is creating, it's called X Outposts. So the company will rent a house like in the Canary Islands for a month, a month and a half, and so on. And people can book in and just meet. Maybe they work on different teams. But they can just sit around the same table, do their work. And whenever they feel like it, go out and surf. And next time it's in Thailand. And previously it was Naples. I lost track because I have a family, so I can't do all this all at the same time. But we go to conferences together. There's a conference next month. We did, at one time, get the entire global team together in Los Angeles and meet up for a week there. They're hugely beneficial. We still have, we talk about stuff going on there. It's outside the scrum ceremonies. And I would say this, it's very idealistic. But the ceremony should be something that you look forward to coming to, isn't that? Oh my god, now I have to break my work and go to the stand-up or the retro, whatever, the grooming. The meeting-free environment, that's really the goal. We didn't quite achieve it on that project. We're looking forward to it on the next. Yes? I have a question about when developers are blocked. So let's say in my virtual stand-up, I say, I'm blocked on this. And then the people I'm blocked on may go to bed or have dinner or something. Do you have set windows of what's acceptable to wait for someone else to come help? Or is that worked out between the individuals? Because I previously was a remote person working three hours ahead of the rest of my team. And sometimes it was a whole lost day. Like I would try to find other things to do. But my main task, I would be blocked on maybe till 4 PM my time. Well, see, then you cannot rely on the stand-up. I would say the 24-hour circle works fine in an office. But it doesn't work when you work remote, especially when you're spread out globally. If you're blocked, you cannot wait till the stand-up to say that you're blocked. You have to raise that flag immediately. There's a lot of responsibility on the developers to be proactive to foresee these things. There's a lot of pressure on the developers to think ahead. You can't just say, oh, I'm blocked. So good night. No, let's just say, I would say in my morning, 9 AM, I'm blocked. But then if everyone else doesn't come on till later, then how do you coordinate that? Does it become the next person's first priority to unblock me? Because I've already been working for six or so hours. But you do have an overlap around the stand-up time. I'm asking you. No, no, no. My stand-up was first. I would log on and say, 9 AM, my time, this is what I'm doing. Everyone else doesn't come on till three hours later. And then that's their morning. And I'm saying they're doing their stand-up by my noon. And then they don't really get to address my blocker until what is now 4 PM my time, because I'm ahead. Yeah, yeah. Well, you do have to get together around the same time. Because otherwise, you're totally disconnected. I don't know if that's what you meant about the disconnect on the team. There has to be a common time. But you don't do it like it's not a social thing. We do have to find out what are the technical issues around the stand-up. We do use it for notices if someone is entering the team or leaving the team other practical information on the stand-up, which might as well be something that just goes out into the daily notes. So everything from the stand-up is collected in notes and documented. But yeah, it varies around the blocking and unblocking. But you do have to adapt to it. That was a very shitty answer. So yeah, a while ago, I was involved a lot with e-learning. And this was one of the biggest questions on e-learning. Do you do things asynchronously or synchronously? And there were even measures that we got in the end that didn't actually get us a conclusion if people learning asynchronously would learn better or even faster than the ones that were actually having proper classes with video. One-to-many or one-to-many. Yeah, but they were all remote. So my question is, because this is like when we are developing, we are learning with each other. We are getting things that the other just grabs and pick that up and unblock and stuff. So what is your, did you ever try to measure that? What is the best thing to do the passing of stuff synchronously or asynchronously? My experience is asynchronously works really fine. I think that when we have talks, we schedule it. Let's do a one-to-one. Even if it's very informal, actually, let's talk in two hours something that doesn't interrupt your work. That's really my biggest concern, that you give the developers the freedom to organize their own work. And you don't bug them with things all the time. If they, there's so many different tools that can help you and that you can adapt to your style, a tomato, something where you work in these 25. Pomodoro. Pomodoro. That is tomato. Anyway, that gives you these 25-minute blocks. That's one way of doing it. And then you get up anyway. And then maybe you check your mail or check Slack. Is there something I need to check? I'm a huge fan of asynchronous communication because it works very, very well for me. And sometimes you just have to be there. It depends. Like I said, it's not for everyone. I understand that they are something that works better for you, your team. So we're an agency in central London. And central London is great. But the rent is hell. The community is hell. The remote works really well. We have one remote developer in the Ukraine. And today is actually the first time in the company that we've all been in the same place, however. And this is the question really. I was wondering if you have an issue with clients. Because we are an agency so we're constantly dealing with clients. All of our clients want us in meetings. So the goal of a remote company would work well for us as a goal. But actually, we still need to have a base in London. I was just wondering if you give any insight on, if you are completely remote all over the world, where are your clients? Are they also all over the world? I think, for us, the biggest issue would be trying to convert them to a scrum-type approach rather than, I mean, their government except the clients, so they're all worse for them stuck in the 50s, basically. Phone conferences work, Google Hangouts work. I've been in meetings with potential clients where I was the only one in the room physically. And then the sales guy would be on an iPad on Skype or on Google Hangouts. And the client was like, OK. Yeah, well, he's in LA. And the other senior person is in an airport in Australia. So that's how we roll. OK, cool. If you don't dare break that barrier, because, I mean, that's our selling point at least as a company. We are remote. So we are not around the corner. We don't have offices. We don't want offices. And if you think we're stupid, that's fine. That's your prerogative. But that's how we roll. And that's our strength. There's a whole lot of things that are an advantage to it. But it starts at the very first contact with the company. I lived just around the corner, so it wasn't a problem for me. But just do it. I mean, have that confidence to say, if that's what you do, you can make tons of excuses why not to do it. But we're just determined. And you get that weird look from a potential client in the beginning, OK. And then they get over it. And I want to say, after that meeting, the head of development, he came around and tapped me and showed us that you guys are so effing cool. I want to move all my development to remote. But I don't know how. But that's cool. OK. That was a sales pitch. So I don't know. It's not conclusive. Again, we can talk in the corridors. I think we have two questions left. OK, I just don't know if you said it before, if I got it. But how many people are working for your company? How many Scrum teams? And how many team members in the Scrum team? That would be interesting. I have no idea how many work for us right now. If I may have to object. Basically, we have a company of about 50 developers. But we have sub teams. We have a particular team for each client. So there is one team that's a customer leads. And they are sort of Scrum leader. But we also have different teams that basically choose their own solutions. So you can basically imagine Slack as our own office, which is a fully virtual office. And we do all kind of social integrations and social activities, either on Slack or we have those one-to-town halls where basically before creation still just gives an update by Google handouts to the whole community, what has been done in the past month. Then we have those ex-outposts where we rent houses all around the world where people can just buy in a week or three if they choose to connect with their team members. But yeah, I think that's a very important thing to mention that we have about 50 developers in the company. But we already buy them into sub teams. And each team chooses their own work style. And a team leader, is it Scrum or PO? What is really in Scrum, there's not really a team either. That's why I'm asking. So it again depends on the team. We can either build a team from scratch for clients. Or we can merge with clients team. Or we can just give them a developer that's controlling their team. So we can adapt to the work style. So that's for the team leader. And he manages the whole ex-team sub team. But then again, it depends on the other team. What would you call yourself? Would you call yourself a product owner or a Scrum? Oh, none of those things. OK. Product manager, team lead, Jaguar trades, you need. That's a lot of names. It's just to find some kind of title that kind of explains. We work with other vendors at this particular project which is kind of massive. So there needs to be some personal liaison or interfacing on that level. Hi, just a quick one. Do you think your methodology or your organization would work in a corporate environment where not everybody would be allowed to work at night? Or there are more strict time and attendance windows, especially the team is remote? That's really difficult to answer. I don't know. It's me, yeah, it's a bloch. Correct me if I'm wrong, but right. Casper has this situation where he's spread across different time zones. If you reduce the number of time zones, then you would be doing the same thing, but just without the separation of time. So yes, absolutely, it could work, because that's what we do. So we have a team of 14 people who are separated by one time zone. So it's only an hour apart. So everyone can be in the same place at the same time in remote environments. What I'm saying is the opposite. When it's not the same time zone, then that's what Casper. Yes, but he works at night. That's what I'm saying. Yeah, I work both at night. If there were more strict working windows, like if you work from 9 to 5, and you have people in India and in South America, then asynchronous communication becomes necessary. Yeah, but I don't see the point. I don't see the value. I, again, over the last 20 years, I've seen a lot of different kind of developers. Some love to come in in the morning. They know exactly where the coffee maker is, the same colleagues, the same parking spot outside the offices, that, for me, excessive grind every day, day in, day out, it makes me mad. Every day, wake up, basically when you want, because you don't have to set a clock. The day starts at 6. It doesn't. But for the client, it starts at 6. And then you participate as much as you can during the night. And sometimes it spills over midnight. I mean, if you want to do this, you can't be hung up on what time it is. I mean, you try to level it out. Let's say over a year, hopefully you get like $8 a day. You don't have kids yet. I have four kids. So how do you do that? Well, I don't, the person be so. We need to talk later. I always have four kids. And working from home in a remote environment allows me to be the full-time mom and the full-time employee. I do it all. I can give you an example. For many, many years, because I chose to live where I live, because I want to live there, it's very rural. But I love it, the scout thing and all that. That's a whole different session. So I had to commute a whole lot. And I didn't wake up one day, but it was sort of a gliding movement against, now I can't do this anymore. I left in the morning. It was dark. Before my kids woke up, when I got home in the evening, it was dark and my kids had gone to bed. I maybe saw them on weekends and then trying to be a parent for those few light hours on a weekend. It was very bad. It wasn't quality time at all. And it sucked. And I hated it. It was like, why do I have to go to this work so I can make all these money to pay for this house that I never see? I never see it. I don't see it, maybe on a weekend. And for a car that I only used to drive to and from work, it was such a waste of time. And now, if I work 18 hours one day and two hours the next time, I don't care. That's not the point of it. That's not the point of working remote for me. You may get a different answer from other remote workers, but it's the freedom part that you can make things balance. And my point is there's actually also a process and project management framework around it that helps you a lot. But you have to be dedicated. You have to do it right. Not right, but you have to be committed to it. Do it fully. Don't just take a dive in the deep end. It will pay off. And it works. I don't know any other remote companies that are so committed as our company. Because you hear us, yeah, yeah, totally remote, well, on our continent. Because the time zone always gets people confused. Well, are you global or are you not global? Are you remote or are you not remote? Because otherwise you're just kind of co-located. This is where I expect getting chairs thrown at me and rotten fruit. But that's what I feel. It has to be 100%. Do it and commit to it. And be proud of it. Like if you want to be remote, be remote. And if the customers don't like it, then you have the wrong customers. That's a very bold statement. But they will drag your work down. There's so many sessions that I've talked about. You have to also do work that is fun and that has a purpose for you. Otherwise, you're just another little hamster in the wheel. No chairs? I got through without no chairs. Thank you.