Aaron Erickson, author of The Nomadic Developer, explains why Agile development teams must deliver and keep delivering on a regular schedule. The surest proof of your team's practicing Agile methodology correctly is that you continue delivering working product.

Like this article? We recommend

Now that Agile has passed the 10-year mark, many people are starting to wonder what the next step should be in the evolution of Agile. As we start to think about what's next, it doesn't hurt to think for a moment about how we got here in the first place. As the saying goes, it's hard to know where you're going if you don't know where you've been!

So let's turn back the clock through the mists of time in the years leading to the Agile Manifesto in 2001. Back when this movement started, many of the "reasons for Agile" just seemed very intuitive. People over process? Sure. Responding to change versus following a predefined plan? Common sense. On the surface, few people would disagree with the assertions made in the Agile Manifesto. But is that enough? Can you following the Manifestodo it all by the bookand be guaranteed to create software that delivers economic benefit? No. By itself, Agile doesn't lead to business value!

How Can By-the-Book-Agile Fail?

Let's be clear. With its increased collaboration with the customer, more frequent releases, and increased engineering and testing discipline, Agile makes delivering value more likely. It's certainly a vast improvement over multi-year "too big to fail" Waterfall software projects. But even if you do everything right, even if you have the best practitioners in the world building your product, you can still create a product that fails to make money.

Agileand here we mean the kind that includes the right engineering practices, such as test-driven development (TDD), pairing, SOLID principles, automated acceptance testing, and continuous integrationwill ensure that you create a product that works...in the lab, at least. However, despite your best efforts, you might build a very functional eCommerce site that tries to sell something that nobody really wants. Or you might build an internal application that can't go beyond the lab because the operations people can't support it in production. These issuesand many other things outside direct control of the team practicing Agilecan thwart even your best efforts.