Applying the Inverted Pyramid to Agile Development

Although it may be apocryphal, the story goes that the pyramid method was invented when reporters started using the telegraph to transmit their stories across the country to their editors. Prior to this, most articles where written much like today's school essays or technical reports, that is, in a deductive style with the conclusion at the end. But reporters quickly discovered that the telegraph was an unreliable transmission mechanism. Not only was the physical connection unreliable, but also they could easily be bumped off the line if someone more important, like the military, wanted their place. A half-transmitted article with the conclusion at the end was useless ("So, Custer was in an exciting battle, but did he win or lose?").

The reporters quickly adapted their writing style so that each article started with the most important details. This new format meant that if their transmission was cut short, then their editor still had the most valuable article possible. It also meant that the reporters kept their jobs and their incomes; what's the point of having a roaming reporter if he can't reliably deliver good copy?

Although the inverted pyramid approach has also been used for decades within software development to reliably deliver good software on time, despite the extreme uncertainty faced by most projects, it's only become well known within commercial software development with the growing use and awareness of the agile approaches such as Scrum and Extreme Programming. We don't refer to these approaches as the inverted pyramid. We use other names like evolutionary, iterative, incremental, or spiral, but the principles are the same: prioritize the features (or paragraphs, as in a story), deliver them so that our customers (the readers and editors) can consume them, and then repeat the process.

One of the reasons why the inverted pyramid approach succeeded is that it not only helped the journalists keep their jobs and made the articles more readable but also made the editors' jobs much easier, too. They would edit each article and then shorten it according to how important they judged the story and how much space they had available. If the article was on the front page, it also ran the risk of being chopped down to accommodate late-breaking news. The inverted pyramid style gave them the flexibility to quickly resize the article as needed. It meant that they could meet their daily commitments of shipping a highly readable newspaper despite the fixed space available.

Similarly, when software projects use the inverted pyramid style, senior managers have far more flexibility to react to changes in their environments. If a new opportunity opens up in the marketplace, then they may choose to close down an active project to work on the new opportunity. Since the software on that project is currently the best it can possibly be and because it is currently useable, the investment is not lost. In fact, the customer has received the best possible software he could expect and the organization has invested its development budget in the most profitable way possible.

I'm going to finish this article with what, ironically, is probably the most important point. One of the key lessons we can learn from the inverted pyramid principle is that when reporters are writing their articles, they will easily spend eighty percent of their effort focusing on writing a strong first paragraph, also known as the lede. Once they've correctly written the lede, they say that the rest of the article almost writes itself.

If a reporter gets the lede wrong, then the article is not only difficult to write, but it will inevitably be muddled and muddy to read. Newspaper folk call this "burying the lede." In software development, we often "bury our promise." We tend to focus too much on the software features or functional requirements—the concrete stuff—at the expense of the higher-level requirements that the customer and users really care about. It happens just as much in agile projects as it does in other types of projects.

Just as a reporter will figure out an article's lede by asking what the article is really about and then use the lede to guide him as he writes, software development projects need to ask not what its lede is, but what promise they are making. What's the project really about? How will the project's customers and the team's bosses judge if it is successful? I like my teams to agree on a one- or two-sentence "promise" with their customers. Last year, for instance, I ran a project where our promise to the team's management was simply to "rebuild trust with the customers." A few years earlier the promise was even simpler: "Do what you've got to do to beat our competitors to market with a good quality product."

A clear promise, like a good lede, sets the stage for everything that follows. Just as the reporter will scrutinize every sentence to ensure that it fits with the lede, a project's staff must always keep the promise in mind when making a decision. For instance, a month into the first project, we had some bad news which we could easily have hidden from the customer, but when I asked myself "Will this rebuild trust with the customer?" I decided that no, I would actually build more trust by sharing the bad news. Likewise, we quickly decided that the second project would deliver a very austere, but functional, product rather than one that was all singing and all dancing. Why? Because the product, the higher our odds of keeping our promise and beating our competitor into the market place.