How I ditched sprints (and regretted it)

A story from experience:

Many years ago, I was leading tech efforts in one international organization. We were using Scrum and 2-week iterations. Everything went well, we were conquering the market, and our customers were happy with our 2-week delivery cycle.

It was 2010 – a year a fantastic book about Continuous Delivery was published:

Even today, it’s still one of my favorite books. I was very excited about the continuous delivery idea and the doors it can open. Thanks to the practices described in the book, I envisioned the future with no sprints, no planning, and no promises. I just wanted to focus on the flow and deliver things as soon as they’re done, and respond to annoying and difficult “when it’s going to be done?” like John Carmark:

“It’s done when it’s done.”

I became a victim of Confirmation Bias: even though the book didn’t say a word about ditching sprints, because sprinting wasn’t easy and I didn’t see much value in it, that’s was the main message I took away from the book.

Working in iterations stopped making any sense to me. When talking to my colleagues engineers, sprinting didn’t make much sense to them either (Confirmation Bias?). I also strongly believed that switching from iterative to continuous delivery would make the business happy because they’ll get solutions in their hands sooner. I was telling myself and everybody a story that sprinting is old school, sprinting is a limiting factor in our company, and it’s something we need to fix asap, because “every business needs it”.

Like a crusader, I saw it as a battle to the death for souls that if not saved will be forever lost.

So, backed by my enthusiasm and powerpoint, armed by a cooked-up support of Jez Humble and Dave Farley, whom I deeply admire, I sold the solution (to a non-existing problem) to the business. Then I started switching teams, one by one, from sprints to kanban-ish workflow.

And it worked as expected. Sprints and Scrum with all its iterations, ceremonies, and plannings, and promises, and retros, have been replaced with… Nothing. At the beginning it was refreshing and fun. It’s like that feeling of total freedom when you stop living with parents for the first time :-) But over time, the negative side-effects a young engineering manager could not anticipate, began to pop up:

1️⃣ Spontaneous and uncoordinated “continuous deliveries”

We started demo-ing new things to the business (sponsors) more often – many times a week, sometimes daily. We were delivering things sooner, but also unpredictably and spontaneously:

Nobody knew when the delivery team would come. We came unexpectedly and we came from nowhere, bringing new functionality, changes, and a cool demo with us. And because changes often affected people with different levels of seniority working in different departments, unpredictability had a ripple effect on the whole org.

A bi-weekly sprint demo was a highly anticipated ceremony: all affected and interested parties knew what to expect, when, and were able to prepare for it. Together with sprints, sprint demos were gone. Instead, we’ve got hundreds of spontaneous and uncoordinated “continuous deliveries”, causing stress, anxiety, and company-wide interruptions and context-switching.

💡 As a result, we started receiving even more questions like “when something is going to be done?”. Not like we want you to move faster… We just want to know when in order to prepare better. Ideally, at least a week in advance. Like with these sprints we had before.

2️⃣ A death by a thousand plannings

As we ditched the sprint backlog, bi-weekly sprint planning was also gone. Instead of asking business to set priorities bi-weekly, on dates known in advance, and letting them prepare and plan their schedule, we were asking what they want every day. At random times.

At first it was fun, but the mood quickly turned into annoyance. Nobody knew when engineers would come for talks. When engineers came, some relevant people were not available. That also had a negative effect on the team’s morale and caused waiting. Sometimes we had to reschedule the planning many times in a row.

Now we had more meetings than before. My colleague rightfully called it a slow death by a thousand plannings. And asked to return bi-weekly planning ¯\_(ツ)_/¯.

3️⃣ Customers satisfaction declined

Since we eliminated sprint planning and sprints, the level of trust and satisfaction with the delivery team began to decline (I was measuring it with NPS).

With Scrum, everything we planned in the sprint, the customers received in two weeks. We treated sprints seriously – as a commitment, a promise, and were successfully delivering on that promise, and were proud of that. That’s how we earned trust and respect.

Replacing a predictable iterative delivery with continuous delivery was perceived as a negative change: the customers saw the teams as less reliable, unable to plan, avoiding commitment, and also slower. Moreover, it was thought that the team is doing less than in the good old times of predictability and sprint demos full of new features and improvements. 📉

Summary

Even though the switch from iterative to continuous delivery sounded like a good and logical move, the business didn’t like it. We were doing extremely well with 2-week sprints, and switching to a fully continuous mode made things worse. That also wasn’t the best use of my time. Moving in iterations, while occasionally delivering value continuously during the sprint, would be a better and safer move.

What I thought customers wanted is not what they actually needed. Combined with successful sprinting experience (and cognitive biases like Certainty Effect that favors predictability), my customers asked to bring back the sprints. So I did. And the satisfaction level began to recover. 📈

Take-aways?

• There is no single best process that works equally well for all organizations.
• Predictability and fixed delivery cadence can trump speed. Sooner != Better.
• Predictability builds trust. To build trust, be predictable.
• Cognitive biases play a key role in how our work is perceived. Know it. Use it.
• Your assumptions what business wants can be flawed. Don’t assume. Verify.

Hope you learned something.