Let’s pretend we’re starting a car company. If we want to build a luxury model, that’s going to be reflected in our workflow. We’ll focus on hand-made components and meticulous finishes. We’d be fine with building a single high-quality vehicle per week.

If we choose to design a budget model, that workflow will be vastly different. We’ll focus on cutting costs, cheaper materials and high sales volumes. The more cars we can produce, the better.

Both are valid business models, but the build strategy is a crucial choice.

A build strategy is optimized for one thing over others.

When building software, choosing the right build strategy is equally important. Yet we don’t give it as much thought. What are we optimizing for?

Since the early 2000s, the entire industry has defaulted to Agile Software Development. With its inspect-and-adapt feedback loop, it’s quick to gather user feedback and adapt the scope of the product in the desired direction. It’s a build strategy optimized for discovery.

But that’s not the only thing we can optimize for, right?

A lot of companies want their build strategy to be optimized for control. They don’t need to discover. They know what they want and need to be able to predict cost and timing. Agile Software Development is a lousy build strategy for that. A waterfall-style approach would be better suited.

If we don’t optimize our build strategy, we’ll end up with the worst-of-both-worlds. When we want our car to be luxurious AND cheap, we’re out of business before we started. If we want a controlled project plan, but optimize to be able to change the scope every week, we’re in trouble.

Yet we see loads of companies doing Scrum with a full backlog that is all Must-Have. They’ll present work-in-progress demos to people who only care about the end result. We’ll have endless discussions on how many hours a Story Point represents and frustrating attempts to plan a few sprints ahead.

On the other hand, we see fixed-price projects that try to figure out the scope as they go along. They get crushed under the weight of change requests and expensive redesign. They are optimized for delivery, yet don’t know exactly what they want to deliver.

So, ask yourself this: is this the right build strategy? What are we optimizing for?

Is it discovery? Speed of delivery? Predictability?

Your workflow should be vastly different. One size fits none.