Cargo Cult Requirements

Blog: Tyner Blain

Photo of Melanesians with bamboo plane

Is your team focusing on the mechanics of creating good software, without understanding the connections from your efforts to your goals? Are you primarily focused on the structure of use cases, the syntax of user stories, and the cardinality of your domain diagrams? All of these things are important to effective communication – but if this is your primary focus, you may be in a cargo-cult environment.

When you first hear about cargo cults – a real thing that happened – you may laugh at the absurdity of it, but when you read the Wikipedia article on cargo cults, and start to understand the context in which the Melanesian people formed the cults, you will stop laughing. The lack of perspective and implied desperation of the people of Melanesia is quite sobering. For folks who don’t want to click through to the Wikipedia article, here’s the short version. During World War II, the Japanese, and later the Americans, delivered supplies to their troops on the Melanesian islands. After the war ended, the cargo shipments stopped. In attempts to get more cargo to fall from the sky, islanders imitated the behaviors of the then-absent military personnel. Placing torches to light runways, carving headsets from wood, even mimicking daily military activities like wearing uniforms and marching in formation – all of these “following the mechanics” activities were performed in hopes of achieving the goal – getting more cargo.

The Melanesian islanders precisely followed the procedures that their “instructors” followed – they were intelligent people, who learned exactly everything that was shown to them. However, they were not told that the rituals of signaling to incoming planes did not cause the planes to fly over and drop cargo – the rituals were only important to getting cargo when the planes were already flying overhead.

Melanesian bamboo plane

A similar thing happens with many teams when it comes to creating software. When developers are following the rituals of good software engineering practices, it does not cause them to create good products. It only causes them to create products effectively. There’s no correlation that assures that they are being asked to build the right product. The developers have no power to make planes drop cargo. Like the Melanesians, they can only march in formation. Without the right requirements, the product will fail.

Development teams realize this, and intellectually appreciate the importance of having someone give them good requirements. Some development teams go out and get requirements themselves – I would argue that another way of saying this is that on some teams, the developers are also playing the role of business analyst or product owner, on a part time basis. One of the responsibilities of the product owner is to “feed” the development team requirements – specifically good requirements.

There’s another problem here, though, that I see far too often. Product owners trapped in a cargo-cult of their own. When product owners (or product managers or business analysts) focus on following a use case template, or writing user stories according to the common sing-song structure, or create UML diagrams with proper syntax, they are just waving torches and hoping that the plane will drop cargo for them. Writing measurable, unambiguous, consistent requirements is necessary – but not sufficient. Grooming the backlog and doing estimation exercises or formulating a cogent SRS (software requirements specification) are the software development equivalent of carving a wooden headset when focusing on the needs of the market doesn’t happen.

Torches (thanks Vince Wingate for the photo)

The most important responsibility of the product manager (or product owner or whomever) is to assure that the team is solving the right problems. If the product manager is not sending the planes, it doesn’t matter how good the team is at lighting the runway – no cargo will be dropped. I’ve seen teams invest years of effort building the wrong products.

Building the wrong features into products to expose capabilities.
Building the wrong capabilities into products for the users to solve their problems.
Building solutions to the wrong problems for their users.
Building solutions to problems for the wrong users.
Building solutions for users in the wrong markets.
Building solutions for users in markets that aren’t aligned with their company’s strategy.

I numbered the list above intentionally. The lower the number, the more frequently I see teams addressing the problem. The higher the number, the bigger the problem. As a guy who “went agile” almost 14 years ago when developing software and leading teams, I see exactly the opposite of what would happen if we prioritized our efforts to build better products correctly. Teams are focused on the things that are easiest to fix (wearing uniforms and creating requirements artifacts) instead of focusing on the things that cause the biggest improvements (scheduling planes and identifying the right problems to solve). But the teams keep expecting cargo to fall from the sky.

Here’s the most valuable hour you can spend today – skip one of those meetings that monopolizes your day and try it.

Pick a feature (or story) from the “must have” section of your requirements document (or the top of your backlog), and walk through the following questions – each time you get a “Yes” you can advance to the next question. When you find a “no”, figure out what you need to do to change your answer to “yes”, and move to the next question. Can you get through all the questions in an hour? If not, where did you get stuck (chime in below)? If you made it through all of them, quickly scan the next few requirements (or stories) and ask yourself if it would be worthwhile for you to do the exercise again. My guess – somewhere along the way, you’ll open Pandora’s box. Imagine that you open the box, and engage your leadership team to actually fix the problems – how awesome will your product be then?

For the story / requirement you picked – who is the user? Specifically, is there a user persona defined? Pick the primary user if there are multiple ones. A requirement not intended for a specific user is a requirement that has no users.
For this user, do you know what problem are they trying to solve when using the features / capabilities represented by the story? The features may be explicitly defined (e.g. “The system must allow users to make off-site backup copies of their photos.”) or implicitly (e.g. “As a photographer, I want to retain my photos if my device is destroyed.”). You need to explicitly articulate the problems that those features are intended to help users solve.
Are the capabilities represented in this story the best ones you can build to solve that problem? “Best” is defined as “makes the most sense right now” – you may be iteratively delivering incrementally more-capable solutions – that’s often completely appropriate – be pragmatic, not pedantic here.
Is this problem the most important problem you could be helping your users to solve? It may be the most important problem to your user, or it may be the most important problem to you – perhaps your competition is winning deals because they are much better than you at enabling users to solve this problem. Perspective is key here – a perspective, or at least a hypothesis about the definition of “most important” is what matters.
Do you have a rationale for why you are focusing on this user persona – and within that rationale, is this the right persona? Maybe this persona represents the bulk of your target market. Maybe this persona is a thought-leader who will drive adoption by other users, once you convince this user to love your product. Maybe this is a buyer persona, who you have to satisfy before your product ever gets in a user’s hands. Answering this question requires you to have an intentional approach for getting your product out there, and a definition of the “there” you want your product to be. As a quick litmus test – if you don’t know who the “wrong” personas are, can you know this is the “right” persona?
Have you elected to focus on the right market? Your persona represents a subset of your market (or your entire market, if you are hyper-focusing). There’s a rationale for selecting the right market. It combines sizing the potential opportunity, assessing the risks of failure in the market, looking at ease of entry, and understanding the alignment of that selected market (for this product) with the overall company strategy. If you aren’t a single-product start-up that never intends to sell other products, market selection should be done from a portfolio perspective.

OK, so how did you do? If you’ve got “yes” answers all the way through the list of questions, your product might still fail, but at least you’re being intentional.

You’ve avoided the cargo cult requirements anti-pattern.

If you ran into a “no” somewhere along the way, you’re making the same leap of faith that the Melanesians made when they lit the torches.

Landing gear (thanks Henri Sivonen for the photo)