SpaceX flies. Boeing struggles. What this has to do with your choice of methodology.

What happened

SpaceX pursues an approach that relies heavily on early testing and rapid learning. The first Falcon rockets fail spectacularly. The company comes close to collapse in 2008. Yet with every setback, lessons are learned and carried forward into the next iteration.

In 2020, Crew Dragon brings astronauts to the ISS for the first time. Since then, the system has been flying regularly and has established itself as a reliable part of NASA's programme.

Boeing is also developing a new spacecraft system with Starliner. However, the first uncrewed test flight in 2019 does not go as planned: software issues prevent docking with the ISS. On the second test flight in 2022, Starliner reaches its destination, but technical anomalies occur once again.

In June 2024, the first astronauts finally launch to the ISS aboard Starliner. During the mission, helium leaks and thruster issues are investigated, among other problems. NASA and Boeing jointly decide to return the capsule uncrewed as a precaution. The astronauts later return to Earth aboard a SpaceX Crew Dragon.

When looking at cost, schedule, and operational track record to date, SpaceX was clearly more successful in this programme.

More than just a story about winners and losers

This story is not meant to disparage Boeing.

Boeing has been developing highly complex systems for decades in an industry where mistakes can have serious consequences. And of course, the differences between Boeing and SpaceX cannot be reduced to project methodologies alone. Corporate culture, organisation, technical decisions, and many other factors also play a role.

Nevertheless, the comparison raises an interesting question:

Does the chosen approach actually fit the nature of the problem?

Because developing an entirely new spacecraft system is different from optimising a familiar product. Many challenges are still unknown at the outset. Problems often only become visible when real-world testing takes place. Learning becomes part of the solution.

It is precisely in situations like these that an approach based on experimentation, feedback, and adaptation seems to be beneficial.

The pattern also shows up in organisations

Space travel may seem far removed from everyday life. Yet the underlying pattern is something I encounter regularly in projects.

Teams launch digitalisation initiatives and attempt to define all requirements months in advance — even though at that point no one yet knows exactly what the solution will look like in the end.

Other projects are managed with rigid milestones, even though requirements change constantly during implementation.

And sometimes the opposite happens: Scrum is used even though the requirements have long been clear and really only need to be reliably executed.

The problem is not the method itself.

The problem arises when the method and the situation do not match.

Because the crucial question is not:

Which method is better?

But rather:

Which method fits this situation?

It's not about always being agile

This is a point I emphasise time and again in training sessions and conversations:

Agile methods are not a cure-all. Scrum is not automatically better than a traditional project plan. And waterfall is not inherently outdated.

There are many situations in which a structured, plan-driven approach is exactly the right choice.

When requirements are stable, regulatory specifications are clearly defined, and the task is fundamentally well understood, then planning, specifications, and fixed processes can offer enormous advantages.

In other situations, however, insights only emerge during implementation. Then learning becomes more important than predictability.

The decisive factor is not whether an approach is “modern” or “traditional”.

The decisive factor is the fit between the problem and the method.

The next question

If the choice of approach is so important — how do you actually make that decision?

How do you recognise whether a situation calls more for planning or for experimentation?

And how do you know when Scrum makes sense — and when it doesn't?

That is exactly what the next article is about.

In it, I introduce the Cynefin Framework — a thinking tool that helps to categorise different situations and derive appropriate approaches from them.

And yes: SpaceX and Boeing will make another appearance.