Agile Fact or Fiction: What Does Being Agile Mean?

Agile Fact or Fiction: What Does “Being Agile” Mean?

We’ve gone some way toward answering this question throughout this chapter, but we thought it would be kind of fun to get our three coauthors’ separate opinions on the subject. So in this section (which also continues in Chapters 4), we discuss some of the myths and misconceptions that have grown up around agile software development.

• Mark:   A dictionary definition of agility would be something like “the ability to change direction while moving at speed,” and this motivation is at the heart of software agility.

  I see agility as a logical extension of moving away from waterfall-style software development (i.e., do all analysis, then all design, then all coding, then all unit testing, then integrate the software, then system test it, etc.) to iterative and incremental development, whereby systems are delivered in a number of stages. Functionality is prioritized, and a self-contained useful subset of functionality is delivered on a regular basis.

  Agility takes this idea further and puts additional emphasis on the ability to be able to change direction—and by “direction” I mean the direction in which business requirements are pulling us—while still moving at some speed toward our number one goal of a working software system. In order to move at speed, agile development approaches downplay the importance of nonsoftware deliverables to varying degrees, certainly when compared to very heavyweight, documentation-oriented processes like RUP or those used in many conventional software houses.

• Matt:   Hey, Mark, a quick search on Dictionary.com defines agility as “being nimble.” But somehow I don’t think “software nimbleness” would have caught on in quite the same way as “software agility”! Seriously, though, what defines software agility is really the goals of agility—that is, why you’d choose to apply agile practices to your project—and the agile practices themselves. Short iterations, test-driven development, interleaved modeling/testing—these are all practices that help us to achieve agility, but they aren’t themselves agility.

  Agility, in my mind, is an increased ability to change direction without causing excessive expense, with the end result being a system that closely matches the customer’s needs (which might not have been fully understood at the start of the project).

  However, changing direction without excessive expense is something of a Holy Grail, because changing the requirements (or the design) midproject is never going to be free. But it’s an ideal that we strive toward on each project, by applying various agile practices. Knowing which practices to apply—tailoring the process for each project—is, of course, the difficult part. So it’s best to start with a core subset (hey, like the one we define in this book!) and build on top of that.

• Doug:   Well, the nebulous use of the term “agility” is one of our main motivations for writing this book. In general, there’s probably a consensus that agility is about being able to respond to changing requirements, and there probably aren’t too many people that would argue that avoiding long, drawn-out periods of specification and design without doing any coding is agile. Going a step further, we probably wouldn’t be controversial if we claimed that small increments, short iterations, and frequent releases are near the core of agility, and that getting early and frequent feedback from customers is agile.

• Beyond that, there’s a plethora of advice, practices, and guidance that purport to be agile—some of it’s good, some of it’s bad, some of it’s interesting but not particularly relevant to achieving “agile goals,” and some of it’s just plain awful. What we’re trying to do in this book is define a core subset of agile concepts and practices, and then illustrate it by example. My earlier books define a core subset of UML modeling techniques to support use case–driven development, and I’m hoping that between that subset and the subset we define in this book, we’ll be able to give people a really useful set of techniques to apply on their projects.