The 400-Year-Old Lesson in product development
The other day someone tried to convince me that the regal ship Vasa was built with an agile approach.
I don’t know Swedish history too well, and I’m not really an expert in 17th-century marine craftsmanship. But I know a thing or two about agile. And my gut feeling on the topic before further investigation or research was something like: Spending years building a crazy expensive flagship so lousy that it sank within 15 minutes of its maiden voyage can hardly be considered anywhere near the same galaxy as agile. But my lack of history and... boat knowledge made me struggle with downplaying my arguments.
I have now listened to two-thirds of an audiobook about the Vasa ship, read a decent part of the Wikipedia page, and realized that I probably should pay the Vasa Museum a visit. So, I’m still no expert on the subject, but I can now, based on my research, confirm that the process of building the Vasa was pretty far from agile. In fact, the project method was so anti-agile that it stands as a perfect example of what we are trying our best to avoid by working agile. It’s such a great example that we should use it as a story when teaching agile. We should use this tale as words of wisdom when explaining design-driven product development to business stakeholders. It's a tale we should always keep in mind and heart, tell our juniors, put in our agile way of working sales pitch decks, tattoo on our forearms, and so on, to never forget: Why agile?
Here’s the tale.
Once upon a time, there was a king, Gustaf II Adolf, who was crowned at the age of sixteen and had since then spent most of his days fighting wars against pretty much every nation you can think of. If Gustaf II Adolf had his war stats written like a UFC fighter, it would look something like: W 30 - L 5 - D 2. He had turned Sweden into a great power, now knocking on the door of controlling Europe. In other words, not your average grumpy-high-maintenance-kind-of-stakeholder. This was a badass who knew just what he needed to win this ongoing war against his cousin Sigismund, king of Poland, who also considered himself to be rightfully entitled to the Swedish throne (yeah, it all sounds a lot like a certain HBO series). Gustaf II Adolf needed a battleship like no other, the kind of ship that makes the enemy quake in their boots before they resign, jump in the water, and swim home.
Henrik Hybertsson and his brother Arendt were just celebrating winning the noble and lucrative business contract of building this ship and a couple of other almost as expensive ships when they received the following requirement spec from Gustaf II Adolf:
Must have 64 guns, both long and short cannons
Must have two gun decks
Must be <220ft long
Must have a stern castle (it’s sort of this high balcony part at the end of the ship where Captain Hook hangs out)
Non-functional: Needs to showcase how awesome I am as a king and that God is with me on this journey of taking over the world.
400 years later, this set of requirements might sound like an average ship order detail spec from the past to your ears. But back then, it was seen as:
Henrik Hybertsson, who was highly regarded and reputable in the business of crafting warships, had already led projects building several well-served ships for the Swedish navy. He had some deserved confidence at the time and answered the king something like: "Dear King of Sweden, your spec is beyond the reason of what is possible to build." He tweaked the spec into something he, with all his knowledge and experience, thought would make a great ship and a happy customer but within the physical limits of what was considered possible to build at the time.
The king responded: "You will build the ship my way."
And with respect to the king, he answered, like every consulting firm afraid to lose a well-paying client would: "Let’s do it your way then."
At the time, public procurement was not really invented, but the contract they signed actually serves as a great example of how wrong this type of negotiation can go. Knowledge is foresight, and the explicit requirement list is what’s on the table to deliver on. The best price wins the deal, regardless of it being possible or not to deliver on, without room for expert advice. It’s funny we still put this method into practice in Sweden 400 years after we tried it for the first time, despite the memorable outcome. If you’re not familiar with Swedish public procurement, it usually ends up with very expensive hospitals or useless journal systems for 5,5 billion SEK or so. Or like in this case - a warship at the bottom of the sea.
At the time, ships had no blueprints—you sort of built them based on your experience and refined them by making small incremental changes upon the last ship you built. And yes, you heard "incremental," so this is where the argument of Vasa being built with an agile approach is born. It’s not a rock-solid argument, and I’ll come back to why. One problem with the design/requirement spec of Vasa was the combination of two decks of cannons plus the stern castle. This combination had never been done by Hybertsson before, and this was what he initially advised against.
The 300 craftsmen who worked on building this ship for two years without getting properly paid all realized along the way that this design would make a pretty wobbly warship. Gustaf II Adolf did not exactly have an HR department in place yet, and the union wasn’t invented until 200 years later, so if you wanted to keep your job and also your head attached to your body, you kept your mouth shut about questioning the stability of the ship.
You can probably imagine how toxic this chain of leadership was when no one dared to report their really valid concerns to upper management.
Hybertsson's stakeholder management skills may go down in history as poor. Or let’s call it a textbook example of what poor stakeholder management can lead to. But he was also sick and passed away during this project, and he took his game plan of how Vasa should be tested and refined during the process—and his experience and gut feeling—with him to his last resting place. So the new project manager finished Vasa by creating the missing pieces of the puzzle with his best guess of what he thought Hybertsson had in mind. Stressed out with letters from the King, who was writing to know: "IS IT DONE YET?!"
Turns out, a blueprint or some documentation might have come in handy after all. The ship’s ballast (heavy stones put in the hull of the ship to improve its stability) was already built into the ship, and it was way too small to make up for the 64 guns so high up on the ship to make it stable. The ship was unstable as a flagpole with cannons on top. And everyone knew. Even if it was possible to load more ballast onto Vasa, it would have made the lower cannon windows take in water as the ship was already very heavy—so the ship was badly engineered from the start and impossible to improve.
On the 10th of August 1638, Vasa was fully loaded and ready to conquer Poland. The captain of the ship commanded a stability test right before departure and had 30 men run back and forth across the deck from port to starboard. The test had to be aborted after just three runs, as Vasa was about to capsize at the harbor due to this test. "Phew! Thank God we called that off in time!" he said and later the same day sailed the ship right to the bottom of Mälaren, where it stayed for 333 years. The captain said in hearings that he wished the King had been there to see how unstable Vasa was during this test. What a test lead.
Imagine your product team doing a stress test of your latest feature in stage, aborting the test as the servers were about to catch fire—but you still push to production saying, "I wish the CEO could have seen how unstable this feature was before we released it." It’s not a valid excuse, captain.
To sum up the process with some key highlights:
Unrealistic requirements - expert advice foreseen
Poor stakeholder management
Poor documentation
No handover when changing project manager
Massive budget failure
No room for proper testing - due to pressure on delivery in time
Toxic leadership
Ship the entire product at once
It’s not exactly the ground rules of the agile manifesto we are looking at, but even if we for a moment try our best to see the Vasa ship as an incremental change or experiment in a very long product cycle being the Swedish fleet, it’s still everything we try to avoid with experiment-driven development as well. In a digital product comparison, it would be like building the entire product in production right away, making sure to spend the last nickels of your budget to paint the product in actual gold before the release, inviting the entire city to take part in the release ceremony, ignoring the failed stress test right before release, and hoping no one dies.
That’s it. That’s the tale. So:
Whenever someone tries to push for unrealistic requirements without carefully considering expert advice, you tell them about Vasa.
The next time you find yourself arguing with someone who tries to push deadlines down your roadmap, ask them if they have heard the tale of Vasa.
Next time you find yourself explaining agile when marketing is asking for a release date on your next feature so that they can plan for a huge campaign, you tell this story.
So, to make use of this epic failure: Whenever you start up a new project, product, or business, or whenever you see the need, take your stakeholders and partners to the Vasa Museum for a kickoff and tell them the tale of Vasa. Let’s come together, unite, and agree that we never build the Vasa ship again—in any form. Can we all please agree on this now?
And if you still consider the Vasa ship to be built with an agile approach, let’s not build a boat together.
Ahoj,
Gunnar
Always be shipping is a newsletter on product development that is shipped on a not so regular basis - feel free to subscribe.