It’s been a while since I wanted to share my experience about an atypical mission that taught me a lot in 5 years.
Scrum defines a framework for teams whose mission is to deliver a software solution adapted to an end user placed at the center of their concerns. Like a rugby scrum, all members of a team must push together in the same direction in order to move forward and achieve a common goal. Communication within the group must be fluid and fast. Proximity and physical interactions are an integral part of Agile principles. Within this team, the Scrum Master is in a way the scrum-half, and their role is to streamline the work of others by letting them focus on the essential: advancing the scrum. It is often called a “facilitator”; they must ensure that information circulates well and transparently.
Still staying on this rugby metaphor, how can you imagine a match when the scrum-half does not even play on the same field? This is exactly what I was asked to set up as Scrum Master of a team located nearly 2000 km from me, in Bulgaria. This article aims to share with you my experience, the problems I faced, and how I got out of them.
I started my mission in a British company in a restrictive legal context. The IT solution was developed by teams in Sofia, Bulgaria, and represented an important reference in Europe. After two years, the British company was bought by an American company whose technical part was mainly carried out in India. The Americans were then bought up by the Germans. In the end and with the various takeovers, I found myself with developers in Bulgaria, architects in Bangalore, Product Owners in Peru and all while reporting to Americans and British people. One of my biggest fears before starting this mission was my English, which was very academic and sorely lacking in fluency. I quickly caught up and am now able to survive meetings in English with very different accents and not always good sounds. In all, no less than 14 Scrum teams were working on changes to the American platform.
Now that the scene is set, let’s focus on my life as a Scrum Master to remote interlocutors.
It’s hard to feel like a full member of a team made up of people who know each other well, whom you’ve never met, and who don’t natively speak the same language as you. I had the opportunity to meet and get to know the developers and testers by spending a week every three months in Sofia. This frequency imposed itself because it corresponded well to the balance between budgetary constraints and the need to discuss face-to-face with my team. Human contact is essential for team spirit and cohesion. I don’t think I would have made it without these trips, which clearly allowed me to humanize communication with my team. The reception of the Bulgarians towards me has always been irreproachable and I have excellent memories of my evenings spent there!
A Scrum Master must listen to their team and not only in the context of a discussion between them and the team. They must succeed in capturing areas of tension, irritants, and anything that can slow down the team’s productivity. Very often, this information is not accessible through formal exchanges, and, without a daily presence, it is very difficult to identify areas for improvement. In my opinion, the Scrum Master must be “seen” by the whole team as a key resource who is there to improve working conditions and contribute to the well-being of their team members. They are not the leader of the team because it is the team itself that defines the procedure to follow according to the constraints of the company. This lack of hierarchy makes the Scrum Master a full member of the team.
Then there is the eternal question of whether the Scrum Master should develop or not. In my opinion, they can but must make it a priority to take care of the team. If the scrum half considers it better to push with their playmates, they are likely to be unable to focus enough on recovering and clearing the ball which is much more important for scoring goals. points. For my part, I did not develop but I followed closely what the development team produced to stay on the ground and be in the heart of the game. Code reviews were done online, via Crucible, and could involve several Indians depending on the modified files and the corresponding ACLs. It was a mandatory passage to allow Bulgarian developers to push their code. The most important thing for me was to earn the respect of the team by being useful on a daily basis. This last point was a bigger challenge than just improving my English.
Whatever the means are chosen, a remote Scrum Master can only exist through regular and benevolent communication. All coaches will tell you, that you have to communicate to move forward! The manner of speaking depends a lot on the individual. Personally, I use humor a lot to convey my messages. However, you have to be very careful about your level of English and the culture of your interlocutor because a little joke to relax the atmosphere can quickly turn into discomfort in the event of misunderstanding. I have personally experienced this kind of awkward moment with Indians who felt their intelligence insulted when I asked them to forget a misunderstood (or just not funny) little joke. Since that day, I haven’t tried any more acrobatic puns, or only with the Bulgarians.
There are several communication channels that each have advantages and disadvantages.
The phone is a quick way to get a message across and check that the person has understood. It also has the advantage of providing direct information about the mood and motivation of the interlocutor. Its main disadvantage is monopolizing someone’s attention at a time that may not be convenient and having a team member talking aloud in the middle of open space. As a former developer, I know that it can be very unpleasant or even counterproductive to be cut in the midst of creative madness. On the other hand, it is sometimes the best way to convey urgent information and ensure that it is understood and taken into account. It’s all a matter of dosage. The best thing is to reserve a time slot to plan a call on a specific subject if the urgency allows it. Videoconferencing is an option that I have only very rarely used because I consider that it does not bring much more, except for first contact.
Writing is less intrusive and makes it possible to keep traces of the information exchanged. It also makes it possible to overcome any misunderstandings linked to an incomplete English vocabulary, whether for sending the message or when receiving it. When I started out and due to a lack of self-confidence, I used a lot of tools like Skype or sending e-mails to talk to my team members. I even happened to chat with Bulgarian colleagues when I was right next to them.
Choosing the most appropriate media is important, but much less so than the content of the exchanges. Bulgarians are generally very respectful of the hierarchy and considered me their superior, which somewhat curbed spontaneity and non-formal messages. Humor helped me a lot to smooth the exchanges and to show the team that I was on their side.
Identifying problems and taking corrective action is one of the missions of a Scrum Master. Even from a distance, it is possible to feel the frustrations and measure the motivation of a team. You have to be very attentive to all the exchanges, to the voice, to the lexical fields (although limited by English) or even the emoticons used. In general, I was able to identify human problems upstream and I took advantage of my trips there to try to solve them. One week was more than enough because these points were my priority. I often discovered that the situation was worse than I had interpreted. Over time, I became much more suspicious of these small details that could hide serious problems that must be dealt with quickly.
During the development of a computer application, a lot of data is created, representing an important source of communication. It is quite possible to follow the progress of a sprint during a day only based on status changes and ticket comments. The only constraint is that everyone modifies their tickets well at each of the development or test phases. I fought for a long time on this subject and my main enemy was the post-its that the team stuck everywhere. After they understood that it was faster to move an issue in JIRA than to answer their Scrum Master regarding a question about the progress of development, everyone got on it. Visual management is generally very useful but completely isolates people who do not have access to it. With well-configured tools and good work habits, we managed to do it without difficulty.
The Scrum Master is often likened to the person leading the Agile ceremonies. As these are generally based on oral exchanges, not having everyone in the same room can be problematic. One of the bases of Agile methods is the continuous improvement and the possible questioning of procedures that may not be adapted to a particular context. If a ritual is ineffective and a waste of time, it must be adapted.
Each working day, therefore, began with the scrum, which was by telephone. I was reluctant at first but it quickly became very important to me because it allowed me to greet the team in person, to remind them that I was there and that I shared the same problems as them. Better, I was there to solve them, and the fact of opening up to me allowed them to get rid of problems of organization and communication with teams all over the globe. The whole team ended up adhering to this ritual and understanding its value. Unlike a more conventional scrum where everyone knows when to speak, you must explicitly designate the next person to speak. I always managed to never follow the same order in order to keep everyone’s attention. It must be taken into account that in this kind of meeting, everyone cuts their microphone and can do almost what they want, so it is better to plan ahead. Before starting, I used to do some vocalizations to have an “awakened” voice. Warming up is very important before starting a match!
The context of the project was particular because the teams were not working on a global backlog but on important functionalities. These were described in a very comprehensive specification written by the Peruvian POs. In general, we could take between one and three subjects according to the complexity estimates made by the American architects (with a raised finger, it seemed to us). The division into functional stories was the responsibility of the development teams who chose the most appropriate mesh. It usually took several introductory and then Q&A meetings to estimate whether or not the team was able to handle all of the functionality within a sprint. The team was made up of Quality Analysts (1 for 2 developers) whose mission was to validate the correct functional coverage in automated tests. These people actively participated in the phase of clarifying the need. The team’s Tech Lead was tasked with providing a technical specification for the changes needed to implement the feature. The functional and technical specifications must imperatively be approved and signed by the architect of the solution, a kind of highly solicited great guru. The test plan was also subject to the approval of the “QA Managers”. We were far from an Agile context on this point but it was the procedure to follow because it corresponded more to the legal context preventing partial deliveries of a feature.
My role in all of this was to:
- schedule these meetings;
- clarify the need as much as possible;
- propose models to UX teams;
- obtain the validations to respect a very procedural Definition Of Ready.
I used to draw each spec on one page. It was an arduous but very instructive exercise because it made it possible to identify functional deficiencies and served as support for the creation of QA test plans. The expected functionalities generally corresponded to ports of what existed on the British solution to the American platform, which allowed me to use my functional knowledge on the subject. With 14 Scrum teams and time zones between India and the US West Coast, the preparation phase could last several weeks. All these meetings had to be prepared in advance in order to make these moments of exchange as effective as possible. I used to check my e-mail before going to bed in case the questions asked by the team had been answered. Not clarifying these points in the evening amounts to postponing the PO’s explanation until the following evening, who will not necessarily respond in the evening. In all, it is very easy to stay two days (or even more) with a question in suspense if the interlocutors kick in touch!
The retrospectives were mostly planned during the weeks I was in Sofia and did not always correspond to the end of a sprint that lasted a month. For those made remotely, I had to improvise a solution. The idea was to have PowerPoint support shared via WebEx. After presenting the scenario, each member of the team had to send me by Skype the positives and negatives. For my part, I had prepared the equivalent of post-its on a drawing tool (yEd) and all I had to do was paste the content of the message and the name of the team member into it.
As all the returns never arrive at the same time, I had time to have a document containing all the tickets. However, I had to act quickly so as not to break the dynamics of the meeting. The creation of tickets was done on a screen not shared with the rest of the team. Once all the returns were computerized, I presented a blank page to the team and I copied and pasted the tickets one by one. Its author would then add a short oral commentary to clarify what they wanted to say, just as if they were on the blackboard. When all the tickets have been positioned and grouped by theme, the retro can continue via PowerPoint support. The advantage of this kind of retrospective is that no post-it notes fall in an insistent way and that the final report is very clean. Once you get used to it,
The demonstration of the work carried out is, in my opinion, an essential step for the valorization of the work of a team and influences its commitment. The context of the project was very specific because a big meeting was organized every month for the 14 Scrum teams to present and share their achievements. The demonstrations were held remotely as they were aimed primarily at Americans and Peruvian POs. The imposed WebEx format lent itself rather well to the exercise and I never really encountered any difficulty with this ritual. Whether around a table or remotely, a successful demo relies mainly on good presentation support (Powerpoint under WebEx), credible data, and functional scenarios.
Demos are usually made by the developers themselves. In this mission and with the support of the team, I was in charge of presenting the functionalities that they had realized. I really liked these meetings because they allowed me to promote the work of the team and to have a very specific role that I gradually built up for myself. The developers were very happy not to have to devote time to preparing a meeting, not to have to speak in English in front of a large assembly, and above all not to have to answer questions that were sometimes very functional or related to functionalities. that they might not know. The environment of the demos was not particularly benevolent and it was an obligatory passage imposed by the Americans. One of the objectives for us was to show that we were quite capable of delivering quality features and to be considered as a team in our own right, on an equal footing with the Indians with whom we felt in competition. After two years of fighting, we managed to integrate into this complex organization and be a recognized team without distinction from the historical teams.
For those who have had the courage to read this far, you will have understood that my role as Scrum Master was quite far from the definition of the Scrum Guide. Nevertheless, the problems encountered are very similar. The essential point for which I particularly fought was to find my place and to feel useful to this team. I must say that my last two years working from home have helped me a lot. Just like for an on-site Scrum Master, I tried to make myself available and protect my team. I managed the meetings very early with the Indians or very late with the Americans or the Peruvians in order to let the team focus on the deliverables and the improvement of the solution. Although the Scrum Guide does not recommend that the Scrum Master handle the communication alone, in our context and in view of the complexity generated by this communication, it was I who took care of it. To be able to embed a feature, it was necessary to obtain approvals from different people for the specifications (functional and technical), the test plans, the UX… Rebelote to validate the developments and push the feature into production. I have never seen such exhaustiveness in the Definition of Ready and Definition of Done.
A few weeks ago I was in Sofia as a tourist and talked a lot with my former colleagues. They told me then that they had especially realized the importance of my role once I had left because they had collected a whole bunch of very time-consuming external requests. This is the thankless role of the Scrum Master. When it’s there everyone wonders what it’s really for and when it’s gone, everything becomes more complicated.