IntroductionRigor Without the Mortis

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).

That’s great in theory, but it might leave you wondering how to go about doing it in practice. There are plenty of agile books out there that set out to tell you how to “be agile” at a management or process level, but this book is different for a number of reasons. First, we look at each level of agility and show how it can be applied to a real-life project, from issues with team adoption of agile practices down to a specific logical design process.

We also believe that being agile doesn’t mean you should have to abandon up-front analysis and design (although we do agree with agilists that too much up-front analysis and design can be a bad thing). So, in this book we define a core subset of UML diagrams and techniques, and show how to apply them to your own project using a core subset of established agile practices. Our goal is to show how to make your own process minimal yet sufficient.^[1]

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.

In our attempt to find the “sweet spot” between agility and discipline, the spot we’ve landed on is probably far removed from where some agilists (most notably the creators of Extreme Programming [XP]) would expect it to be. For example, we place a higher emphasis on UML modeling than XP does. However, if you’re an XP practitioner, you may well find that the object modeling process this book demonstrates works very well in collaborative modeling workshops (in fact, we place a high emphasis on the value of collaborative modeling).

Plan Driven and Feedback Driven

Agile ICONIX Process is plan-driven and feedback-driven, small-increment, short-iteration development, using the following artifacts:

• Use case model (including personas)

• Domain model

• Release plan

Then for each release, we aim to produce the following:

• Robustness and sequence diagrams for each use case

• An updated class diagram

• Source code

• Unit and acceptance tests as appropriate

Using this process, we tie the persona modeling^[2] into the iteration plan and drive the feature set, via the iteration plan, from the usage requirements. (This is similar in some ways to Feature-Driven Development [FDD], which we discuss in Chapter 4.)

^[1]This isn’t dissimilar to Agile Modeling’s principle of making documentation “just barely good enough,” though we distinguish it because there are some important differences in our guidance, as we describe in this book.

^[2]See Chapter 10.