Cargo Cult Requirements

This content is syndicated from Tyner Blain by Scott Sehlhorst. To view the original post in full, click here.

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 now-gone 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.

  1. Building the wrong features into products to expose capabilities.
  2. Building the wrong capabilities into products for the users to solve their problems.
  3. Building solutions to the wrong problems for their users.
  4. Building solutions to problems for the wrong users.
  5. Building solutions for users in the wrong markets.
  6. 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?

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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)

Will you be more successful than they were?

Post to Twitter Post to Facebook

Leave a Reply

Your email address will not be published. Required fields are marked *

1 × two =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”



To explore how we can help you, please get in touch