Learning Agile summary

Let’s talk about e-book readers for a second. 

It’s easy to see why they’re so popular. The object itself is about the size of a regular paperback, but it holds thousands of books. Even better, every text is responsive to you, the reader. You can enlarge the words, change the font, or skip back and forth between the main text and references. With a single click, you can access libraries and catalogs; with another click, you can borrow or download new books onto your device. 

In short, this is great software. It’s well designed. Convenient. Intuitive. It satisfies every stakeholder. Readers find it easy to use, and it displays texts accurately, which is important to authors. It also helps booksellers and publishers sell and distribute books.

The first e-book readers didn’t do all these things, though. In fact, it took over a decade of development before the software got to where it is today. Back in the early 2000s, it wasn’t clear what would make an e-book reader valuable. We only know that today because hindsight is 20/20 – which brings us to our little thought experiment. 

Let’s go back in time. Imagine we’ve been tasked with developing the software to display electronic books on brand-new handheld devices. How will we approach our task? 

Well, we’re actually going to do it in the worst possible way because this isn’t the kind of company that’s exploring new ways of building software. This is an old-school operation, with leaders who lead and followers – that’s us, the developers – who follow. In short, this isn’t the kind of office where you’ll hear the word “agile.” So let’s see how things play out. 

The hardware team has already made a prototype. Picture a chunky black tablet with a USB port for loading books and a fiddly little keyboard for interacting with the reader. It's up to us to build the software that will display e-books on this gadget. 

Our company applies what’s known as a waterfall process to its projects. What that means is that projects are front-loaded. All the product requirements are defined at the outset. As we said, leaders lead and followers follow. All the stakeholders – the senior managers, publishing representatives, online retailers, and so on – sit down and and hash out a plan. They outline requirements and come up with a specification that ticks all their respective boxes. Every other stage of the process, from design to development and testing, flows downstream from these decisions just as a body of water flows downstream from a waterfall. 

So what’s in the specification? In a word, everything. This e-book reader is going to be revolutionary. It’s going to have tons of features. It'll capture market statistics for publishers. It’ll have an internet storefront for readers to buy books. Authors will be able to preview and edit their books as they write them. And it’s all going to be ready in 18 months.

Fast-forward a year and a half. Since this is a thought experiment, we don’t have to be realistic, so we’ll say the project is completed on time. And it’s all there – every requirement in the specification has been implemented, tested, and verified. Everyone’s happy. 

Can you guess what happens next? The reader hits the market . . . and it flops. Hard. No one buys it. 

What went wrong?

The thing is, people’s needs aren’t static – they change with the times. If your only choice is a horse, you want a faster horse. But a horse, no matter how fast, isn’t much use if everyone else is already driving cars. Similarly, the software that people needed 18 months ago isn’t the software they need today. Since our project began, a new industry standard for e-books has emerged. No retailer wants to publish our unstandardized format – it’s too much bother. And so none of our revolutionary features are supported, which means they’re no use to anybody. 

This also means we’ve wasted lots of time and money creating software that’s not very valuable. So what should we have done differently?