Out of Sight, Out of Mind: Survival tricks and tools for remote developers (especially Python and Django)
Bragadini, Alessio
What to do and what not to do in order to collaborate remotely on Django projects without losing your mind Remote working and “smart working” is very much in fashion these days, but what does it entail for the daily routing of a distributed development team? We will talk about tools, the disputed use of email, Skype, Slack but more specifically about time management, what you can expect from yourself and from other members of the remote team. Is your company “remote-friendly” or rather “remote-first”? When it’s time to spend a few days in physical proximity with your colleagues? We will share some examples out of the experience of a distributed team actively working with Python and Django on a daily basis, and show how you can make it all work, if you work on it.
 It's very nice to be here. It's very nice to be here in Eidelberg. It's my first time at DjangoCon Europe. This talk, I presented it in a slightly different way yesterday, yesterday here at PyCon in Florence. The funny thing about this talk is that one year to the next, a lot of things change. So it's very nice to revisit. We will talk about remote working. Remote working is an extremely big topic. We will just cover the tip of the iceberg. I will try to make it short. There could be time for some questions at the end. It's very nice to do it in a conference when there is streaming, live streaming. So there are people out there watching now, probably remote developers. So I would say hello to everyone who is a remote developer and is taking time out of the schedule to watch the conference from another location, which is kind of the point of the whole thing. Another thing is Tower Day. I work for a company that has 42 in the name, so we cannot just ignore it. Our company motto is don't panic, which is always a very useful thing to say and to keep in mind. The other thing is GDPR Day. So again, don't panic. It's very nice to be in such a theater. It's probably my first time on a proper stage with a proper microphone and with all the technology. So it's tempting to feel like a rock star. I'm not a rock star. So I would like to introduce a bit who I am and the people I work with because it's very relevant for the kind of talk I'm introducing. I'm mostly a web developer, always been in my career, and especially I work with Django and Python and that's the reason I'm here. As I said, I work with a company that has Agile 42 in the name. It's a coaching and training company. And we are a very distributed company in Europe, in North America, and in South Africa. And especially our web and IT team has a network in Berlin and a number of people, including myself, that work remotely. And in particular, I work from Milan. And not only I work remotely for this job, but I used to do it also for previous jobs. So I have a bit of experience in that. I've seen it all. I've also worked in offices, so I see the difference. And basically the question I ask myself every day is how this is possible to do effectively and without too much stress. You know the dream. The dream is to be an IT worker that works whenever they want, usually from the beach with flexible hours, leaving a very nice lifestyle. But actually the reality is that you work out of a cramped space. You work in not very good hours. You basically have all the problems of working in an office and none of the perks like chatting with your friends at the water cooler or around the cup of coffee. Not to mention that remote working has this kind of peril. It's very nice that you still left this slide because it's a slide from last year and I was wondering, will it be still relevant today? But yeah, you know what I'm talking about. So let's get a bit to the core problem that we may face. I took this quotation from an article that is linked there from Zach Holman. And I think it encapsulates very nicely the problem. First difference between a remote friendly company and a remote first company. A remote friendly company is a lot of IT companies these days. You can do one or more days of work at home. You can take time off. You can do flexible hours. The result is what really counts and not the number of hours you spend in the office. But still there is an office and people who choose not to work in that office. A remote first company instead is a company that breaks the structure of the office work and creates a workflow that allows people to contribute in a more free environment and a more free structure. And that's really the challenge for this century. As I mentioned, we work in agile coaching. Agile methodologies, the whole culture of agile, tries to help companies to work better and workers to work more effectively without burning out. So we ask, can agile methodologies help remote workers or can agile methodologies help a remote culture in the company? We think there are a certain set of agile methodologies that definitely help remote working. For example, a culture of TDD, which means test drive and development, which means that you create first set of tests against which you run your code, actually helps a lot remote teams because it sets a number of boundaries that don't just work because people share the same code intimately over the same keyboard. But in a more flexible environment. No code ownership, the same. It's easier to work with a remote colleague if we all agree that a certain area of the code can be improved by all members of the teams. And especially what we call visual radiators, meaning that you have structures that help understand what's the status of the project, like backlog, boards, all kinds of artifacts that you can either share in your office or in a virtual board. But then comes the kicker. We know instead from experience and from work with companies that actually the most effective teams are the ones that are co-located, meaning that they work in the same office. For example, in large American companies, they discover that not only they have to be on the same building, but they have to be tied together. Even if people have nice offices far from each other, it's better to put them together so they can contribute more. That seems to break the whole reason of remote working. This is a principle from the Agile manifesto, and we know it's a few years old by now. And it says explicitly that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. So this looks like a problem. But I would like to parse this principle because it seems obvious from the face of it, and I think it keeps standing if you check carefully what it means. So for example, we should discuss exactly what we mean by face-to-face, because in the good old days, it was quite obvious to say that face-to-face meant some people in the office or even some people around the table. Some people around the table discussing the problems of a software project. But now we are in a completely different culture. Part of what face-to-face meant was proximity, you are next to your colleague, but also a sense of truthfulness, meaning that what face-to-face was against, was against thick documentation that moved from one level to another, large meetings when there is no real discussion, and these kind of things that were common in enterprise development. So a face-to-face discussion not only means that we are standing with our bodies in short proximity, also means that we talk to each other without a barrier and telling things exactly how they are. In the 21st century in 2018, we have a lot of this conversation in chats, group chats, over electronic messaging. You can be really true with your colleague in Slack and you can just say a lie face-to-face. So Slack, Skype, WhatsApp and Gout are now very common tools for teams. And this is 99% of what face-to-face means in that sense. Of course, there is still an aspect of body language and the pleasure of interacting with each other that we don't want to discount, but it's not the key part of face-to-face. And the reason to be face-to-face is to exchange information. So what can we call information in the area of project development? Well, the most obvious is discussion about the project, so how we should do some things, how we should move forward and so on. Very specific details about the code, very specific details about design, the artifacts that the development team does. And also, you want to communicate to your team the things that worked, commits, tasks done, the things that didn't work, all the bugs, all the regressions. And you want to chit-chat and grow that team culture that is very important for a successful project. Yes, this is all information. These are all things we talk to our colleagues about. Do we really need to be in close proximity to do this? Not necessarily, because all these things you can, for example, rely on a Slack channel. Slack is very popular, Skype chat or even Google email. Some of these things are actually better to be discussed online, especially if you are talking about code or design, having a shell screen helps you more than just discussing it at a meeting. So we go back to that article by Zach, and where he says that using a culture where everything you do is either manually or automatically pushed into a communication channel, and for example, he mentioned chatbots, a tool that takes an action from some other system and puts it automatically in your chat, then you create a culture where it's not important if you're in the office. It's not important if you're in the office that day. It's not important if you are in the office ever, because basically we are all remote workers from different locations. Some of them accidentally are in the same office, and we all contribute to the same project and to the same communication channel. So basically it's a cultural challenge rather than a plain old technical challenge. This is a new slide that I added a couple of days ago. There are articles from the enterprise side of things, for example from the Harvard Business Review that start to talk about this change in the workplace. It's not just for one team here and there, but it's a real change that's happening in the workplace where electronic tools are the glue that keep together a remote team. This is a tweet from Leigh Bryant, a researcher at Postshift, and I suggest you check him out. He always writes very interesting stuff. So one reason to do this at a conference like DjangoCon is to help teams and individuals that want to go down this path. So here I would like to tell how we do it with our team at Agile 42. Basically we have a lot of shared stuff. We have a shared code repository, and possibly this is reachable from the outside. You have GitHub, you have Bitbucket, some companies may have security issues. It's something you can work around. We have automated unit testing and integration testing. That's what I said that Agile methodologies or plain old methodologies from extreme programming they come very useful because all testing helps create a safety net for developers, especially developers who don't have someone next desk to confront with. They can just rely on the structure and they can move their code forward in a more sustainable way. Of course we have continuous integration, which is pretty common nowadays, but helps us with contributing code from different individuals who are not necessarily synced, especially in time zones or in working hours. We have boards, we use all kinds of task planning, and also we like to test a lot of things. All of this, of course, must be available from any location, and all of this goes into a channel, which is our main communication channel and the heartbeat of our project. But of course you also have to adjust your personal style and the way that the team interacts with each other in order to make it work. If you do Agile methodologies and I strongly suggest you should do it and you do your Agile ceremony starting with the daily stand up, with the sprint planning, the reviewer at respect this and whatever your method calls for, you do it online. You do it in a way that allows remote workers to attend and remote workers to contribute. For example, with my team we connect regularly over Skype, we even see each other that helps with the distance barrier, and we do our sprint reviews, we do our daily stand ups. You should not work alone in the sense that you wake up in the morning, you just hack your code and you go to bed, possibly other things as well. But you should contribute to the life of the project. You should say, I'm going to do this, I'm going to do that. Or if you are going to do that to a colleague, then I can help, or I think this is a better idea to follow up. One thing that I discovered in my career that is a bit against the whole dream of remote working is that having working hours that are compatible with the rest of the team, especially if you have some team, some parts of the team that work out of an office and therefore they do something more closely aligned to 9-5, or at least to be available around the time where you expect other members of the team to be online. And you have to keep that chat channel open during work hours. It's basically your way of checking in in the office and checking out from the office. I know that a major company that does remote working, full remote working, so we would say remote first, has one of the few requirements is to keep the chat channel open during work hours. You cannot be remote 100% of the time. Occasionally you have to meet. If it's more than occasionally, it's nice. The kind of interactions you have when you are face-to-face are different from the ones you have online. And sometimes they are just funnier or sometimes they are just more forward thinking, so it helps with the planning. So every remote team should just meet occasionally just to sync up and to put a face to the presence online. And of course, there are a few companies, just named two, that do remote first. They like to talk about it. They like to explain the tools they are using. And so it's a good source of inspiration. This is, for example, a screenshot. And I understand that the details may be lost. But this is a screenshot from our own Slack channel of developers. And you see, for example, Slackbot that remind us of agile ceremonies like a stand-up, an error message from our bug tracker, Trail-Low, which we use for lightweight project management, sending out comments about a work in progress, and things like this. And you see the comments. You see, for example, coming from GitLab comments attached to a specific story. They are pushed also into the channel. That's what we meant as chatbots trying to keep the communication channel alive and to put everything so we can comment on. These are a lot of statuses from our continuous integration project. And this is much more lively discussion about a certain feature, what we should do about it. And I can say that I'm not sure where the people were at that time. I was remote in Milan, but other people were probably on vacation and contributing a little bit. So this is the way we keep a project moving forward. And of course, they come from Slack, which a lot of people are using these days for this. So we are using a lot of tools to do that. And these tools change constantly over time. We are continuously refining and changing. As we said, we do test driving development, and we use unit tests, Selenium. We have a lot of visual tests to align with what we want to achieve. We try to do infrastructure as code, another layer that helps us get away from the concept of having a staging server and a test server. At the moment, we mostly use virtual machines, but Docker is a very nice solution. So I was very happy to hear from Lacey from the talk before. If I understand correctly, she's also a remote developer. So we see how all these techniques come together. And recently, we've moved to GitLab, our own hosted GitLab as a Git repository and project center for our development. This also allows us to use pipelines for continuous integration, tying even closer together the development, the project management, and the continuous integration inside GitLab. At that point, we integrated GitLab with Slack and with Sentry, which is a tool to alert of bugs. And we created this chatbot that allows us to see almost everything that is happening in the project in real time. We also moved project management to GitLab with boards and some Trello, which is always nice because it's very lightweight. As I mentioned, we use Skype for the agile ceremonies and Google Docs, whatever. Basically, we try everything that can be helpful for having a team that is not in the same office to coordinate and exchange information. Here I have a screenshot of a pipeline. A pipeline is in GitLab. It's a set of tasks that you can do to test and build and install on either staging or development machine. And this is very helpful because it's triggered automatically by a commit in the repository. And this allows us to work as a team and not having, for example, a person who is only tasked with code integration and code testing and therefore may feel detached from the team. As you can see here, we configured WebBooks from GitLab into Slack to notify everything that's happening in the project inside our communication channel and therefore to be alerted about what's going on. Another tool that I wanted to mention is Sentry, which is an add-on to your code that alerts you of errors and problems and is configured to feed into the Slack channel as well. So if we go back to this, you see, for example, notification from Sentry that app automatically on the channel and allow the team to talk straight away about what's going on if it's just a small problem or if it's a major problem and needs to be tackled. Here instead, you see more notification about the code and the integration of pipelines coming from GitLab. All marked with a team member that contributed to that code allow us to give a sense of what's going on in the development at that specific moment. And so, for example, you see the great advantage of this approach is to intermix this automatic notification from, for example, from GitLab with personal comments. This means that you don't have a separated channel for the more technical stuff, but it's all part of the team discussion and you can have a better sense of what's going on in the project without having to move from one project, from one tool to the other. Okay. Thank you. I think I ran a bit fast because I'm always afraid of going too late, so I'm open for questions. Thank you. That's for you. Thank you. We have time for questions. Hello. I am a 100% full-time reward worker. I don't do meetings in person. I don't go to see clients. The only time I see clients is at events like this. And one of the things you said kind of bothered me and I wanted to know if you could tell more about this is that you said that a lot of companies, when it's the communications channel to be open during business hours. And this in my experience is really bad because people see you online and they want to talk to you, and so you don't have your time to concentrate and do your work. You're constantly interrupted, so do you have any guidelines that you want to share to avoid this kind of problem? Yes. It's an extremely good question because it opens up the whole area, which is kind of team management. So what do you expect from your team members and so on? In this respect, I don't think it's different from a team that is located in the same office. You shouldn't assume that since your co-worker is at the desk next to you, is always ready to take questions. And this basically happens in the same way when you're remote. Since you're remote, you're not expected to be available to chat at any moment because just because you have a green dot next to your avatar or something similar depending on the tool you use. One thing that I skipped over because it's a lot of other things is you have to have a working agreement with your team. A working agreement is a term we use a lot in agile coaching, and basically it starts with nothing, with an empty piece of paper, and can grow to be extremely complicated. The working agreement you have with your team is, for example, that you are online, it doesn't mean that you're available. You may say on the channel, well, today I'm just doing lightweight work, and so I'm free if anyone needs help. Or the contrary, usually you're free, but if today you're going to do something that really needs concentration, I'm not available for anything. I cannot give you exactly what's best. The thing I can say is you have to talk about it in the team. You have to come up with something that is probably written down because it helps. Just you have a shared document and you put down these rules. We prefer to call it working agreement. Sometimes the rules are pushed down by management. That's unfortunate. Sometimes it's necessary. The thing I said is, yes, management asks this, has to have the chat channel open. Is good or is bad? Well, they probably have their reasons. It's something that is part of a discussion. It's as part of an agile coaching company, something that probably gets a lot from us. I'm sorry, you have to talk about it because that's the key. You have to define your own process. One thing I can suggest more precisely, one of the ceremonies is the daily stand-up. It's common to most agile methodologies. We found it's very useful. Even if you and the rest of your team are working on different projects or different sub-projects, different tasks, even if you work remotely at even a different time zones, you should find a time each day to sync up with the rest of the team. For example, myself and my team, we do it at 3 p.m. each day and over Skype. If you're really busy with your project or from the task you're doing, which is part of a larger project, you should still find time to do these five to 15 minutes and these five to 15 minutes say to the rest of the team, I'm working on this. I'm sorry, guys. I cannot help with anything else because I'm 100% focused on this and the team should understand. Then, at that point, if someone chats you up, did you see the thing? I said, I'm sorry. I said very specifically that today is devoted to this. Then we enter in the area of rudeness, which is a completely different thing. Since it's a ceremony and it's not when you have time, but it's a fixed time each day, you plan your day around it. If you know it's first thing in the morning or after a break and so on, it's not interrupting you because you plan your day around it. Everyone gathers around, either in person or with a tool. They tell each other how much they're available to help each other with the things I'm working on. I hope it helps. Thank you. That's another question at the back, if you're up for that? Yes, definitely. Yes, thank you. I too had an issue with one of the things you said. No code ownership. This resonated with one of my personal mantras, which is, if you write it, you own it. Which means take responsibility. How do you avoid, if people are not allowed to own parts of the code, how do you avoid that nobody takes responsibility for problems that arise? Well, the responsibility is from the team. If you work in a team and our idea is that we always work in a team rather than individuals, of course, if you're being subcontracted to just work on a specific piece of software and you're the only one really working on it, so things may be different. But in most cases, you work on a project as a team. The code is owned by the team. The team has responsibility and individuals within the team may take action on a specific part of code, on a specific task. Always saying to the rest of the team, we are doing this because of this. I've chosen this solution because of this. Other members may contribute or may even change it, giving explanations. Now, if someone from your team enter in the code you've been working on for six months at very astute level with a lot of good ideas and put bad code inside it because he didn't understand what you were trying to do and commits it, then again, we enter the state of rudeness. It's a problem within the team. It's a problem that your colleagues are not up to the same level of quality that you have and you should have a discussion with them about this. I understand, since I always had a career as a developer, how we feel about the code and the artifacts we have developed. Without entering into the world of code reviews and also pair programming, which is very useful and now basically can also be done online in a number of ways, you should always be up for discussion and review of what you've done with the rest of the team. In this respect, the responsibility of what the code does moves from yourself personally to the whole team. I don't know if it's the answer you wanted to hear. No, it's exactly what I wanted to hear. Thank you. Okay, thank you. Okay, that's one more question in the front. So I wanted to add to the first question. And I think that one of the most common problems with tools like Slack is defining what has to be real-time communication, what can happen offline. So imagine I have an issue. I want to talk to someone. It's like a lightweight meeting which had for five minutes that works. But if there's something that requires somebody's attention and doesn't have to happen immediately, then an email is probably better or a ticket or whatever. So my question is how do you define the things that can go on Slack and things that you probably better not put on Slack because then they will be buried by 500 more messages. And it was something that could have waited and it's better if you deal with it like once a day when you look at your emails or tickets or whatever. Yes, sure. No, as you probably noticed from my hair, I'm not exactly a freshman out of college. So I grew up with email and I still find that email is an extremely valuable tool. You can express your point of view, especially about the design of code or a project much more clearly and allows for also for a bit more time to articulate your message. So my coworkers get a lot of emails from me. I'm active on the company's lack, but they get more emails and sometimes they say, oh, it's one of those long emails from Alessio again. And they say, well, which is my boundary between Slack, real time communication and email. I think the synchronous evaluation is the best one. As I mentioned, I have a rough feeling of the time my coworkers are in the office or they are active. I don't know for sure, especially, you know, 5 p.m. is the in is the out or whatever, but I have a rough idea. So I don't like the evenings, Saturdays and Sundays or things like that. And also I don't push long discussions over Slack. By definition, a long discussion, something that I want to say about the project doesn't need to be resolved in the next five minutes. It's something that can wait and can also have a longer discussion. And I put it in an email and I explain, well, this is my point of view. We can discuss it. Or sometimes I say, if you have some idea, just let's chat about it or let's review it at the next stand-up meeting, which is always a good syncing point for this kind of stuff. Nowadays, I've moved to an even more asynchronous way, meaning if I have something very long to say, I usually put it in a Google doc allowing other members of the team to comment and even edit what I've written. I use chat, basically now Slack, but in the past it was Skype and other tools. Just when I have something to ask to a co-worker of mine that would be in a traditional office just moving to their desk and asking, so are you working on this? Have you seen that problem? Do you think we should act immediately or it can wait? What are your plans for today and things like this? Or help, help, help. The server has a system load of 120 and I ran out of ideas and that's probably the best use for an instant message. Yes. Thank you. Thank you. Last slide, I will put them on slideshare. There are some links to things I talked about and don't panic.
 It's very nice to be here.  It's very nice to be here in Eidelberg.  It's my first time at DjangoCon Europe.  This talk, I presented it in a slightly different way yesterday, yesterday here at PyCon in Florence.  The funny thing about this talk is that one year to the next, a lot of things change.  So it's very nice to revisit.  We will talk about remote working.  Remote working is an extremely big topic.  We will just cover the tip of the iceberg.  I will try to make it short.  There could be time for some questions at the end.  It's very nice to do it in a conference when there is streaming, live streaming.  So there are people out there watching now, probably remote developers.  So I would say hello to everyone who is a remote developer and is taking time out of  the schedule to watch the conference from another location, which is kind of the point  of the whole thing.  Another thing is Tower Day.  I work for a company that has 42 in the name, so we cannot just ignore it.  Our company motto is don't panic, which is always a very useful thing to say and to  keep in mind.  The other thing is GDPR Day.  So again, don't panic.  It's very nice to be in such a theater.  It's probably my first time on a proper stage with a proper microphone and with all the  technology.  So it's tempting to feel like a rock star.  I'm not a rock star.  So I would like to introduce a bit who I am and the people I work with because it's very  relevant for the kind of talk I'm introducing.  I'm mostly a web developer, always been in my career, and especially I work with Django  and Python and that's the reason I'm here.  As I said, I work with a company that has Agile 42 in the name.  It's a coaching and training company.  And we are a very distributed company in Europe, in North America, and in South Africa.  And especially our web and IT team has a network in Berlin and a number of people, including  myself, that work remotely.  And in particular, I work from Milan.  And not only I work remotely for this job, but I used to do it also for previous jobs.  So I have a bit of experience in that.  I've seen it all.  I've also worked in offices, so I see the difference.  And basically the question I ask myself every day is how this is possible to do effectively  and without too much stress.  You know the dream.  The dream is to be an IT worker that works whenever they want, usually from the beach  with flexible hours, leaving a very nice lifestyle.  But actually the reality is that you work out of a cramped space.  You work in not very good hours.  You basically have all the problems of working in an office and none of the perks like chatting  with your friends at the water cooler or around the cup of coffee.  Not to mention that remote working has this kind of peril.  It's very nice that you still left this slide because it's a slide from last year and I  was wondering, will it be still relevant today?  But yeah, you know what I'm talking about.  So let's get a bit to the core problem that we may face.  I took this quotation from an article that is linked there from Zach Holman.  And I think it encapsulates very nicely the problem.  First difference between a remote friendly company and a remote first company.  A remote friendly company is a lot of IT companies these days.  You can do one or more days of work at home.  You can take time off.  You can do flexible hours.  The result is what really counts and not the number of hours you spend in the office.  But still there is an office and people who choose not to work in that office.  A remote first company instead is a company that breaks the structure of the office work  and creates a workflow that allows people to contribute in a more free environment and  a more free structure.  And that's really the challenge for this century.  As I mentioned, we work in agile coaching.  Agile methodologies, the whole culture of agile, tries to help companies to work better  and workers to work more effectively without burning out.  So we ask, can agile methodologies help remote workers or can agile methodologies help a  remote culture in the company?  We think there are a certain set of agile methodologies that definitely help remote  working.  For example, a culture of TDD, which means test drive and development, which means that  you create first set of tests against which you run your code, actually helps a lot remote  teams because it sets a number of boundaries that don't just work because people share  the same code intimately over the same keyboard.  But in a more flexible environment.  No code ownership, the same.  It's easier to work with a remote colleague if we all agree that a certain area of the  code can be improved by all members of the teams.  And especially what we call visual radiators, meaning that you have structures that help  understand what's the status of the project, like backlog, boards, all kinds of artifacts  that you can either share in your office or in a virtual board.  But then comes the kicker.  We know instead from experience and from work with companies that actually the most effective  teams are the ones that are co-located, meaning that they work in the same office.  For example, in large American companies, they discover that not only they have to be  on the same building, but they have to be tied together.  Even if people have nice offices far from each other, it's better to put them together  so they can contribute more.  That seems to break the whole reason of remote working.  This is a principle from the Agile manifesto, and we know it's a few years old by now.  And it says explicitly that the most efficient and effective method of conveying information  to and within a development team is face-to-face conversation.  So this looks like a problem.  But I would like to parse this principle because it seems obvious from the face of it, and  I think it keeps standing if you check carefully what it means.  So for example, we should discuss exactly what we mean by face-to-face, because in the  good old days, it was quite obvious to say that face-to-face meant some people in the  office or even some people around the table.  Some people around the table discussing the problems of a software project.  But now we are in a completely different culture.  Part of what face-to-face meant was proximity, you are next to your colleague, but also a  sense of truthfulness, meaning that what face-to-face was against, was against thick documentation  that moved from one level to another, large meetings when there is no real discussion,  and these kind of things that were common in enterprise development.  So a face-to-face discussion not only means that we are standing with our bodies in short  proximity, also means that we talk to each other without a barrier and telling things  exactly how they are.  In the 21st century in 2018, we have a lot of this conversation in chats, group chats,  over electronic messaging.  You can be really true with your colleague in Slack and you can just say a lie face-to-face.  So Slack, Skype, WhatsApp and Gout are now very common tools for teams.  And this is 99% of what face-to-face means in that sense.  Of course, there is still an aspect of body language and the pleasure of interacting with  each other that we don't want to discount, but it's not the key part of face-to-face.  And the reason to be face-to-face is to exchange information.  So what can we call information in the area of project development?  Well, the most obvious is discussion about the project, so how we should do some things,  how we should move forward and so on.  Very specific details about the code, very specific details about design, the artifacts  that the development team does.  And also, you want to communicate to your team the things that worked, commits, tasks  done, the things that didn't work, all the bugs, all the regressions.  And you want to chit-chat and grow that team culture that is very important for a successful  project.  Yes, this is all information.  These are all things we talk to our colleagues about.  Do we really need to be in close proximity to do this?  Not necessarily, because all these things you can, for example, rely on a Slack channel.  Slack is very popular, Skype chat or even Google email.  Some of these things are actually better to be discussed online, especially if you are  talking about code or design, having a shell screen helps you more than just discussing  it at a meeting.  So we go back to that article by Zach, and where he says that using a culture where everything  you do is either manually or automatically pushed into a communication channel, and for  example, he mentioned chatbots, a tool that takes an action from some other system and  puts it automatically in your chat, then you create a culture where it's not important  if you're in the office.  It's not important if you're in the office that day.  It's not important if you are in the office ever, because basically we are all remote  workers from different locations.  Some of them accidentally are in the same office, and we all contribute to the same project  and to the same communication channel.  So basically it's a cultural challenge rather than a plain old technical challenge.  This is a new slide that I added a couple of days ago.  There are articles from the enterprise side of things, for example from the Harvard Business  Review that start to talk about this change in the workplace.  It's not just for one team here and there, but it's a real change that's happening in  the workplace where electronic tools are the glue that keep together a remote team.  This is a tweet from Leigh Bryant, a researcher at Postshift, and I suggest you check him  out.  He always writes very interesting stuff.  So one reason to do this at a conference like DjangoCon is to help teams and individuals  that want to go down this path.  So here I would like to tell how we do it with our team at Agile 42.  Basically we have a lot of shared stuff.  We have a shared code repository, and possibly this is reachable from the outside.  You have GitHub, you have Bitbucket, some companies may have security issues.  It's something you can work around.  We have automated unit testing and integration testing.  That's what I said that Agile methodologies or plain old methodologies from extreme programming  they come very useful because all testing helps create a safety net for developers, especially  developers who don't have someone next desk to confront with.  They can just rely on the structure and they can move their code forward in a more sustainable  way.  Of course we have continuous integration, which is pretty common nowadays, but helps  us with contributing code from different individuals who are not necessarily synced, especially  in time zones or in working hours.  We have boards, we use all kinds of task planning, and also we like to test a lot of things.  All of this, of course, must be available from any location, and all of this goes into a  channel, which is our main communication channel and the heartbeat of our project.  But of course you also have to adjust your personal style and the way that the team interacts  with each other in order to make it work.  If you do Agile methodologies and I strongly suggest you should do it and you do your Agile  ceremony starting with the daily stand up, with the sprint planning, the reviewer at  respect this and whatever your method calls for, you do it online.  You do it in a way that allows remote workers to attend and remote workers to contribute.  For example, with my team we connect regularly over Skype, we even see each other that helps  with the distance barrier, and we do our sprint reviews, we do our daily stand ups.  You should not work alone in the sense that you wake up in the morning, you just hack  your code and you go to bed, possibly other things as well.  But you should contribute to the life of the project.  You should say, I'm going to do this, I'm going to do that.  Or if you are going to do that to a colleague, then I can help, or I think this is a better  idea to follow up.  One thing that I discovered in my career that is a bit against the whole dream of remote  working is that having working hours that are compatible with the rest of the team, especially  if you have some team, some parts of the team that work out of an office and therefore they  do something more closely aligned to 9-5, or at least to be available around the time  where you expect other members of the team to be online.  And you have to keep that chat channel open during work hours.  It's basically your way of checking in in the office and checking out from the office.  I know that a major company that does remote working, full remote working, so we would  say remote first, has one of the few requirements is to keep the chat channel open during work  hours.  You cannot be remote 100% of the time.  Occasionally you have to meet.  If it's more than occasionally, it's nice.  The kind of interactions you have when you are face-to-face are different from the ones  you have online.  And sometimes they are just funnier or sometimes they are just more forward thinking, so it  helps with the planning.  So every remote team should just meet occasionally just to sync up and to put a face to the presence  online.  And of course, there are a few companies, just named two, that do remote first.  They like to talk about it.  They like to explain the tools they are using.  And so it's a good source of inspiration.  This is, for example, a screenshot.  And I understand that the details may be lost.  But this is a screenshot from our own Slack channel of developers.  And you see, for example, Slackbot that remind us of agile ceremonies like a stand-up, an  error message from our bug tracker, Trail-Low, which we use for lightweight project management,  sending out comments about a work in progress, and things like this.  And you see the comments.  You see, for example, coming from GitLab comments attached to a specific story.  They are pushed also into the channel.  That's what we meant as chatbots trying to keep the communication channel alive and to  put everything so we can comment on.  These are a lot of statuses from our continuous integration project.  And this is much more lively discussion about a certain feature, what we should do about  it.  And I can say that I'm not sure where the people were at that time.  I was remote in Milan, but other people were probably on vacation and contributing a little  bit.  So this is the way we keep a project moving forward.  And of course, they come from Slack, which a lot of people are using these days for this.  So we are using a lot of tools to do that.  And these tools change constantly over time.  We are continuously refining and changing.  As we said, we do test driving development, and we use unit tests, Selenium.  We have a lot of visual tests to align with what we want to achieve.  We try to do infrastructure as code, another layer that helps us get away from the concept  of having a staging server and a test server.  At the moment, we mostly use virtual machines, but Docker is a very nice solution.  So I was very happy to hear from Lacey from the talk before.  If I understand correctly, she's also a remote developer.  So we see how all these techniques come together.  And recently, we've moved to GitLab, our own hosted GitLab as a Git repository and project  center for our development.  This also allows us to use pipelines for continuous integration, tying even closer together the  development, the project management, and the continuous integration inside GitLab.  At that point, we integrated GitLab with Slack and with Sentry, which is a tool to alert  of bugs.  And we created this chatbot that allows us to see almost everything that is happening  in the project in real time.  We also moved project management to GitLab with boards and some Trello, which is always  nice because it's very lightweight.  As I mentioned, we use Skype for the agile ceremonies and Google Docs, whatever.  Basically, we try everything that can be helpful for having a team that is not in the same  office to coordinate and exchange information.  Here I have a screenshot of a pipeline.  A pipeline is in GitLab.  It's a set of tasks that you can do to test and build and install on either staging or  development machine.  And this is very helpful because it's triggered automatically by a commit in the repository.  And this allows us to work as a team and not having, for example, a person who is only  tasked with code integration and code testing and therefore may feel detached from the team.  As you can see here, we configured WebBooks from GitLab into Slack to notify everything  that's happening in the project inside our communication channel and therefore to be  alerted about what's going on.  Another tool that I wanted to mention is Sentry, which is an add-on to your code that alerts  you of errors and problems and is configured to feed into the Slack channel as well.  So if we go back to this, you see, for example, notification from Sentry that app automatically  on the channel and allow the team to talk straight away about what's going on if it's  just a small problem or if it's a major problem and needs to be tackled.  Here instead, you see more notification about the code and the integration of pipelines  coming from GitLab.  All marked with a team member that contributed to that code allow us to give a sense of what's  going on in the development at that specific moment.  And so, for example, you see the great advantage of this approach is to intermix this automatic  notification from, for example, from GitLab with personal comments.  This means that you don't have a separated channel for the more technical stuff, but  it's all part of the team discussion and you can have a better sense of what's going  on in the project without having to move from one project, from one tool to the other.  Okay.  Thank you.  I think I ran a bit fast because I'm always afraid of going too late, so I'm open for  questions.  Thank you.  That's for you.  Thank you.  We have time for questions.  Hello.  I am a 100% full-time reward worker.  I don't do meetings in person.  I don't go to see clients.  The only time I see clients is at events like this.  And one of the things you said kind of bothered me and I wanted to know if you could tell  more about this is that you said that a lot of companies, when it's the communications  channel to be open during business hours.  And this in my experience is really bad because people see you online and they want to talk  to you, and so you don't have your time to concentrate and do your work.  You're constantly interrupted, so do you have any guidelines that you want to share to avoid  this kind of problem?  Yes.  It's an extremely good question because it opens up the whole area, which is kind of  team management.  So what do you expect from your team members and so on?  In this respect, I don't think it's different from a team that is located in the same office.  You shouldn't assume that since your co-worker is at the desk next to you, is always ready  to take questions.  And this basically happens in the same way when you're remote.  Since you're remote, you're not expected to be available to chat at any moment because  just because you have a green dot next to your avatar or something similar depending  on the tool you use.  One thing that I skipped over because it's a lot of other things is you have to have a  working agreement with your team.  A working agreement is a term we use a lot in agile coaching, and basically it starts  with nothing, with an empty piece of paper, and can grow to be extremely complicated.  The working agreement you have with your team is, for example, that you are online, it doesn't  mean that you're available.  You may say on the channel, well, today I'm just doing lightweight work, and so I'm free  if anyone needs help.  Or the contrary, usually you're free, but if today you're going to do something that  really needs concentration, I'm not available for anything.  I cannot give you exactly what's best.  The thing I can say is you have to talk about it in the team.  You have to come up with something that is probably written down because it helps.  Just you have a shared document and you put down these rules.  We prefer to call it working agreement.  Sometimes the rules are pushed down by management.  That's unfortunate.  Sometimes it's necessary.  The thing I said is, yes, management asks this, has to have the chat channel open.  Is good or is bad?  Well, they probably have their reasons.  It's something that is part of a discussion.  It's as part of an agile coaching company, something that probably gets a lot from us.  I'm sorry, you have to talk about it because that's the key.  You have to define your own process.  One thing I can suggest more precisely, one of the ceremonies is the daily stand-up.  It's common to most agile methodologies.  We found it's very useful.  Even if you and the rest of your team are working on different projects or different sub-projects,  different tasks, even if you work remotely at even a different time zones, you should  find a time each day to sync up with the rest of the team.  For example, myself and my team, we do it at 3 p.m. each day and over Skype.  If you're really busy with your project or from the task you're doing, which is part  of a larger project, you should still find time to do these five to 15 minutes and these  five to 15 minutes say to the rest of the team, I'm working on this.  I'm sorry, guys.  I cannot help with anything else because I'm 100% focused on this and the team should  understand.  Then, at that point, if someone chats you up, did you see the thing?  I said, I'm sorry.  I said very specifically that today is devoted to this.  Then we enter in the area of rudeness, which is a completely different thing.  Since it's a ceremony and it's not when you have time, but it's a fixed time each day,  you plan your day around it.  If you know it's first thing in the morning or after a break and so on, it's not interrupting  you because you plan your day around it.  Everyone gathers around, either in person or with a tool.  They tell each other how much they're available to help each other with the things I'm working  on.  I hope it helps.  Thank you.  That's another question at the back, if you're up for that?  Yes, definitely.  Yes, thank you.  I too had an issue with one of the things you said.  No code ownership.  This resonated with one of my personal mantras, which is, if you write it, you own it.  Which means take responsibility.  How do you avoid, if people are not allowed to own parts of the code, how do you avoid  that nobody takes responsibility for problems that arise?  Well, the responsibility is from the team.  If you work in a team and our idea is that we always work in a team rather than individuals,  of course, if you're being subcontracted to just work on a specific piece of software  and you're the only one really working on it, so things may be different.  But in most cases, you work on a project as a team.  The code is owned by the team.  The team has responsibility and individuals within the team may take action on a specific  part of code, on a specific task.  Always saying to the rest of the team, we are doing this because of this.  I've chosen this solution because of this.  Other members may contribute or may even change it, giving explanations.  Now, if someone from your team enter in the code you've been working on for six months  at very astute level with a lot of good ideas and put bad code inside it because he didn't  understand what you were trying to do and commits it, then again, we enter the state  of rudeness.  It's a problem within the team.  It's a problem that your colleagues are not up to the same level of quality that you have  and you should have a discussion with them about this.  I understand, since I always had a career as a developer, how we feel about the code  and the artifacts we have developed.  Without entering into the world of code reviews and also pair programming, which is very useful  and now basically can also be done online in a number of ways, you should always be  up for discussion and review of what you've done with the rest of the team.  In this respect, the responsibility of what the code does moves from yourself personally  to the whole team.  I don't know if it's the answer you wanted to hear.  No, it's exactly what I wanted to hear.  Thank you.  Okay, thank you.  Okay, that's one more question in the front.  So I wanted to add to the first question.  And I think that one of the most common problems with tools like Slack is defining what has  to be real-time communication, what can happen offline.  So imagine I have an issue.  I want to talk to someone.  It's like a lightweight meeting which had for five minutes that works.  But if there's something that requires somebody's attention and doesn't have to happen immediately,  then an email is probably better or a ticket or whatever.  So my question is how do you define the things that can go on Slack and things that you probably  better not put on Slack because then they will be buried by 500 more messages.  And it was something that could have waited and it's better if you deal with it like once  a day when you look at your emails or tickets or whatever.  Yes, sure.  No, as you probably noticed from my hair, I'm not exactly a freshman out of college.  So I grew up with email and I still find that email is an extremely valuable tool.  You can express your point of view, especially about the design of code or a project much  more clearly and allows for also for a bit more time to articulate your message.  So my coworkers get a lot of emails from me.  I'm active on the company's lack, but they get more emails and sometimes they say, oh,  it's one of those long emails from Alessio again.  And they say, well, which is my boundary between Slack, real time communication and email.  I think the synchronous evaluation is the best one.  As I mentioned, I have a rough feeling of the time my coworkers are in the office or  they are active.  I don't know for sure, especially, you know, 5 p.m. is the in is the out or whatever, but  I have a rough idea.  So I don't like the evenings, Saturdays and Sundays or things like that.  And also I don't push long discussions over Slack.  By definition, a long discussion, something that I want to say about the project doesn't  need to be resolved in the next five minutes.  It's something that can wait and can also have a longer discussion.  And I put it in an email and I explain, well, this is my point of view.  We can discuss it.  Or sometimes I say, if you have some idea, just let's chat about it or let's review  it at the next stand-up meeting, which is always a good syncing point for this kind  of stuff.  Nowadays, I've moved to an even more asynchronous way, meaning if I have something very long  to say, I usually put it in a Google doc allowing other members of the team to comment and even  edit what I've written.  I use chat, basically now Slack, but in the past it was Skype and other tools.  Just when I have something to ask to a co-worker of mine that would be in a traditional office  just moving to their desk and asking, so are you working on this?  Have you seen that problem?  Do you think we should act immediately or it can wait?  What are your plans for today and things like this?  Or help, help, help.  The server has a system load of 120 and I ran out of ideas and that's probably the best  use for an instant message.  Yes.  Thank you.  Thank you.  Last slide, I will put them on slideshare.  There are some links to things I talked about and don't panic.
DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_0_59.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_60_359.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_360_683.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_684_1715.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_1716_1835.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_1836_2039.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_2040_2135.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_2136_2963.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_2964_5327.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_5328_5795.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_5796_7151.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_7152_7955.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_7956_14279.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_14280_17579.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_17580_17687.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_17688_17903.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_17904_20135.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_20136_21839.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_21840_23447.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_23448_23531.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_23532_25739.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_25740_37979.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_37980_40559.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_40560_42647.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_42648_46403.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_46404_52511.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_52512_52703.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_52704_55055.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_55056_55175.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_55176_55631.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_55632_55871.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_55872_57455.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_57456_57647.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_57648_59447.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_59448_60383.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_60384_60455.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_60456_60695.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_60696_61643.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_61644_62171.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_62172_62531.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_62532_64727.png DjangoCon_2018_-_Out_of_Sight__Out_of_Mind__Survival_tricks_and_tools_for_remote_64728_64935.png
It's very nice to be here. It's very nice to be here in Eidelberg. It's my first time at DjangoCon Europe. This talk, I presented it in a slightly different way yesterday, yesterday here at PyCon in Florence. The funny thing about this talk is that one year to the next, a lot of things change. So it's very nice to revisit. We will talk about remote working. Remote working is an extremely big topic. We will just cover the tip of the iceberg. I will try to make it short. There could be time for some questions at the end. It's very nice to do it in a conference when there is streaming, live streaming. So there are people out there watching now, probably remote developers. So I would say hello to everyone who is a remote developer and is taking time out of the schedule to watch the conference from another location, which is kind of the point of the whole thing. Another thing is Tower Day. I work for a company that has 42 in the name, so we cannot just ignore it. Our company motto is don't panic, which is always a very useful thing to say and to keep in mind. The other thing is GDPR Day. So again, don't panic. It's very nice to be in such a theater. It's probably my first time on a proper stage with a proper microphone and with all the technology. So it's tempting to feel like a rock star. I'm not a rock star. So I would like to introduce a bit who I am and the people I work with because it's very relevant for the kind of talk I'm introducing. I'm mostly a web developer, always been in my career, and especially I work with Django and Python and that's the reason I'm here. As I said, I work with a company that has Agile 42 in the name. It's a coaching and training company. And we are a very distributed company in Europe, in North America, and in South Africa. And especially our web and IT team has a network in Berlin and a number of people, including myself, that work remotely. And in particular, I work from Milan. And not only I work remotely for this job, but I used to do it also for previous jobs. So I have a bit of experience in that. I've seen it all. I've also worked in offices, so I see the difference. And basically the question I ask myself every day is how this is possible to do effectively and without too much stress. You know the dream. The dream is to be an IT worker that works whenever they want, usually from the beach with flexible hours, leaving a very nice lifestyle. But actually the reality is that you work out of a cramped space. You work in not very good hours. You basically have all the problems of working in an office and none of the perks like chatting with your friends at the water cooler or around the cup of coffee. Not to mention that remote working has this kind of peril. It's very nice that you still left this slide because it's a slide from last year and I was wondering, will it be still relevant today? But yeah, you know what I'm talking about. So let's get a bit to the core problem that we may face. I took this quotation from an article that is linked there from Zach Holman. And I think it encapsulates very nicely the problem. First difference between a remote friendly company and a remote first company. A remote friendly company is a lot of IT companies these days. You can do one or more days of work at home. You can take time off. You can do flexible hours. The result is what really counts and not the number of hours you spend in the office. But still there is an office and people who choose not to work in that office. A remote first company instead is a company that breaks the structure of the office work and creates a workflow that allows people to contribute in a more free environment and a more free structure. And that's really the challenge for this century. As I mentioned, we work in agile coaching. Agile methodologies, the whole culture of agile, tries to help companies to work better and workers to work more effectively without burning out. So we ask, can agile methodologies help remote workers or can agile methodologies help a remote culture in the company? We think there are a certain set of agile methodologies that definitely help remote working. For example, a culture of TDD, which means test drive and development, which means that you create first set of tests against which you run your code, actually helps a lot remote teams because it sets a number of boundaries that don't just work because people share the same code intimately over the same keyboard. But in a more flexible environment. No code ownership, the same. It's easier to work with a remote colleague if we all agree that a certain area of the code can be improved by all members of the teams. And especially what we call visual radiators, meaning that you have structures that help understand what's the status of the project, like backlog, boards, all kinds of artifacts that you can either share in your office or in a virtual board. But then comes the kicker. We know instead from experience and from work with companies that actually the most effective teams are the ones that are co-located, meaning that they work in the same office. For example, in large American companies, they discover that not only they have to be on the same building, but they have to be tied together. Even if people have nice offices far from each other, it's better to put them together so they can contribute more. That seems to break the whole reason of remote working. This is a principle from the Agile manifesto, and we know it's a few years old by now. And it says explicitly that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. So this looks like a problem. But I would like to parse this principle because it seems obvious from the face of it, and I think it keeps standing if you check carefully what it means. So for example, we should discuss exactly what we mean by face-to-face, because in the good old days, it was quite obvious to say that face-to-face meant some people in the office or even some people around the table. Some people around the table discussing the problems of a software project. But now we are in a completely different culture. Part of what face-to-face meant was proximity, you are next to your colleague, but also a sense of truthfulness, meaning that what face-to-face was against, was against thick documentation that moved from one level to another, large meetings when there is no real discussion, and these kind of things that were common in enterprise development. So a face-to-face discussion not only means that we are standing with our bodies in short proximity, also means that we talk to each other without a barrier and telling things exactly how they are. In the 21st century in 2018, we have a lot of this conversation in chats, group chats, over electronic messaging. You can be really true with your colleague in Slack and you can just say a lie face-to-face. So Slack, Skype, WhatsApp and Gout are now very common tools for teams. And this is 99% of what face-to-face means in that sense. Of course, there is still an aspect of body language and the pleasure of interacting with each other that we don't want to discount, but it's not the key part of face-to-face. And the reason to be face-to-face is to exchange information. So what can we call information in the area of project development? Well, the most obvious is discussion about the project, so how we should do some things, how we should move forward and so on. Very specific details about the code, very specific details about design, the artifacts that the development team does. And also, you want to communicate to your team the things that worked, commits, tasks done, the things that didn't work, all the bugs, all the regressions. And you want to chit-chat and grow that team culture that is very important for a successful project. Yes, this is all information. These are all things we talk to our colleagues about. Do we really need to be in close proximity to do this? Not necessarily, because all these things you can, for example, rely on a Slack channel. Slack is very popular, Skype chat or even Google email. Some of these things are actually better to be discussed online, especially if you are talking about code or design, having a shell screen helps you more than just discussing it at a meeting. So we go back to that article by Zach, and where he says that using a culture where everything you do is either manually or automatically pushed into a communication channel, and for example, he mentioned chatbots, a tool that takes an action from some other system and puts it automatically in your chat, then you create a culture where it's not important if you're in the office. It's not important if you're in the office that day. It's not important if you are in the office ever, because basically we are all remote workers from different locations. Some of them accidentally are in the same office, and we all contribute to the same project and to the same communication channel. So basically it's a cultural challenge rather than a plain old technical challenge. This is a new slide that I added a couple of days ago. There are articles from the enterprise side of things, for example from the Harvard Business Review that start to talk about this change in the workplace. It's not just for one team here and there, but it's a real change that's happening in the workplace where electronic tools are the glue that keep together a remote team. This is a tweet from Leigh Bryant, a researcher at Postshift, and I suggest you check him out. He always writes very interesting stuff. So one reason to do this at a conference like DjangoCon is to help teams and individuals that want to go down this path. So here I would like to tell how we do it with our team at Agile 42. Basically we have a lot of shared stuff. We have a shared code repository, and possibly this is reachable from the outside. You have GitHub, you have Bitbucket, some companies may have security issues. It's something you can work around. We have automated unit testing and integration testing. That's what I said that Agile methodologies or plain old methodologies from extreme programming they come very useful because all testing helps create a safety net for developers, especially developers who don't have someone next desk to confront with. They can just rely on the structure and they can move their code forward in a more sustainable way. Of course we have continuous integration, which is pretty common nowadays, but helps us with contributing code from different individuals who are not necessarily synced, especially in time zones or in working hours. We have boards, we use all kinds of task planning, and also we like to test a lot of things. All of this, of course, must be available from any location, and all of this goes into a channel, which is our main communication channel and the heartbeat of our project. But of course you also have to adjust your personal style and the way that the team interacts with each other in order to make it work. If you do Agile methodologies and I strongly suggest you should do it and you do your Agile ceremony starting with the daily stand up, with the sprint planning, the reviewer at respect this and whatever your method calls for, you do it online. You do it in a way that allows remote workers to attend and remote workers to contribute. For example, with my team we connect regularly over Skype, we even see each other that helps with the distance barrier, and we do our sprint reviews, we do our daily stand ups. You should not work alone in the sense that you wake up in the morning, you just hack your code and you go to bed, possibly other things as well. But you should contribute to the life of the project. You should say, I'm going to do this, I'm going to do that. Or if you are going to do that to a colleague, then I can help, or I think this is a better idea to follow up. One thing that I discovered in my career that is a bit against the whole dream of remote working is that having working hours that are compatible with the rest of the team, especially if you have some team, some parts of the team that work out of an office and therefore they do something more closely aligned to 9-5, or at least to be available around the time where you expect other members of the team to be online. And you have to keep that chat channel open during work hours. It's basically your way of checking in in the office and checking out from the office. I know that a major company that does remote working, full remote working, so we would say remote first, has one of the few requirements is to keep the chat channel open during work hours. You cannot be remote 100% of the time. Occasionally you have to meet. If it's more than occasionally, it's nice. The kind of interactions you have when you are face-to-face are different from the ones you have online. And sometimes they are just funnier or sometimes they are just more forward thinking, so it helps with the planning. So every remote team should just meet occasionally just to sync up and to put a face to the presence online. And of course, there are a few companies, just named two, that do remote first. They like to talk about it. They like to explain the tools they are using. And so it's a good source of inspiration. This is, for example, a screenshot. And I understand that the details may be lost. But this is a screenshot from our own Slack channel of developers. And you see, for example, Slackbot that remind us of agile ceremonies like a stand-up, an error message from our bug tracker, Trail-Low, which we use for lightweight project management, sending out comments about a work in progress, and things like this. And you see the comments. You see, for example, coming from GitLab comments attached to a specific story. They are pushed also into the channel. That's what we meant as chatbots trying to keep the communication channel alive and to put everything so we can comment on. These are a lot of statuses from our continuous integration project. And this is much more lively discussion about a certain feature, what we should do about it. And I can say that I'm not sure where the people were at that time. I was remote in Milan, but other people were probably on vacation and contributing a little bit. So this is the way we keep a project moving forward. And of course, they come from Slack, which a lot of people are using these days for this. So we are using a lot of tools to do that. And these tools change constantly over time. We are continuously refining and changing. As we said, we do test driving development, and we use unit tests, Selenium. We have a lot of visual tests to align with what we want to achieve. We try to do infrastructure as code, another layer that helps us get away from the concept of having a staging server and a test server. At the moment, we mostly use virtual machines, but Docker is a very nice solution. So I was very happy to hear from Lacey from the talk before. If I understand correctly, she's also a remote developer. So we see how all these techniques come together. And recently, we've moved to GitLab, our own hosted GitLab as a Git repository and project center for our development. This also allows us to use pipelines for continuous integration, tying even closer together the development, the project management, and the continuous integration inside GitLab. At that point, we integrated GitLab with Slack and with Sentry, which is a tool to alert of bugs. And we created this chatbot that allows us to see almost everything that is happening in the project in real time. We also moved project management to GitLab with boards and some Trello, which is always nice because it's very lightweight. As I mentioned, we use Skype for the agile ceremonies and Google Docs, whatever. Basically, we try everything that can be helpful for having a team that is not in the same office to coordinate and exchange information. Here I have a screenshot of a pipeline. A pipeline is in GitLab. It's a set of tasks that you can do to test and build and install on either staging or development machine. And this is very helpful because it's triggered automatically by a commit in the repository. And this allows us to work as a team and not having, for example, a person who is only tasked with code integration and code testing and therefore may feel detached from the team. As you can see here, we configured WebBooks from GitLab into Slack to notify everything that's happening in the project inside our communication channel and therefore to be alerted about what's going on. Another tool that I wanted to mention is Sentry, which is an add-on to your code that alerts you of errors and problems and is configured to feed into the Slack channel as well. So if we go back to this, you see, for example, notification from Sentry that app automatically on the channel and allow the team to talk straight away about what's going on if it's just a small problem or if it's a major problem and needs to be tackled. Here instead, you see more notification about the code and the integration of pipelines coming from GitLab. All marked with a team member that contributed to that code allow us to give a sense of what's going on in the development at that specific moment. And so, for example, you see the great advantage of this approach is to intermix this automatic notification from, for example, from GitLab with personal comments. This means that you don't have a separated channel for the more technical stuff, but it's all part of the team discussion and you can have a better sense of what's going on in the project without having to move from one project, from one tool to the other. Okay. Thank you. I think I ran a bit fast because I'm always afraid of going too late, so I'm open for questions. Thank you. That's for you. Thank you. We have time for questions. Hello. I am a 100% full-time reward worker. I don't do meetings in person. I don't go to see clients. The only time I see clients is at events like this. And one of the things you said kind of bothered me and I wanted to know if you could tell more about this is that you said that a lot of companies, when it's the communications channel to be open during business hours. And this in my experience is really bad because people see you online and they want to talk to you, and so you don't have your time to concentrate and do your work. You're constantly interrupted, so do you have any guidelines that you want to share to avoid this kind of problem? Yes. It's an extremely good question because it opens up the whole area, which is kind of team management. So what do you expect from your team members and so on? In this respect, I don't think it's different from a team that is located in the same office. You shouldn't assume that since your co-worker is at the desk next to you, is always ready to take questions. And this basically happens in the same way when you're remote. Since you're remote, you're not expected to be available to chat at any moment because just because you have a green dot next to your avatar or something similar depending on the tool you use. One thing that I skipped over because it's a lot of other things is you have to have a working agreement with your team. A working agreement is a term we use a lot in agile coaching, and basically it starts with nothing, with an empty piece of paper, and can grow to be extremely complicated. The working agreement you have with your team is, for example, that you are online, it doesn't mean that you're available. You may say on the channel, well, today I'm just doing lightweight work, and so I'm free if anyone needs help. Or the contrary, usually you're free, but if today you're going to do something that really needs concentration, I'm not available for anything. I cannot give you exactly what's best. The thing I can say is you have to talk about it in the team. You have to come up with something that is probably written down because it helps. Just you have a shared document and you put down these rules. We prefer to call it working agreement. Sometimes the rules are pushed down by management. That's unfortunate. Sometimes it's necessary. The thing I said is, yes, management asks this, has to have the chat channel open. Is good or is bad? Well, they probably have their reasons. It's something that is part of a discussion. It's as part of an agile coaching company, something that probably gets a lot from us. I'm sorry, you have to talk about it because that's the key. You have to define your own process. One thing I can suggest more precisely, one of the ceremonies is the daily stand-up. It's common to most agile methodologies. We found it's very useful. Even if you and the rest of your team are working on different projects or different sub-projects, different tasks, even if you work remotely at even a different time zones, you should find a time each day to sync up with the rest of the team. For example, myself and my team, we do it at 3 p.m. each day and over Skype. If you're really busy with your project or from the task you're doing, which is part of a larger project, you should still find time to do these five to 15 minutes and these five to 15 minutes say to the rest of the team, I'm working on this. I'm sorry, guys. I cannot help with anything else because I'm 100% focused on this and the team should understand. Then, at that point, if someone chats you up, did you see the thing? I said, I'm sorry. I said very specifically that today is devoted to this. Then we enter in the area of rudeness, which is a completely different thing. Since it's a ceremony and it's not when you have time, but it's a fixed time each day, you plan your day around it. If you know it's first thing in the morning or after a break and so on, it's not interrupting you because you plan your day around it. Everyone gathers around, either in person or with a tool. They tell each other how much they're available to help each other with the things I'm working on. I hope it helps. Thank you. That's another question at the back, if you're up for that? Yes, definitely. Yes, thank you. I too had an issue with one of the things you said. No code ownership. This resonated with one of my personal mantras, which is, if you write it, you own it. Which means take responsibility. How do you avoid, if people are not allowed to own parts of the code, how do you avoid that nobody takes responsibility for problems that arise? Well, the responsibility is from the team. If you work in a team and our idea is that we always work in a team rather than individuals, of course, if you're being subcontracted to just work on a specific piece of software and you're the only one really working on it, so things may be different. But in most cases, you work on a project as a team. The code is owned by the team. The team has responsibility and individuals within the team may take action on a specific part of code, on a specific task. Always saying to the rest of the team, we are doing this because of this. I've chosen this solution because of this. Other members may contribute or may even change it, giving explanations. Now, if someone from your team enter in the code you've been working on for six months at very astute level with a lot of good ideas and put bad code inside it because he didn't understand what you were trying to do and commits it, then again, we enter the state of rudeness. It's a problem within the team. It's a problem that your colleagues are not up to the same level of quality that you have and you should have a discussion with them about this. I understand, since I always had a career as a developer, how we feel about the code and the artifacts we have developed. Without entering into the world of code reviews and also pair programming, which is very useful and now basically can also be done online in a number of ways, you should always be up for discussion and review of what you've done with the rest of the team. In this respect, the responsibility of what the code does moves from yourself personally to the whole team. I don't know if it's the answer you wanted to hear. No, it's exactly what I wanted to hear. Thank you. Okay, thank you. Okay, that's one more question in the front. So I wanted to add to the first question. And I think that one of the most common problems with tools like Slack is defining what has to be real-time communication, what can happen offline. So imagine I have an issue. I want to talk to someone. It's like a lightweight meeting which had for five minutes that works. But if there's something that requires somebody's attention and doesn't have to happen immediately, then an email is probably better or a ticket or whatever. So my question is how do you define the things that can go on Slack and things that you probably better not put on Slack because then they will be buried by 500 more messages. And it was something that could have waited and it's better if you deal with it like once a day when you look at your emails or tickets or whatever. Yes, sure. No, as you probably noticed from my hair, I'm not exactly a freshman out of college. So I grew up with email and I still find that email is an extremely valuable tool. You can express your point of view, especially about the design of code or a project much more clearly and allows for also for a bit more time to articulate your message. So my coworkers get a lot of emails from me. I'm active on the company's lack, but they get more emails and sometimes they say, oh, it's one of those long emails from Alessio again. And they say, well, which is my boundary between Slack, real time communication and email. I think the synchronous evaluation is the best one. As I mentioned, I have a rough feeling of the time my coworkers are in the office or they are active. I don't know for sure, especially, you know, 5 p.m. is the in is the out or whatever, but I have a rough idea. So I don't like the evenings, Saturdays and Sundays or things like that. And also I don't push long discussions over Slack. By definition, a long discussion, something that I want to say about the project doesn't need to be resolved in the next five minutes. It's something that can wait and can also have a longer discussion. And I put it in an email and I explain, well, this is my point of view. We can discuss it. Or sometimes I say, if you have some idea, just let's chat about it or let's review it at the next stand-up meeting, which is always a good syncing point for this kind of stuff. Nowadays, I've moved to an even more asynchronous way, meaning if I have something very long to say, I usually put it in a Google doc allowing other members of the team to comment and even edit what I've written. I use chat, basically now Slack, but in the past it was Skype and other tools. Just when I have something to ask to a co-worker of mine that would be in a traditional office just moving to their desk and asking, so are you working on this? Have you seen that problem? Do you think we should act immediately or it can wait? What are your plans for today and things like this? Or help, help, help. The server has a system load of 120 and I ran out of ideas and that's probably the best use for an instant message. Yes. Thank you. Thank you. Last slide, I will put them on slideshare. There are some links to things I talked about and don't panic.
will talk about remote working. Remote working is with because it's very relevant for the kind of with Django and Python and that's the reason I'm training company. And we are a very distributed actually the reality is that you work out of a these days. You can do one or more days of work of artifacts that you can either share in your kicker. We know instead from experience and from artifacts that the development team does. And that the team interacts with each other in order of tools to do that. And these tools change management. So what do you expect from your team team are working on different projects or you work remotely at even a different time zones, problem that your colleagues are not up to the other members of the team to comment and even Slack, but in the past it was Skype and other