Remote Scrum: So close, and yet so far away

Axel Lütgering

Market & Community

For obvious reasons, a lot has recently been published on the topic of video conferences and remote meetings. Some of the content has been obvious, surprising, and even helpful, of course. The challenges of working from home and beyond also seem to have been considered in detail from all perspectives. We do not intend to use this blog post primarily to deal with these rather general topics. Here we will focus on how to use the Scrum method for remote work based on the example of our company’s experience. Thus, the article will be very concrete and hands-on: How does Cloudogu address the issue working agile?

Since mid-March we have been completely bound to our offices at home, where we have been facing a constant and even increasing workload, including the onboarding of new colleagues. In summary, we can say that the transition to our new working arrangement was rather easy, since we were already using many of the capabilities afforded by Google’s G Suite. Thus, as a team, we were already familiar with the handling, features, and processes of these tools. Thus, any barriers to using the tools were already relatively low. In addition, even before the Coronavirus period, we had a number of remote employees who were well integrated into our workflows, which means that we were able to draw on our experience here. It is, of course, helpful to use a well established and self-explanatory tool, but anyone can find the right one for their company from one of the numerous existing offerings (Mural, Miro, Conceptboard, Zoom etc.). You need to be willing to experiment a little and apply the principle of “inspect and adapt.” And above all: You need to have patience for when something doesn’t work out smoothly the first time.

However, let’s get back to the topic of remote working using Scrum. So how is that even possible? Doesn’t agile organization depend primarily on communication and interaction, and thus inevitably on the personal proximity of the team? Can it effectively be transferred to the offices at home?

Scrum artifacts

Most companies that work professionally according to the Scrum method will certainly use an issue tracker such as Jira or Redmine, which means that there will be no difference in terms of how the product and sprint backlog work from what is true on site. The issue tracker also provides a burndown chart to illustrate the daily progress of the sprint and to reveal any impediments.

A consideration of some Scrum events in detail – My subjective view as a Scrum Master

Where we face the real challenge is with Scrum events, since working with these events remotely presents a significant difference from working on site. We use Google Meet video conferences to conduct all of our meetings. This tool is able to handle our number of participants well, it is constantly being optimized (i.e., they added a tiled view of the participants without needing an add-on), and it is easy to use. For example, I like the feature to automatically mute new participants when a certain number of meeting participants is exceeded, which allows me to keep the noise level low from the start.

(Details about the tiled view in Google Meet)

On the other hand, I find the integrated chat to be a source of distraction. Though users leave helpful comments there, there are sometimes also parallel discussions, which may lead participants away from the main topic. This is where we need a moderator. We typically use TimeTimer on-site to help with our time management to nudge employees to work efficiently. Instead, as the situation requires, I have used an online tool when working remotely. However, when you constantly need to change split screens, this can sometimes be problematic and not always easy to use.

Here is a small tip: If you enter a number after the slash in the URL, you can set an exact amount of time for the countdown without having to use your mouse (so, for example http://visualtimerapp.com/20).

Now, for a detailed discussion of selected events:

Daily scrums

As the Scrum Master, at the daily scrum meeting I share my screen in most cases and show the task board of the current sprint, which also used to be displayed on a large plasma screen at our daily scrum on site. If specific user stories are mentioned, I will open them on the display to share individual tasks and statuses. At the daily scrum, it has also become an established practice to let colleagues speak in a certain order, so that no one is surprised by suddenly being put on the spot. This makes it possible to minimize the amount of time that participants need to prepare their remarks. Some teams prefer to “walk the board” instead of asking individual colleagues to answer the three established questions (see box), especially in order not to lose track of the ticket progress. In this case I go through the board from top to bottom, and we briefly discuss each ticket. At the end of the daily scrum the work is divided up, so that everyone is assigned something to do.

Since we can no longer physically display the sprint goal in the development rooms, during a two-week sprint I have become used to showing it twice at the end of daily scrums together with the retrospective measures, so that we can maintain focus here too.

At the end of the daily scrum I show the respective burndown chart and ask the product owners whether they have any additions or new current developments and comments. Our experience has shown that employees are good at keeping to the binding time limit of 15 minutes.

Often employees reach agreements about collaboration and they conduct meetings or pair programming during the daily scrum, so that they are able to ensure that they will continue communicating during the day. We have also experimented with a permanently open meeting room to bring a little office atmosphere into the home office. However, it quickly became apparent that no one was using the room, since it makes more sense to go straight into pair programming after a brief chat session or to use similar formats.

Sprint Planning

In Sprint Planning I (“What should be implemented in the upcoming sprint?”), the product owner shares the screen, and the first thing that they ask is about the available capacities of the individual team members. Then we switch to the issue tracker (which is Redmine in our case) and go through all the tickets that have been proposed for the sprint. Most of the tickets correspond to the team-specific “definition of ready” as a result of backlog refinement, and a few tickets still have to be refined during the course of planning. During the backlog refinement phase, we estimate user stories mostly on the basis of T-shirt size. During sprint planning we estimate all user stories planned for the sprint using story points.

Conducting planning poker through the chat function: You can do it!

At this point in Sprint Planning I, we opted in favor of Magic Estimation since it is the most efficient. If we were to conduct a similar procedure through remote planning, we would have to change the medium and increase redundancies and setup times (e.g., in order to transfer the individual user stories to notes on a Google Jamboard). So in this case we decided to use classic planning poker here. To this end, we use the chat function of the meeting tool: if all participants believe that the story is sufficiently clear, a story point estimate is posted in the chat at the same time. The colleagues with the lowest and highest estimates exchange ideas until a consensus is reached. The story points are directly entered in the issue tracker. Once all the stories have been estimated, everyone claims the stories that they would like to work on in the next sprint by registering them directly as editors in the issue tracker. This method helps to surface whether an employee has too much or too little work. If we consider the average velocity of our last sprints, we can make a realistic estimate as to whether the workload can be achieved or possibly reduced in consultation with the PO to a manageable level that everyone can feel comfortable with but that is nevertheless ambitious.

The sprint goal is then set. During Sprint Planning II (“How should the planned stories be implemented?”), individual groups of developers are assigned to their own meeting rooms where they perform the task breakdown. These tasks will be refined or expanded in the course of the sprint. Our Product Owner and Scrum Master are usually no longer in attendance during Planning II.

Sprint Review

The sprint review with almost 30 participants feels almost like the one that we conduct on site. Before we implemented measures in response to the Coronavirus, our colleagues would share the screen and present their new features. In addition, even during these in-person meetings we also had a relatively large number of remote participants. So, there is nothing that feels unusual about conducting the entire event remotely. On the contrary, my impression is that the event is even a bit more stringent and regulated now than before and that it allows us to learn much more. It is also easy to leave feedback: though I criticized the chat function above, here it is often used without disturbing the presentation. In this case the chat provides a good alternative to interrupting the speaker to ask questions or make comments.

Sprint Retrospective

In my view, this is the format that presents the largest stumbling blocks when conducted remotely. Since emotional issues are also discussed here, the total lack of or reduced number of body language queues to respond to is a real shortcoming. When strong emotions are involved, it is not always easy to prompt colleagues, let others finish speaking without interrupting them and rushing ahead. Nevertheless, I have noticed that a certain routine has crystallized among the meeting participants. We initially experimented a bit with other tools, but in the end we settled on using Google Presentation as a whiteboard and Google Meet. Google Presentation charts can be edited collaboratively and in real time, and they offer several options that go beyond a pure Jamboard or Google Draw. At the same time, there is no significant barrier to jumping in to use this tool. The tool should feel natural and be self-explanatory, if possible. We try to recreate the retrospective process that we already introduced on site using “Set the Stage” with the “weather report“. Each participant moves their token in Google Presentations and reports how they felt about the last iteration. We used to compare our assessments on site with the Happiness Radar. However, for most of our teams working at home we skip this part, since the lightness and casualness of this device cannot be recreated remotely.

After we review the effectiveness of the measures from the last retrospective, we look at processes in detail: Liked, Lacked, Learned. The retrospective participants prepare cards on their own chart in a defined time slot. Only once everyone is finished writing do they copy them onto the collective whiteboard. This is something that we learned from our experience conducting our initial remote retrospectives: when all participants see what their colleagues are writing, the level of distraction and influence on their own thought process is immense. On top of that, it makes sense to limit the number of cards (if everyone can agree to this). This forces everyone to focus and prioritize their thoughts, and it also makes it easier to cluster their cards. In addition, it is easier and faster to write cards using a software tool than on-site on sticky notes or metaplan cards, where participants can quickly reach 10 cards each, which eats up time and space. We have now settled at a number of around 4 cards per colleague. Participants do not find this limit to be excessively restrictive. If participants feel that that they still need to add a card with another topic, then that’s fine too. When all cards have been placed, we will try to identify the clusters together and move the cards around accordingly.

Once we are done with the dot voting, we start our discussion of the high-priority topics and derive measures from them. In one of my teams, one colleague with a talent for drawing transfers the measures to a flip chart, takes a photo of it, and shares it in chat. The small illustrations and visual aids make the measures more memorable. This method is largely similar to the format that we use on site, where we also write the measures on a flip chart, which is then hung up in the shared office.

“Hey, that’s my card!” – The homo ludens at work

One of the most important takeaways for me of conducting the scrum format using a shared tool is: Be sure to curb the inclination of your colleagues to turn the experience into a game! “You stole my point!” and “Wasn’t that supposed to be blue?” are typical remarks. Participants also gladly undertake “modifications” of the whole chart. It’s funny, but this behavior is sometimes not conducive to achieving our goal… It is a shame that we can’t share the candy remotely that we otherwise indulge in at our in-person retrospectives! ;-)

Outlook

It will be interesting when we return to the office in the future: there is a high probability that the proportion of users working from home will increase, so then we will face the completely different challenge of how to conduct hybrid-format meetings: Challenge accepted!