When looking at a product like Swarmia, it can be hard to see how to put the theory into practice. In this blog post, I'll share how we use Swarmia to make our engineering team work better.
Getting pull requests through
The basic building block of any software company is getting your code smoothly through the review process and to production. If this part doesn't work, any other improvements that you attempt will have limited impact.
At Swarmia, our PR cycle time (measured from first commit to code deployed to production) is around 24 hours. That includes time that PRs spend waiting for reviews outside of working hours, so we're pretty happy with this number.
Swarmia helps us achieve this speed in two ways: the Slack notifications and the Pull Requests view.
The Slack notifications give you instant feedback when you need to take some action on a PR, which greatly reduces the waiting times. In addition to the personal notifications, we also receive team level notifications when a new PR is ready to be reviewed. We have a culture where anyone can review any PR, which makes getting reviews faster and effectively avoids knowledge silos.
The Pull Requests view is another way for us to stay on top of our pull requests. It shows all the PRs from our team members across all repositories, separated from the noise like bot-created dependency upgrade PRs. The PRs are divided into sections based on where they are in the review process, which makes it easy to understand what needs attention right now.
We're actively looking to help out with reviews, so whenever we have time between tasks, we just come to this bookmarked page and look at the Review section to find open PRs to review.
Reviewing where our time goes
The Investment Distribution view has been an extremely useful tool for our team. By setting up rules to automatically link issues and pull requests to investment categories, we can quickly and accurately see the general themes of where our engineering time goes.
We follow the Balance Framework approach, where work is divided to mandatory "keeping the lights on" work and elective investments (building new stuff, improving existing stuff or increasing productivity).
For our team, the biggest problem has been maintaining enough focus on building new features. As engineers, we often gravitate towards making the code nicer to work with (increase productivity) and sometimes lose focus on the customer-facing goals. This view helps us see when the balance is slipping, and has allowed us to course correct to ensure that we're also shipping new features to customers.
Hosting retrospectives
We host bi-weekly retrospectives in the engineering team. We usually follow a generic format, where we just look at the work we've done in the past two weeks and reflect on any feelings or thoughts that come up.
In our retros, we use Swarmia to give visibility into that work, because it's surprisingly hard to remember what the team worked on in the past two weeks. We take screenshots of the relevant views (Work Log, Investment Distribution) with a two-week timeframe and put them on our Miro retro board so that everyone has easy access to them.
We also go through our Working Agreements, though usually we are pretty good at staying on track with them, as we already get notified about exceptions in our Daily Digest.
In the future, we'll probably build a similar retro view into Swarmia but until then, the screenshot approach will do the job.
Reviewing work done
Every Friday at Swarmia, we host demos for the whole company and show some of the work that we've done. For this, we use the Work Log view in Swarmia.
We group the view by issue, and walk through each of the lanes, briefly describing the work that we've done and the work that's in progress. After that, we host individual walkthroughs of the features we've finished this week.
We also occasionally host retrospectives for individual features if we feel that there's something we can learn. For example, our team management epic didn't go as smoothly as we would've liked. We hosted a retro where we looked at how the epic progressed and discussed what we could've done differently. Swarmia's issue activity popup gives good visibility into how the work actually happened on that issue.
Using Swarmia in your team
This post explains how our engineering team at Swarmia is using Swarmia to improve our workflows and get real value out of it. Hopefully it gives you some inspiration, ideas, and a starting point, but as one of our product principles goes: "every team is different." These approaches may or may not work for your team, but as a tool, Swarmia is flexible and can adapt to your team's ways of working to support the way you want to work.
