It has been a year since most of our life has become online. We at ISPsystem are used to working from the office and seeing all team members every day at arm's length. I adapted quickly to the new format. However, I will be honest; working remotely is not as easy as it may seem from the outside. Many fail to cope. The lack of live communication and the too familiar four walls make you not notice how the seasons change.
So how can one adapt to the situation? How to diversify your work, get new experiences and pump up your skills without leaving home? I want to share our experience with internal mission trips. It can be useful for companies that have several product teams at once.
The idea of mission trips
The idea of sending people on mission trips originated with management long before the pandemic and the switch to remote work. The basic idea was to take one technical specialist from a product team and send him/her out for a couple of sprints to another team. We had five teams in our company at that time, consisting of frontend and backend developers, QA, UX-designers and product specialists. It seems we all work plus or minus the same, we live by scram, we close sprints... Still, each team is a separate world, with its own processes, approaches to work and habits.
The mission trip looked not only like a good way to diversify the life of a developer or QA, to gain experience with another product and improve skills, but also as an opportunity to transfer useful processes from one team to another. Sometimes it happens that there are not enough resources in a team to solve a big problem. In that case, a mission trip is also a way to help the team.
“For a person, a mission trip is a change of scenery. When you work on one project for a long time, you get bored. It seems like everyone around you is creating something interesting and you are the only one stuck in a dull routine. However, in fact, programming is programming everywhere.
It is also an exchange of experience and an opportunity to do a kind of audit. To understand how easy or difficult it is to onboard people to the team, to look at the processes from the outside”.
Alexander, Head of Development and Testing
Offline mission trips looked harsh. With a full-fledged move to another office and full immersion in the atmosphere and internal workflow of the other team. Imagine several people from different teams meeting in a hallway with monitors in their hands on the same day. For us, this picture was not so surprising, as transitions from one team to another are usual for us, although not frequent. Therefore, a mission trip was interpreted as a transition to another team for good. One team is saddened by the loss of a soldier, while the other, on the contrary, is delighted with the new member.
First mission trip offline
The pioneers of the experiment were the developers. It seemed that it would be easier for them to fit into a new product. The technology we have are more or less the same, the products are similar, for example VMmanager and DCImanager overlap in their functionality in many ways. The duration of the mission trip was set at about a couple of weeks, but there was no clear end date.
But it is the first step that is troublesome. The first mission trip of one of our frontend developer was unsuccessful. He was sent to another project to help develop one of the big features. It was supposed to take a couple of weeks, but it took a long time to develop. The team became worried that the mission trip would turn into a full-blown departure. That was exactly what happened. After that, we began to look at the experiment with apprehension.
Mission trips stopped for a while. Eventually it was decided to restart them – to send people to help with major tasks.
"I went on a mission trip already after the start of the pandemic, going to the DCImanager team for three sprints.
I had been given the following goals: to help the team by writing a feature, to share experience, and to provide an outsider's view of the processes. But the main thing was to put out the fire. The team was short of resources, and there were many tasks. The mission assignment of writing the "Scripts" feature was successfully completed, experience was gained, and feedback was left. The benefit was that I really helped the team with their current work. Even though all the teams are doing the same work, the processes are very different."
Alexander, Frontend Developer
My mission trips
I work as a QA Specialist on the BILLmanager team and have pioneered mission trips among QA. Whereas everything worked out with the developers, with the exchange of experience among QA things were a little more complicated. Even though we understand each other better and communicate more often after the Testers’ School, still, the testing processes in the teams remain different. Some teams predominantly rely on manual testing, while some prefer automated testing. One team writes checklists, and another writes test cases with a high level of detail. Everyone uses a different approach, which comes from the needs of testing a particular product. At this point, we are only striving to standardize them.
My first mission trip was in September 2020 to the VMmanager team. I was a little skeptical of the suggestion to "go on a mission trip”. Although it is very useful in terms of growth, changing teams still means leaving your comfort zone. It is a shake-up that I was not prepared for, but I decided to try it out of curiosity.
Doing mission trips with the switch to remote work has become much easier. There is no need to drag all my equipment and a bunch of things to a new workplace in one day, to adapt, or to waste time. You wake up in the morning, have a coffee, turn on your laptop – and there you are on a mission trip. A new team, new challenges, new experiences, all with a cat on my lap.
The duration of the trip this time was clearly defined - six weeks. All of the company's teams live on two-week sprints. Therefore, a person is on a mission trip for three full sprints. This should be enough to delve into the product, learn about the processes of the team and start solving problems.
My goal was to look at the testing processes in the team, to optimize them if possible, and to pass on my experience. The mission trip proved to be a good way of sharing knowledge.
During these six weeks, I was able to get to know the product better, look at familiar processes at a different angle, share experience and give feedback to the VMmanager team. I was also able to introduce some useful practices used in BILLmanager to the team. This way, the VMmanager team now has a task template that allows them to describe bug reports more accurately and completely, and detailed checklists began to appear in the tasks.
My second business trip was four months later. In February 2021, I joined the DCImanager team for three sprints as well. The purpose of the trip was the same. As a result, I got to know the product better; it turned out to be very complex, but interesting. I looked at the testing process. It actively uses automation to solve many problems – this is fundamentally different from the approaches of other teams. In addition, of course, I saw another variation of the processes I am familiar with. We have a lot to learn from each other. I was able to take only a small part in automation, but it was a rewarding experience. Now I want to start using it for everyday tasks.
The benefits of mission trips
A mission trip is a great way to share experience for both development and testing. It is not easy, and at first it may seem like six weeks is too short to do anything significant. In fact, this period allows you at least to objectively assess your own level. For me, it became the most useful thing. I find it hard to evaluate myself. Especially because I have been working in the same product long enough. I used to wonder a lot about how qualified I really am. After the mission trips, my inner doubts were dispelled.
In six weeks, it is difficult to bring something to the team and somehow change the already established processes, but you can share your view from the outside and offer alternatives to improve them.
"This practice of 'sharing wisdom' has been useful. We have the same stack on the frontend in all of our products, so I started solving problems fairly quickly: I came in the morning, the guys explained the basics of the product, helped to get started with the backend and in the evening I was already doing something.
However, later, when the time came to present and deliver the feature, I realized that the testing and review processes in the team were built differently. It was unusual at first.
In the process, we discussed differences in code style and general architectural approaches. At the end of the mission trip, I brought some useful frontend learnings to my team.
As for the scram-process, it went without adopting any practices. I explained to the guys how retro and standups are done in VMmanager, I even tried a few standups in a different format, but it didn't seem to stick."
Kirill, Frontend Developer
What to consider if you want to arrange a mission trip at your company
The optimal duration of a mission trip is three sprints (6 weeks). Maybe more, but not less. Here is how it works roughly. In the first sprint, a person gets used to the processes, learns the product, and gets used to the team. In the second sprint, a person already begins to immerse into the team, do tasks, move toward the goals together with the team. In the third sprint, he/she is already able to assess the processes within the team, suggest ways to optimize them, or, conversely, understand what processes can be brought to his team.
There must be a break of at least six months between mission trips. It is not a good idea to move from team to team too often – it is a shake-up that can be exhausting.
You should plan your mission trips. Teamwork often involves long-term planning with resources in mind. There are rather large features or tasks with a specified deadline. To avoid having to rearrange plans within the team, risking deadlines or abandoning something halfway through, it is better to plan business trips at least a month or two in advance.
