Why you should have Sprints that fail

I recently started as Product Owner with a new Scrum Team. We were facing high amounts of uncertainty and stress. We started in a domain that was completely new to the whole team: Finance.

Expectations were high. We had to interact with unfamiliar systems without documentation. We had a lot of dependencies we were not even aware of.

In short: we had no clue what we needed to build and how.

In this situation the natural reaction is to plan spikes and do up-front technical design. To focus on research when you lack information to come up with a good approach. To design a solution that exhibits ‘overfitting’: something that works in theory, but not in reality.

I opted for a different approach. I believe you learn most by actually starting difficult work when you have little information. When facing hard problems where you lack information to solve them, empirical process control trumps predictive process control.

We were sitting in a room for our first Sprint Planning. The only thing that was clear: the biggest pain point of our stakeholders. I pitched their pain point to the Scrum Team and it was too big to pick up. I asked them: “How can we break it down in a smaller goal that is achievable in two weeks?”.

After some discussion we agreed on a smaller Sprint Goal. We then created the Sprint Backlog on the spot and started our Sprint. We did not even create the full Sprint Backlog. We knew we would do a better job if we created and adjusted the Sprint Backlog as more was learned during the Sprint. We probably created around two third of what was necessary to deliver the Sprint Goal.

The only thing that was really clear was the Sprint Goal, the rest we would be able figure out on the fly.

The team was a bit anxious to start the Sprint with so much uncertainty. I told them that failure was okay. Even if we would fail, we could find comfort in having worked on the most valuable thing. By working on the most valuable thing, we would gain so much more information and insights than wasting our Sprint doing spikes and technical designs upfront.

There were two options: either we would be able to deliver a small part of the most valuable thing or we would gain knowledge on what was necessary to be able to deliver the most valuable thing.

The Sprint was a big success. We delivered what was promised in the Sprint Goal. We learned a lot of valuable things we would not have figured out if we focused just on pondering what would be necessary. We also discovered important hurdles we would need to overcome to deliver future increments, which we would have not discovered by just doing research.

By working on hard problems, you will automatically have more Sprints that fail. And that’s okay. When the focus is on learning, failure is part of the journey to success. And in our case we got lucky: we had success and increased our learning.

If we had failed, we would have learned a lot about the obstacles we would need to overcome to make the next Sprint a success. This is very valuable information by itself. At the Sprint Review we would have been transparent about the challenges encountered and discuss together how we would tackle these in upcoming Sprints.

Make your team feel safe to have the courage to work on tough problems

How many times have you been in a situation where it is not possible to start working on something because there are too many things unclear? The whole team rejects working on that most valuable thing because there is too much uncertainty. The team lacks the courage to start working on it.

It is essential your team feels safe enough so they have the courage to work on hard problems. You need to provide them the experience of failing without repercussions and celebrate what was learned through failure as valuable discoveries.

In order to start a Sprint, it is not necessary that everything is clear. You just need to be reasonably confident you can figure it out during the Sprint. If you make your team feel safe enough to fail, you do not need the safety of doing a gazillion spikes and technical designs upfront. You just need to feel confident that you will figure it out as you go along.

Worst-case you will fail completely, but you will have a clear picture of all the obstacles that lie ahead. That risk reduction in both the short and long-term is worth a little bit reduction of value delivery on the short-term. Failing pays off more than creating false certainty in theoretical documentation.

You learn the most by actually starting the work instead of theorizing how you can prevent the obstacles that lie ahead. You will never be able to figure out all theoretical obstacles. Some theoretical obstacles will turn out to not be a problem. Other obstacles only appear when you do the work and realize you missed something.

By doing difficult work reality is revealed. You will be better able to figure out what really matters. And that’s what counts most in the end.