I've been working as an application developer in a Scrum team for more than five years now, around half of which I've spent working remotely. While the rest of my team is in the office in Wiesbaden, I'm working from my home office 250 kilometers away in Swabia, in southwest Germany. This two-part blog series looks at how we handle distributed work. The first part was about sprint planning, stand-ups, and pair programming. Now, we'll move onto backlog refinement, code reviews, and retrospectives.
Day 6: Backlog refinement
On Monday, there's a fully loaded backlog awaiting refinement – the process of looking for and defining user stories. We discuss any open issues, ambiguities, or questions, aiming to each come out with a manageable story to work on in the next sprint.
To do this, it is important to "estimate" the complexity of the user story. There are many different approaches and estimate variables you can use. We estimate based on the concept of story points. We usually use the Magic Estimation principle for allocation, which considers the complexity in relation to other user stories. After all, it is easier to say Story A is more complex than Story B than it is to assign Story A an absolute value.
To put it in a nutshell: We usually have five to ten user stories, which we first arrange in relation to one another. To do so, the developers each hang printouts of their stories on the wall in turn. At the same time, one team member synchronizes the arrangement of the stories in Confluence using Live Edit mode. Rather than using the standard Jira issue macros, we use our Jira Issue Manager app, as this allows us to read the ticket description while in Edit mode.
This way I can see all the stories in real time. One of my colleagues moves my story around for me on the board until it is in the right spot. Once all stories are on the board, we adjust the order again step by step. When everyone is happy with the order, we group the user stories and give each group a story point number.
Day 7: There’s a bug in my app
As software developers, we often receive bug reports, which can be caused by a number of different things. The first thing to do is clear up any issues with infrastructure or the specific version itself.
If we can't reproduce the bug, we first have to rule out incorrect use. Depending on the description of the problem, in this context, it often makes sense for an employee with a technical background (developer) to talk to the customer. Since we usually don't have access to the customer's system, we mostly use desktop sharing. Luckily, I can do this from wherever I am.
If it does happen to be a real bug, I create a task in Jira, and the Product Owner then prioritizes it. Throughout this entire process, the customer has no idea that I'm not in the team office and my remote work has no disadvantage for them.
Day 8: Code review
A story is not fully complete after the implementation of the tasks alone; quality assurance is also a necessary and important step. This includes a technical test (to test acceptance criteria), UI and UX quality checks, compatibility checks, and a code review.
We have agreed that at least one member of our own team and one member of another team should review the code. To do so, we open a "pull request" in Atlassian Bitbucket, in which all changes are visible. The reviewers can leave comments and tasks in every line, which the creator can then resolve. Once all tasks have been completed, the reviewer can then approve the pull request. When the build server then says "all green" (Bamboo), we can merge the new code, and the story is complete.
I enjoy reviewing code and see it as a good opportunity to interact with developers on other teams. When you're not in the office, it can quickly become that case that you are only really present in your own team. So I try to take part in as many cross-team projects and meetings as possible.
One such meeting is our Developer Weekly. This is a chance for developers from all teams to meet up and talk about challenges, solutions, and tools. As with any other meeting, I can easily join via video chat and be part of the action.
Day 9: AgileOrg review via live stream
Once a month, we have the AgileOrg review. AgileOrg is a process for continuous company-wide improvement and transformation/change. This is where individual workgroups present their results to their colleagues. It is also a place to introduce new team members, and provide general company updates, etc.
It's worthwhile for every employee to join so that they don't miss any important information. The company recently started streaming it directly via YouTube Live and also providing a recording for access after the event. This is also a bonus for colleagues who can't be there for other reasons. With a good camera and microphone, the quality is significantly better than your conventional video chat. If anyone has a question, they can post it on the Hipchat channel for the presenter to see.
Of course, I can take part in the AgileOrg Review as a remote employee too. In fact, my remote work was once planned and presented as an AgileOrg story (here's a post about it Does a Distributed Workplace Work? Well, It Depends).
Day 10: Review and retro
As part of the Scrum process, we hold a review at the end of each sprint. This aims to gain direct and, above all, fast feedback from the customer. Since we develop software products, we rarely work directly for any specific customer and so we don't hold a classic review, as you might in other Scrum teams. In its place, we hold an internal review (the jour fixe), in which all five development teams present their achievements and receive feedback from internal stakeholders. If I want to show something here, a team member lets me to use their computer for the presentation and displays my screen for the group to see.
The retrospective is the team's internal conclusion to the sprint and serves to continually improve and clear up any problems on all levels. Since we often discuss sensitive issues in the retrospective, I've found it to be the most challenging Scrum meeting to attend remotely. Meta information or non-verbal cues are often very difficult to recognize via video, especially in conflict situations. For this reason, I try to synchronize my visits to the office with our retrospectives.
A remote retrospective is also particularly taxing for the Scrum Master because they have to play the role of facilitator as well as acting as a proxy for me. When it comes to gathering topics for the retrospective (for example using the 4 L's), it's proven best to share my topics with the Scrum Master via Hipchat. They then write them all down and stick them on the board, while I explain them to the group.
When we use other methods (e.g. with large posters), the team sends me them in advance via email or Hipchat. But discussions and debates feel different via video chat, and it took quite some time for the whole team to get used to it.
Takeaway
As we already established in the first part, integrating a remote employee into an agile team requires good planning and above all, an awareness there is a virtual participant. All team and company-wide meetings must be made accessible to remote employees and encourage their participation.
Once the infrastructure is in place and it becomes natural for the team to have participants from outside the office, all employees can benefit. On average, more people watch the live stream of the AgileOrg review than the total number of remote employees in the company and just as many take advantage of reviewing the recording afterward.
Lesen Sie diese Seite auf Deutsch
Further information
Does a Distributed Workplace Work? Well, It Depends
Contemporary collaboration: Conflict resolution online
8 Advantages of an Enterprise Group Chat for Distributed Teams
Why HipChat, Microblogs and Confluence Should Be Used Together
