The Day We Stopped Sprinting

Ten years ago, in early October of 2007, my colleagues and I at Industrial Logic stopped working in sprints. We'd been using sprints (called iterations in Extreme Programming) since the late 1990s, carefully measuring how many story points we'd completed and aiming for a consistent velocity. It was starting to feel stale. We wondered how we could improve and be more agile?

That Summer we tried abandoning story point estimates and simply estimating using hours. After a few months of doing that, the team decided they didn't like it. We felt good for having experimented and started to think about our next experiment.

Later that Summer, at the Agile 2007 conference in Washington, DC, we heard David J Andersen talk in the open space about something new that he called kanban. It was refreshing to hear of someone who had escaped the timebox and was getting good results.

In early October, my colleagues and I began our next experiment: working without sprints. We decided to pick something important, work on it, ship it and repeat. We still did some rough time-based estimates ("that work will take around 2 days" or "that work will take around 2 weeks, so how can we make it smaller?") and regularly practiced what I call bargain hunting.

Our new approach felt more natural and we became more responsive to our customer's needs. We spent less time trying to predict how much work we could get done in a rigid time box, and instead allowed ourselves to work on items that ranged from a few hours to a few days.

The new cadence required us to talk more regularly about what was most important to do. This led to short, focused huddles in which we continually challenged ourselves to identify what was most critical. And that led to constantly thinking about what would make our customers happier and more successful or what we needed to improve internally (e.g. paying down some technical debt).

We would huddle immediately after completing the top priority - so our huddles happened whenever we were ready to discuss the next priority. We'd huddle after completing a half-day piece of work, a 1-day piece of work, 2-days, 2.5 days - whenever we completed something, we'd start our next huddle. While we did have some rough idea of what work we wanted to do in the future, we always used the huddle to discuss and reflect on what was truly most important to do at that given time.

Shifting away from sprints made us faster, more reflective and more adaptable to change. At the Agile 2008 conference in Toronto, I shared our team's experiences in a Breaking Acts session I provocatively called Estimation Considered Wasteful: Introducing MicroReleaeses. Within a few years, we'd make the leap to continuous deployment: releasing to production many times per day.

But You're Experts!

So this approach is only good for experts, right? I mean, we had all those years of sprinting before we dropped sprints. I get this a lot because I run a company filled with experts in agile.

The answer is no, this is not for experts. In fact, I'd say that for beginners, it's harder to succeed with sprints than it is without them. We get better results faster when we help new agile teams begin with a flow-based approach rather than sprints.

The secret to succeeding with a sprint-less cadence is to master evolutionary design. If you don't know how or why to produce a walking skeleton of your feature or system, you'll struggle with the modern agile principle, Deliver Value Continuously.

For many organizations, a sprint seems like a necessary guard rail, since they have multiple teams all trying to coordinate work together. This shifts the focus away from evolutionary design towards time-based commitments ("get you work done in the time box!"). Completing work in a time box isn't the same as producing working software. Evolutionary design asks you and your collaborators to evolve something (initially primitive) that works, instead of focusing just on completing individual or team tasks by some date, without bothering to integrate that work into working software.

When you practice evolutionary design, either within a team or across many, you get working software up and running quickly. This solves lots of collaboration and integration problems. It asks you to identify the smallest piece of work that will lead to a primitive but working version of your ultimate end results. Will that take a few days or a week to do? You seek the shortest time possible and work with all of the people involved to get something up and working.

Evolutionary design takes the place of sprints and work happens in a flow-based approach, always focusing on small, valuable work that helps you minimize risks, deliver value and measure if you've actually moved any needle. Beginners need training in evolutionary design, for it is a skill that doesn't come naturally.

So that's how we dropped sprints ten years ago. Today, I reflect back and come away with three thoughts:

• Had we not been committed to experimenting continuously (in order to find better, faster ways of working), we might still be sprinting today.
• It was a joy to discover that something we once thought was vital to agility (sprints) was actually not vital at all.
• We became faster, more responsive and adaptable as a result of dropping sprints.

I hope you too embrace change by constantly experimenting and discovering better ways of getting awesome results.