Chapter 1: What Is Agility? (And Why Does It Matter?)

Overview

“What is agility?” is a simple question with a complex answer. The answer is complex because there is no central authority to dictate the “agile standard” and define in legally binding terms what agility is or isn’t.^[1.] While many (including us) would argue that this is a good thing, the result is that not everyone will ever agree on a single definition. To some, agility is all about the people: emphasizing people over tools. To others, agility is all about the ability to change requirements late in a project (in fact, this is what most people mean when they talk about “being agile”). To the industry thought-leaders, agility is a combination of these things. But in true agile spirit, the very definition of agility evolves and warps over time.

To be honest, we’re glad that there isn’t a central standards authority for software agility, handing down the “agile spec” from on high and stipulating that all agile processes must conform to its ideals to be allowed to call themselves AGILE™, because that would stifle the exciting air of innovation and exploration of new development techniques that have ignited the industry over the past few years.

Of course, with the excitement of new ideas and new frontiers, there’s always the danger that we will disappear down a blind alley or two in our search for better ways of doing things. There’s also a danger that previously learned lessons will be forgotten in the rush to discover new improvements. These lessons include the benefits of doing an up-front design and exploring requirements in sufficient detail before coding. We discussed the dangers of forgetting these important lessons in our previous book, Extreme Programming Refactored: The Case Against XP (Apress, 2003).

The pendulum has swung from one extreme to the other. It’s gone from the inflexible, inefficient, old-guard, waterfall, high-ceremony methodologies to the highly fluid, trendy agile processes that we’re seeing today.^[2.] As you might expect, the pendulum has already begun to swing back the other way, and it will hopefully come to rest somewhere between the two extremes.

We’re hoping that this book will contribute toward finding the ideal middle ground. This book tells you how to create software using a small increment, short iteration, feedback-driven strategy while still modeling up-front and using that up-front thinking to avoid lots of rework (i.e., it has the benefits of agility but not the penalties of skipping up-front design).

ICONIX Process is a use case–driven analysis and design methodology. Its main focus is on how to get reliably from use cases to code in as few steps as possible. In this book, we describe ICONIX Process and show how it was applied to a real-life project. We also describe in detail how to apply ICONIX Process to a broader agile project environment. This combination of process and practices is shown in Figure 1-1. Informally, we refer to this combined process as Agile ICONIX.

Figure 1-1: Agile ICONIX in a nutshell

This book is all about how to be agile and accommodate the real-world situations of changing requirements, new technology baselines, and so on, without skipping analysis and design, using a small increment, short iteration, model-driven and feedback-driven approach. This book also teaches how to drive the development from UML models, and then shows how to adjust both the models and the code using an interleaved approach in a way that the model and code become more tightly linked over time.

Although much of ICONIX Process can be considered agile, some parts of it stand in stark contrast to recent agile thinking. In particular, agile methods often tell us not to bother keeping design documentation and source code synchronized. The theory is that once code has been written, we don’t need the diagrams anymore.^[3.] ICONIX Process, on the other hand, suggests exactly the opposite: the more tightly synchronized the design documentation is with the code, the faster, more maintainable, and more accurate (i.e., closer to the customer’s requirements) your project will be over successive releases.

Luckily, ICONIX Process also aims to make this process easier (again in contrast to other agile processes). To achieve this tight synchronization between diagrams and code, we need to cut down on the number of diagrams that we have to draw (and therefore maintain). It’s also important to know which diagrams are going to be important to ongoing iterations and which can safely be discarded. “Minimal but sufficient” analysis and design is right at the core of ICONIX Process.

Of course, there’s an ever-increasing number of development processes claiming to be agile. Project leaders may decide that the project they’re embarking on will be agile, or their existing project may not be working out too well, so they decide to introduce some agile practices. But what exactly does “agile” mean? What’s the yardstick by which agility is measured? Where’s the magic point of latitude when a project flips from being nonagile to being agile?

In this chapter, we examine the somewhat nebulous term “agility” and attempt to disambiguate it. In doing so, we aim to answer the questions in the previous paragraph.

^[1.]Of course, there is the Agile Alliance (see www.agilealliance.org), although this isn’t quite the same sort of thing. We discuss the Agile Alliance later in this chapter and in Chapter 4.

^[2.]If we think of a big, high-ceremony process as elephantine, and an extremely minimal/agile one as mouselike, it’s amusing to note that some folks try to equate the mouse to the elephant because both are gray mammals with tails. In reality, however, there are significant differences between a mouse and an elephant, and neither of those animals does the work of a horse very well.

^[3.]This mind-set comes from thinking of diagrams as documentation rather than as tools that enable the design process and efficient communication about the design across the team. In our estimation, this is 100% backward. Modeling should be about doing design and communicating the design to the rest of the team, not about documentation.