In the past six weeks I wrote about the benefits of remote working and introduced five elements to make it work. Maybe you already applied some of the elements. Maybe it was too abstract and you had no idea how to translate this into your environment. In order to summarize the “remote five” and wrap up this blog series, I’ll come up with two scenarios and apply the “remote five”. Hopefully this helps to make it more tangible and get into action.
The first scenario is a project team working on an IT project. Let’s say they develop software for an IoT application. They are globally dispersed with developers in Germany, Poland and India. They are using Scrum and work in 2 week iterations. You might think remote work is pretty standard in a setup like this? I met people who claim remote doesn’t work well for this scenario and people need to be co-located.
The second scenario is a German civil engineering company. They want to install a community of practice among their site managers, who are distributed across Germany. I could imagine that remote working is not very common yet in this industry. Let’s apply the “remote five” to the two scenarios!
#1 – Purple space
As you might remember, there are three aspects of purple space: Purpose, location and cultures. For the IT team the purpose is to build the IoT application. Within the purple space they agree on goals for the respective sprints, perform their daily standups and do the demo and retrospective. The coding might happen outside the purple space. It is important that the location is not in one site and dominated by one culture (e.g. India because majority of developers located there).
For the civil engineers community the purpose could be to share learnings about a new material. It also could be to help each other out with resources (e.g. goods) or people. The location of the purple space should be a virtual one and not in the headquarter. A dominating “culture” could be somebody from a central function who forces this community of practice.
#2 – Heartbeat
The two scenarios perfectly illustrate two completely different heartbeats. The IT project team needs a fast heartbeat, due to their 2 weeks iterations. The main “frequency” of their heartbeat is daily. They run their daily standup as a video conference. Every two weeks the amplitude is a bit higher for the sprint planning and demo meeting. And then there are some peeks between the daily heartbeat (e.g. two developers doing pair programming).
A daily heartbeat is unrealistic for the civil engineering community. They don’t have something to share so often. For them a weekly or bi-weekly call of one hour might be the right heartbeat. In between there’s some 1on1 interaction (e.g. one civil engineer answering followup questions to another one on a learning he shared in the weekly call).
#3 – Digital communication
Do you remember media richness, synchronous and asynchronous communication? The IT team can easily use tools with high media richness. They usually work in a desktop environment and have high bandwidth. Their synchronous communication tool has everything from video conferencing to instant messaging integrated – makes it easy to use. As asynchronous tool they might use the Atlassian tools suite, which has Wiki capabilities for documentation (Confluence) but also digitizes their workflows (Jira).
The civil engineers need to trade media richness over reliability of communication. A construction site can be in an area with low bandwidth. Using phone as synchronous media might be a better choice than video, where they exclude people or waste half of their time making it work. As asynchronous medium I would choose a Wiki or forum that is mobile friendly and works well under low bandwidth conditions.
#4 – Secret rules
For the IT team, the different cultures are apparent (India, Poland and German) and differences might be well known and already taken care of in a team agreement. I bet there’s still more below the tip of the iceberg. What about “notions of cleanliness”? One developer might want to spend more time on cleaning up code. Remember that reduced media richness could mean that his voice is not heard!
And where do you have different cultures among a group of German civil engineers? Think about different “attitudes towards age”. One person of the group has an important learning to share, but he believes his more senior colleagues should speak first. How do you make sure this person is heard?
#5 – Feedback
The IT team already has a regular feedback channel – the sprint retrospective. They can easily use one of the online tools (e.g. https://www.retrium.com/). But what about the civil engineers? They probably need to do their first retrospective in their semi-annual face-to-face meeting. On the other hand, Kudo cards should easily work in their environment. So why not giving Kudos to the colleague who shared the great tip on handling the new material?
Over to you – Get into action!
Ready for takeoff? Although the examples above haven’t been complete, I hope they were a good summary of the “remote five” and inspired you to apply it to your scenario. Give it a try! Feel free to share your scenario in the comments below or via social media. I’m more than happy to give you a few pointers to get started.
This post concludes my blog series about remote working. I’m curious about your success stories but also where it didn’t work out. Would be great if we can share them on this blog!
If you want to learn more about remote work, here are three resources for further reading:
- Lisette Sutherland’s blog – http://www.collaborationsuperpowers.com/
- Line Jehle’s books – Leading in Hyper-Complexity and Closeness at a Distance
- Buffer’s remote working insights