In this article, I would like to look at the Agile Manifesto Principles and see how FDD relates to each.
This article is only a draft, and feedback is actively solicited!
Agile processes have rapidly gained mindshare over the last few years as practitioners, disillusioned with the so-called "heavyweight" processes have sought to find better ways of delivering software to spec.
FDD was around before the Agile Manifesto was published. But FDD seemed to be aligned with the values expressed in the Manifesto, and thus was placed under the same Agile umbrella term. There are quite a few processes that fall under this same umbrella; apart from eXtreme Programming and FDD, there is Scrum, and others.
However, there seems to be a frequent misconception that Agile Processes equates to XP. While XP is currently the most popular of the agile methods, it is by no means the definitive approach. In order to differentiate FDD from XP, this article looks at the Agile principles and sees them from the FDD perspective. In this way, the same principles in their abstract form are instantiated in different but valid ways in XP, FDD, Scrum and others.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
After a relatively short ramp-up period (though not short enough for some!), where an initial model and feature list is developed, development begins. The development cycle of FDD focuses on feature sets, so that features are delivered complete and working at least every 2 weeks. This ensures the steady and continuous delivery of new functionality.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Changing requirements are inevitable, and a central concern of the agile processes are to be adaptable to change. So too the iterative nature of FDD enables adaptability. And if, during the modelling phase, an area of risk is identified where requirements may change, or are not cemented, this area can be decoupled, abstracted and isolated to ensure the impact of change is minimised.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
As mentioned above, features are no more than 2 weeks work. Thus a constant stream of features and feature sets are delivered. The workflow system that the CPs follow ensures the pipeline is optimally filled. Typically a weekly release would be delivered to system test.
Business people and developers must work together daily throughout the project.
FDD does not mandate daily involvement of the client. However, during the ramp-up phases - #1 Develop an Overall Model and #2 Develop a Feature List - direct collaboration with the domain experts from the customer is required. There are numerous benefits: developers get exposed to the domain and learn the model at the same time, and customers gain a stakehold in the architecture of the system. During #4 Design and #5 Build by Feature, customer interaction takes a different form. This could involve system testing, usability feedback, performance testing, leading user focus groups, bug reporting and so on. The changing role of the customer reflects the changing needs of the project as it progresses.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
FDD has always emphasised the inherently human nature of the software development process. The Feature Team structure (inspired by surgical teams) is a very powerful shape. It reduces unnecessary lines of communication, focuses small teams on related areas of work (feature sets) and encourages mentoring on several levels. FDD also emphasises the need for supporting tools to ensure that the working environment and infrastructure provides all that is required for success. (*Discuss the Toolsmith role here.)
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The workflow aspects of FDD encourage direct collaboration. This is evident especially during the modelling sessions where the customer is very much involved. But also during the code reviews of the construction phase (#4 DBF and #5 BBF) the round-table meetings encourage open communication. However, FDD diverges from this in an important aspect: in order to capture important project information, knowledge, meeting minutes, decisions and issues, a central repository (which we dub the KMS - Knowledge Management System, for want of a better name) is put in place. The role of the KMS is to capture all essential communication regarding the project, and to publish it openly and engage and involve the customer. This level of transparency is often confronting for some not used to it, but it is highly valued by clients, and proves also valuable to the developers. Having a chronological record and central collection of project artefacts, including defect reports, test results and feature requests, provides transparency, accountability, and also traceability.
Working software is the primary measure of progress.
FDD has numerous aspects that address this. The way the CP manages the workflow of feature teams ensures optimal delivery of features. The built-in monitoring gives insight into true progress, in the form of Parking Lot charts and Feature Complete charts. Metrics provide measures that enable PMs to track progress, check for stalling, and more. A great deal of effort has gone into ensuring FDD delivers constant progress, but more importantly, it has built-in tools to enable effective measuring and reporting of progress for management.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
FDD has been successfully used to deliver projects as short as a few months, to nearly 2 years. Few customers would be happy to pay for developers to work indefinitely, so finite scope would (hopefully!) always bound the project. However the aspects already described above ensure FDD can deliver sustainably.
Continuous attention to technical excellence and good design enhances agility.
FDD places a great deal of emphasis on modelling and design -- but not down to the metal! Technical excellence is encouraged at all levels.
Simplicity--the art of maximizing the amount of work not done--is essential.
Rather than embark on a constant cycle of refactoring, FDD advocates doing enough design up front so that the construction phase is optimised.
The best architectures, requirements, and designs emerge from self-organizing teams.
The Feature Team has proven to be highly effective in a number of ways. It keeps communications channels to a minimum, thus avoiding high overheads. It focuses a small agile team on a set of related functionality. It promotes mentoring to accelerate learning. It optimises to the workflow. It delivers consistent working results. It focuses on delivering quality by requiring FT inspections on design and code. And more...
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This presumably is referring to process improvement. Regular checkpoints in FDD ensure that progress and performance is reviewed. Built-in monitoring identifies areas of concern quickly, thus mitigation steps can be initiated.
The Agile Manifesto has struck a chord in the development community. And the principles described above are a reflection of changing attitudes and the recognition that the practice of software engineering must be adaptable to rapid change, while minimising overheads. Clearly there are many ways to implement these agile principles, and FDD gives us a best-practice process to deliver results while remaining agile.
** Please post your comments, ideas and feedback below! Thanks... **
:: Gavin -- antonym.org