When developing our collaboration tool, Favro, we have two teams with developers based in Sweden, Vietnam and Ukraine. The distributed nature of our teams represents a great reason for using a collaboration app like Favro — put simply, we need something real-time, always on and always up to date to minimise communication loss and make sure everyone is in sync regardless of time zone.

We’re biased, naturally, but we love using Favro. However, we also love programming, designing and testing even more. Time spent in Favro manually dragging and updating cards is time spent away from our true passions. This is where Favro’s apps and integrations enter the picture.

So now let’s take a look at the Favro Core App team board:

Here’s a breakdown of the columns:

• Selected. Cards in this column have been picked out from either our product backlog or escaped production bugs board by the product owner. The team can simply pull a card from here and get to work on it.
• Doing. If someone is currently working on something, they’ll pull the card into this column.
• Ready For Review. Great! The code is ready for another developer to take a look at before merging into master.
• Done. The code has passed review and has been merged.
• Deployed in TEST. The team’s embedded QA have seen that there is new work ready for testing (and that our continuous integration builds have passed) and have built these changes to a test server.
• Testing. The previously built changes are now currently undergoing testing. The developer responsible for these changes will now spend their time explaining bugs away as undocumented features…
• Ready for Release. A feature has now passed both manual and automated testing and is ready for release either as a toggle feature or for immediate roll out to all users.
• Deployed in PROD. The feature has now been deployed to our production servers. It has made it the whole way and is now in the hands of our users. Time for a celebration.

As you are probably thinking, this process is extremely simple and could easily be handled by the team without the use of any apps or integrations. However, the whole experience for the team can be heavily optimised and improved by turning on some apps and integrations. So here’s the full list we use and why:

Defined workflow

The defined workflow app allows us to ensure cards are only created in the Selected column and then pass through each gate in the process. Since QA are so integral to our process when it comes to determining if a feature is fit for public consumption, we also apply rules through the defined workflows app to ensure that only QA can pull cards into TEST and so on.

Slack

The Slack integration posts whenever cards are moved into the Done column, which notifies our QA team when work is ready to be pulled into TEST.

GitLab/GitHub

Previously our process for commiting changes to our Git repository consisted of these six steps:

1. Pull a card into ‘Doing’.
2. Commit world class code into a Git branch.
3. Create a merge request.
4. Manually track down the card on the team board and move it into ‘Ready for Review’.
5. Another developer would then sanity check the changes and approve the merge request, merging the changes into master.
6. The reviewer or the original author would then need to manually track down the card again and move it to ‘Done’. It was typically adhoc who would be the one moving the card.

Whilst these steps are fine and generally worked well, they would often fail because of the need for a lot of human input. Sometimes the team boards wouldn’t reflect reality because someone would commit code changes without remembering to move a card to Done. Now with the Git source control integrations, we can streamline this process into just four steps:

1. Pull a card into ‘Doing’.
2. Commit world class code into a Git branch and include in the commit message the card’s human readable identifier, e.g. han-1234
3. Create a merge request. The card will be automatically moved into ‘Ready for Review’.
4. Another developer reviews the code and approves the merge request, merging the changes into master. The card will be automatically moved into ‘Done’.

Pretty neat. Once you pick up a card from Selected and move it to Doing, you can focus solely on development until you need to take the next card to work on, safe in the knowledge that the card will automatically travel through the process. In addition, given the distributed nature of our teams, we benefit from being able to collaborate and review code from developers on different time zones without needing to manually track down which card to move to Done to notify QA that code has hit master that is ready for testing.

WIP Limits

With all of the automation tricks we employ above, we could easily get ourselves into a position where developers start taking on work before their existing cards have gone through review. This is where we enable the WIP limits app to set a strict WIP limit of one card per developer in the Ready for Review column. We value finishing stories before taking on new ones.

Wrapping up

By taking advantage of Favro’s apps and integrations, we are able to automate and streamline a number of previously manual steps in our development processes. This help us improve the accuracy of the data in our planning tool of choice and reinforces the benefits of using it in the first place — improved collaboration and communication between our distributed developers, which in turn increases the velocity at which we can continously deliver improvements to our users.

I hope this post has provided an interesting insight into how we develop Favro.