The term “Agile” has almost become synonymous with Scrum or XP. However there are several other methodologies under the Agile umbrella. These methods have varying levels of agility. Barry Boehm and Richard Turner in their book- Balancing Agility and Discipline: A Guide for the Perplexed – have ranked Scrum the highest in terms of agility and conferred the dubious distinction of lowest agility among all the recognized agile methods to FDD (Feature Driven Development).
However in my view FDD is an excellent stepping stone towards agility for the organizations deeply-rooted in traditional (aka waterfall) way of software development and “command and control” style of management. Such organizations face many challenges while transitioning to agile methods.
One of the biggest challenge is changing the traditional mindset to an agile one. It is rather very difficult to let go the way of working which you have become very familiar with.
Agile methods like Scrum or XP introduce a completely different paradigm – minimal upfront requirements specification and design, new terminologies, roles, a Boolean measure of “Done” (i.e. either “Done” or “Not Done” ). However FDD has certain characteristics which the traditionalists can better relate to and hence be more willing to transition to. This would hopefully make the Agile journey less painful.
FDD invests comparatively more time in upfront requirements specifications and design as compared to other agile methods. It has a well defined sequential modeling and planning steps for this purpose.
The FDD roles like Project Manager, Development Manager, Chief Architect are perceived more favorably by traditionalists since they sound more familiar than Scrum roles like ScrumMaster, Product Owner.
Unlike other agile methods like XP and Scrum which do not give credit to partially done work, FDD defines completeness of work in terms of discrete percentages. For e.g. a feature which has completed design inspection is considered 44 % complete. This will get more buy-in from the project managers and team members used to conventional way of tracking the project.
Like traditional methods, FDD stresses on individual code ownership, design inspections and code inspections. This will avoid the apprehensions regarding the agile practices like collective code ownership, pair programming, test driven development.
FDD maintains the core agile principles while recommending practices which are closer to traditional software engineering. It is a low hanging Agile fruit which traditional organizations can initially pluck and enable themselves to continuously move upwards in the agility scale.
Visit the FDD community website to know more about FDD.
Also download an FDD Overview presentation by Nebulon Pty. Ltd. the consulting practice of Jeff De Luca, the primary architect of FDD.
[Last month I had initiated a discussion "Can FDD be the first step towards agility?" in the Yahoo Group - Scrumdevelopment. It received 14 responses from Scrum practitioners and experts. Most of them were in agreement with my stated view.Here is the link to the discussions
[Please feel free to leave your comments below or bookmark/share this post]
Posted the below message in yahoo groups:
I agree that FDD will get quicker buy-in in an organization where waterfall is the religion.
But if the organization culture is more adaptive and flexible to change I would certainly suggest to try out Scrum.
If the organization culture is very bureaucratic and slow in changing – people resist changes in a big way – then take baby steps through FDD.
It does not matter whether we call it FDD / Scurm, a smart manager can inject agile principle in small doses in his/her projects reaping benefits local to the project.
Thanks Rathina. Hopefully your posting will rekindle the discussion and we will get some more perspectives.
Thank you for providing a very balanced review of Feature Driven Development (FDD). I first came across FDD in 2000 and have been an avid fan since. FDD is a lighter-weight, yet scalable software development methodology that is particularly well suited for business driven application development.
In particular you noted that: ‘FDD invests comparatively more time in upfront requirements specifications and design as compared to other agile methods. It has well defined sequential modeling and planning steps for this purpose.’
I would submit your perspectives on FDD are spot on.
Thanks for your comments.
Good to hear from an “avid fan” of this lesser hyped yet pragmatic method of developing software.