5

In several places Feature Driven Development (FDD) is called an Agile methodogoly - e.g. the Wikipedia entry on FDD.

Yet in general, to be considered FDD it seems the following requirements have to be satisfied:

  • Coloured UML has to be used (but documentation isn't necessary);
  • Instead of pair programming the team is divided by software features;
  • refactoring is discouraged or, at least, isn't a task with explicit scope;
  • unit testing is discretionary, the team leaders can decide;
  • the work flow has to pass through the five FDD phases;

On the flip side it seems to me that Agile is

  • UML is an optional tool
  • Tests are documentation
  • Tests are obligatory
  • refactoring is a consequence of the change requests of the customer and it isn't discouraged.

Am I wrong with my understanding of either concept?

Improve this question
8
  • 1
    I would say your view of Agile is too narrow. See also en.wikipedia.org/wiki/Agile_Software_Development. For one thing, "test is documentation" is not a universal principle of Agile.
    – Bart van Ingen Schenau
    May 22, 2013 at 13:07
  • Is testing really obligatory or only encouraged? I would expect that an agile team decides in each situation what needs to be tested and what not. At least I would expect this flexibility from an agile methodology that values "Individuals and interactions over processes and tools".
    – Giorgio
    May 22, 2013 at 13:08
  • 1
    I think you may be comparing FDD to something like XP c2.com/cgi/wiki?FeatureDrivenDevelopmentVsExtremeProgramming and I'm not sure I can see where all the statements you get about FDD come from?
    – jk.
    May 22, 2013 at 13:15
  • @Bart I agree with you: I say what Agile is, not what Agile has to be. The test is documentation is'nt normative, but it is very popular. But can I consider Agile a methodology with normative working tool (UML) and optional test/refactoring? Is FDD Agile only for the iteration, time-box etc?
    – alepuzio
    May 22, 2013 at 13:17
  • 1
    Hi Alepuzio - I've made an edit to your question - could you double-check to ensure that I haven't accidentally changed the meaning of what you meant to ask?
    – Joris Timmermans
    May 22, 2013 at 13:27

3 Answers 3

Reset to default
1

Maybe this link will explain more of the details. FDD came before the Agile Manifesto, so don't always think you have to practice XP or Scrum to be agile or no one considered the benefits long before.

From your wikipedia link:

"Its main purpose is to deliver tangible, working software repeatedly in a timely manner."

Isn't that the whole point of being agile? Like BDD, FDD isn't appropriate for all projects. You may be the biggest UML hater on the planet, but there could be a project that will be eaiser to manage if you have a few.

Look at the reasons/problems solved by certain methodolgies. What aids you in being agile in one type of project could hold you back in another especially if you think the way to not rely on documentation, contracts, etc. is to exclude them completely.

Improve this answer
4
  • I've adjusted my answer based on the downvote comments.
    – JeffO
    May 22, 2013 at 17:00
  • The link and your response are ok for me
    – alepuzio
    May 28, 2013 at 8:03
  • @JeffO: "Isn't that the whole point of being agile?": Having the same or a similar goal does not automatically imply using the same means towards that goal.
    – Giorgio
    Aug 19, 2017 at 6:13
  • @Giorgio - I couldn't agree with you more.
    – JeffO
    Aug 25, 2017 at 17:19
9

It's your definition of Agile that's wrong. Agile is valuing

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

To take your specific points ...

UML is an optional tool

Yes. Most things are when being Agile. Task boards are mandatory in Scrum, which is an Agile methodology, but they're not mandatory to BE Agile.

test is documentation test is obligatory

This is more a TDD policy. TDD is another Agile methodology, but it is not a mandatory part of being Agile.

refactoring is a consequence of the changes of the customer and it isn't discouraged.

I don't think it's discouraged in FDD either. Nor is it explicitly stated. The Agile Manifesto also doesn't explicitly mention refactoring.

Agile is a set of principles, not a set of methodologies. Agile methodologies are methodologies that encourage those principles.

I don't see any way in which FDD isn't Agile.

Improve this answer
4
  • Right, but it's first time that I meet a mandatory programmer tool/language in Agile (the xUnit tools, f.e, are popular but not mandatory). In my opinion TDD can be see as a practice, not as a methodology. FDD discourages refactoring: (www.featuredrivendevelopment.com/files/FDD_vs_XP.pdF).
    – alepuzio
    May 22, 2013 at 13:33
  • @alepuzio: Your link doesn't seem to work. What is the difference, in your mind, between practice and methodology? And, again, nothing is mandatory in the Agile principles but plenty of things are mandatory in Agile methodologies.
    – pdr
    May 22, 2013 at 13:40
  • I read the paper: the correct link is featuredrivendevelopment.com/files/FDD_vs_XP.pdf (f lowercase, not uppercase). I agree that Agile has'nt nothing mandatory, but I'm seeing too much differences between FDD and what I know. Maybe I have to study FDD slower :)
    – alepuzio
    May 22, 2013 at 14:04
  • @alepuzio: Hey, I didn't say that FDD was better than anything else. But it does fit into the principles of Agile, nonetheless. The disagreement on refactoring appears to be in the phrase "does not bring any value to the customer". I would side with proponents of refactoring, but that's just opinion, it's not a matter of principle.
    – pdr
    May 22, 2013 at 14:33
2

Well, I am not an FDD expert, but here are my thoughts about the Wikipedia article:

Coloured UML has to be used (but documentation isn't necessary);

The article says you should develop a domain model. That does not mean that UML is required. I guess your team can decide which kind of modeling language is appropriate for the task.

Instead of pair programming the team is divided by software features

Some agile processes require pair programming (XP), others do not, so this does not proof that FDD is not agile.

refactoring is discouraged or, at least, isn't a task with explicit scope;

I don't see it is really discouraged. But I guess you are correct, the part of evolving a software (by applying changes to an existing product) instead of piling new feature over new feature seems to be disregarded in the whole process. That is of course a sign of a non-agile process!

unit testing is discretionary, the team leaders can decide

Sounds like a process which is adapted to the needs of the current project - which is definitely agile.

the work flow has to pass through the five FDD phases

This could be a sign of beeing non-agile.

In summary, I am under the impression that FDD tries to combine some agile things (like iterative development of small features) with some non-agile things (formal process with phases). Call it semi-agile if you like. Also, note that the same Wikipedia article calling FDD beeing Agile starts with the disclaimer "This article does not cite any references or sources...".

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.