Many judge all of agile development based on what they know about extreme programming. Quite possibly this happens because that is all or most of what they've heard about agile development. I wish all of those folks, especially agile skeptics, would take a close look at feature-driven development (FDD), if for no other reason than it is an example of an agile method that is very different from XP. FDD is quite agile while still employing many of the traditional practices that agile skeptics are probably more accustomed to seeing.
For example, FDD has the more traditional progression of a systems-engineering lifecycle model and uses distinct phases in its iterations, while still being highly iterative and collaborative. It conducts up-front planning, design and documentation and relies very heavily upon domain modeling (including "color modeling" with UML). FDD also uses feature teams with chief architects/ programmers and traditional code-ownership and code-review, as opposed to pair-programming and refactoring.
A Whirlwind Tour of FDD
FDD grew out of the method initially described by Peter Coad and Jeff DeLuca in chapter six of the book Java Modeling in Color with UML. It is a highly iterative and collaborative agile development method that focuses on:
• Delivering frequent, tangible, working results (about every 2 weeks)
• Domain-driven modeling and design
• Building quality in at each step
• Producing accurate and meaningful progress/status with minimal overhead and disruption for developers
As FDD is useful and desirable to managers, clients, and developers, DeLuca and Coad first employed it with great success on a large (1M+ lines of code) Java project for an international bank in Singapore. Since then, it has been increasingly used in other parts of globe with growing success, including parts of large companies like Sprint and