No, that’s not just a creative simile. It’s what happened to the Vasa, a 17th Century warship; the largest of its kind ever to be built. The ship was commissioned by King Gustavus Adolphus of Sweden and it sank on its maiden voyage not far from port. The sinking led to 50 of the 200 strong crew aboard drowning. The story survives in the 21st century as a classic case study retold in business schools around the world to impress upon students the consequences of faulty requirements management. We will discuss it here thinking about requirements in Agile.
What does Vasa have to do with Agile?
A lot more than you’d expect! Whilst the physical exertion required to building a 135-foot vessel thankfully doesn’t compare with what a development team has to go through, there are many parallels that can be drawn between the way the Vasa project was planned and managed, and the common mistakes that plague Scrum teams developing a new software product.
In fact, the term Vasa syndrome was coined by people who study management to describe a collection of risk factors such as frequent or unexpected changes in requirements, problems with goal-setting and miscommunication between team members, all of which increase the probability of any project ending in disaster.
To a certain extent, one or another of these risk factors can pop up in any Scrum team—no matter how experienced—but it is when they all strike together that they can create a perfect storm of severe management errors and oversights that could spell doom for your agile project.
Let’s talk prevention before dispensing a cure
It’s much better to prevent that perfect storm from happening in the first place, than having to pick up the pieces and glue them together after the damage has been done, don’t you agree?
We’ll take a look at the six “disaster triggers” that could cause your professional equivalent of the Vasa fiasco when handling a software project later in this article. But first, I’ll describe how you can virtually disaster-proof your next sprint.
And it’s very simple, really. All it takes to develop a functional product without any of the drama is to make sure you have all the basic requirements in place. In agile methodology, this means adjusting your mindset to working on width instead of working at depth.
When you’re building wide, your main priority should be to cover all bases and create a blueprint for your product which you can be reasonably sure is capable of delivering enough value for the client. What happens next is simply a process of continuous refinement and development of the initial system, every step of which must be justified by requirements that accurately describe the solution for the specific problem at hand (hint: user stories are the perfect tool for this).
Agile encourages (strategic) laziness
In fact, agile principles are meant to prevent overwork. Why build a 138-foot ship when you have enough material and workers at hand to build a smaller and lighter one? Why go through all the trouble of getting enough metal to fashion 64 guns when the gun-decks can only carry 54 without excessive strain?
With the Vasa, the main problem that the king (a very important stakeholder, or the customer) constantly came up with new requirements that changed the ship’s sailing capabilities and seaworthiness. Perhaps the biggest mistake was that the king had heard rumours that the Danes had a ship with two gun decks. Despite the fact that Vasa was built to have only one gun deck, the king felt that his neighbours couldn’t get one up on him. This late change in the design meant that the lower gun deck ended up close to the waterline and that the ship therefore could tip easily.
There are many scapegoats to choose from. The king who wanted two gun decks. The ship builder who did not stop the King (interesting in an IT context, as a serious supplier should give good advice to the customer). The vice admiral who let the Vasa set sail though he knew that the vessel was not seaworthy, and the crew that let the Vasa set sail with her gun ports open.
The same applies to requirements. Agile software development is especially suitable for tackling fast-changing and uncertain requirements because it forces you to work with a focus on time, the end-user, the system as a whole, and the business context your organisation is embedded in.
Keeping track of all these perspectives naturally makes you split your work in shorter sprints or iterations, which in turn makes it possible to collect feedback from users and other stakeholders and thus continually test your requirements for their soundness with respect to the four perspectives mentioned previously.
You can be even more ‘strategically lazy’, and smart, by using a requirements management tool, for example ReQtest, to help you collect feedback from multiple sources, write and prioritise user stories, and document requirements in a consistent manner, across teams of all sizes.
6 disaster triggers that can make your software projects sink and flounder
Though I’ve seen lots of technology changes in the years that I’ve been in this industry and line of work, the fundamental problems are always deeper than technological changes or challenges. In fact, I could probably say that these problems are as old as projects have been around, and perhaps a fair few of these disaster triggers plagued even our beloved crew of shipbuilders tasked with creating the Vasa.
- An impossible work schedule – Putting a lot pressure on your 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 culprit.
- Requirements that change too rapidly – Making changes in mid-project is a sure recipe for something to go wrong. Things get even worse when it’s the people on your team who are changing all the time.
- 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.
- Going overboard with innovation – Software projects always include some degree of innovation, however adding new features just to satisfy some creative impulse should be resisted at all costs.
- Pumping too many requirements in a project – ‘Requirements creep’ is a common symptom of projects destined to failure. This usually happens when old requirements are not updated periodically or when new ones are included without looking at the bigger picture.
- Ignoring obvious problems – It is the testers’ responsibility to speak out whenever they notice any problems that could detract from the users’ experience.
Conclusion
Human fallibility is a seventh risk factor that could have been included in the list of disaster triggers, however this one can never be totally eradicated from a project. It is everyone’s duty to ensure that the Scrum team has the necessary structures in place to help its members learn from past experiences, and use them to find new ways to minimise the risk of setting off the disaster triggers and keep your project afloat.
About the author
Ulf Eriksson is one of the founders of ReQtest, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf’s decades of work in requirements management and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy, which he has abided to for a number of years in his professional life as well as in private.
Ulf’s goal is to make life easier for everyone involved in testing and requirements management, and he works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest easy and logical for anyone to use, regardless of their technical knowledge or lack thereof.
As the author of a number of white papers and articles, mostly on the world of software testing, Ulf has recently written an e-book titled Beyond the Hype: Software Testing Explained, which is a compendium of his experiences in the industry. Ulf lives in Stockholm, Sweden.
