Team tourism at Allegro
We often hear about the importance of exchanging knowledge and practices between different teams. However, less often do we hear concrete suggestions for how to do it. In this article, we discuss one of our practices to address the problem.
This post is a part of a series of three posts about team tourism at Allegro. You can navigate directly to each part here: Part 1 | Part 2 | Part 3
What is team tourism? #
The idea behind team tourism is simple. For a fixed period of time (for example one or two Scrum Sprints), one team member joins another team to work there. In most cases, we aim to do something different from our daily routine work. It may seem that her or his efficiency can be rather low, but the long term benefits are overwhelming.
Other terms used for what we call “team tourism” are “exchange” or “rotations”, because sometimes we swap members between teams at the same time.
The incentive #
There are many reasons why we would like to change teams. Not only are there benefits for participants, but also for the company. In this section I will discuss reasons for doing the tourism.
First of all, there is a mutual exchange of knowledge. The person who is on the exchange can provide a fresh look at existing problems and he or she can bring new practices to his or her home team, as well. The opportunity to observe different teams and their strategies of solving problems can force us to rethink processes in our team.
Next, many developers want to learn new technical skills. For example, if your team is focused on backend engineering, it may be a good opportunity to practice frontend skills. For many of us, it was a big step out of our comfort zone. You may be a senior in your area of expertise, but suddenly you are in a totally different role where you are a complete beginner.
On the other hand, you may decide to go to the other team to explore your interest in some technology even more. During the exchange period, you should focus on one, and only one thing which interests you the most, to achieve a specific goal.
Boredom, burnout and monotony may happen to each of us. After working for too long on a single project you may want to refresh yourself. In that case, team tourism will probably have a vast impact on your morale.
If the product is enormous, it is often hard to keep track of all its facets. As a result, different departments are focused on totally different business requirements. While working in different teams, you may see other points of view which may be very beneficial.
What if this goes so well that the person on the exchange wants to stay? That is also possible and we do not say ‘no’. Of course that decision should not be immediate and more measured actions should be taken. Regardless of that, team tourism is a good place to start when you want to potentially change your team permanently.
Last but not least, we decide to do that kind of exchange because the team needs it. The person who is going to the exchange may go there in order to help the team achieve its goals. To illustrate, we may want to do this to remove some obsolete library from the project or reduce technical debt. Or quite the contrary, to introduce a new library or redesign an existing piece of software.
How to organise it? #
Truth be told, we don’t have strict rules or procedures how to carry out exchanges. Whereas other companies embrace explicit procedures, we mostly try to follow common sense, which can be described in a few sentences.
Before the exchange #
First of all, the need for team tourism should be clarified. Generally, a team member proposes the exchange, but there are cases when a team leader can propose it for someone else.
When there is a desire to go on an exchange, both teams and the person who will be on the exchange have to agree on:
- What is the goal of the exchange?
- How long it should take? When to do it?
- How to handle other duties (for example being on call)? Notice that deciding how long it should take is a completely different question from when to do it.
When you ask yourself the question about the length, it should be long enough to fulfil the goal of the exchange, but short enough not to cause any problems with your original team deliverables. On the contrary, when discussing the time to do it, you should keep in mind different lengths of sprints’ starts. Most common situation is that the exchange should take two weeks. Ideal situation is that two teams start their sprints on the same day. In practice, this is rarely the case, so it is necessary to reach a compromise.
After the exchange #
When the dust settles, and the exchange is over, the person on the exchange should summarise it. We do not impose the form. It may be in the form of a note, a presentation or other way of sharing knowledge. It is often summarised what was done or what was learnt during that period of time.
How to facilitate team tourism from day one #
People who work for several years in an organisation usually have resistance to change teams, contexts or projects. It is consistent with our habits and our human nature. We tend not to leave our comfort zones, which in this case is the team. What helps, is building a culture of tourism from the very beginning of our work. At Allegro this happens in some areas in technology - each new person joining the company spends from two to four weeks in two or three teams in their first three months of work. This greatly facilitates later tourism and makes the desire to develop your self in this way a natural habit.
Pitfalls #
During our practice with team tourism we encountered some problems, obviously. Knowing them beforehand might help you to be successful with tourism from the start.
If we were working from a single office, without remote working option, there would be no problem at all. Yet, we are working in a few different cities in Poland and we can work remotely. When being on the exchange it is important to work closely with your new team. Make sure that there will be no problems in terms of communications and locations.
Quite a common problem that we had was the inadequate length of the exchange. As a result, we finished the project (or our task) after the return to our original team. You have to keep in mind that when learning something new or doing something for the first time, extra time for unexpected problems must be taken into account during the planning stage.
When you are gone for the exchange, your team should be ready to work effectively without you and not bother you with daily routine. Unfortunately, it is easier said than done. There will always be some old task that will disrupt you or your colleague will stop by to ask you just one single question. The team should always be prepared to cope without one of its members.
Summary #
All in all, we believe that team tourism is a marvellous thing to implement. Not only does it enable us to be more agile, but it also help us improve our skills. Such benefits outweigh any organisational or personal costs mentioned earlier. We are working on pitfalls that we encountered and we will continue with team tourism in the future.
In the next few weeks we will publish five case studies written by our engineers describing their exchanges and experiences during them. Stay tuned!