Many of us in the tech industry have experienced the dread of working in environments with prolonged development cycles reminiscent of the archaic waterfall processes. The instinctual reaction is to swing the pendulum to the other extreme, advocating for the release of software as early and as frequently as possible. While this approach has its merits, there’s a growing trend of pushing the envelope too far, focusing on the duration of the iterations rather than their true purpose.

Bad Naming

The term “iterations” itself is a misnomer in this context. What we’re genuinely seeking are effective feedback cycles. Merely shortening an iteration from three weeks to one or transitioning to a Kanban system doesn’t inherently improve outcomes. In fact, there are several pitfalls to this approach.

First, as iterations become increasingly tighter, a disproportionate amount of time is spent on planning and management. The overhead of managing these rapid cycles can detract from actual productive work. Second, the pressure to deliver within these condensed timelines often leads teams to make compromises, selecting tasks that are feasible within the timeframe—though not very useful—rather than those most valuable to users. Alternatively, commitments made for short iterations are frequently deferred from one iteration to the next, leading to a cycle of constant postponement.

Furthermore, these iterations fail to serve their primary function as feedback cycles. Unless you’re operating at the scale of a company like Meta, which can garner immediate feedback from millions of users, your organization likely needs more time to gather and analyze feedback effectively. The result is a nervous cycle of activity that resembles treading water—busy but not necessarily productive or insightful.

Shorter Feedback Cycles, Not Iterations

The solution is not to focus on shortening iterations but to refine feedback cycles. A common pitfall occurs when teams become so proficient at rapid iterations that they outpace the product team’s ability to review and integrate feedback. This leads to a cycle of “feeding the beast,” where tasks are stacked simply to keep engineers busy. This counterproductive approach overlooks the importance of incorporating feedback and learning from each cycle.

It’s essential to identify a rhythm that aligns with your specific circumstances. Don’t abuse this if, say, you don’t have any users: You can’t shrug and say you’ll ship when the company closes a client. However, ensuring each cycle provides valuable feedback and learning opportunities is key. Embrace some downtime to have innovation weeks/intermissions or focus on different areas intermittently. This approach is akin to the Shape Up framework, where sufficient time is allocated for meaningful work, allowing the product team to develop significant “bets” rather than just churning out feature specifications.

In conclusion, while the urge to accelerate development cycles is understandable, it’s crucial to recognize that the value lies not in the speed but in the effectiveness of the feedback and learning obtained.