How you can establish an agile approach in a company is covered by many of our blog posts. But what does an agile organization with remote teams and only one location need to do to both enable distributed work and to integrate distributed employees in the best possible way? Why should any company think about these issues? What are the hurdles and how can they be overcome effectively? And who is actually suited to be a remote employer or employee? Here are some experiences and my thoughts.

Image source: Pixabay, CC0 License

In the previous two posts, I've covered the question of why remote work may be a good thing for your company, and who is suited to remote work. Now I want to look at what you need to do to make the introduction of a remote work environment a success.

Jason Fried and David Heinemeier Hansson (REMOTE: Office Not Required) recommend an iterative approach (as we already know it from the agile environment):

A great place to start is to allow your current employees to begin working remotely.

Time and again they point out that remote work does not have to be an all-or-nothing decision. Similar tips can be found in abundance on the internet and provide a good introduction. Here is a small selection of good sources:

• REMOTE: Office Not Required
• Work Together Anywhere - Book and talk by Lisette Sutherland
• Think globally, code locally: the secret to remote teams - this is how Atlassian works with distributed teams
• Embrace Remote Work Ultimate Guide - beautifully presented guide from Trello
• Can you be remotely agile? - Thoughts from the Agile Alliance
• Travel Restrictions and Offshore Development - somewhat older, but no less interesting

How it all began

Image source: Pixabay, CC0 License

When I made the decidions at the end of 2014 to move to Reutlingen, 250 kilometres away, remote work at //SEIBERT/MEDIA was not widely accepted. Only one colleague in marketing, who mainly takes care of our blog, was already working from Potsdam at that time. Whether this would also work for a classical Scrum team, nobody could say. We decided to take an agile approach - incrementally, in small steps.

Since the topic of distributed work in companies was sometimes viewed negatively, we decided to make the entire evaluation process as transparent as possible. We started an AgileOrg story in which we collected information and experimented. No-one objected to a three-month experiment. I talked about the outcome of this story, about whether a distributed workplace works in a previous post. After three years, I'm still remote and now have six "distributed" colleagues in all of the various teams.

Many small steps

Image source: Shamia Casiano, Pexels License

Remote work starts as soon as an employee is not regularly sitting in the team office. Working occasionally from a home office is allowed by most modern companies and an easy way to get a taste of remote work. You can also start by relocating to another team's space for a certain period of time without much effort. This doesn't cost any money and keeps the risk as low as possible, furthermore it promotes collaboration between the teams.

If already one (half) day of remote work requires extensive preparation and arrangements, this is one of the first points that should be tackled. In my case, for example, it was the switch from analog to digital Scrum boards. Before the changeover, we had printed out all the tasks on paper and hung them on a large whiteboard. If a colleague now wanted to work at home, he had to hang his tasks on the board the evening before or say in advance what he would be working on. With a digital board, there is a "Single Source of Truth" - with the useful difference that it can be viewed and changed from anywhere.

If it works out for one day, you can work remotely for two, three days or a whole week. This usually leads to the next pain points. Just one a day can be planned and discussed quickly in advance, but when several days in a row are spent in a home office, communication channels become much more important. Email, chat, and video conferencing must work and all team members should be prepared to use them. During stand-ups or other meetings, the team must remember to connect remote colleagues prior to starting. The chat must be actively used to answer questions remotely. Decisions and discoveries must be documented and findable in the internal wiki or in Jira.

Weaknesses in the technical infrastructure, and above all in access to important systems, quickly become apparent through such experiments. We could connect to all of the larger systems via VPN, but in the beginning, there were several smaller applications that could only be accessed from within the office. A good relationship with your IT services department or prior consultation and testing with a colleague from this team can help. By the way, my colleagues in the office now also work via VPN - our remote employees were good beta testers for this.

Feel the pain

Image source: Pixabay, CC0 License

I am the only remote employee in my team. There is a danger that my colleagues on-site will not be able to recognize the hurdles I face "in exile". In order to foster understanding among my office colleagues, but also to let them share the advantages of remote work, it can make sense to let individuals or even an entire team work remotely at different times. This is not only a one-day home office session, but for several days. As we were introducing remote work, this requirement led to everyone experiencing the situation, and brought up some great ideas to reduce the pain.

We also shared as much of our knowledge and experiences as possible within the company. Using blog articles and brief status updates, each colleague was able to track how the introduction of remote was going. This also created acceptance and understanding, as well as curiosity about our solutions: Colleagues often approached me and asked about certain processes or the technical infrastructure that was required.

Agreement is everything

Before a complete switch is made, all conditions and requirements should be clarified. This applies not only to our own team, but also to other teams such as HR or the internal IT services group.

In my case, for example, we agreed upon an interval where I attend the office for one or two days. We considered a period of every four to six weeks to be optimal. I always try to be there at the end of a sprint so that I can personally participate in the retrospective.

Even when I work at home, a short "hello" or "bye" in the chat tells others whether I can be reached at that moment or not. The same applies in the other direction. And also my colleagues outside the team need to be included: In the beginning, many hesitated to get in touch with me because the channels were not clear or the tools were not set up. Now though, video calls have become the norm within the company, more important now that we have three locations in the same city (a form of remote work).

Image source: SpaceX, CC0 License

During the introduction of remote work and even afterwards, it is helpful to repeatedly revisit and resolve pain points (inspect & adapt). Larger issues can be dealt with in a retrospective or in their own meetings. It is important to be flexible and pragmatic: You don't necessarily need a top-of-the-line remote workstation with multiple large screens, just a laptop is enough to start with.

The nice thing about this introductory process is that it can be interrupted at any time (as long as you aren't moving cities next week) and can be stopped completely without much effort. But even if the initial remote experiment as such fails, all team members will benefit from the changes it requires to communication and infrastructure. However, if the experiment is successful, the biggest pitfalls will be preemptively covered in the introductory phase before the actual remote work becomes reality.

With this, my trilogy of posts covering an agile remote transition is finished. If you want to see what a standard remote work day looks like, check the blog posts I've written about my remote sprints.

Lesen Sie diese Seite auf Deutsch

Further information

Agile remote transition I: why?
Does a distributed workplace work? Well, it depends!