 Hi, I'm Dan Gordon, Technical Marketing from GitLab. This is GitLab for remote teams. When working in a remote software development and delivery team, there can be new challenges around coordination, collaboration, and efficiency. In this video, we'll look at some best practices and how they can not just enable but enhance remote teams. Our first best practice is to document everything. Don't just document the decisions, but also capture the discussions which led up to those decisions. This way, others, like those in different time zones or with other priorities, can catch up and then still contribute. Using GitLab issues to have written conversations about the work you are doing means that plans, processes, and execution are automatically documented. What's more, because issues are a many to many channel, it's easy to invite others to collaborate at any time. All that's required is to at mention them and they'll be notified so they can join the collaboration. Connect strategy and execution. Teams that understand the purpose of what they're doing do better work. When your team is remote or when your team grows large enough to require several subteams, communication becomes more difficult and it becomes even harder to make sure everyone is working towards the same goals. GitLab roadmaps can help by providing a way to organize and visualize your entire portfolio of work and they can help remote teams to see the overall plan and big picture of the work they are doing no matter where in the world they are working from. Roadmaps provide a time-based summary view of the epics in the plan and also reflect percentage done, which helps you to assess whether or not the plan is on target. From roadmaps, you can dive down into the GitLab epics which represent entire features or projects and can help teams to stay focused on the larger customer value their work is intended to achieve. Epics can contain other epics and issues. Issues represent day-to-day or week-to-week tasks. Coordinating more than a few people on a single project can prove to be a challenge. When it comes to remote teams, it's even harder to be able to keep track of the status of the work that is being done and you can't require synchronous in-person meetings to keep everyone on the same page. Labels, which can be on epics, issues and merge requests, can help by enabling you to categorize your work in many different ways, such as into workflow stages, like backlog, development and QA. Labels are flexible, so another example of their use is to track which issues are from customer feedback. The combination of labels and GitLab boards give you the visibility and control over how work is being done. They behave like flexible whiteboards, which can reshuffle your post-it notes for you to give you many different views of your work and how it is progressing. Some examples are scrum or Kanban tracking, sprint planning, or even who's working on what. And boards are all online, so you don't have to be in the same conference room to participate or keep track. Speaking of tracking work, GitLab's milestones help you to track work against certain periods of time, whether you call them sprints, releases, or quarters. Milestones enable you to track issues as they move through the development cycle. You can set optional start and due dates. And milestones provide visuals such as burn down charts to help your team to improve their time estimates. Review and collaborate. Teams who do peer reviews and collaborate more produce better software more efficiently. On remote teams, the effort to do this becomes harder, and therefore peer reviews and collaboration become less likely to happen. GitLab's advanced code review functionality is built right into the natural flow of development. As part of the centralized and unified work environment, GitLab's code review ability enables remote teams to do code reviews like they were having a natural conversation with each other. What's more, GitLab's code review functionality provides conveniences which encourage collaboration, such as the ability for the reviewer to not just comment on the code or text, but also to offer actionable suggestions which can be automatically applied if accepted, saving the code owner time and helping everyone to share their abilities. At the project level, unresolved threads can be set to block merges so that peer input is not missed or ignored. This helps to ensure that peer reviews and collaboration are not wasted, which in turn encourages more collaboration. And GitLab supports other types of peer reviews than just code reviews. GitLab's design management makes it easy for product designers to upload their work to share. Once they share it, they can get team feedback and questions overlaid on the different versions of their designs. A great way to encourage working iteratively. This works great even if you are remote because GitLab is a shared software delivery system that everyone can use to collaborate. Make results transparent. In remote organizations, it becomes easier to work in isolation, keeping results to yourself and trying to solve your problems before anybody else sees them. A best practice of successful remote software teams is being extremely transparent because it reduces the threshold to contribution and makes collaboration easier. GitLab merge requests help with results transparency because they centrally collect and make available the results of code changes, test results, deployments, security scans, and license scans. When all stakeholders have access to all the results, then they are all enabled to identify, react to, and resolve issues more quickly. In a traditional IT environment, it's hard enough getting all these results about your change. Could you imagine what it's like to try and collect all this information with everyone remote? GitLab review apps are temporary staging environments automatically deployed and configured from the branch with your changes. They make the results of your changes available for everyone to review in as simple a way as possible, a shareable link in the merge request. This level of ease and access encourages feedback from all the stakeholders, not just the software team. And transparency about security scan results means that everyone, no matter where they are, can help catch and resolve vulnerabilities before they get released to production. GitLab enables this by providing detailed information about discovered vulnerabilities, including remediation information when it's available. GitLab also propagates information about discovered vulnerabilities through security dashboards at the developer, team, and sec ops levels, so vulnerabilities don't have a chance to get by without being managed properly. Make operations transparent. Software delivery doesn't stop once the software is released into production. A proper DevOps lifecycle provides transparency of operational results in the form of a tight feedback loop right back into the next development cycle. It is more difficult for remote teams to form the relationships that establish these all-important feedback loops, so GitLab builds them in. As an example, GitLab's deploy boards and environment dashboards give the software development team a consolidated and information-rich view of the current health and status of each CI CD environment. This includes deployment history, change details, and the details of the processes that are changing them. Access to this wealth of information about their software changes enables the development team to continuously improve their software at a rapid pace and to get ahead of problems quickly before they become bigger problems in production. Similarly, GitLab's monitoring is automatically set up per Kubernetes deployed application and has the monitoring results, infrastructure, and application performance readily available to the development team. Again, this enables them to rapidly react and resolve problems before they hit production. And here's an example of that value in action. Because of the transparent operations that GitLab provides, when a spike is found in the infrastructure monitoring, the team is quickly able to correlate the behavior back to the code change, which might have caused it. So that's it. Software development best practices for remote teams. Document everything, connect strategy and execution, categorize and track the tasks, review and collaborate the outputs, make results transparent, make operations transparent. Thanks for hanging with me. If you found this useful, you can find out more at about.gitlab.com. See you next time.