Dr. Strangework

or: How I Learned to Stop Worrying and Love Remote Working

In these difficult times due to the recent crisis caused by COVID-19 (or coronavirus), as a software development team we have been forced to radically change the way we work.

In this article I will try to describe the situation in which we suddenly found ourselves having to work 100% remotely from home, in the hope that this will inspire other studios like our own, and also to understand whether any of these procedures are worth adopting when we return to working normally.

Our team is an “Agile” team that has been working for 6 years in a “Scrum” consisting of 8 people, including the Scrum Master and developers, who work together in Sprints that are typically 2-week work cycles.
Like nearly all other companies, following the lockdown imposed by the Italian government, we weren’t allowed to return to the studio where we usually work in close contact with each other.

The team in question is made up of two companies, Chialab and Channelweb, who had already been working in synergy for years in two different premises. So, even if they are not actually very far apart, they had already implemented a number of remote working procedures in their daily routines.

Like Chialab we have never used remote working much. We believe that a number of very important components in our day-to-day work depend on physical presence. These include exchanges of opinion between colleagues working side by side on the same project or the voicing of ideas
when developing software. So, the immediacy of (verbal and non-verbal) communication plays a central role in our work process.
As I have already said, all this was lost overnight.

These days, the word “smartworking” seems to be everywhere. It is a term that is often used to describe remote working, when that is really only one of the practices it covers, as smartworking originally refers to a much wider flexible work system.
Smartworking is sometimes translated in Italian as “lavoro agile” (agile working), but this should not be confused with “Agile working” (with a capital A) which refers to a series of clearly defined work procedures that have been adopted by Chialab for some time.
It would therefore be more correct to use “remote working” when referring specifically to the henomenon of working away from the office.
In the specific case outlined in this article, I will illustrate a number of remote working practices, combined with Agile methods.

What has changed

As ours is an Agile team, whose main feature is that of responding to change quickly, we found that we had a significant advantage when facing this extraordinary situation.

The team, in this particular case, creates and manages platforms for scholastic publications (secondary schools) for the publisher Zanichelli. When the schools were closed due to a state order aimed at stopping the spread of coronavirus, these platforms were pushed to the limit, as they were the only tool available for conducting remote teaching. In a matter of days, the main platform that previously averaged about 800 visits a day, leapt up to over 40,000 and then stabilised at about 20,000 daily visitors.

From a technological point of view, our products had to sustain a vast increase in visits by scaling up the resources of the infrastructure server. The communication aspect also proved to be of strategic importance, as it was necessary to  ighlight the features and contents that were  undamental for remote teaching.

The situation was also very difficult to predict as the priorities from a business point of view were continually changing on account of the xceptional nature of the situation we found ourselves in.

How we have adapted

The first thing we dealt with was managing the workload.

The team normally operates with a constant workload that includes creating new functions for the platforms, but in this case, it also had to find time to solve unforeseeable problems or  mergencies during the construction process. This is why, to begin with, not as much effort was put into the sprints as usual.

At the same time, we couldn’t completely block the creation of new features, partly out of respect for the customer’s roadmap, but also to keep up the morale of the development team. A sprint focused on just bugfixes or emergencies would not have been good for team spirit.

Given the extremely dynamic situation, during construction, the Product Owner and various stakeholders also tended to raise more problems with the development team.
In the long-term, this could have become problematic for the team, who were already dealing with various kinds of emergencies and would therefore have had to stop to assess the new requests.
To alleviate this particular situation, the Scrum Master spent more time mediating than usual in order to help the (customer’s) Product Owner identify priorities.
As all those who work in an Agile system know, it is not good practice to act as a filter for the team, but in this particular case we thought that leaving the team more freedom to focus on its work was the right way to move forward.

Tools and practices

In a normal situation, the team and customer (which includes the Product Owner) communicate via an immediate messaging channel, Slack, that, in our case, focuses on eventual problems or project requirements.
The Scrum Master’s mediation activities described previously are conducted mainly hrough the shared chat channel.

Obviously, there are also message channels reserved for the development team for more technical discussions and also a channel reserved for stand-up meetings (Daily Scrum). This channel, that has already been used by the team for some time, works with a bot that every day asks the Daily Scrum, classic questions like: 

• what did you do yesterday?
• what are you doing today?
• Is anything blocking your progress and do you need any help?

In turn, each team member writes their own responses and the Scrum Master examines them to help solve any problems that may arise in the future.

In addition to the stand-ups, every week the team has what is called a “weekly scrum”, i.e. a video conference with the (customer’s) Product Owner, to keep them up-to-date with the tasks being carried out.

Previously, we also had a rule that developers should meet in the same place every week to keep everyone updated. This involved one or more members of the team displaying a particular task in the sprint in progress or some new technological feature they had researched or created.

This meeting has been maintained and modified to allow each member to exhibit an aspect of the week’s work, in order to keep everyone updated even if they are no longer working in the same room.

From when it began 6 years ago, the whole process has been regularly tracked in board on Jira, and can therefore be consulted remotely at any time.

To manage the priorities and specifications of the activities to be completed (Product backlog refinement), the team had previously held physical meetings two days before the end of every sprint. During lockdown, these were transformed into video conferences without any particular problem.

In the same way, Sprint Planning Meetings and Sprint Reviews also became video conferences.

On the other hand, it was more difficult to adapt the team retrospective, an initiative that seeks to continually improve the team’s work.

While conducting a search for documentation online, I found an article by the Hotjar team, that explained how to use a Trello template and a step-by-step meeting via video conference to transform the classic post-it on a wall retrospective into a shared board displaying the team’s strong and weak points in the sprint recently completed.

What we have achieved

The first sprint was, as you can imagine, very difficult, because everything changed suddenly and not at all gradually.

Meetings, as we have said, did not change much compared to usual, apart from the retrospective, which was still useful for identifying problems and keeping discussions valid even if they were remote.

The Scrum Master’s increased mediation between the team, Product Owner and stakeholders also helped the developers remain focused and avoided work stoppages.

Despite some carefully handled urgencies, the features progressed with a reasonably regular rhythm, even if there were obvious, but minimum slippages in the general project timeline.

So, we can definitely say that even if a number of important live communication components were missing, working remotely was a success in that it maintained our performance and the quality of our work and I would not rule out the chances of it becoming an integral, but not exclusive part of the way we operate in the near future.

Small personal tips

I would like to end by sharing a few tips on personal conduct that have helped me handle this lockdown and remote working in general.

• create a personal workspace at home, as it helps to keep your mind in work mode and avoid distractions
• think very carefully before writing stuff in chats with colleagues and customers, as written communications are more complicated and need to be carefully thought out
• create routines similar to your usual office ones
• try to keep fixed working hours and don’t go beyond them; as it helps to have real free time so you can focus on non-work interests too

Manuel Zanettin