What Can Testers Learn From the Vasa Incident?

What on Earth does a 17th-century Swedish warship ‘The Vasa’ have to do with agile software project management?

For those of you who aren’t familiar with this classic case study of project management gone wrong, repeated in business schools around the world, here’s some background about the Vasa.

The Vasa Incident

The Vasa was a huge project commissioned by King Gustavus Adolphus of Sweden (1611-1632) between 1626 and 1628 as a way to bolster the might of the Royal Swedish Navy, back when the Swedish Empire was a leading military power in Europe and engaged in frequent battles against its neighbouring countries.

The King poured enormous amounts of money and man-hours into constructing one of the largest, most expensive military project ever undertaken till that point in time in history.

The Vasa would be 135 feet in length and carry 64 guns arranged over two gun-decks.

Or so were the requirements that the royal Product Owner specified at the end of an ever-changing list of decrees. In fact, the expected outcomes for the Vasa project kept changing constantly and this was one of the factors that ultimately contributed to its untimely end.

When it was time to launch the Vasa on its maiden voyage on 10 August 1628, the ship sailed for no longer than a few minutes, less than a mile from the coast, when a sudden gust of wind caused the ship to capsize and sink, taking down with it 50 of the 100 sailors who were on board.

The Vasa was eventually salvaged and it is now housed in its own dedicated museum. The salinity of the waters it sank into kept it surprisingly well-preserved, and the battleship today attracts hundreds of thousands of visitors each year who go to admire its tragic splendour and remind themselves of the potentially catastrophic consequences of flawed project management.

The ship in the main hall of the Vasa Museum.

Fast-forward to today: Vasa and agile software projects

Building a ship is an ambitious endeavour today as it was centuries ago during the time the Vasa was being constructed. Therefore, there are many parallels that can be drawn between the Vasa project and the software product you and your Scrum team are developing right now.

In fact, the Vasa syndrome is a term used in management which is inspired by that disastrous event and describes a collection of risk factors, including problems with goal-setting, team communication and handling unexpected changes in plans, which could spell doom for any project.

To make sure you avoid repeating the errors that contributed to the Vasa fiasco, I compiled a list of the top six software project management problems that this historic incident highlights.

6 problems in software projects that could be your ‘Vasa’

1. An impossible work schedule

Putting too much pressure on your Scrum team members is almost guaranteed to set your project up for disaster. Changing requirements and a lack of estimates based on data from previous projects are often the cause of an overburdened schedule that needs to be trimmed down pronto.

2. Requirements that change too rapidly

I mentioned it in the previous point and I’ll mention it again: making changes in mid-project is a sure recipe for something to go wrong. Things get even more complicated when it’s your people who seem to be going in and out through a revolving door, not just your requirements!

3. Lack of detailed planning

Software projects often grow from small activities that the team is familiar with and then gradually snowball into bigger and more complex affairs. In many cases keeping track of an expanding project requires you to use sophisticated tools to list your technical specifications, cross-reference documentation and draw up detailed project plans that can be instantly circulated among the stakeholders.

4. Going overboard with innovation

Pardon the nautical pun, but this is one of the problems that Scrum teams almost constantly run into: letting their ambition take over practical considerations. Software projects always include some degree of innovation, however adding new features just to satisfy some creative impulse without regard for user experience and the company’s bottom line is a temptation that must be resisted at all costs.

5. Pumping too many requirements in a project

‘Requirements creep’ is a common symptom of projects destined to failure. This can happen both when old requirements are not updated periodically or when new ones are just included without looking at the bigger picture. A complication of this is when a project becomes so big that it’s almost impossible to dig through the layers of unnecessary code to fix any bugs lurking deep inside without incurring tremendous costs.

6. Ignoring obvious problems

One of the most shocking revelations about the Vasa is that the ship had failed its ‘acceptance’ test, which consisted of a group of sailors running along the deck to see how the ship would hold up to stability. The Vasa lurched horribly, so much that the test was suspended after a few tries, but this finding was never reported, probably to avoid displeasing the King. It behooves software engineers to speak out whenever they notice any problems that could detract from the users’ experience.

The Wrap-up: Saving your software project from disaster

The Vasa was a complex project that involved plenty of risk and pushed to the limit of the skills and knowledge that the people who worked on it had.

Human fallibility is a risk factor that can never be completely eradicated from a project, however the struggles your Scrum team experiences when working on software products are the same that any group of people face when getting together to work on a common goal.

Learning from past experiences that parallel your own is a great method to control these problem areas more effectively and keep your project afloat.