Why Tech Debt Sprints Failed At Quizlet
Every startup starts by finding product market fit. To do this, you build as quickly as possible and take shortcuts when needed. However, once you find that product market fit, it’s important to start resolving those shortcuts (aka tech debt) in order to invest in your future velocity. Quizlet has achieved product market fit and is rapidly growing. Our engineering team is expanding fast, so we need to maintain our ability to execute quickly while keeping our bar high on quality.
At the point when you realize you’ve diminished your ability to move quickly, it’s often a huge investment to resolve. To consistently pay down our tech debt, Quizlet established company wide tech debt sprints. For two weeks every quarter, all engineers would focus on tech debt projects organized by their functional teams (Web / iOS / Android). For a time, this worked well. Engineers valued the time they got to decide how they would improve their everyday developer environment.
Over the course of the last year, we grew quickly from three to eight cross functional, mission-driven teams. Coordinating tech debt sprints around deadlines and delivery of important features became increasingly difficult. To alleviate this pressure, we tweaked our plan to allow every team to decide for themselves when they would schedule their tech debt sprint.
In line with our principle of empowerment in the engineering team, this gave teams autonomy to schedule as they saw fit. But these dedicated sprints had an unexpected consequence. Instead of addressing tech debt as a discipline when working with code that should be refactored, it was being put off to be addressed in this dedicated time.
Also, since teams were scheduling tech debt sprints at the time best suited to their roadmap, it was much harder to get momentum on debt issues of larger scope. This resulted in a significant and important category of work being left untouched.
With issues mounting, we asked ourselves the questions:
- Could it be that we were actually addressing less tech debt as a result of having dedicated tech debt sprints?
- What would happen if we didn’t have dedicated tech debt sprints, and instead simply held teams accountable for addressing tech debt as needed, at the best time?
- How would our teams invest and ensure they were able to move quickly and efficiently to deliver a high quality product?
We made the realization that tech debt sprints are a crutch that makes work easy to plan, but constrains our ability to address it outside of those times.
Tech debt sprints are a crutch that makes work easy to plan, but constrains our ability to address it outside of those times
So in April, we removed our planning constraints and set the expectation that teams should use good judgment, address debt issues at the right time, and take into account the context of urgency, efficiency, and technology stewardship to make great decisions. To keep teams accountable, they each committed to technical investment OKRs to define the success of their commitment which are reviewed and approved by the leadership team.
The astute reader may wonder how we know teams are succeeding in this new framework. Great question. We look to the teams themselves. Inspired by Spotify’s “health check” model, after every sprint, teams reflect on their work and environment and vote on several factors, including quality and tech debt. This feedback mechanism helps raise the priority of maintenance work when needed.
While initial results are positive, the long-term impact is yet to be seen. As teams experiment with different approaches to work toward those goals, we hope to end up with an efficient solution to this ongoing problem that scales well as our teams continue to multiply. If you’ve found an approach that works for you, we’d love to hear about it in the comments below!
