FDD gets a good mention along with XP, Scrum, RUP and some others in the new book by Barry Boehm and Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed.
The book is aimed at big company IT managers who have to decide whether agile processes are worthwhile and whether to adopt them rather than traditional methods. It also introduces the idea that risk management can be used as a method to allow an organization to successfully mix the best of both worlds.
The main section on FDD is in pages 183 - 185. It's a pity that some of the conclusions drawn are wrong and I wonder if the authors had anyone from the FDD community review their work. I also think it is a pity that people are quoting Jim Highsmith who interpreted from Jeff that FDD only works with really good people. This is just plain wrong. FDD still works with pretty average teams, it just doesn't work as well. It's a matter of degree.
The text also states that FDD is vulnerable to changes which break the architecture. I only ever use FDD with DNC/Archetype modeling for the PD architecture and Statechart/MVC-Type2 UI architecture. My experience is that this provides a very robust architecture which copes very adequately with change, even late change.
 | Balancing Agility and Discipline: A Guide for the Perplexed author: Barry Boehm,Richard Turner asin: 0321186125 |
Title
I read some reviews and the book doesn't seem too bad (take a look at Ron Jeffries' one for example) but I hate the title because agile demands for discipline and whoever has chosen that title don't have any idea of what agile is!! :)
Marco Abis
http://agilityspi.com
http://agilemovement.it
Software development is a human activity
How are you attributing statements like that to Highsmith? He said nothing of the sort. FDD doesn't rely on good people any more than other processes. It's simply honest enough to say up front what the facts are: process isn't a substitute for talent or skill. There's no snake-oil sales pitch here trying to tell you that you can turn a sweatshop full of artless hacks into a world class team overnight "just by adopting the new and improved [insert process name here] (oh, and sending a cheque with lots of zeros on it)".
The closest that Jim comes to anything about relying on good people is a statement about the Singapore banking project. We're talking about the most complex domain Peter Coad had modelled, and a project that another major vendor had spent two years on with no results. Jim's guess was even with FDD, the prvious vendor would still have failed without the appropriate level of technical and management talent.
Reader interpretation
You pick the correct section from the Highsmith book - mr. Anonymous - and I agree Jim doesn't say that. However, it has been interpreted that way and people who have read the book have asked me about it in the context that "it appears FDD only works with good people".
As a general thread in the Boehm/Turner book, they pick up on some things Alistair Cockburn has said/written about agile methods requiring a higher compliment of good people for success. Hence, the book probes this issue of "good people" continually.
As a former manager, in a Fortune 100 company, in mid-Western America, I can understand why managers in big companies have to worry about whether or not they have enough good people to execute with success. Hence, the issue is real and the question the authors are trying to answer is whether or not agile can be applied in these environments.
I believe that their conclusion about FDD is wrong in this regard.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
FDD doesnt mandate an architectural approach.
Pretty interesting assertion on the part of the authors, given that FDD doesn't say anything about what architecture to use.
There are some common approaches that we always use at Nebulon, and of couse we use FDD on our projects. But that's about the closest connection I can make between the two.
We always use archetypes and the Archetypal Domain Shape when modelling the PD layer. And we always layer the solution into HI, PD, SI and DM layers. Sometimes one or more of these are extremely thin or non-existant, but we approach it that way every time.
The rest of the details are in the modelling. In the business layer we always MODEL THE DOMAIN. This is the single best way to provide a robust, sustainable architecture there.
But NONE of these things are mentioned in, or mandated by, FDD.
is the DNC in or out?
I would prefer to avoid re-opening old wounds on this one. I think we are all in screeming agreement on it. FDD works best (so far) when the DNC is used. However, as to whether it is "mandated" or not in FDD, you have to consider that Steve and Mac included it in their book. Most people learning about FDD today learn from the book or this website. The book is seen as definitive.
Perhaps an article on this website co-authored by a number of us would clear the matter up. The line I took in my own book is that FDD works best when the DNC is mandated as part of the process. I did this for reasons we already understand - it provides a robust shape which withstands change and reduces the need for refactoring, it also provides a good skeleton with which to devise the Feature List and results in Features with a lower variation, which in turn leads to more accurate planning, greater certainty and a reduced project buffer which ultimately means that the project gets delivered earlier.
And I agree - I too was stunned by the Boehm/Turner conclusion that FDD was subject to architectural brittleness.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
It's Out
This has been asked and answered before my me and Steve Palmer (offline).
Jeff
n-levels deep in interpretations
I've not seen the book or read it, so anything I say will be my interpretation of your interpretation of Boehm and Turners interpretation of Highsmith's interpretation of what I originally said (!)
So, against what you have interpreted above.
That FDD only works with really good people is a nonsense. I could cite several experiences (not theories) in response to that. Furthermore, FDD works with LESS EXPERIENCED people than with other Agile approaches - and I'll be writing on this soon based on my experiences at the Agile Development Conference in Salt Lake City this year.
That FDD is vulnerable to changes which break the architecture simply astonishes me. Where on earth does that come from? What architecture do any of the 5 FDD processes mention? (answer - none). The only thing I can speculate that someone could misapply the term architecture to is the object model in the Develop an Overall Model process. If that is "the architecture" then it is a nonsense to suggest FDD is vulnerable to changes to it. After all, the key to object modeling is to model the domain. That is why OO systems are more sustainable and flexible as they are modeling the underlying business itself (the domain) rather than the ad-hoc functional requirements of today's problem. So, we are as vulnerable to changes as the business is itself. How much better off could we be? (rhetorical)
Too much speculation on too many levels of interpretation I think.
I can say that the authors did not contact me or anyone at Nebulon. They may have contacted Steve Palmer, I haven't asked him, but he usually tells me about such things...
Jeff
Definitely works with less experienced people
I would concur that FDD works with less experienced people. I have a lot of experience doing this in the last 4 years - too much perhaps. It would be nice to work with a team as good as you built in Singapore.
I don't have enough experience to say whether it works better with the same quality of people as other agile methods. However, what I inherited at my current job was a pseudo-XP-ish process and using the same people, the results were much better with FDD.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Quote from page 185
Here is the contentious text from the book... (page 185)
FDD differs from XP in code ownership and architecture
FDD differs from XP in two significant ways. Its principle of classes assigned to individuals is the antithesis of XP's collective ownership of code. Its focus on architectures and "getting it right first time" is the antithesis of XP's simple design and YAGNI. This makes FDD stronger for more stable systems with predictable evolution, more vulnerable to nonpredictable "architecture-breaker" changes.
Comments
Up-front planning and architecture enable multiple concurrent iterations for scaling
Multiple packages may be designed and implemented by several teams, allowing FDD to scale much more easily than some of the other agile methods. The architectural work and planning performed up front provides the structure for parallel development.
Needs good people and strongly coupled to object techniques
FDD emphasizes the importance of good people. It very much needs a strong complement of Cockburn's Level 2 and Level 3 people to succeed, especially when scaling up. Modifying the architecture during rapid and unpredictable change makes top talent necessary and in general compensates for the lack of explicit focus on risk. While all agile methods generally espouse object-oriented techniques, FDD specifically defines its process and roles with object technology in mind.
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Architecture in RUP
Jeff wrote: The only thing I can speculate that someone could misapply the term architecture to is the object model in the Develop an Overall Model process.
My interpretation of RUP based on Kruchten's book is that architecture (in RUP) includes domain modelling - Quote: Architecturally significant elements include the following: Major classes, in particular those classes modelling major business entities, page 89.
When I was reading the book last week, I was struck by how architecture (in the sense of the implementation structure of the software) was combined with domain modelling, things that clearly should be separate activities (on the don't-couple-things-you-don't-have-to-couple principle).
Phil
Separation of Concerns and (lack thereof in) RUP
Incredibly timely post Phil! I was about to write a Blog entry on this and decided to post it as a reply on this thread instead.
I have to credit Martin Geddes for this explanation - Martin worked with me in Ireland and Kansas City. He is familiar with FDD in as much as he was present while it was happening though he wasn't directly involved.
Following my post about Business Rules and their possible relationship with Features and Processes/Tasks, Martin made the following observation...
There is strong value in separating the domain from business rules from the tasks or user interface design because each has a different amount of uncertainty attached to it. The domain is by far the most stable and least likely to change. If the domain has been modeled and code written to implement it, then that really does represent significant progress.
The business rules are more likely to change and tend to reflect changes in the market and other external influences. Hence, keeping them separate makes sense. They have greater uncertainty and this needs to be both buffered and partitioned.
The tasks and their description in the user interface have the greatest uncertainty at the outset of a project. In fact, the UI may not be truly finished until after delivery when real users start using it and changes are made to accomodate real usage. Hence, the UI must be partitioned from the rest and its flow must either be a-modal (i.e. does not commit on tasks) or the tasks contained within it may be subject to change. A flexible architecture such as BrÃan O'Byrne's JStateMachine may protect you against this becoming too costly but likely than not such measures will not have been taken.
Hence, Features, Business Rules and the UI flow must be separate. FDD gets this (mostly) right. RUP, on the other hand, puts all three into the one document - a Use Case. It couples them together.
The result of coupling is that all three inherit the uncertainty attached to the worst element. This increases overall project risk and is likely to lead to greater amount of re-work.
Regards,
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Link is wrong?
The link for the Boehm and Turner book points to one of my newsletters. I don't think that is what you intended.
Jeff
Fixed
Sorry about that - must have had the wrong URL in the clipboard. Should have checked it better.
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/