Some of you found yourself in a situation, where your company asked you to start working remotely very suddenly. Some of you were already working partially or mostly remotely for some time and found ways of dealing with the challenges it presents. No matter which group you are identifying with - remote communication and modelling isn’t always easy, and each day brings new ideas, tools, discoveries, and challenges.
I’ve decided to share with you some of the tools, techniques and resources I found to be working well. They are based on 3.5 years of experience working for remote clients, delivering remote consultancy and Domain-Driven Design trainings. I believe that you will find them to be useful and make your own transition easier.
Online board
Using an online tool that helps to communicate visually is a key to successful modelling. For me, the right tool for the job turned out to be Miro (formerly RealtimeBoard). I’ve used this tool for the first time 4 years ago and didn’t look back. Its collaboration mode is very slick: you can turn on mouse cursor tracking, see what has changed, comment, set timer and so forth. You can prepare a set of templates for each activity and let people draw and annotate graphs as they wish. That’s one of the opportunities of the online tooling - the modelling space is truly unlimited and gives amazing possibilities, so make sure you take advantage of them.
Another good aspect about Miro is their commercial offering. For people doing training or consulting, they have a consultant plan, where people can access a project for 24h using a daily pass, which costs $3 per person. It gives access to all features and so I can recommend it for private engagements. Another option is to use Anonymous Guest Editors that are free! The downside of that is that all the edits will be indeed anonymous, so it’s a tradeoff that you will have to make.
Breakout rooms
One of the challenges of online communication is its single-threaded nature - usually, only one person can talk at a time and having a separate conversation is harder. Fortunately, online video conferencing providers such as Zoom or BlueJeans have an ability to create breakout sessions. During such session, people are assigned to a set of smaller rooms, that are effectively separate calls. This way you can divide a bigger audience into small groups. I usually use groups of 3 or 4 people as I found such size to be very productive - because the groups are small people tend to keep each other accountable and it’s harder to slack off. Another related aspect is that in my experience an online training/modelling requires more facilitators than a regular in-person engagement as it’s not that easy to monitor progress made during many independent calls.
Short iterations
The attention span of attendees during a remote training or session will be shorter than what I’d expect from a typical in-person engagement. There are many reasons for that, and the reality is that some of the people will be multi-tasking or will have a sub-optimal working environment. For that reason to keep people interested and engaged, I usually split exercises and activities into short sessions (up to 20 minutes). Then after each session, we have short review or retrospective so that we can course-correct or make sure we are making progress. It’s also a good opportunity for people to have a look where other groups are heading and ask for feedback!
Lightweight documentation
The ability to keep, evolve and improve online boards with domain models is great. Unfortunately, it’s not going to replace proper software architecture documentation or isn’t providing enough information as to why the system was designed in one way or another. For that reason, I usually recommend teams that I work with to document their system architecture using C4 Model created by Simon Brown. It’s a structured, yet simple way of documenting the design, and can be easily versioned using PlantUML templates. Another tool that works great in a remote setup is an Architecture Decision Record. It’s a lightweight approach to documenting why the system is designed in a certain way, and it allows people to provide feedback on a decision asynchronously (for example with pull requests).
Camera
It’s a trivial but very important one. Having the camera on while working remotely with a group of people is a must for me. Because of the fact that we are not in the same room, we are already missing a lot of the non-verbal cues. If the camera is turned off then you are missing another one - a facial expression. I can honestly say that running a remote training, where I can’t see people’s faces is quite a frustrating experience as I can’t see if people are nodding, disagreeing or simply doing something else. So please do yourself and your colleagues a favour and have a culture of turning the camera on if you can. This way your communication will be more effective and productive.
Summary
That’s it! I found above to be useful for me. I hope you will also share your findings with the community so that we can all improve and discover better ways of working together online. If you are interested in exploring this topic further then feel free to join Gien, Nick and myself during our online DDD London meetup: “Group Exploration: How Can We Improve Remote Domain Modelling?”.