There are many posts detailing how to establish an agile approach in a company.
- But how should an agile organization with remote teams and just one site approach the facilitation of distributed work and integration of distributed team members?
- Why is it fundamentally a good idea to take a closer look at this?
- Which obstacles can come up and how can you overcome them effectively?
- And who makes for a good remote employer or employee?
Here are some thoughts on the topic.
The Agile Manifesto
From the principles behind the Agile Manifesto:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This could already be the end of our journey towards an agile remote team, as we could interpret this sentence as a flat-out rejection of distributed work. But we should not forget the section that comes before it, which presents another principle:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
And if the environment required by one team member is a few hundred kilometers from the company's site, then we should create the necessary conditions for integration.
Why bother with remote work at all?
The topic of remote work has polarized the IT world like nothing before. After distributed work became widespread, especially in the USA, some large companies are now switching sides and calling their employees back into the office (Why are big companies calling their remote workers back to the office?) So why bother establishing remote working if Google and co. are reversing course to do the exact opposite?
From an employee perspective, home office or permanent work from home is a great opportunity for more flexibility in their everyday lives. They can quickly accept a package delivery, do the laundry, etc. when they need to. From my own experience, I can tell you that, especially with a young child, being able to take a lunch break when they come out of daycare is great; as is spending time with them before 7 pm. Another big perk is not having to commute: Even a 30-minute one-way trip adds up to around 20 hours in a month. And even though we can now work en route, it is still not really dedicated work time.
There are also initial benefits for the companies as remote employees no longer require a set desk in the office and all the infrastructure that goes with it. Moreover, the pool of potential employees is much larger, and there is no need for an employee to leave the company if they have to move locations for personal reasons. The former is of increasing importance in times when skilled workers are in short supply, as highly qualified specialists are highly contested, particularly in urban centers. The latter has the obvious advantage that experienced, loyal employees, remain within the company along with their wealth of experience and their established role in the team.
A second glance shows that the integration of remote employees allows companies to open outwards. On-site employees benefit from the necessary optimizations in (digital) communication tools. For example, working from home becomes easier for everyone, meetings are streamed as standard and perhaps even recorded, all necessary information has to be available digitally, and vague verbal arrangements – hopefully – become a thing of the past.
Of course, this can all work without remote employees, but as an "outsider" it comes to my attention much more quickly when the company isn't playing along. This "internal aerial view" compels team members to communicate and document information, which in turn ultimately helps all team members and the company, especially in the longer term.
Another aspect is the expansion of the company's reach. By participating in conferences and user groups in the Neckar-Alb area of Germany, I can bring knowledge from another region into the company, which we can assume would have otherwise remained out-of-the-loop. The effect is even greater when a company has remote employees in other countries or even continents: We've already worked with colleagues in the USA and Australia.
Only good things?
Is there a remote land of milk and honey? No, of course not. The improvements described above involve considerable expenditure, especially at the beginning. Companies must first establish appropriate software and hardware infrastructures and get them up and running. From my own experience, it makes sense to carry out as many dry runs as possible and take a day or a week to work as though you were a remote employee to try things out.
Problems will then surface before they can disrupt live operations (more on that in another post). But despite all the tests and trial runs, obstacles will continue to come up, even after the transition, requiring continuous optimizations to processes and infrastructure.
Where does "agile" come into it?
It's quite simple: I consider distributed work to be agility in practice. The relationship of trust between the company, or team, and remote employees, which among other things is described in the agile principles (see the quote above) is made plainly apparent. It feels good to know that my colleagues think of me and appreciate my work despite the distance.
Distributed work also encourages a continuous "inspect and adapt" approach in view of communication and processes. Even minor flaws that would only come up at a later point on site catch the attention of remote employees immediately, because – for example – important information is missing or processes have been changed without documentation.
This post was an introduction to the topic of agile remote transitions. In the posts to come, I will look at more questions and among other things consider, how we approached remote transitions in the past and who is cut out for remote work.