Many people (especially agilists) associate a high-ceremony software development process with a dead project (i.e., rigor mortis), and this association is not entirely incorrect. Our approach aims to put back the rigor while leaving out the mortis—that is, we can do rigorous analysis and design without killing the project with an excessively high-ceremony approach. The goal of this book is to describe that process in full detail.

Agility in theory is about moving ahead at speed, making lots of tiny course corrections as you go. The theory (and it’s a good one) is that if you spend months or years producing dry specifications at the start of the project and then “set them in concrete,” this doesn’t necessarily (and in practice, doesn’t) lead to a product that meets the customer’s requirements, delivered on time and with an acceptably low defect count.

It’s likely that the requirements will change over time, so we need to be prepared for that, and it’s likely that a lot of the original requirements will turn out to be wrong or new requirements will be discovered after the requirements “concrete” has set. Agile methods answer this problem in a number of different ways, but the overriding principle is to break things down into smaller chunks and not to go setting anything in concrete (least of all your requirements specs).

Another reason this book is different is because we’re essentially “outsiders” in the agile world. We’ve been in the industry for a long time and have taken part in a number of agile projects, but we’re approaching agility from the standpoint of more traditional software engineering. We examine how agility can be applied in organizations that may approach “all-out, party-on extreme agility” with a heavy dose of caution and distrust. As a result, the process we describe in this book could well be more applicable to traditional or more disciplined organizations than other agile processes.