Remote work is coming - some pointers for developers

Many organizations find themselves struggling with the Corona Crisis, because they have never prepared for Remote Working. Without going into the reasons, I want to give you some pointers from my own experience of what you can do to make the best out of it.

The domain is huge, so in this post, I'll focus only on Developers in order to keep it a bit concise.

A remote working space - doesn't mean it needs to be much different from an office.

Working Remotely as a Developer

This has three domains:

• How you yourself work
• How you collaborate with your teams
• Participation in agile events

We'll take a look at each, separately.

Working remotely

Working remotely by myself, I have come to appreciate the value of a desk with three-monitor layout: Centrally in front of me, the laptop - on my left, the Web Meeting where I can see people's face - and on my right, a browser where I can switch between the latest build, the CI tool and the ticket system.

It's incredibly hard to maintain break discipline, and so I often spend many hours glued to my seat, despite all promises to myself to take frequent breaks. Therefore, an ergonomic chair is essential.

Although I do what is arguably called "home office", I refrain from taking the laptop anywhere else except my desk. I maintain an isolated (albeit small ) room as office which is noise protected. Still, I only un-mute the microphone when it's necessary to speak.

I maintain "regular office hours" (i.e. typically between 7:30am and 6:00pm) because that's when others need to contact me and I need to be there - for them! 

Since I have the luxury that I have a wall right in front of me, I also keep a Personal Kanban so that I'm always aware of where I myself am heading at the moment. I am not sure how important this would be to developers whose only goals are the team goals - as a remote coach, it helps me tremendously.

( While I have heard rumours that other people don't seem to do this, I keep the same level of hygiene as if going out, including proper attire. Everything else would just be gross - to myself! )

Team Collaboration

This section is more specific to developers, although similar aspects apply to other roles and responsibilties. You don't need to write code to rely on some basic teamwork practices.

Continuous Integration gets an entirely different meaning when working distributed and remotely - especially if your code base is bigger than your team! I prefer to commit after every single line of code change, whenever tests run green. Yes, that can be dozens of commits in a single day, and that's actually how it should be. If you haven't done so yet, now is the time to learn how to rigorously and reliably apply CI and Clean Code practices. It saves tons of arguments and headaches!

A physical board is out of question when nobody is in the room - you'll need a virtual task board, a.k.a. ticket management system. Without entering too deeply into the solution space, you'll need to update your tickets in real time is essential to keeping the team synchronized. The perfect time to update a ticket is to use the CI time between "Push" and whenever the CI returns the commit status. Commit hooks could be valuable to automate this process as far as possible.

I hate disrupting development because of meetings, but we need to synchronize - frequently. The easiest way to cut down on the need for synchronization through frequent pair or mob programming sessions. To do that in a remote setting, you should find an IDE plugin that supports remote pairing, and if your IDE doesn't support that - now may be the right time to move to a different IDE.

The next way to reduce disruptive meetings is to use your team's virtual office room and ping people, asking them for a convenient time to meet. Ideally, you're able to refrain from using separate chat apps, because that creates a different stream of communication that adds distraction and drains productivity: you've already got at least four things to pay attention to already!

Sometime, you'll want to be alone. Let your team know that you need privacy and turn off the camera when that need arises. There are many reasons - make Working Agreements that ensure everyone understands what your team's mode of collaboration is. Some such agreements could include, i.e. the need to recede, specific time periods where everyone has to be online, timeframes for pair programming etc.

Participating in agile events

Some events are inevitable, though: Dailies, Planning, Reviews and Retros for Scrum - as well as PIP, Demos and I+A in a SAFe context. 

Since this post would be too long with my full tips on each of those meetings, I'll cut it short here by giving some generic guidance:

• A "One person speaks" rule alone doesn't help because you often don't know who speaks next until that person does. Be forbearing when someone accidentally interrupts you. Maybe you need working agreements that make sure everyone gets their voice.
• Prepare for meetings offline. Reserve some preparation time on your calendar for this.
• Avoid status reporting during Dailies or Reviews. If you do this, you've got a collaboration problem that should be addressed as soon as possible!
• Arrange for appropriate tooling support for events like I+A and Retrospectives. Relying on your team office platform probably won't be enough. There are tons of tools out there. Invest time to research online collaboration tools. Experiment until you found one that suits you.