Developing software products is a long-term effort and requires ongoing adjustments. These marathons are usually composed of multiple iterations or sprints. However, these today in many companies are no longer enabling effective work. Instead, they are essentially waste, as teams end up in some hybrid process that makes little sense. If you’re on a quest to create an amazing team that delivers incredible results—especially in today’s climate of no-growth in tech—realigning the meaning of this cadence in your process is crucial. Without it, you are guaranteed to suffer from inadequate impact-per-engineer.

Words Don’t Mean Much

The root cause of many process issues I see across the industry is that teams follow rituals without understanding them. Sprints are a mere echo of what they were initially meant to be, which is why we see many processes that take up a lot of time yet produce little results. Let’s consider what sprints ended up looking like today.

Most teams I work with attempt to work in some agile-like methodology where development happens in iterations. They “plan” those sprints, estimate what will fit in them, and have retrospectives when they’re done. The central piece missing is that these sprints mean nothing. What happens when things drag on, and the engineers see they clearly won’t get everything that was planned done in time? Too many times, the answer is a resounding nothing. The sprint ends, we drag all old tickets to the following one, and the cycle repeats.

Therefore, what results is a hybrid process, where you pay all the overhead of managing iterations where work flows similarly to a Kanban process: things just continue on and on until they are done, regardless of any iterations. If your process looks like this and rarely has demonstrable results ready by their end, you’ve got a problem. Not only is your team wasting time “pandering” management by playing the “sprint planning” game, but it is also likely drifting away from business impact. You don’t have to continue with these vestigial sprints.

Return to Significance

These hollow sprints harm your team in multiple ways:

• When features routinely take more time than originally allocated/estimated, you are likely investing too much in them. Often, had product leadership known the actual cost of a feature, they would’ve cut its scope or skipped it entirely.
• Having no real deadline to feature development also hampers the agility that’s supposed to be part of agile. The intention was that the team would be able to review progress and realign routinely. That tends to happen a lot less when things are dragged on and on, and the dedicated time to reassess—sprint retrospectives and planning sessions—are disconnected from the actual development progress.
• Engineers lose any sense of urgency. When work is allowed to take endless amounts of time, nothing seems important. After all, our scarcest resource is our time, and if we waste it so willfully, what does matter?
  

The fix is straightforward, although not simple: sprints should mean something. Find a healthy cadence that allows the team to deliver meaningful progress. Are you on weeklong iterations? Perhaps two weeks will suit you better; give it a try. Set expectations with the team about the meaning of sprints and how it is crucial to allow everyone—including themselves—to drive towards value.

For example, even if it feels contrived or like overhead, splitting work into sprint-long milestones usually pays off instead of having a colossal project span months. First, the team should show steady progress every sprint. Second, this chunking of the work allows us to change course, put something on hold, or even drop it entirely if that’s the right move. This extra freedom is what agile means.

Don’t just sprint aimlessly. If you’d like more help with this transition, check out the Leading Edge Club—my global community for executives in tech.