In the bleary days of stay-at-home orders and endless Zoom calls, time, for many, began to lose meaning. For those of us working from home, our online hours provided structure to otherwise shapeless swaths of minutes and days. That is, until those hours online began to blend together too, and the days, weeks, and months fused into a single blur.
It happened to me. At work, daily stand-ups began to feel scripted, each sprint indistinguishable from the last. My team planned and shipped new features at a rapid clip, but the work began to feel never-ending. This constant, iterative development is a hallmark of the agile process, the standard for software development today—but if you’re anything like me, the past couple of years have left you wondering whether it’s actually useful. Maybe, in our emphasis on incremental development, we’ve overlooked an essential element: the space to slow down.
The agile approach
Books on agile software development tend to make use of an automotive analogy. If you want to build a car, they declare, start by building a skateboard. Sell that skateboard to customers, then build a scooter. Next, you’ll build a bike, then a motorcycle, and finally a car.
This approach emphasizes the power and potential in software built incrementally over time, providing value to the user at each interval. As teams progress through this process, they generate momentum. Each two- to three-week sprint involves shipping something new and moving toward the end goal, the ideal state. Throughout, the software becomes more complex, augmenting the size and scope of the product. Agile facilitates these shifts by emphasizing incremental changes and allocating time to address previously unrealized unknowns.
Like the name suggests, agile also emphasizes speed. The sprint cycle allows teams to react to feedback from users swiftly and adjust the product accordingly. It accounts for the ever-changing nature of our work and includes built-in meetings or ceremonies to facilitate constant feedback and reorientation. For startups, this process is practically a given, since it’s essential to stay nimble while scrambling to build software and find product-market fit.
But agile methods fail to fully account for software maturity. Not every company has projects or applications that are unstable and in their infancy. Even within high-growth companies, some systems are already mature and feature-complete. As software moves toward this mature state, continuously sprinting and adding features can start to feel like inconsequential busywork. Projects become less dynamic and impactful and more about finessing—think adding new buttons to an existing website rather than building the site’s entire frontend and backend. Because they’re no longer working on large parts of the application, teams can easily fall into an almost mindless cycle of adding small, less significant features. And that’s a recipe for burnout.
I’ve seen this happen on multiple teams I’ve belonged to. We released a fabulous feature but just couldn’t let it go, gilding the lily when we could have been working on more satisfying or meaningful projects. Here, the very characteristics that have made agile an effective process—rapid development, constant iteration, fast feedback loops—begin to lose their potency.
The power of milestones
In the pre-agile age, before 2001, teams mostly developed software using the waterfall method. Waterfall software development resembles the traditional manufacturing process, with discrete time periods for planning, designing, and building. It’s fallen out of favor among developers for many reasons, but perhaps most importantly, it isn’t nearly as reactive or nimble as agile, with releases potentially taking months to agile’s mere weeks. Investing that much time into launching a product without a proven business model can spell disaster for a startup, where survival depends on the ability to respond to changing market needs.
But one element of the outmoded waterfall method might help us break out of the sprint cycle, take a step back, and plan time to work on the more foundational and often neglected aspects of software, like tech debt: milestones.
In waterfall development, milestones are clear markers or deadlines that delineate space between when one task ends and another begins, typically in the form of handoff and kickoff meetings. Consider the car analogy from earlier: If the agile approach is to continue to add cupholders and tweak the dashboard display as the car rolls off the assembly line, a milestone, in contrast, involves bringing work to a stop, celebrating that the vehicle has left the factory, and figuring out what comes next. Introducing milestones into our agile processes offers a chance to acknowledge the progress we’ve made and cool down from the frenzied pace of successive sprints. It gives our teams time to reflect on what we’ve built and reorient ourselves toward the next phase of development.
Agile affords us opportunities to do this, at least in theory, in the form of retrospectives. Retros tend to occur at the end of a sprint, and they’re aimed at dissecting what happened, or didn’t happen, within that time frame. But in my experience, these meetings aren’t always treated as an essential part of the process. For instance, I’ve found they’re frequently rescheduled or canceled as the end of the sprint approaches and engineers rush to close any remaining tickets. As a result, many teams I’ve worked on have perceived them as procedural and unproductive, which dramatically diminished their utility as a space to deeply scrutinize our processes.
Milestones, in contrast, can offer an opportunity for more holistic reflection by occurring outside of the sprint cadence and focusing on the outcomes of multiple sprints. By introducing milestones at the end of every few sprints, or even once a quarter, teams can build in real, dedicated time for pausing and planning. These milestones can span a single day, or even be the length of an entire sprint. At The New York Times, for example, my team has a two-week cooldown period every six weeks. We use that time to gather our thoughts, address technical debt, and plan our next set of work.
The particulars of our approach might not make sense for your team; what matters is that you create breaks in development. Such pauses in the sprint cycle encourage reflection and realignment. They’re also a moment for teams to ask themselves, “Why are we doing this?” Where agile champions continuous experimentation and iteration, milestones advocate for letting work come to a finishing point. Together, they can produce a steady, sustainable rhythm.
The way forward
At a time when many are reflecting deeply on systems that once seemed foundational, we have an opportunity to rigorously rethink the way we work. What might more thoughtful and tailored approaches to building software look like?
By creating room for introspection and holistic consideration of products and processes, milestones can build much-needed space into the agile development cycle. Making pause a part of development allows teams to take a step back, replenish their energy reserves, and reevaluate their processes—ultimately enabling them to build better software. It might help relieve that feeling of days and weeks blurring into one another, too.