I've been an application developer in a Scrum team for more than five years, and I've now spent almost half of that time working remotely. In this series, I'll talk about the everyday obstacles and their solutions as well as best practices based on an "ideal" sprint. This first part is all about sprint planning, stand-ups, and pair programming.

Day 1: Planning

I'm sitting in my home office approximately 250 kilometers away from my colleagues in the Wiesbaden office, and I'm not just at the sprint planning meeting, I'm right in the thick of it. Our Product Owner sits proudly before us and shows us the new tasks for this sprint. They already shared the prioritized backlog with me in advance (on a Jira board). I can find any further information on a wiki page. Here we document key indicators from the last sprint (completed story points, open tickets, etc.) and important information for the coming sprint.

On my two monitors, I can see the whole team on one side and the sprint's wiki page on the other. Thanks to Confluence's Concurrent Editing feature, I can watch as they note down the names of the attendees. Whenever something is presented on the projector, my colleagues share their screen with me so I can see it too. I've also noticed that it's important to gain an overview of the room via video; without this level of communication, you can feel a little lost, and it's difficult to take part in discussions.

Day 2: Let the sprint begin

An enthusiastic "Good morning" in the chat opens the first development day of the new sprint. We're finally ready to get started. I can see all of the open tasks on the Jira board, as well as the most important information and sub-tickets necessary to complete them. Thanks to the virtual board, I can also see who is working on which task and get in touch with that person directly if necessary.

The ticket shows me all the essential information for the task: Has a branch already been made? Have changes been made to the code? Is the build still green? Is there a screen or even a click dummy? All on one page.

Day 3: Remote stand-up

An important part of Scrum is the daily stand-up. The team talks about their successes but most importantly the obstacles that have come up over the last 24 hours. We have a large monitor in our team area for this, complete with an Apple Mac Mini, Genius WideCam camera, and Jabra Speak microphone. They invite me to join via Google Hangout or HipChat and thanks to the fish-eye lens I can see the whole team. Both my colleagues in the office and I have our Jira boards open during the meeting.

After the stand-up, I sometimes stay in the channel for a while and enjoy a bit of the team feeling. My on-site colleagues can now make use of virtual stand-ups too, when working from home, for example.

Day 4: Virtual pairing

In our team, we have decided to program in pairs whenever possible and practical. "Pair programming" improves the quality of the code and encourages the exchange of knowledge. A common analogy is that of a driver and navigator: The driver sits at the keyboard, and the navigator more or less dictates. Thanks to video chat and shared screen functions, it works well when in separate locations too. Another positive side effect here is that I get to experience something of the team feeling in the office, as my pair-programming partner is often sitting there so I can hear what's going on around them.

There are numerous solutions for pair programming (e.g. Remote Pair Programming), although video chat and screen sharing works just fine for us.

Day 5: What was that again?

Despite all of the information in the ticket, there are often a few things that still aren't entirely clear and questions can crop up while working on a task. Depending on how complex the issue is, you can usually get the answer via chat or a short video call. Chat programs also serve as an indicator of who is in the office or a meeting. They are useful for fast communication on quick questions and exchanging snippets of information, but also provide some entertainment here and there. Larger documents are added to the microblog (with a notification in our chat) or on a Confluence page. This guarantees that all information is captured, and is, in case of doubt, easy to find.

Takeaway

Half-time – part 1 done! A remote team does require a certain technical outlay at the start, but above all, it demonstrates the importance of communication and documentation.

It might sound like (unnecessary) overhead at first, but a closer look shows that it can also be a positive thing for colleagues in the team office. Anyone in the team can work from home without having to make arrangements with everyone beforehand. Also, team members can quite easily jump right back into the middle of a sprint after a vacation and get to work.

In part two, I'll take a look at estimation meetings, reviews, and retrospectives – stay tuned!

Lesen Sie diese Seite auf Deutsch

Further information

Does a Distributed Workplace Work? Well, It Depends
The advantages of pair programming
Scrum meetings: Goals, team activities, and customer benefits
99 Reasons for Scrum: How service providers benefit from Scrum projects