When Arc first launched, the digital publishing platform had one client and full-time front end developer. Nine months later, two more developers joined. Now—somehow—we’ve grown to 12 developers on the front-end team alone, with most starting within the past six months.
Such sudden, massive growth is an exciting managerial challenge; it’s also a logistical nightmare. More developers, more problems, right?
Soon after our hiring spree, we started to see this firsthand. Unsurprisingly, it quickly became clear that 12 developers working in a single repository would be overkill, yet our workflow wasn’t flexible enough to accommodate multiple projects. Even when we did split into multiple projects, our Git flow wasn’t robust enough to keep everyone organized—and by that I mean that it didn’t exist.
It wasn’t as if we weren’t trying. We did some sprint planning, but we were sprinting on a functional basis. Front-end developers and back-end developers attended separate sprint-planning meetings with separate priorities, and topics assigned at sprint planning spanned across the multiple projects that people were working on. We held these meetings weekly, but didn’t enforce completion of work within the sprint; as a result, tickets often languished for weeks at a time, frustrating clients who wanted to see bug fixes and meaningful improvements.
In other words, we were agile with a lowercase “a”—agile in name only—and something needed to change. We never officially “decided” as a team that the workflow needed to change. No one said we needed to choose Agile. Instead, our workflow overhaul began as an organic experiment.
And, in retrospect, that’s why it worked.
Overhauling Our Process
Our first step in solving the problem involved getting everyone on board with change. This process felt surprisingly liberating. Our team growth had fundamentally changed everything, and what had always worked—at least for the first 18 months of Arc—would not continue to work in the future. Once everyone recognized this as an obstacle, we empowered them to fix it.
Getting everyone, newcomers and veterans alike, bought into this belief was key, because we did not want our changes to come as a top-down mandate from management. Top-down changes typically foster negative sentiments amongst employees, making them less likely to adopt and take ownership of the methods. This, in turn, makes most top-down directives harder to roll out, scale and ultimately succeed.
After all, Agile—or any major workflow change—only works if the team wants it to. Our workflow experiment could have failed if it weren’t actually better for our developers, but especially so if they didn’t buy into it first. So we didn’t just get them to buy in; they actually suggested the switch to Agile.
Even these suggestions began organically, shared between meetings or over Slack. The first suggestion that bubbled to the surface? Surprisingly, people asked for more code reviews. We decided to take this to heart enforce higher code quality standards by implementing mandatory code reviews for all of our work. Before a ticket could be considered “done” or even reviewed by a client, the code would need to go through at least one round of review.
These code reviews kicked off a remarkable side effect beyond code quality: a desire for greater transparency across projects. In our comfy siloes, it was easy to forget about other projects—or even other people on the same project—entirely; with ongoing reviews, however, developers saw the need for better, more effective communication throughout the entire process.
As a result, we re-imagined our concept of “teams.” Our functional siloes were the first to go. Instead of keeping the front- and back-end teams split, we reassigned ourselves into cross-functional pods based on projects. At the same time, we established a recurring set of ceremonies—including sprint planning, estimations, demos, and retrospectives, and happy hour (this last item is not “true Agile” but we think it is still very important). Now, all of the developers on a particular project—both front- and back-end—would actually meet, talk, and start to understand how their tickets and roles interact.
On our one-week sprint cycles, however, establishing these ceremonies would have been taxing on everyone. One goal was to have more meeting-free time, not less, so we also switched to two-week sprints. In this model, we begin sprints on a Wednesday and commit to the work we want to complete in the sprint. The rest of the ceremonies are split across two, full work weeks. We check-in throughout the sprint to touch base on progress and blockers, which helps surface issues before the “panic zone” at the end of the sprint.
We certainly expected two-week sprints—accompanied by the introduction of more recurring ceremonies and, therefore, accountability—to be a point of contention. However, we were pleasantly surprised to discover that many developers are happy to attend ceremonies if the meetings are relevant to one’s project and capped at 30 minutes.
Even amidst some initial bumps in the rollout, the team saw real improvements within only a few sprints. Even with smaller groups of developers per sprint, we increased both the number of tickets completed and the percentage of tickets completed in a given period.
For example, one pod of 5 developers completed 48 issues and only left 4 issues incomplete over a period of two weeks. We considered that pretty impressive compared to our pre-Agile benchmark, in which 8 developers completed 24 issues in a week—but also left 73 incomplete issues in the sprint. (Yes, 73)
The numbers are important, but what’s most exciting is that we solved a very real problem without losing momentum on any of our projects—and without a scrum master or any other particular Agile expert. Our workflow experiment is not an Agile success story, but a team success story. We’re figuring it out as we go, adapting Agile to fit Arc, not the other way around.