Chapter 4: Asynchronous Work: Collaborate from Anywhere

In the previous chapter, you learned about collaborative development with pull requests and how you can leverage them to create shared ownership for the code and the product you built. In this chapter, we'll focus on synchronous and asynchronous work and how you can use the benefits of asynchronous workflows for better collaboration in distributed, remote, and hybrid teams and better cross-team collaboration.

The following topics will be covered in the chapter:

• Comparing synchronous and asynchronous work
• Distributed teams
• Cross-team collaboration
• Shift to asynchronous workflows
• Teams and Slack integration
• GitHub Discussions
• Pages and wikis
• Working from everywhere with GitHub Mobile
• Case study

Comparing synchronous and asynchronous work

Every bit of work we information workers carry out is basically communication. Even everything about programming: you have to communicate what you are coding, you have to communicate the architecture, and even the code itself is communication to people in the future—including yourself—on how to change your program. So, the way we communicate directly influences how we get things done.

The history of communication

How we humans interact and communicate has often changed throughout our history. Communication was mostly pure verbal with some limited written communication until the invention of the print press by Johannes Gutenberg in 1450, which caused a printing revolution with a big impact on religion and education by providing access to information to a broader audience. In the 17th century, the invention of the newspaper again revolutionized communication by reducing the time from sender to recipient tremendously. In the 18th century, the public post system became so efficient that more and more communication took place using letters. This allowed private communication to happen as quickly as in newspapers. In the 19th century, the invention of the telegraph allowed for the first time communication in real time over a great distance. The first telephone was invented in 1861 by Philipp Reis in Frankfurt. The transmission still had fluctuations, and most people thus underestimated the invention. It was 15 years later in 1876 when Alexander Graham Bell finally patented the telephone that revolutionized communication by allowing real-time verbal communication.

Until then, changes in communications were more associated with centuries than with decades. People had time to adapt, and it was always pretty clear and intuitive as to which communication form was the best. This has changed rapidly over the last 30 years. In the late 1990s, cellular phones became pocket-sized and affordable. Anybody could talk to anybody at any time. This, interestingly, led to a new phenomenon: people started to write short messages to each other and often preferred asynchronous communication over synchronous communication. With the rise of the internet, email replaced letters rapidly. But in the beginning, the internet was not mobile, so the expected response for an email was still a few days. This changed in the middle of the first decade of this century. The internet became mobile, and smartphones allowed access to emails everywhere at any time. At the same time, new forms of communication became popular: Facebook, Twitter, Instagram, and Snapchat. They allow different kinds of communication in the forms of text, voice, and video with different groups of audiences (reach and privacy) and different durability (time to live, or TTL) of the messages.

Figure 4.1 illustrates the relation between the exponential growth of our world population and changes in our communication behavior:

Figure 4.1 – Exponential growth and changes in communication

The rapid development in the last 30 years led to very different communication patterns. Whether you write a text message, make a video call, or send a story to a group depends more on personal preferences than on the content of the message. There is no social consensus anymore as to what is the correct communication form for a particular kind of message.

Work and communication

Work is more than just communication. Information work adds the desired output to a conversation. You can divide work into synchronous and asynchronous work. Synchronous work refers to when two or more people interact in real time to achieve the desired output. Asynchronous work happens when two or more people exchange messages to achieve the desired output.

If you work in a traditional enterprise, the mix of asynchronous and synchronous work might still look like in Figure 4.2. At least it looked like this a few years ago. Most of the work is done by email or in meetings, and meetings normally take place in the same room:

Figure 4.2 – Work and communication in a traditional enterprise

Most asynchronous work is done by email and remotely, while most synchronous work is done in in-person meetings. What is dominant depends strongly on the culture of the company. In companies with a strong email culture, people usually respond to emails within minutes. In these companies, many people have their laptops open during meetings and people normally complain about too many emails. In companies with a strong meeting culture, people often do not respond to emails in a timely fashion because they are attending meetings. This leads to fewer emails but more meetings.

In the last couple of years, this has changed tremendously. Small companies and start-ups, in particular, have abandoned email for work in favor of other asynchronous mediums such as chat. Many companies have also discovered the benefits of remote working, some only after they were forced to do so by the pandemic.

I already showed you in Chapter 2, Planning, Tracking, and Visualizing Your Work, how context switching kills productivity. So, for development teams, asynchronous work is desirable as it allows you to establish pull for work items and reduce context switching. A more modern work mix that is optimized for developers could look like this:

Figure 4.3 – Work and communication optimized for development

The less synchronous work people have, the more focus they can put into their work without context switching and planning. It is important to be intentional: what kind of work do we perform in a synchronous way and what can we do asynchronously? What kind of work do we perform in-person and what can we do remotely?

In-person and remote work

Synchronous work can happen in-person or remotely. Both have their advantages and disadvantages.

In-person meetings are desirable if you must convince someone. A salesperson always prefers an in-person meeting over a phone call or remote meeting as they are also better for socializing and relationship/team building. Critical feedback and sensitive issues are also better discussed in-person than remotely. Complex discussions or problems for which you need creativity can also benefit from physical proximity.

The advantage of remote meetings is that they are more productive due to less travel time. People can participate independently from the physical location, which allows you to have a team that spans multiple time zones. Remote meetings can be recorded, which allows people to watch the meeting even if they could not participate.

Remote meetings should be planned differently than in-person meetings. An 8-hour workshop (2x4) works well in-person but not remotely. Remote meetings should be shorter and more focused. People tend to get distracted rapidly if they are in front of their computers.

In the coming years, we will see more and more hybrid work. Hybrid work enables employees to work autonomously from different locations: home, on the go, or in an office. 66% of companies are considering redesigning office spaces for hybrid work, and 73% of employees want more flexible remote-work options (see https://www.microsoft.com/en-us/worklab/work-trend-index/hybrid-work). Hybrid work will be a big challenge when organizing your meetings. Remote meetings are optimized for individuals and in-person meetings are optimized for groups. Bringing both together will be a challenge, not only for the technical equipment in the meeting rooms but also for the persons responsible for organizing the meetings.

Distributed teams

Tech companies that are nearly 100% remote and have their teams distributed across the globe have existed for quite some time. I know a company that has a completely remote hiring process. Every employee gets a budget to invest in their home office or to rent something in a co-working space. The company is distributed across the globe and only comes together once a year to meet in person.

With the pandemic and the rise of remote and hybrid working, more and more companies are starting to see the benefits of having distributed teams, which include the following:

• You are not restricted to hiring in a certain metropole region and therefore have more talent and more specialists available to hire (war of talents).
• Hiring in other regions often comes with a cost reduction.
• If you target multiple markets with your products, it's always beneficial to have team members from these different backgrounds to help understand the customers (diversity).
• By providing support, you automatically have more hours covered, which means less pager duty outside normal work hours for engineers.

Distributed teams also have their challenges, the biggest one being the language. Non-native speakers have more problems communicating and you need a good base language—most likely English if you want to span many countries. Also, cultural aspects may make communication harder. Team building and a cultural fit for the team must play a much greater role in a remote hiring process.

If you want to increase your team with additional remote engineers, make sure to plan for the time zones accordingly. You should at least have 1 or 2 hours overlap of the normal working hours in the time zones, depending on the number of meetings you have. This means you normally can go a maximum of approximately 8 hours in one direction to have a 1-hour overlap. If you already have a 4-hour shift in one direction, you can only add another with a maximum of 4 hours in the other direction (see Figure 4.4).

Figure 4.4 – Planning time zones with overlap for meetings

Take into account that daylight-saving times and different working hours make planning for overlap across time zones a quite complex task!

Distributed teams have advantages, and we will see this a lot more in the coming years. It's good to already start with working practices that allow you to later hire experts from other countries in other time zones. This means that it's important to have all communication in English or another common language in your region and have as many asynchronous workflows as possible.

Cross-team collaboration

To accelerate software delivery, you want your teams to be as autonomous as possible. The ability to deliver value to your end users at any time without dependencies on other teams is one of the biggest influences on velocity, and yet you need some alignment across teams: design, security, and architecture are some shared concerns that must be addressed across team boundaries. Good cross-team collaboration is a sign of healthy alignment across the teams.

Good cross-team collaboration should not need the involvement of management, usually going up and down the command chain to the first shared manager. Good cross-team collaboration is based on asynchronous workflows that directly get the right people together to solve issues. The fewer meetings that are needed for daily work, the better.

Shift to asynchronous workflows

To shift to a more asynchronous way of working and allow remote and hybrid work, there are some best practices that you can easily adopt, such as the following:

• Prefer chat over email: Workflows that rely on emails have many disadvantages: you don't have a common history; if a team member gets sick or leaves, you get blocked; and so on. Try to move all your work-related conversations to a chat platform such as Microsoft Teams or Slack.
• Make (most) meetings optional: Make all meetings that are work-related optional. If you don't see value in the meeting, leave. This helps to make meetings more focused and better prepared as nobody wants to be the only participant in their own meeting. Of course, there are some meetings for team building or town hall meetings that should not be optional.
• Record all meetings: Recording all meetings gives people the chance to catch up, even if they could not participate. Recorded meetings can be viewed at a faster speed, which helps to digest meetings in a shorter time.
• Be intentional: Be intentional about what meetings are and what an asynchronous workflow is (chat, issues, pull requests, and wikis).
• Review your setting: Be sure to know your metrics and regularly check your setup. Are meetings successful or can they be moved to discussions in issues or pull requests? Do discussions in issues and pull requests take forever and might some things be resolved faster in a meeting? Don't change the setup too often as it takes some time for people to adopt, but be sure to review and adapt your setup at least every 2 or 3 months.
• Use mentions and code owners: Use mentions and code owners (see Chapter 3, Teamwork and Collaborative Development) to dynamically get together the right people to finish a task. Both features are also great for cross-team collaboration.
• Treat everything as code: Try to treat everything as code and collaborate on it like you do on code: infrastructure, configuration, software architecture, design documents, and concepts.

Teams and Slack integration

If you prefer chat over email, you can use the integration features in GitHub for Microsoft Teams (https://teams.github.com) or Slack (https://slack.github.com). These allow you to receive notifications directly in your chat channel and interact with issues, pull requests, or deployments. The features in Slack and Teams are very similar, as outlined here:

• Notifications: Subscribe to events in a repository. You can filter notifications with branch or label filters.
• Details for GitHub links: GitHub links automatically get unfurled and show details of the item to link points to.
• Open new issues: Create new issues directly from your conversations.
• Interact: Work directly with issues, pull requests, or deployment approvals from your channels.
• Schedule reminders: Receive reminders for code reviews in your channel.

The installation is straightforward. You must install the GitHub app in Microsoft Teams or Slack and the corresponding Teams or Slack app in your organization in GitHub.

Once installed, you can interact with the GitHub bot and send messages. In Teams, you mention the bot with @GitHub, while in Slack, you do this with /GitHub. If you mention the bot, you receive a list of commands that you can use (see Figure 4.5):

Figure 4.5 – Sending commands to the GitHub bot

The first command you must use is signin. This will link your GitHub account to your Teams/Slack account:

@GitHub signin

After that, you can subscribe to notifications or schedule reminders. The unfurling of links and the interaction with issues work without needing to configure anything. Figure 4.6 shows an issue in Teams that was created from a conversation. You can directly comment on the issue or close it:

Figure 4.6 – Integration of issues in Microsoft Teams

Chat integration is a powerful feature that will come in handy when more and more of your workflows are initiated and managed through chat instead of through meetings or emails.

GitHub Discussions

In Chapter 2, Planning, Tracking, and Visualizing Your Work, you learned how to use GitHub issues and GitHub projects to manage your work. GitHub Discussions 
is a community forum that allows members to ask questions, share updates, and have open-ended conversations. Discussions are a great way to reduce a load of issues and pull requests by providing a different place for long discussions and questions and answers (Q&A).

Getting started with Discussions

To get started with GitHub Discussions, you must enable it in your repository under Settings | Options | Features by checking Discussions. Once you have checked this option, you have a new main menu item, Discussions, in your repository.

Note

GitHub Discussions is a feature that was still in Beta at the time this book was written. Some features might since have changed. You can give feedback and participate in discussions under https://github.com/github/feedback/discussions, which, of course, is itself a GitHub discussion.

Discussions are organized into categories. You can search and filter in discussions the same way you can search and filter issues. Discussions themselves can be upvoted and indicate the number of comments and labeled if they are considered answered. You can pin up to four discussions to the top of the page to make some important announcements. A leader board shows the most helpful users that have answered the most questions in the last 30 days. Figure 4.7 shows how discussions look:

Figure 4.7 – Overview of GitHub Discussions

Discussion categories

You can manage categories by pressing the edit pencil next to Categories. You can edit, delete, or add new categories. A category consists of the following:

• Icon
• Title
• An optional description

There are three kinds of categories, as outlined here:

1. Question/Answer:

Discussion category to ask questions, suggest answers, and vote on the best suggested answer. This category type is the only type that allows the marking of comments as answered!

2. Open-ended discussion:

A category to have conversations that don't require a definitive answer to a question. Great for sharing tips and tricks or just chatting.

3. Announcement:

Share updates and news with your community. Only maintainers and admins can post new discussions in these categories, but anyone can comment and reply.

Starting a discussion

You can start a discussion by clicking Discussion | New discussion. To start a new discussion, you must select a category, and enter a title and a description. Optionally, you can add labels to the discussion. The description has full Markdown support. This includes references (#) to issues, pull requests, and other discussions, as well as mentions (@) of other persons, code with syntax-highlighting, and attachments (see Figure 4.8):

Figure 4.8 – Starting a new discussion

Participating in a discussion

You can comment on or directly answer the original discussion description, or you can answer existing comments. In each case, you have full Markdown support! You can add reactions in the form of emoticons to all comments and the original description. You can also upvote the discussion or comments/answers. In the menu on the right, you can convert a discussion into an issue. As an admin or maintainer, you can also lock the conversation, transfer it to another repository, pin the discussion to the top of the forum, or delete it. Figure 4.9 gives an overview of an ongoing discussion:

Figure 4.9 – Participating in a discussion

Discussions is a great place to collaborate asynchronously with your peers and across team boundaries. For more information on Discussions, see https://docs.github.com/en/discussions.

Pages and wikis

You have many options to share content in a collaborative way. In addition to issues and discussions, you can use GitHub Pages and wikis.

GitHub Pages

GitHub Pages is a static website-hosting service that serves your files straight from a repository in GitHub. You could host normal HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript files and build a site yourself. But you can also leverage the built-in preprocessor Jekyll (see https://jekyllrb.com/), which allows you to build good-looking websites in Markdown.

GitHub Pages sites are hosted by default under the github.io domain (such as https://wulfland.github.io/AccelerateDevOps/), but you can also use a custom domain name.

GitHub Pages is a free offering for public repositories. For internal use (private repositories), you need GitHub Enterprise.

Note

GitHub Pages is a free service, but it is not intended for running commercial websites! It is forbidden to run webshops or any other commercial websites. It has a quota of 1 gigabyte (GB) and a bandwidth limit of 100 GB per month. See https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages for more information.

The best way to learn about GitHub Pages is to see it in action. Here's how:

1. If you have already forked the https://github.com/wulfland/AccelerateDevOps repository in the hands-on exercises in previous chapters, you can directly go to your fork. If not, create a fork by clicking the Fork button in the top-right corner of the repository. This will create a fork under https://github.com/<USER>/AccelerateDevOps.
2. In the forked repository, navigate to Settings | Pages. Select the branch you want to run the website from—in this case, main—and select the /docs folder as the root for the website. You can only choose the root of the repository or /docs! No other folders can be used. Click Save to initialize the website (see Figure 4.10):

Figure 4.10 – Enabling GitHub Pages for a repository

3. It may take a few minutes until the site creation has finished. Click the link, as highlighted in Figure 4.11 and refresh the page if it is not yet available:

Figure 4.11 – Navigating to the web page

4. Inspect the site and note that it has a menu with static pages and a menu that shows posts with an excerpt (see Figure 4.12):

Figure 4.12 – A website with Jekyll

5. Head back to your code. First, inspect the /docs/_config.yaml configuration file. Here, you can place the global configuration for your website, such as the title and description, as illustrated in the following code snippet:

   title: Accelerate DevOps with GitHub

   description: >-

     This is a sample Jekyll website that is hosted in   GitHub Pages.

     ...

There are many themes that you can use to render your site. Each theme has its own features, so be sure to check the documentation. I have the default Jekyll theme minima. To render Markdown, you can use Kramdown or GitHub Flavored Markdown (GFM). Jekyll also supports different plugins. The minima theme supports jekyll-feed and, with the show_excerpts option, you can set whether excerpts for the posts are displayed on the home page, as illustrated in the following code snippet:

theme: minima

Markdown: kramdown

plugins:

  - jekyll-feed

show_excerpts: true

Many themes support additional values. For example, you can set social media accounts that get displayed on your site, as follows:

twitter_username: mike_kaufmann

github_username: wulfland

Normally, static pages are displayed in the top navigation bar in alphabetical order. To filter and sort pages, you can add a section to the config. As we want to add a new page, add a my-page.md entry right before About.md, like this:

header_pages:

- get-started.md

- about-Markdown.md

- my-page.md

- About.md

Commit the change directly to the main branch.

6. In the /docs folder, select Add file | Create new file in the top-right corner. Enter my-page.md as the filename and add the following header to the file:

   ---

   layout: page

   title: "My Page"

   permalink: /my-page/

   ---

Add some more Markdown if you wish. Commit directly to the main branch.

7. Now, head over to the /docs/_posts/ folder. Select Add file | Create new file again in the top-right corner. Enter YYY-MM-DD-my-post.md as the filename, where YYYY is the current year, MM the two-letter month, and DD the two-letter day of the month. Add the following header and replace the date with the current date:

   ---

   layout: post

   title:  "My Post"

   permalink: /2021-08-14_writing-with-Markdown/

   ---

Add some more Markdown content to the page and commit it directly to the main branch.

8. Give the processor in the background some time and then refresh your page. You should see the page and the post on the start page, and you can navigate to them (see Figure 4.13):

Figure 4.13 – Examining the new page and post in Jekyll

You have seen how easy it is to publish content in GitHub Pages. Jekyll is a very powerful tool, and you can customize nearly everything, including the themes. You can also run your site offline to test it when you install Ruby and Jekyll (see https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/testing-your-github-pages-site-locally-with-jekyll for more details). However, this is a very complex topic and outside the scope of this book.

GitHub Pages with Jekyll is a great way to present content in a nice way and to collaborate on the content as you do on code, with pull requests. You can use it as a technical blog or for user documentation. In a distributed team, you can use it to publish the results of each sprint in a small post, maybe with small videos. This helps to communicate your success, even when people cannot attend the sprint review meeting.

Wikis

GitHub has a simple wiki included in every repository, but you also can choose to create your own Markdown-based wiki alongside your code.

The GitHub wiki

There is a very simple wiki available in every repository. You can choose to edit the pages in different formats: Markdown, AsciiDoc, Creole, MediaWiki, Org-mode, Prod, RDoc, Textile, or reStructuredText. Since everything else in GitHub is Markdown, I think this is the best choice, but if you already have wiki content in one of the other formats, it can help you to move the content over.

Note

Other editing formats, such as AsciiDoc or MediaWiki, have more advanced features such as an autogenerated table of contents (ToC). If your team is already familiar with the syntax, it might make sense to you, but learning Markdown itself and another Markdown language at the same time probably does more harm than good.

Wikis are very simple. There is a home page that you can edit, and you can add a custom sidebar and footer. Links to other pages are specified in double braces as [[Page Name]]. If you want a separate link text, you can use the [[Link Text|Page Name]] format. If you create a link to a page that does not exist yet, it gets displayed in red, and you can create a page by clicking the link.

A wiki is a Git repository with the same name as the repository and the .wiki extension (<name_of_repository>.wiki). You can clone a repository and work locally in branches with a wiki. But unfortunately, up to now there is no way to use pull requests to collaborate on the changes! This is the biggest downside of GitHub wikis!

Also, wikis do not support nested pages. All pages are in the root of the repository. You can use the sidebar to create a menu with a hierarchy using Markdown nested lists, as follows:

[[Home]]

* [[Page 1]]  

  * [[Page 1.1]]  

  * [[Page 1.2]]  

If you want parts of the menu to be collapsible, you can use the <details></details> GitHub Markdown feature. This creates a collapsible part in Markdown, and with <summary></summary> you can customize the heading, as follows:

* [[Page 2]]

  * <details>

    <summary>[[Page 2.1]] (Click to open)</summary>

      * [[Page 2.1.1]]  

      * [[Page 2.1.2]]  

    </details>  

Note that the blank lines are necessary for this to work! The result looks like in Figure 4.14:

Figure 4.14 – The structure of a GitHub wiki

The GitHub wiki is a very simple wiki solution and lacks many features that other wiki solutions have, especially as you cannot use pull requests, which limits its benefits for asynchronous workflows. But luckily, you can host the Markdown in your own repository and build a custom wiki yourself.

A custom wiki

If you don't want the complexity of GitHub Pages but you still want to work with pull requests on your wiki, you can just put Markdown files into your repository. GitHub will automatically render a ToC for all your Markdown files (see Figure 4.15). You may have already noticed this in README files in GitHub repositories:

Figure 4.15 – GitHub TOC for Markdown files

The problem with a custom wiki is the navigation. It is easy to build a navigation system using Markdown nested lists and relative links. You can also make it collapsible with details, as illustrated in the following code snippet:

<details>

    <summary>Menu</summary>

* [Home](#Header-1)  

* [Page1](Page1.md)  

  * [Page 1.1](Page1-1.md)

  * [Page 1.2](Page1-2.md)

* [Page2](Page2.md)

</details>

But if you need it to be on every page, you must copy-paste it to all pages when you change it. You could automate this, but it would still clutter your history. It's better to have breadcrumb-like navigation on every page that people can use to navigate back to the home page and use the menu from there. You can see an example of a custom navigation in Markdown here: https://github.com/wulfland/AccelerateDevOps/blob/main/ch4_customWiki/Home.md.

From a community forum, to simple Markdown wikis to a fully customizable web page with Jekyll, there are many options to host additional content for your work on GitHub. Choosing the right one for the task at hand is not easy. Sometimes, you'll just have to try to figure out what works for your team.

Working from everywhere with GitHub Mobile

Most of the time, you will collaborate on GitHub issues, pull requests, and discussions from your browser. But there are also other options that help you to bring GitHub to where you are.

GitHub Mobile is a mobile app that is available for Android and Apple through their marketplaces (see https://github.com/mobile). The app gives you access to all your issues, pull requests, and discussions in all your repositories. It has a dark mode and a light mode, and you can pin your favorite repositories to the start screen (see Figure 4.16):

Figure 4.16 – GitHub Mobile home page in dark and light mode

I personally love the GitHub Mobile app—it is very well crafted and helps you in your everyday work to be independent of your workstation or laptop and collaborate on issues and discussions. You can configure notifications so that you get notified when you are mentioned and assigned, or when a review had been requested. The notifications appear in your inbox and you can use configurable swipe actions to mark the notification as Done, Read, or Unread; to save the notification; or to unsubscribe from the notification source. The default mark options are Done and Save. The inbox looks like in Figure 4.17:

Figure 4.17 – Notifications in GitHub Mobile

What impressed me the most when I used the app for the first time is how well the code review experience works on mobile devices. You can turn line wrapping on, which makes it easy to read the code, see changes, and comment on them (see Figure 4.18):

Figure 4.18 – Pull request review with GitHub Mobile

GitHub Mobile is a great way to unblock your teammates, even if you are not in the office. It allows you to participate in discussions and comment on code changes and issues. The possibility to review small changes on the go can help your team to move to smaller batch sizes of work because you have smaller wait times for approvals.

Case study

The first thing our two pilot teams at Tailwind Gears do is move their code over to a GitHub repository. One team is already using Git on a Bitbucket server. For that team, the migration is as easy as pushing the repository to a new remote. The other team is using Team Foundation Server (TFS) version control and must migrate the code to Git first on the server before pushing it to GitHub.

Both teams decide to participate in 2-day Git training to be able to leverage the full power of Git and craft good commits that are easy to review. They use draft pull requests so that everyone in the team always knows what the others are working on, and they set a minimum of two required reviewers for the time being.

Many of the work is still outside the repositories and happens in Word, Excel, and Visio documents that are stored on the company SharePoint server. Some of the documents are converted to Portable Document Format (PDF) and are signed off by management before releasing the product that is compliant with certain regulations. There are too many documents to convert all at once to Markdown. The teams create a custom Markdown-based wiki in their code repository to have everything close to the code. They add links to the current documents in SharePoint. Every time a change to a document is necessary, the content will be moved to the Markdown file and the link will be removed. Instead of signing PDF documents, management gets added as code owners to the corresponding files and approves the changes directly in the pull request. Together with the audit log, this is valid for all necessary compliance audits.

When moving to the new platform, many aspects are relevant for both teams, and later will be for other teams as they also move over to the new platform. That's why they create a shared platform repository. The repository contains GitHub Discussions to collaborate with all engineers, even those who are not yet in one of the two teams. A technical blog is set up using GitHub Pages to share tips and tricks. The Jekyll site is also used to collaborate on common review guidelines and a code of conduct.

Summary

In this chapter, you've learned the advantages and disadvantages of synchronous and asynchronous work. You can use this to create effective, asynchronous workflows that allow for better cross-team collaboration and enable you to have remote and hybrid teams that can span multiple areas and time zones. You've learned how GitHub Discussions, Pages, and wikis can help you to have asynchronous workflows for topics other than code and requirements.

In the next chapter, I will explain the influence of open and inner sources on your software delivery performance.

Further readings and references

Here are the references from this chapter that you can also use to get more information on the topics:

• History of communication: https://en.wikipedia.org/wiki/History_of_communication, https://www.g2.com/articles/history-of-communication, and https://www.elon.edu/u/imagining/time-capsule/150-years/
• History in general: https://www.dhm.de/lemo/kapitel (German)
• World population growth: https://ourworldindata.org/world-population-growth
• Hybrid work: https://www.microsoft.com/en-us/worklab/work-trend-index/hybrid-work
• Work trend index: https://www.microsoft.com/en-us/worklab/work-trend-index
• GitHub Discussions: https://docs.github.com/en/discussions
• GitHub Pages: https://docs.github.com/en/pages
• GitHub Mobile: https://github.com/mobile