Summary

The article advocates for embracing uncertainty and learning through empirical process control by tackling difficult work in Sprints, even when information is limited, to gain valuable insights and deliver meaningful outcomes.

Abstract

The author, a new Product Owner in a Scrum Team, discusses the benefits of engaging with challenging projects in the face of high uncertainty, particularly in the unfamiliar domain of finance. Instead of relying on extensive upfront research and technical design, the team focused on addressing the most pressing stakeholder pain point by setting a smaller, achievable Sprint Goal. This approach allowed the team to learn through actual work rather than theoretical planning, leading to a successful Sprint and the discovery of unforeseen hurdles. The author emphasizes that failure in such Sprints is acceptable and valuable, as it provides crucial knowledge for future success. The article also stresses the importance of creating a safe environment for teams to encourage them to tackle tough problems without fear of repercussions.

Opinions

Empirical process control is more effective than predictive process control when dealing with hard problems with little information.
Starting difficult work with uncertainty can lead to more learning and valuable insights than spending time on upfront research and design.
It's important to break down large problems into smaller, achievable goals for Sprints to manage uncertainty and focus on delivering value.
The team should feel safe to fail, as failure in Sprints is a means to learn about obstacles and is preferable to creating theoretical documentation that may not reflect real-world challenges.
Celebrating learning from failure is crucial for team morale and encourages courage to work on complex issues.
A successful Sprint is not only about delivering the goal but also about gaining knowledge that will benefit future work.
Reducing the risk of future Sprints by understanding current obstacles is more valuable than a slight reduction in short-term value delivery.
Theoretical obstacles are less important than practical ones encountered during the actual work, which can lead to unexpected discoveries.
Encouraging teams to start Sprints without full clarity, but with the confidence to figure things out, can lead to significant progress and learning.

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.

Do you want to share an article in Serious Scrum? Connect with us and make it happen!