Remote Development: First Sprint Insights

Over the past couple of weeks, perhaps the lazy one has not advised others how to switch to a remote location without loss. We will not advise you anything. And just tell us how we set up remote development of our key product and by April 3rd we had already completed the first, completely remote, two-week sprint of the development teams of Dozor Core (the central module of the system).

Who cares, study our experience, join the discussion, share yours in the comments. Here we go!

I note right away that the transition to the online mode of operation was quite easy and inconspicuous. Strong processes, built by teams over a year that have passed since the introduction of Scrum and Less, have affected. A high level of self-organization, along with experience working with remote colleagues, which are in almost every team, also played a role. The guys themselves resolved most of the issues that arose, and those rare things that required the intervention of management highlighted and communicated to their leaders on time. One of the components of success was also an excellent inter-team interaction not only within Dozor Core-teams, but also with developers of other modules.

So, what insights we received during this time and the innovations that we started to apply?

First, we made sure that remote sprint planning (we use the Zoom and Agile Board videoconferencing service in Jira) can be as efficient and fast as live. The key to success is in preliminary meetings of the PBR (Product Backlog Refinement, or clarification of the product backlog), where the product owner team tells the development team about those elements of the general backlog that are planned to be done in the next sprints. The development team at these meetings plunges into the business problems of customers and after that organizes a series of special meetings for themselves, which we call design sessions.

Secondly, actually, themselves design session. At these meetings, the guys design technical solutions and further protect them from the architects and the product owner. It so happened that a couple of months ago the teams mastered and independently adjusted a new format of design sessions for themselves. Due to this independence and the lack of a narrow link in the form of management, they also made adjustments to the remote format themselves and, admittedly, very quickly. As a result, for the next sprint-two, almost all the stories planned for work by the product owner are redesigned.

What does “designed” mean in terms of our readiness criteria? They describe in detail what and how teams are going to do, start and evaluate subtasks for development and testing, and protect the solution from architects and product owners. Below, for example, is an intermediate version of the design of one of the current stories of the Solar webProxy team in the Miro collaboration platform. It still needs to be completed on it in Jira, but it already looks impressive

Thirdly, for planning work on the sprint, we use a tool such as Timeline, a simplified analogue of Gantt charts. Teams create it when planning a sprint to highlight the relationship between different tasks and teams. In the online format, it turned out to be very convenient to run Timeline in Miro. It is worth noting that we think about security and therefore do not upload any data critical for the company to the cloud. Here’s what it looks like:

Here you can identify the subtasks for development and testing. You can put down the status of tasks and two funny emoticons to cheer up colleagues. We use and update this tool at our daily daily rally, where we briefly discuss the current status and problems, and successes in achieving the sprint goal. For a daily rally, we use Zoom until it shows itself to be the most stable solution. As a plan B, in case of problems with Zoom, we plan to use the Discord messenger. Now another of our Scrum teams is actively testing it. And, I hope, the other day I will share my observations.

Fourth, Sprint Review, which we started through Zoom long before the whole story with mass removal. The fact is that our presale-team has moved to another office for a long time, and we really want to receive feedback from them. Their view of customer problems, sometimes “non-standard” for us, and useful comments help to better adapt the product to customer needs. This time we broke our previous record, more than 30 people came to our Sprint Zoom Review.

I note that the teams already got the hang of quickly switching screens and transferring desktop control to each other. It remains to learn how to talk more about the business value of features and about which users and why they are needed. But there is definite and noticeable progress in this direction.

It is worth noting that Sprint Review is becoming a serious unifying event, which, in addition to its main purpose – increasing transparency and getting feedback – is becoming a place where you can pause to discuss hot news together and just laugh at another meme about coronavirus.

Fifth, retrospective. To be honest, she personally caused me the most anxiety. This event is held at the end of each sprint to discuss all its pros and cons and outline specific steps for improvements in the next iteration. As a rule, this event is very saturated with communication, and it is difficult for remote employees to participate in it. This time we all had to feel in their shoes. Miro came to our aid and ready-made templates for retrospectives in it – this is what happened:

And even one number of stickers pasted shows that the event was a success. There are comments on timing, but I hope that with the growing experience of our Scrum-masters in the online format, we will successfully overcome this problem. The main thing I’m absolutely sure of: switching to remote work will not stop teams in their continuous process of self-improvement!

What passed, as usual, and has not changed with the transition of the whole team to remote work, this is a daily rally. We have been spending it for more than a year, the format has settled down, and the presence of Timeline allows us to look at the course of the sprint as a whole, and not focus only on our tasks.

Like a growth point, It is worth noting that for faster and more effective PBR meetings, especially in distributed teams, we will ask the product owner’s team to more actively use a tool such as USM (User Story Mapping – User History Map). It allows you to more easily and more fully immerse yourself in the context of the user’s problem and highlight the way to solve it more clearly. Recorded short videos with stories on such story cards work very well in the remote format.

Summary

In general, we studied a fairly large number of materials and tools for remote work. Watched Training coursesdeveloped by our HR specialists. Went to a free online conference on the transition to remote work ONLINE DAYSorganized by Scrumtrek. Records from her, by the way, are available. link. Slowly we begin to introduce all sorts of chips for remote work. But here the teams themselves are mainly the initiators of certain innovations.

Briefly about the toolson which we stopped at the moment (maybe someone will be useful):

We use Rocket.Chat installed on our network as the main text chat. It is available on desktop machines and on mobile phones of almost all employees of our division. You can easily write to any colleague, just knowing his name, and quickly get an answer. The other day IT updated it to the latest version, and some of the problems voiced by some disgruntled telegram lovers disappeared. Thanks to colleagues from IT.
For quick voice communication, one on one, and in the format of large conferences, we use Zoom. The Solar Dozor development division acquired several paid Zoom accounts in the summer and now takes full advantage of the lack of restrictions on conference times. True, with a sharp increase in those who wanted to take advantage of these accounts, I had to add them to our corporate Exchange and book them as negotiators.
Testing Discord. Its main advantages: in one tool there are text and voice channels plus video calls with the ability to share the screen. Moreover, the ease of transition from one mode to another brings the quality of communications and the feeling of them to a new level. The Solar webProxy team already considers him their second home. Together they spend their entire working day at Discord: talking at daily rallies, having paired and / or mob programming sessions, discussing and designing technical solutions. According to colleagues, with the advent of such a tool and a high level of intra-team communications, they are no longer afraid to spend a month or more online.
For retrospectives, design and Timeline we use the Miro service. A very convenient tool for collaboration, in which we simultaneously glue stickers, draw all sorts of arrows and write colorful text. Sometimes it turns out a lot of fun.

In general, it is quite possible to conduct development successfully and efficiently in a remote mode. As they say, whoever wants, he seeks opportunities and certainly finds them.

Posted by Andrei Gritsevich, Head of Development, Solar Dozor