At Swarmia, we use the tagline "ship 10x faster.” To many, that sounds like an audacious claim. This blog post is the long footnote behind the asterisk (*) on that tagline.
When we talk about “shipping 10x faster” at Swarmia, we mean that your customers will have the features that matter to them in their hands 10x sooner. Ultimately, this allows you to serve your customers better than the competition.
“Shipping 10x faster” can be achieved through the combination of improving the speed at which you ship code, improvements, and — most importantly — value to your customers. In this blog post, I’ll explain and share practical examples of what shipping faster on each of these three levels looks like when using Swarmia.
Ship code faster
Shipping code faster is the natural starting point for engineering teams who want to improve productivity. It has the most immediate impact on the everyday life of the team members. Engineers hate wasting time on manual work or chasing people down to get their code reviewed.
When you’re deciding how to measure productivity, you want to avoid vanity metrics. DORA metrics are the most thoroughly researched engineering metrics with a proven relationship to business performance. The “lead time for changes” DORA metric is great for measuring shipping code faster as it measures "the amount of time it takes a commit to get into production.”
In Swarmia, we track lead time for changes through pull request cycle time. Our cycle time metric is broken down into four distinct parts: time in progress, time in review, time to merge, and time to release.
People often have an optimistic view of how long this process takes and are usually surprised when they see their team’s actual cycle time. Understanding their real cycle time allows teams to identify bottlenecks that have been previously invisible or downplayed.
Example: Team with slow code reviews
Here’s an example of a team that has a review time of 46 hours. This means that each engineer has to wait for more than two days to get their code reviewed — and often chase people down to get a faster review.
Swarmia can help the team in multiple ways:
- The team can adopt a review time working agreement that allows them to see how they’re doing and get daily reminders about pull requests waiting for review.
- They can enable review notifications for their Slack channel and a personal Slack notifications when a PR is reviewed.
- Swarmia’s pull request view clearly shows all the pull requests waiting for review across all the repositories the team is working on.
By making code reviews a priority, the team’s review time went down to nine hours, cutting away 37 hours of their cycle time. You can also see that their in-progress time went down by seven hours and merge time by six hours. Why? Turns out that when people have long review times, they start making larger PRs. They also forget to merge their PRs after they’ve been reviewed as they’ve already moved on to a new task.
In total, the team cut 50 hours (65,7%) of their cycle time, which means they now ship code to production ~3x faster.
Ship improvements faster
Once a team has understood and started addressing the bottlenecks associated with shipping individual pull requests, it’s important to start thinking about bigger chunks of work. Larger improvements or new features often consist of multiple tasks and pull requests. It’s common for the improvement to go live only after most of the tasks have been completed.
In Swarmia, larger units of work can be tracked through epic, story, and issue cycle time. These metrics show how fast you’re shipping improvements. Issue cycle time often reveals if a team is having a hard time focusing and getting things done.
Example: Improving the focus and impact of a team
Above we see Swarmia’s high-level Work Log visualizing epics for a team that’s having trouble staying focused. This manifests itself as very long issue cycle times and gaps in active weeks.
The developers in this team have clearly started gravitating towards simple tasks, instead of the roadmap work that's more difficult to complete. Whenever there’s a blocker, the engineers pick up a new task to work on. This leads to increased multi-tasking and amplifies the existing problems with cycle time.
Let’s take a look at what the epic cycle times would look like if the team were able to reach 80% flow efficiency. “80% flow efficiency” means that the team does some work on the epic four days a week while the epic is in progress.
In this second screenshot, the red box is the original completion date and green is the new one. Every light red box represents a week of unnecessary delay. We can see that with proper prioritization, the cycle time for most epics could have been 2-3x shorter. For example, “Fantastic Rubber Cheese” could have been in the hands of customers almost five months earlier.
This is not an isolated example. We know from research and our data that teams with clear priorities are able to ship the most important things much faster. You can take a look at our blog post on improving issue cycle time to learn more.
To improve their focus using Swarmia, the team can do multiple things:
- Adopt a “work-in-progress” working agreement that helps them stay honest about their priorities.
- Adopt issue cycle time working agreements. These help the team scope their work into smaller chunks so they can maintain their focus and switch to other priorities in an organized manner.
- Adopt an “avoid solo work” working agreement to teach the team to split work better and collaborate on important issues.
- Drill down to individual issues to understand where the gaps in the work came from.
Ship value 10x faster
Industry-leading engineering organizations not only enable teams to ship code and improvements quickly but also help them focus on the most valuable work. In the end, the goal of shipping faster is not to build a huge list of features but to create value for customers and the business. We call this impact.
The highest-performing organizations aim for productive teams that are customer-focused. Teams that use good DevOps practices, infrastructure, and automation. Teams that ship in small increments, learn from their users, and take that feedback back into the product.
As software companies grow, maximizing value becomes a cross-team effort. It becomes necessary to align teams across the organization around strategic goals and to help them balance the investment between new features, improving features, increasing productivity, and simply keeping the lights on.
Swarmia helps teams consistently ship high-quality code and features while aligning on priorities with the rest of the engineering organization.
Example: Balancing investment between maintainability and building new stuff
Even teams with experienced engineers have big differences in how much they emphasize improving the maintainability of the product vs. building new stuff for customers. This is even more true at the company level, where customer support, sales, marketing, and other functions have different extremely pressing needs for engineering and product.
In many cases, shipping value 2-3x faster is about making sure you don’t waste time on unnecessary work. To prevent individual engineers, managers, or stakeholders from dominating the prioritization, you have to be deliberate about allocating your work. Swarmia’s investment distribution allows you to do just that.
The investment distribution above has been configured to use the categories recommended by Dropbox’s VP of Engineering. We can see how much reactive work goes into “keeping the lights on.” We can also see how much effort goes to “building new stuff,” “improving existing stuff,” and “increasing productivity.”
If “keeping the lights on” starts to grow too much, teams can prioritize projects that decrease it. Allocating around 20% of the remaining time for “increasing productivity” and an additional 20% to “improving existing stuff” allows engineers to continually improve quality and tackle technical debt. The limited allocation helps the team to focus on the most impactful technical improvements. Continually improving things allows your teams to continually ship value and not paint themselves into a corner with technical debt.
Example: Visualizing cross-team dependencies and unblocking critical work
One of the worst-case scenarios for an engineering team is to end up in a situation where they suddenly need to drop the majority of feature work for a long period of time. This can be caused by some pressing technical problems that require some kind of a migration or a dead-end brought on by the unexpected ballooning of a crucial project due to risks or unknowns.
These kinds of situations are bad enough for the team itself, but often cross-team efforts will suffer the most. Innocent-looking “patchy” tasks can immensely slow down cross-team work.
Let’s imagine three teams: the Core team and two feature teams, A and B. Both feature teams are building their own new feature that requires 10 days of work from the Core team. Only after the Core team has finished their contributions, the feature teams can start their own task that requires an additional 10 days of work.
Ideally, all of the work could be completed in four weeks without any waiting time:
Now, let’s say, the Core team has to spend 40% of their time on fixing bugs and other tasks required for “keeping the lights on.” As a result, the other teams have to wait for an added 12 working days to complete their work. Not too bad yet.
But what happens if the Core team has allocated most of their engineers on some major migration and only a single engineer can work on the 10-day tasks and works on each task every other day? Suddenly, the added wait time grows to 44 working days (~3.5x)
This may seem like a lot, but in reality, things often get even messier. Cross-team interactions can be challenging and yet, they have a huge potential for shipping value faster.
In this case, even a simple thing, like a work-in-progress limit in Swarmia, could have saved one of the teams 15 working days of waiting time. As a result, they would have shipped the feature to their users almost 2x faster (26 vs. 41 working days).
Summing it all up
Many software teams and organizations can achieve 2-3x speed increases on each of these three levels: shipping code, shipping improvements, and shipping value. Together, these changes compound and allow the organization to address the critical needs of their customers 10x faster than the competition.
Accelerating engineering performance requires a solid understanding of what makes engineering teams productive and tools to support continuous improvement. With Swarmia, all engineering organizations get the insights and tools they need to drive small changes that have a big impact over time.
