How we work remotely

Being a remote-first company we have developed a no-bullshit set of usage scenarios for commonly known tools for running a remote software development team.

Ruunis is a Netherlands based global software consultancy that hires people from all over the globe to work on client engagement ranging from innovative blockchain startups and ending with business process automation tools for major enterprises the size of NOKIA, T-Systems.

The tools and scenarios that are described are used both in the clients' engagements and internally. Though the set of tools seems to be pretty straightforward, we guess it's good habits that make all the difference.

Delibr is an outlining tool for product management. It helps you to capture ideas before they have got an actionable shape. The beauty of the product is that it mimics the bullet-point like note-taking in addition to allowing end-users to change a type of bullet item in the future. Instead of a bullet-point, it can become a question, a task, a decision to be taken, a point of discussion etc.

What's also great, it has a deeply nested structure. Items within a document can be organized in as many levels as possible, helping you to really see how things interrelate and depend on each other.

Finally, any line/item can be converted into a Jira item that holds all of the history of the discussion, key decisions made and actionable information. Never have 'what was there?' kind of questions again. As we use Jira as our issue tracking system, it speeds up information exchange. We don't hold much information within 'tickets'. The information is captured in the document that tells the whole story of a piece of a requirement that has to be developed. When it's updated, the information gets updated in the work item too. Lovely!

Some ideas have to be chewed over before they are turned into requirements, and some have to be given a second thought. There are two ways how we treat this kind of problem, and the method depends purely on our ability to integrate a customer into our internal communication tools.

Savvy clients who are well-familiar with Slack can participate in an on-going discussion until an idea gets a digestible shape. We use idea-dedicated Slack channels for this purpose. One feature idea = one Slack channel. It creates chaos on day one but starting from day two sanity comes. You are able to stick to the topic of the channel and bring people in and out when appropriate to get advise, consultation. After the discussion is completed, the channel is archived and, to be frank, we even don't keep track of it as Slack does it itself by suggesting to you which channels have not had activity lately.

There are clients who just love email. Emails require a completely different level of skills. Discussing ideas over email is a pain in the ass. So, email is used as a 'transport mechanism' that pings the other side about the need to review something written down in a document that is stored in Google drive. Online documents give you space and time to think about what are you trying to convey really. If crafted well, these are perfect tools for asynchronous conversation via means of comments and editing.

There's information that has to be available to everyone and accessed often. Pins in Slack don't work. A nested structure of a file system in online storage turns into a mess quickly. Wikis is to the rescue. We use wiki for technical documentation, team retrospective notes, process description, shared access, architecture documents etc. Atlassian stack keeps improving and as we try to limit (no the extend of it not affecting quality of our work) the number of tools we use, we pick Confluence.

Spaces in Confluence is a fantastic and severely underutilized feature. We use spaces to group information between projects, clients, topics. For example, we may have a client that has two spaces devoted to her: one space is a technical space and the other is a user documentation space.

As a pleasant bonus, spaces can be converted into hep/user portals via Atlassian ServiceDesk. This decreases the need to communicate a lot and brings an extra portion of sanity.

Text is not the only way we communicate. Most of the projects require something visual to illustrate what's to be achieved and here Miro comes to the rescue.
We use it to create high-level flow diagrams, mockups that are then grouped together into complete use cases. We rely on virtual sticky-notes in order to annotate these use cases (read as product information containers/sections) so those important conversation bits are captured and placed where they truly belong. Those sections are added to work items in Jira, and as mentioned above, it allows us to keep names of the work items really trimmed so that Jira provides us with a tracking capability purely.

With all of the drawbacks, flaws, and inefficiencies Jira still remains our favorite issue tracking. If you don't like Jira, you just don't know how to cook it. Here's our recipe. Start with a project. One project per client/product that has a dedicated team.

Use epics as features/classical user stories, not as containers. Using epics as features instead of containers helps to keep information clean. Epics as containers tend to turn into messes of items somewhat related to the topic but that will never be worked on.

Use user-stories/tasks as work to be done in order to get something achieved. Use subtask as a WBS for layers of work.

Here's a simple example to illustrate the point:
Epic - log in (it has all of the acceptance criteria, test scenario, requirements information etc.)
Tasks: web, ios, android, backend
Subtasks within a given task (say iOS): update UIhandler component, Unit test

Now, you have all kinds of layers needed in order to understand where you are with regard to completion. You know how much work is remaining per a given stack of technology, you know what kinds of work have been accomplished in order to get the overall user story/feature done, you have all of the requirements for a feature/user story in the same place.

If we want to build some form a connection between the work items, we use releases. Each release has a number, name and a quick summary of the work items that are grouped together and the reasoning behind it.
We use daily standups for staying in the loop and resolving problems (more on this later) and therefore we introduced a number of boards each aimed at providing a different slice of information. For a typical project we relly on three boards: product management, daily activity, and a cost estimation board.

List of boards we use
Product management board slices work into epics (that are treated as user-stories/features in our case) so that we see what is lagging behind and what is progressing at a planned pace. As epics are organized in priority order, it's easy to keep everyone's focus on what's really important.

Daily activity is a board that is mostly used by our consultants and engineers to see what's to be done for this week and make sure that nothing is missing.
Cost estimation board relies on custom fields that calculate the cost of building a feature based on the original estimated field and on the hourly rate of the consultant. This is how we can answer a question: how much would it cost for me right away without much of back and forth discussion. Our clients appreciate the speed of this approach and its ability to influence product management decisions. Our clients know how much yet another product idea may cost them, become more thoughtful and way more organized.

A product backlog is not a trash bin. If you/your client is not sure that something is to be developed then you have two options: don't create an item, write it down somewhere else or have a separate space for items that are somewhat related and even have been discussed and agreed upon before, but seem out of the scope of interest now. Place them in a separate Jira project.

As for the structure of the backlog apart from having sprint containers that show work for two-three iterations ahead, we rely on three other containers before work items get to a backlog. Those 'sprints' (they are never launched that's why we use quotes here) are used to differentiate between the importance of the items that may be coming into work. Before an item hits a real sprint backlog it travels between Must, Should, Could containers and if it does not find a place there, it gets to a backlog until it's the right time or until it's disregarded completely.

We love daily standups. If organized well they tend to be a source of valuable information and the ability to set conversations aimed at resolving blockers. Some projects we run for our clients tend to have quite big teams of up to 20 people. In a remote environment, it can be a bit difficult at first, but with some practice, everything is kept into 15-30 minute conversation that kills the need to check-in and ensures that nothing falls between chairs. If there are questions to be answered you stay after the meeting. If there are things to be shared you stay after the meeting. You don't need to reach out to a person, negotiate schedule, etc. Everyone knows that they have a dedicated time interval to raise a flag, find support, indicate blockers. This is achieved by a simple trick of using screen sharing and a virtual board (Jira) focused on progress over the work items related to getting high-priority features done (this is the board that was called as a product management board). Beautiful!

We are in a completely distributed environment spread across the globe with up to 5-hour difference between the participants of the meeting, and it works. You absolutely don't have to be in the same time zone for this.

Statuses are provided by Jira and updates to Slack. Everything that changes status (and only those items) in Jira and Gitlab sends a notification to our Slack channel with #updates. Its a blessing for a product manager because it is literally as if you are sitting in a shared office with somebody and once something really important gets done he shouts 'Done', 'Code merged', 'Testing passed' etc.

Bugs happen. You need to log them, you need to inform the rest of the team about them. Often bugs are important and have to be worked on immediately. It means that the priority of an item has to be assessed once a problem is discovered. As with the updates in a Slack channel, we keep a separate channel per bugs. Having it separately helps to differentiate between the general course of events that can be followed by monitoring the updates chat and what' considered to be a problem. As we keep a separate Slack space for a client/project, bugs never mix and we can easily decide on what requires attention.

Emails will not go away in the coming future. We can only try to make it less obtrusive and more useful than they are now. Our product managers who facilitate delivery for a given client via context transfer and setting focus for the team write a weekly summary over email. This is followed by a 30-60 minute weekly video conversation to talk through the email, raise other important topics. The content of the email shares valuable context and sets the agenda. These are summaries, not reports. They can have a playful tone, usually very informative and help to answer the question of what's really important has happened, where shall the attention be paid.

Companies we know tend to overthink the complexity of vacation schedules by setting strict policies about who can take vacation, for how long, how much time in advance shall this be communicated etc. All of this results into a number of cumbersome systems that are used in order to communicate limited availability. You may got used to shared calendars, spreadsheets with availability schedules and even some custom software.
We approach the problem differently. We don't count vacation and sick days and we always pay for them. We just hire people that understand clearly that the company is there to make money, and therefore, if they cannot produce more than they cost or if they affect performance of the others so the company overall starts to produce less than it spends, we lay them off. What happens in your life, how sick you are etc. is not of our business. We don't want to know a thing about it. If you can't work today, or at this part of the day that we got used to see you available, just don't, and figure out how to fix it later.

This simplifies 'vacation accounting' quite a bit. Instead of having shared calendars, cumbersome spreadsheets or paying for some extra software, we use Slack and a channel where you inform the rest about the vacation, days off and sick leaves. This is how we know when you are available and/or whether we need to get prepared in advance for you being not available.

In a physical office you can always tap your colleagues shoulder in order to get attention, but how do you get this level of interaction when all of the team is remote. Obviously via some video conference. It really does not matter which you use (we use Zoom, though).

The trick is to count the number of messages you exchange with a colleague. We have learned this trick from an advertising genius David Ogilvy. He owns the idea of picking up a phone and calling a person with whom you have exchanged three messages already but have not understood each other yet.

Messaging is cheap. You can always make somebody busy with answering you. It takes a while until you get to a shared understanding so please call. Just make sure that the person on the other end of the line is available and can talk about this right now. As simple as that.

This is not relevant, though, for the environment in which you use shared channels in order to exchange ideas on a topic that is yet to be given a shape.

We hope you have enjoyed reading it as we enjoyed writing it. If it inspired you to either try remote work out or experiment with some of the presented approaches it means that we managed to achieve what we wanted.

You can always send kudos to our email d[at]ruunis.com, share this with colleagues or approach us via the contact form.