Discover more from Dev Interrupted
How DevCycle Flattened Their Team & Increased Deployment Frequency
When a company successfully pulls off both of these things, you want to find out how they did it.
Successful engineering orgs have multiple moving parts – probably too many to list here. But, as DevCycle and many other eng teams have proven true, two crucial components of successful engineering teams are:
A proper tooling stack that best meets your engineering teams’ needs.
A set of metrics to adequately measure the success of those tools and how they impact your team’s performance.
At DevCycle, we’ve seen the impact this powerful combination of tooling and metrics has had on our team’s productivity, satisfaction, deployment frequency, and overall growth. We’re so confident about the positive impact it has had that our VP of Engineering, Nikolas LeBlanc, sat down with Dev Interrupted’sand Ben Lloyd Pearson to break down how we did it:
Who is DevCycle?
Before delving into the exact tooling and set of metrics we use at DevCycle, let’s set the stage a bit. Most importantly, you should know that we weren’t always the well-oiled engineering machine we are today.
We needed a new way for a traditional team to work
Our legacy brand, Taplytics, was fueled by a siloed, segmented engineering team. Our developers only worked in areas that they had the most experience in. There needed to be more knowledge sharing, and if something broke, you had to wait for the one person with the most expertise in that area to address it. In other words, things moved painfully slow — and were risky.
When we launched DevCycle, we knew we wanted to take a different approach: one that increased knowledge sharing, the versatility of our team members, as well as communication and collaboration within and among teams. Most importantly, this approach needed to allow developers to touch more aspects of the development process and get things moving faster.
When we launched DevCycle, we knew we wanted to take a different approach: one that increased knowledge sharing, the versatility of our team members, as well as communication and collaboration within and among teams. Most importantly, this approach needed to allow developers to touch more aspects of the development process and get things moving faster than ever before.
We flattened teams and then split them
So, we identified and invested in a few of our current developers and asked if they wanted to take on the role of team lead. We split the engineering group into various teams with two leads per team: One for the project stuff (“How are people feeling?” “Are tickets being completed?” “Is JIRA up to date?”) and one for the tech stuff (“Is the code for the project solid?”).
And then, when those teams proved they could work well together, we split them up again. As our VP of Eng, LeBlanc, puts it, “We split the teams in half, and then split those teams in half so that each team lead had the opportunity to work with new team members, on new projects, and blend what they’ve learned with other teams.”
Splitting teams up when they’re working well together may seem counterintuitive. Still, the end result was an engineering team where any developer could thrive, fix any bug, or assist with a given SDK, at any given moment.
No more silos. No more knowledge gaps. No more waiting. Things started moving fast.
DORA Metrics Allowed Us To Move Fast
We knew the aforementioned “things” (deployments, releases, bug fixes, change time, etc.) were moving fast because we use DORA Metrics to measure the success of our development processes. If you’re unfamiliar with DORA, it’s a set of metrics used by dev teams to track Deployment Frequency, Change Lead Time, Mean Time to Recovery, and Change Failure Rate.
With DORA Metrics in place, we could see that our deployment frequency increased as a result of the new team structure.
But, thanks to DORA, we could also see blockages in the pipeline, specifically around our PR-approval process.
At the time, we didn’t really have an established PR-approval “process” at all. Every single PR request (no matter the significance) just kind of waited around to be picked up. Of course, not many developers will pick up a PR over a ticket they’re working on, so many of these PR requests were pushed to the back burner–only to be visited days (or even weeks) later. This was hindering the full potential of our CI/CD pipeline and deployment speed.
Continuous Merge Completed Our New, Faster CI/CD Pipeline
If you’re unfamiliar with Continuous Merge, you should read this article.
But here’s the TLDR version: Continuous Merge is the process of automating your PR approval process so that once a code change has passed all tests in the CI pipeline, it will be automatically approved, merged, and released via continuous deployment.
If the thought of automating your PR approval process sounds scary, we get it. But with gitStream, you can actually assign rules for which types of code changes get automatically merged after passing tests in the CI pipeline and which should undergo a manual review.
As Pearson puts it, when using gitStream for CM, “you can still leverage your experts for PRs when you need them.” And for the lower-risk, mundane code changes that just need to prove they can pass your tests to be merged, you can automate the process.
What Continuous Merge Actually Looks Like Day-To-Day
LeBlanc reflected on how our team is using CM and DORA Metrics alongside each other to inspire growth across the entire organization. We use the GitHub<>Slack integration, so any PR that needs manual review is posted in Slack.
When someone responds with the “👀 emoji,” it means they are actively reviewing it. When they respond with the “✅ emoji,” they are finished.
The rule of thumb on our team is to take a few minutes to address any PRs in the queue if you’re between tickets. And since tickets are being completed faster than ever before (we’re deploying 10+ times per day), it’s never a long wait before someone has a minute to check out a PR.
LeBlanc credits DORA Metrics for the speed at which tickets and PR requests move now.
“One thing I love about DORA Metrics is having something to celebrate with the team,” he says. DORA gives you the insight to know when even the smallest improvements are happening, and there’s almost always something to celebrate. And if something is going wrong or can be improved upon, we also have the insight.
DORA Metrics have made our devs more proactive and incentivized to find inefficiencies in our pipeline and deal with them quickly.
Take our PRs, for example. Thanks to DORA + CM, there’s more attention than ever before being paid to PRs that need manual review because our team can actually see the impact that slow PR approvals have on our entire development process.
How we see tools like CM & DORA Metrics changing the way development teams work in the future
Obviously, DORA + Continuous Merge/gitStream has had quite the impact on our team. But there are still limitations to what we can actually get out of DORA. For example, DORA is really good at showing us where we’ve improved, how fast we deploy, how quickly we can address bugs, etc.
But deploying faster and shipping high-quality code doesn’t actually matter all that much if the features we’re releasing aren’t what our users want. And the only way to determine that they are is to identify the metrics to help us measure it and hold someone accountable for it.
Similar to how DORA and CI+CM+CD have held us accountable for our deployment speed and frequency, the future of our metrics and tool stack will ideally hold us accountable for finding and releasing features that really move the needle.
For more information on getting started with gitStream for CM in your organization, check out the tool’s docs.
And if you’re looking to improve your deployment frequency as much as we have here at DevCycle, check out how we’re using CM alongside feature flags to optimize every aspect of our release process.
DevCycle is the leading feature management platform trusted by companies of all sizes to improve their software development process, and ship features faster with confidence. DevCycle offers feature flags, A/B testing, real-time updates, and integrations with popular development tools like GitHub and Jira. Sign up for your free DevCycle account today.
Want To Add Continuous Merge To Your Team? “The Continuous Merge Guide to Merge Standards: A Free Guide To The Merge Standards That Empower Policy-As-Code In Elite Orgs.”
The Continuous Merge Guide to Merge Standards covers where CI/CD falls short, the importance of establishing merge standards on your team, and how LinearB workflow automation can help.
Inside, you'll find:
A breakdown of Continuous Merge philosophy and its many benefits
13 of our favorite merge standards that enforce quality and boost efficiency
Tactical advice on how to implement merge standards on your team