Why do we build in sprints?

A fundamental truth: not all problems are created equal.

If we think about our day-to-day lives, we’re sometimes successful in juggling multiple demands, decisions, and responses. But, all too often, the competition for our attention means that we’re dealing with lots of different problems simultaneously. And, as the circumstances around us change, the situations become increasingly complex. And, to make it worse, we even lose sight of the problem we’re looking to solve!

When we start to tackle the development of a product, the same is true. We make assumptions about business model, client expectations, or the human experience. These factors may (or may not!) even show up and be resolved before we start to deal with the inherent complexity of technology, integrations, or regulatory dependencies.

However you look at it, product and technology development is both complicated and complex. This has to do with the fact that there are so many things we just don’t know — yet.

Estyn Edwards says something that I repeat time and time again: “Why would I make all the decisions today when I have the least amount of information?” Now, this doesn’t mean that we avoid making decisions. In fact, it’s exactly the opposite! By using the constraint of time and budget to align with the value of solving the problem, we can make the best, most adaptive decisions today, that support the growth of our team, our company, or our product.

Addressing known-knowns

In 2002, Donald Rumsfeld, the US Secretary of State, stated at a Defense Department briefing, “There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — there are things we do not know we don’t know.”¹

I think about known-knowns as obvious problems. Addressing these type of problems, we typically have the ability to apply best practices to solve a well-understood problem. In many organizations, we may see standard operating procedures, and as management thinker Thomas A. Stewart has said, “Here, decision-making lies squarely in the realm of reason: find a proper rule, and apply it.”

In software development, this is defined scope, where assumptions have been validated and are now facts. The key here is that there is a certain amount of cognitive bias associated with known-knowns: we think we know more than we actually know. (“From my perspective, that seems easy, so it must be simple or easy to do.”) When developing digital products, we need to spend real time challenging our biases to remove the real risk with obvious problems.

Celebrating the unknown and value creation

When it comes to unknowns, this is really where value is being created in digital and product development. When we think about the startup ecosystem, it’s because there is risk that we are able to create value. One of the reasons that we include product strategy and user experience talent in our sprint teams is to expose that value!

That being said, if we spend the time to understand and eliminate every single risk, we would never get to development. That’s where the magic of our sprint process comes into play. There are two factors that make sprints work:

1. For known-unknowns (eg. complicated problems), we leverage the value of the team’s expertise. A single person can’t know everything, but a cohort of team members bring expertise and perspective  to understand and solve.
2. For unknown-unknowns (eg. complex problems), we leverage the value of experimentation and constraint. By fixing our time and budget, we allow scope to be fluid, to respect the fact that we have to adapt to what we learn. The more we test and iterate, the more we learn — and the easier it becomes to develop a great product.

Sprints help you find a place to start.

Big, complicated problems (and products!) can be overwhelming. It can be difficult to understand where to begin. By defining a sprint team, a series of constraints, and the outcome desired, you can shorten the pathway to solving the problem.

Recently, we worked with a client to develop a minimum viable product; the focus of a single sprint allowed us to focus on building and validating core features, and a series of sprints enabled us to get to market quickly.

Sprints help us move from ‘planning’ to ‘doing’.

While we start most of our product engagements with a discovery sprint, our goal is always to move from strategic planning into development as quickly as possible. By implementing real technology quickly, we can understand if we’re making the right decisions, and we can better set up those decisions for the future.

Sprints keep you focused on what matters the most.

A major key to a successful sprint is the act of resetting our expectations at the beginning of the sprint. Every sprint starts with the opportunity to define a new outcome, and re-define the problem we’re currently solving. If we don’t spend the time re-aligning the team, we’re likely going to waste time and money, and focus on the wrong things!

Sprints optimize our decision-making.

Within a sprint, the fact that we have a constraint on our time and budget gives us the power to be ruthless with our decision-making. We just don’t have the luxury of putting effort into the things that aren’t critical to the outcome, and a team with clear direction always produces better results.

There’s a knock-on effect, too, with a series of sprints: by consistently evaluating outcomes, on a sprint-by-sprint basis, teams develop momentum, and momentum turns into speed.

It is absolutely worth solving both complex and complicated problems; that’s how we create new and untapped value. By using sprints, we can solve those problems faster, with less resources, and with a higher degree of success.

You might also like