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
Some comments on Agile and FDD
Gavin
If someone ever writes a history of software development processes, I would be interested in hearing the motivations of the Agile Alliance. I know it was in large part a reaction against the formulistic, heavy-weight, high-ceremony RUP (and similar) approach. In a sense it was a back-to-basics movement!
The whole Agile thing is very fashionable at the moment and there is a strong motivation for people to say - We are Agile! I'm going to be the voice of dissent here and argue that FDD is in several important respects not Agile. I'll do it in the context of the Agile Manifesto.
And if this sounds like a bit of a rant on Agile then maybe its time!
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Good principle assuming it works! A better principle would be Our highest priority is to satisfy the customer by maximizing delivery of valuable software. Early delivery per se has almost no business value! Most businesses would not deploy half a (planned) system even if they could. The real value of early delivery is risk mitigation. Hence if this principle were honest it would read Our highest priority is to mitigate risk to the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
I have a number of problems with this statement! Firstly it links two only weakly related statements. The welcoming changing requirements part is a clear reaction to the cast-in-stone requirements syndrome of classical waterfall. But most apparent requirement changes are not real changes at all they are corrections to faulty requirements. A better solution to this problem is We will endeavour to get the requirements right the first time - The approach taken by FDD. There are several posible interpretations of the second part of the statement. I interpret it to mean that Agile faciliates changes to the customer's business. This claim probably rests on the on the cooperative and inclusive Agile approach which would doubtless make IT driven changes easier for the business to assimilate, but not really related to the first part of the statement.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Repetition of the first point!
Business people and developers must work together daily throughout the project.
Doing what! In this principle Agile looks most like recycled RAD! RAD doesn't scale either in size or duration! FDD tries to formalize the interaction with the customer and keep an audit trail through a KMS both important to achieving scalability.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
I'll ignore the self-serving tone of this statement - Trust me I'm an Agile developer!, and focus on the big picture. The Agile Alliance is in a significant way a plea to return to the good old days of craft-based software development! Whilst I recognize that software will always (or at least for a long time) have a large craft element, we have to make software development a reliable and repeatable activity and that unavoidably means process. It is here that FDD differs the most from Agile and IMHO FDD is on the right side (of history)!
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
And it doesn't scale and it isn't persistent! Again this is recycled RAD thinking! FDD addresses the scalability question through organized processes and the persistence question through the KMS.
Working software is the primary measure of progress.
I could spent several pages deconstructing this statement. Suffice it to say, The final deliverable is the only measure of success. And FDD endeavours to give early visibility on the final deliverable.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
As a long-standing critic of the project paradigm for software development, I agree with the sentiment behind this. However there is more to sustainable development than people. Lets call it the VB syndrome - rapid early development which quickly becomes unmaintainable software - frequently before any thing useful has been delivered. Domain modelling as practiced by FDD is one important way to avoid this situation.
Continuous attention to technical excellence and good design enhances agility.
This translates to - good software is Agile. The cynic in me reads this as a disclaimer - If your software is bad then its not Agile's fault!
Simplicity--the art of maximizing the amount of work not done--is essential.
Agree completely!
The best architectures, requirements, and designs emerge from self-organizing teams.
This revisits the trust us we are Agile theme! One of the biggest problems in software development is we always want to build a project infrastructure from scratch. Consequently, projects spend far too much time in the start-up phase. Remove self-organizing from this statement and replace by autonomous then I have fewer problems with it! FDD provides a formal out-of-the-box approach that does a lot to short-circuit the start-up problem!
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Again a variant on the previous statement with the same issues! I also think this embeds a fundamentally untrue premise. Namely, a group of intelligent, knowlegeable people will spontaneously arrive at the right the solution to the problem they are presented with (I am talking about the best way to organize the project). The history of ideas and science demonstrates this is false. The best most of us can do is add minor refinements to the solution we have been given!
Phil
Luddites
Phil,
Great post! Thanks!
The term Luddites comes to mind when you talk of a return-to-craftsmanship. I had this similar discussion with Dave Astels who writes the TDD column at the Coad Letter. I see a lot of "love of the craft" (of programming) in XP and its derivatives. I see resistance to the idea of engineering of large scale software.
A modern account of this Luddite tendency was described as "neo-craftmanship" and occurred at Volvo around 1990. They abandonded mass production techniques and returned to a single team builds a single car and even finish it with their signatures in a hidden location. This approach was derided in the book, "The Machine That Changed the World" which heralded in the term "Lean" to explain the Toyota management techniques of Just-in-time, statistical process control and Deming quality assurance, used in Asia.
IMO, much of agile is craftsmanship and not Lean. FDD is IMO (having studied this a lot recently) the most Lean of the new paradigm methods.
The notion of "Trust me - I'm a developer" doesn't cut it in Fortune 100 companies or any significantly sized business. The agile community has to learn that lesson. I described TDD as "Native American pottery - you won't find it in Wal-Mart".
As for the Manifesto itself - I thought it was a good start. The fact that 17 people agreed on a document over a 2 day period was an achievement. I don't think anyone expected it to live forever. Your post suggests some significant improvements.
David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers
Luddites and Lean
David
I avoid the term Luddite because its highly pejorative. As I recall the Luddites went around smashing the new weaving loom machines in late 18th century Lancashire. Luddite strongly implies historically doomed! I'm not sure I would put Agile in this category! OTOH I think it was Niels Bohr who said Making predictions is difficult, especially about the future! So perhaps Agile is a temporary phenomenum that will more-or-less rapidly dissapear as our understanding of formal processes in software development matures.
Its a long time since I worked in the Automotive business (the long since dissapeared American Motors, then Renault when they unsuccesfully took it over.
Phil
Craft and science
Speaking of craftsmanship (aka. craftspersonship to be PC), I thoroughly recommend people read the book:
The Pragmatic Programmer, Andy Thomas and Dave Hunt, Addison-Wesley, 1999
The book is all about the craft of sotware development, and has many valuable ideas, techniques and tips. Andy and Dave were party to the original Agile manifesto, and have a wealth of experience behind them. With nearly all of the points they describe in the book I had one of two reactions: either I thought "aha!" when they put down in words something with no name that I had been doing for years through "learn by doing", or it was something I hadn't thought of but instantly recognised as a great idea. They have managed to distill many years of experience into a very readable and practical book.
It is worth highlighting that nothing in this book is incompatible with processes (or a lack thereof). Just about all the practices they describe will enhance developer productivity, improve quality and generally add value to whatever project you happen to be working on. So I guess craftspersonship still has its place, but of course it is no substitute for a framework and processes that help deliver the final product.
Regarding "Lean" and the analogies with the automotive industry: I'm afraid I still don't see how building a car is much like building software. From my limited understanding (and having read about Henry Ford's famous production line), building a car is an inherently sequential process in many ways, largely due to physical constraints. You can't bolt the engine on until the chassis is welded together. And the construction phase is markedly different to the design phase. Certainly no car could be built that hadn't already been through a rigorous process of design iterations, prototyping, safety testing, yada, yada, yada. Perhaps you could explain in some more detail how these processes work, and how they relate to softwaare, such that we may learn from them?
:: Gavin Baker http://antonym.org
Relvant article
And to followup to my own post...
Regarding craftsmanship vs traditional heavyweight approaches: when looking for something else, I came across an interesting article on this very subject:
"Software Development: An Outsider's View", Kyle Eischen, p36--44, Computer 35(5), May 2002, IEEE (online)
Abstract:
Advocates of traditional software engineering and proponents of agile development appear no closer to a consensus now than they were 30 years ago, when their debate began. Yet howsoftware is made is often a central concernin technical circles and in generalsocial debates on privacy, trade, patents,and so on.Building a bridge between the specifictechnical issues and the broader socialconcerns can thus help achieve a clearerunderstanding of software, makingexplicit its unique structures and impor-tantrole in society.
(Reading the full article online requires membership of the IEEE Computer Society.)
:: Gavin Baker -- http://antonym.org
No surprise that FDD doesn't fit all agile principles.
It's always surprised me a bit that FDD wanted to consider itself one of the agile processes. I like FDD--I haven't used it on a project myself but I've recommended it to a couple of companies because I thought it a good fit for their culture and projects.
But, FDD doesn't strike me as "agile" in the same sense as all the other agile processse. I mean that entirely in the context of the real meaning of "agile" not in the buzzword meaning of agile as "something exciting, new and sexy."
Phil makes some good points in his post--I have trouble, too, with justifying daily customer involvement. When I need a customer I need her now but that doesn't mean she needs to sit 6' from me.
I disagree on a couple of points, though--I think there is intrinsic value in delivering something monthly and it goes beyond risk reduction. MOntly delivery (via Scrum in my case) allows a team to get in a rhythm that speeds them up. It also builds up trust from our customer.This type of trust used to take 12-18 months to get; with Scrum I find we get in in 3-4 releases. After that the customer learns that we will deliver what we say each month.
I've always felt that the signers of the Manifesto accomplished an amazing amount by agreeing on the 4 main values. The principles they added do not always seem as consistent and I'm sure they were not as diligently wordsmithed to withstand the scrutiny they get. Just like the post that started this thread there are numerous other authors who dissect the principles one by one. (Robert Glass's article probably being the most well-known.)
Mike Cohn
I was a bit surprised too - but then it made perfect sense
Hi Mike,
from my perspective, FDD didn't want to consider itself one of the Agile processes. After it had been listed as Agile by the "founding fathers"
I went back and looked at the four core values of Agile and found that they resonated strongly with me and with what I was about with FDD. Then, through Jim Highsmith interviewing me for his book, I went back and read his first book and saw a great deal in common with regards to complex systems, adaptiveness, emergence and so on.
I see a great deal of this thinking and these values in alignment with Agile and with FDD and therefore I have no problem whatsoever with FDD being listed as Agile. In fact, I promote it - precisely because of the resonances and alignment I have just described.
However, if doing any design or practicing class ownership ever becomes too heavy for Agile then I will be the first to declare FDD as agile and not Agile and I'll be proud of it!
About a year ago I had dinner in Cambridge with Martin Fowler. After some chit chat, he hit me straight up with a leading question which went something like "So what do you think of this whole Agile thing?" to which I replied something like "Well... I'm not doing anything different now from what I've always done..." and on the conversation went.
Jeff
Well said
Oh, I forgot to mention Mike that I think the last paragraph of your comment (about the four main values versus the entire manifesto and wordsmithing, etc.) is very well said indeed!
Jeff
Continuous delivery of valuable software - What value?
Mike
I think there is intrinsic value in delivering something monthly and it goes beyond risk reduction. MOntly delivery (via Scrum in my case) allows a team to get in a rhythm that speeds them up. It also builds up trust from our customer.This type of trust used to take 12-18 months to get; with Scrum I find we get in in 3-4 releases. After that the customer learns that we will deliver what we say each month.
I think you understate the point! Frequent delivery not only speeds up delivery, it substantially improves the quality of the delivery (versus say waterfall) IMO. I'll ignore in-the-small versus in-the-large issues here.
However I still maintain that Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. per se has, at best, close to zero business value. Frequently it has negative value! Implementing less than a planned 'whole' system commonly causes more business disruption than it is worth and these implementations only go ahead (in my experience) when sold as a temporary step towards the whole system. Excepting risk mitigation, continuous delivery of valuable software is an oxymoron. How much is half a bridge worth?
We as software developers see the benefits of iterative, frequent delivery and therefore assume it has direct value to the business. Assume is the wrong word in the prior sentence - its more like psychological projection! Ultimately the customer doesnt care how we deliver. Ever wonder how an elevator is built? I don't and I use one every day!
The problem is that software developers have such a dismal record of delivering (projects of any size and complexity on time, etc.) that we have serious credibility problems, and this distorts our perspective.
Phil
Frequent Delivery and Business Value
Hi Phil,
nice to see you back in form :)
I think part of the problem here is the notion that frequent delivery is equal to putting a partial working system in the hands of the customer. Perhaps it is the credibility problem driving this - to attempt to justify what's been done they throw a partial system at the users - and do it as often as they can.
But perhaps a factor is that in more extreme agile methods there is no planning up front, let alone design, so there really is nothing to report progress against. If the plan is "let's keep refactoring until someone yells stop" then how can you know where you are up to?
But we're really getting to the core difference between an iterative approach (where it's ok to rework previous code) and a truly incremental approach (where we build it once, and keep adding small pieces one at a time). An incremental approach requires a plan, an iterative one doesn't necessarily.
FDD is heavily biased toward an incremental approach: we aim to get it right the first time. Most other agile methods go in the other direction, but my impression so far is that the real reason is that they just don't want to tackle the requirement problem!
Requirements is hard - Parnas wrote an excellent paper that suggests we may never get it right. And so we've gone from "it's hard" to "ok, let's not do them"??? Somehow we've gone from the waterfall approach that said we must do them all at once up front and set them in concrete, to the other extreme where we're not even gonna attempt to figure it out before we start doing something.
Huh? This makes no sense!
Requirements and Agile/XP
Hi Mr S.
I agree with you that requirements are a hard problem, but I don't think it's an insuperable problem.
There are several aspects to the Requirements Problem! One is getting the requirements right! I think this is insuperable for reasons I have gone into at length at various times. One of the main reasons it's unsolvable is that implementing any system necessarily changes the requirements for the system. So you step back and treat requirements as a management problem, i.e. changing requirements are inevitable. To their credit XP (The Planning Game) and Agile endorsed approaches such as SCRUM deal with requirements as a management problem.
There is another aspect to requirements and FDD exploits this and is more-or-less unique in this respect. It can be explained as follows: Domain entities exist and have properties (behaviour) irrespective of any specific articulated requirement. These properties are externally constrained, i.e. beyond the control of those defining requirements and hence substantially immutable! This IMHO is the key to the importance of domain modelling. To take a simple example, an Order has properties, which an organization cannot change because the Order is the means by which the organization communicates with its customers.
I hear what you say about incremental versus iterative (in the sense of refactoring). I have had several run-ins with Ron Jefferies on this subject. Continuous refactoring is based on two unproven assumptions: 1. You can efficiently arrive at a model (all systems embed a model) through incremental refactoring. 2. There are no model discontinuities - What I mean by this is no nth requirement that breaks your model and requires large scale refactoring. In my view assumption 1 is empirically unproven and with good evidence that with systems of any significant scale it doesn't work. I consider assumption 2 naive at best and my personal experience is that model discontinuities are frequent and highly disruptive in the code stage.
Send me the Parnas link I'm interested.
pxbradley@excite.com
Dave Parnas article
The full title is "A Rational Design Process: How and Why to Fake it", and first appeared back in 1986, but it's also in his book from 2001 "Software Fundamentals".
D.L. Parnas and P.C. Clements. "A rational design process: How and why to fake it." IEEE Transactions on Software Engineering, SE-12:251--257, 1986.
http://www.aw.com/catalog/academic/product/1,4096,0201703696,00.html?type=TOC
How much is half a bridge worth
How much is half a bridge worth?
Depends on how you slice it. A (lengthwise) half-bridge gets you across the river. One that stops midway is less valuable.
A short comment on the Glass article
I read the, IMO far too long, Glass article and found little of interest in it! Its an apology for heavyweight processes!
Having said that, I agree with this conclusion The focus of methodological investigation should ..... be on determining, for each idea, what its area of best applicability is.
Glass presumes heavyweight processes to have applicability (in the sense of an advantage) relative to competing ideas/processes. He does this by invoking the law of the excluded middle - Agile doesn't apply therefore you must use a heavyweight process.
Phil
Agile principles
Hi Mike,
But, FDD doesn't strike me as "agile" in the same sense as all the other agile processse. I mean that entirely in the context of the real meaning of "agile" not in the buzzword meaning of agile as "something exciting, new and sexy."
Do you think you could expand upon that point? What do you see as the real meaning of "agile"?
I've always felt that the signers of the Manifesto accomplished an amazing amount by agreeing on the 4 main values. The principles they added do not always seem as consistent and I'm sure they were not as diligently wordsmithed to withstand the scrutiny they get.
Indeed, they did. The way the values are written belies the significant effort that must have been behind them. Obviously the principles have not received so much polish. However, for the unitiated (as well as the scholarly looking to compare and contrast), those points are just about all we have to go on as far as a community-sanctioned definition. Far from over-scrutinising them, I think much can be learned from studying them as is. The contents of that website is what the Agile community has decided to "put out there", so it stands to reason that this will affect how people analyse things.
Rather than dissect the principles, the above was merely an attempt to to explore how FDD mapped into them. It seems to me that this exercise alone has brought some interesting results. Maybe it will feed into something down the track that sheds more light on both FDD and Agile.
:: Gavin Baker -- http://antonym.org
Agile Principles
Alistair here... Nice site, by the way, and I'm enjoying reading the discussions...
Saw the references to the Snowbird meeting and the difference in quality between the 4 values and the 12 principles, and thought I'd add a personal historical note...
<<
I've always felt that the signers of the Manifesto accomplished an amazing amount by agreeing on the 4 main values. The principles they added do not always seem as consistent and I'm sure they were not as diligently wordsmithed to withstand the scrutiny they get.
Indeed, they did. The way the values are written belies the significant effort that must have been behind them. Obviously the principles have not received so much polish. However, for the unitiated (as well as the scholarly looking to compare and contrast), those points are just about all we have to go on as far as a community-sanctioned definition. Far from over-scrutinising them, I think much can be learned from studying them as is. The contents of that website is what the Agile community has decided to "put out there", so it stands to reason that this will affect how people analyse things.>>
You're right, there is a quality difference between them, and there are 2 morals to the story. The first is about the writing process, the second is about levels of agreement between the people.
In terms of the process: for the 4 values, we all sat in the room, at the whiteboard, for about 2 hours, meandering in and out, eating lunch leftovers, having side conversations, etc, with perhaps 4-6 people in front of the board at any time, but varying subsets. Discussing, ideating, etc. At some point something started to take shape, people did the normal thing - tossed in ideas, improved on them, etc. Totally unfacilitated (unlike the selection of the term agile, which was totally facilitated and took about an hour). After a shape was achieved, we went through it word by word as a group, more objections, ideas, changes, improvements. In the end, we could each happily sign our names to the entire thing.
The 12 principles didn't have such a luxury. People started aiming for their flights back, so we drafted what we could, and promised to settle the differences by email. Email - hah! You know what we think of that medium for shaping thoughts. The difference in quality in the 12 principles is primarily due to loss of face-to-face and moving to email. Slow, awkward, not everyone there, low feedback rates, etc. So with the time available and the emailing technology available, we did what we could. We commented on the difference instantly --- the 4 values were generated by Individuals and Interactions with rapid feedback and lots of face-to-face.
But even if we'd gotten the quality up, there wasn't the same level of agreement. Fact is, we differ in preferences on how to behave at the minute-to-minute level. And accept that. And those differences start to show up when moving from 4 values to 12 principles (and even more if we were to write 50 rules or whatever).
In my view (which Ron Jeffries won't say that he agrees with - but I'm not sure he'll say he disagrees, either), we agreed on 4 things:
1. At the lowest level of precision, the word "agile" captures the sense of what we're after.
2. At the second level of precision, the 4 values capture what we center on.
3. At the third level of precision, the 12 principles, we start to diverge, and can barely hold together on the 12 values. I know I only marginally agree with the wording of some of them, and what I find significant is that other people only marginally agree with ones I completely agree with, and when we went to change words, we wanted to change them in opposite directions.
4. At the fourth level of precision, project tactics, we won't agree. But we agreed to disagree --- that we share 1 adjective, 4 values and mostly 12 principles is already a lot. There's more than one way to skin a cat, as the saying goes, and lots left to discover about ways to develop software. So we don't sweat the differences, except when we're arguing with each other (case in point: in Japan, Kent Beck and I sounded so alike on stage, we could have been swapped at any point... from that altitude over the subject, we said nothing different. Between the two of us, we differ on many things, of course.)
Therefore, if FDD differs mildly at the 12 principles level, fine. And if the details of FDD look opposite some in DSDM or XP, also fine.
hope this helps --- Alistair
More perspectives...
Hi Phil,
You make some very interesting points. The first thing that struck me from your feedback was that it is probably more revealing to explore how FDD differs from the Agile way than how it is similar. My original take was to explore FDD in the context of the Agile principles, and see how FDD works as an instantiation of Agile (at least to a limited extent). There is clearly much more to explore here.
Early delivery per se has almost no business value! Most businesses would not deploy half a (planned) system even if they could. The real value of early delivery is risk mitigation.
It is certainly true that having a skeletal barely-functional system in the early phases has little business value, but I don't think the original intent was that it was deployed. I can think of several reasons to deliver early and often: testing, usability feedback, performance testing, and certainly risk mititation. I think it is misguided if the motivation is purely to "keep the customer happy" though. What they say they want is not necessarily what they need, nor is it always best for them. For example, so many customers want to see GUI screens in the first weeks of a system, even before proper design has been undertaken. This poses several risks; you have developers who should be doing real work wasting time fiddling around trying to get mockups ready, then you have customers who start thinking that the mockups equate to the final deliverable. Since screens are the only way most customers can visualise/conceptualise a system (ie. they typically don't think architecturally) they think this is the most important. I have seen this backfire, and I always prefer to use pencil and large sheets of paper to develop and present screen mockups. It is low tech, fast, easy to modify, and still manages to convey the essential points. Ironically enough, risk management (as I see it) would therefore be a primary motivator for this principle, yet most agile procseses seem to eschew RM as being too heavyweight.
The welcoming changing requirements part is a clear reaction to the cast-in-stone requirements syndrome of classical waterfall.
Indeed, but I think sometimes this can throw the baby out with the bathwater. It is well established that change is more expensive the further along the project you are. So IMHO welcoming change is inviting huge risk. It prevents the project from being well-defined, clearly scoped, and bounded in terms of time and cost. I presume that this "welcoming change" is where the "Agile" nomenclature arises; that it is nimble and adaptable to changing requirements. But to me this is just unnecessary risk; welcoming change is not the same as allowing for change. As a risk management exercise, during the analysis phases of FDD you idenfity areas of potential change and isolate them in the design, promoting loose coupling. This can allow for the change (which we all agree is inevitable to some extent) without losing all the precious advantages of having a bounded project.
However there is more to sustainable development than people. Lets call it the VB syndrome - rapid early development which quickly becomes unmaintainable software - frequently before any thing useful has been delivered. Domain modelling as practiced by FDD is one important way to avoid this situation.
Yes, I think we've all seen the hairballs that can result from such approaches. It's odd that while Agile is not incompatible with SDUF (shape design up front), as the dominant agile approach, XP once again seems to impose its anti-design approach on the rest. The idea that development consisting of constant refactoring, asymptotically approaching an implicit design curve, seems to me to be terribly inefficient. If adaptability to change is the core concern, this can still be taken into account with a good design. And a shape design on a whiteboard or even in a UML design tool is much easier to change (and iterate) than refactoring hundreds of lines of code.
""At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."" -- I also think this embeds a fundamentally untrue premise. Namely, a group of intelligent, knowlegeable people will spontaneously arrive at the right the solution to the problem.
I believe the original point is alluding to continual process improvement, which is something highly reminiscent of the heavyweight processes. But to call it that would not be 'extreme', so it seems 'a rose by any other name...' Of course there is the danger that by eschewing process, yet acknogledgeing process improvement is necessary, that people would not be leveraging the wealth of existing knowledge in "how to become more effective" beyond the above principles. By codifying best practice and integrating approaches that have demonstrated they can deliver, FDD has "built in" efficiency. That's not to say it can't be improved upon of course, and FDD does not explicitly address a number of important issues in the complete lifecycle. But it requires less reflection on effectiveness, and does not reply upon spontaneous solutions.
:: Gavin Baker http://antonym.org
Adaptability - design or code.
Hi Gav,
I think one of the points you make in passing is an excellent one:
If adaptability to change is the core concern, this can still be taken into account with a good design. And a shape design on a whiteboard or even in a UML design tool is much easier to change (and iterate) than refactoring hundreds of lines of code.
Thinking more about the differences between FDD and some other agile approaches this really is a fundamental point. We know that the higher the level of abstraction the more productive a developer is. With only a small subset of UML notation we have a simple, concise way to express designs.
So why choose code as the medium to express what we're doing? It takes much longer, is more error prone, no-one else can understand a partial imeplementation other than another developer, it's much more costly to change, and less productive.
Working code might be the only measure of real progress towards the final solution, but that doesn't make it the ideal way to express the solution.
Even if we could bang out code at the same rate (I'd hate to have to maintain it!), there are still several reasons why a UML design is more useful. It's concise. Users can understand it!
That's one thing that we've found from doing process 1 - develop an overall model - domain experts (i.e. users!!!) are okay with UML! And I've done this lots of times, on different size projects, with totally different types of domain experts from many different industries. Using just classes, associations, cardinalities and some attributes they have NO PROBLEM understanding class diagrams. Before we start process one we always do a brief introduction to the notation, but they pick it up very quickly.
Compared to paper requirements documents models have no "wriggle room", that is they're not open to interpretation. A "*" as a cardinality means something completely different to a "1", and it's clear what it means!
Involving the domain experts in process one gives us a shared model - one that everyone owns! It's no longer a case of "their" requirements vs. "our code" - there's just a shared expression of what the system needs to do. The spinoffs from this alone are amazing.
The Agile principles talk about involving users - but how much does each approach really do this? I mean the difference between just doing stuff vs. really participating. I can't think of being more involved than being part of the modelling and feeling a (very real!) sense of ownership of the resulting design. It's one they can understand, and can map any of the features back into quite easily. Rather than just being asked "tell me what you want, and I'll do some programmer magic, and you check out the results" they're now participating in the process.
And then in process 4 - Design by Feature - if we need more detail we go back to the domain experts and get clarifications. But we're still dealing with the same model as we started with (shapewise), but we just want more detail now. The domain experts not only participate in the initial shape modelling, they also present what's needed at the detail level. Often this is obvious (e.g. generate a unique number for an order), other times it's not (perform the interest calculations for a syndicated loan). We don't need them "on call" though - we've planned at least a couple of weeks ahead and can let them know ahead of time, just in case they need to do their own research (e.g. what are the 315 attributes, precisely, that we collect about a hotel that's put up as security on a loan?).
Communication is now at the level of the design - the object model. It provides a common terminology and context. As the development proceeds the model is refined, as we add attributes and methods, but it's still essentially the same shape as was arrived at in process 1.
The code is now just the realisation of the design. But isn't that how it should be?
Software development as knowledge transformation
I read an article a while ago that discussed the idea of software development as a form of knowledge transformation. I've been trying to dig it out from my archives, and I finally found it last night. Your comments reminded me of it, and I think it is worth raising here (otherwise I might forget!).
It is actually part of an excellent series of articles by Phillip Armour in Communications of the ACM, called "The Business of Software." The first article [1] argues that software is not a product but a storage medium for knowledge. He goes on to discuss how "the product is the knowledge that goes into the software". This is contrasted with other knowledge mediums; DNA, brains, hardware, books and now software. Software is unique in that it is active.
"There are only four places we can 'put' knowledge once we get it: we can leave it in our brains, we can build a hardware device, we can write a book, or we can develop software." [1]
"The product focus is so strongly entrenched that it causes us to release software that does not contain the correct knowledge in the mistaken belief that we are shipping a product. It causes us to design and build systems that, if they do contain the 'correct' knowledge, store it in such a contaminated way that it is impossible to reconstitute it from the code." [1]
Armour then goes on to provide seven pointers that are intended to improve the way we work with knowledge -- using models and language to manage the knowledge content of the domain in a usable form; structure the workplace to learn rather than build; set up a framework for knowledge acuqisition and dissemination (this is just like our KMS); training with an empahsis on domain, modeling and methodology; treat all activities as knowledge acquisition; and finally assign value to knowledge and manage it.
The second article [2] presents the Five Orders of Ignorance, where Armour argues that the process of software development is an exercise in knowledge acquisition and ignorance reduction, or more generally knowledge transformation.
I wish I could quote the entire article (it's a great read), but I'll provide just this snippet:
Imagine a hacking project. With hacking there is no real attempt to acquire knowledge first, the project just hacks code. As the code is written and executed (testing may be too strong a word) there comes a point where the validity of the knowledge in the code is checked somehow. This accomplishes two things: it identifies where the code is "correct" (the knowledge), and identifies what in the code is incorrect (what I call "unknowledge"). This unknowledge is often -- somewhat incorrectly -- considered to be defects. From a knowledge perspective, "unknowledge" is still knowledge; it just doesn't apply to this particular system. Coding continues by stripping out the "unknowledge" code and building on the "knowledge" code. [...] At the end of this hacking activity, having written a lot of code, we are left with mostly "knowledge" code. One could legitimately argue that if this system can successfully pass all the tests we can throw at it, it does ipso facto contain all the necessary knowledge. [2]
Armour continues on to make several further observations.
The Five Orders of Ignorance classify our knowledge about what we do and don't know. They are (in a very simplified form, read the articles for more detail, including [3]):
Once we step back and think of our development activities in this light, all of a sudden some of the things we have been doing make so much more sense.
The essential activity of a software developer is to take a problem and produce software to solve the problem. Thus they are transforming the knowledge in the problem domain into a representation of the problem domain enshrined in code, through a series of activities involving knowledge acquisition, interpreation, simplification, abstraction, and general transformation. But all too often the code is not an expression of the problem domain but an artefact of the transformation process. The code implies the solution.
Consider we are building a system to simulate water flow between catchment areas (a project I was involved in last year actuallly). We could either build a system that specifically simulates the Murray River, Darling Basin, the little creek that runs through the top of old Bob's Farm just south of Hayes Peak, and so on. And we could very efficiently code this all together and have a working system, and optimise the code by taking some shortcuts and using some assumptions we have about the particular problem. Or -- we could build a framework for describing catchment systems, modeling rainfall, land use and so on, and thus deliver to the client a way of describing the problem in terms of the problem domain. The latter is obviously the far more valuable solution (and the approach we took) as it permits the solution to be expressed in terms of the problem. The transformation thus does not suffer the loss of context and domain semantics.
One implication is that the code, the very thing we call the "product", is in a sense an artefact of the real work of knowledge transformation. And as such, it is in a sense inherently incomplete. Even very high level languages are limited in their expressive range; we always need to comment our code, because the code ultimately describes the what and not the why.
So relating back to your points about FDD and the shape model: FDD is designed to transform the problem domain into a representation (generally UML) being the high-level object model that provides a good common ground between the customer's problem and the implementation in code. The model can still capture high-level semantic information, and permits of sufficient declarative expressiveness that it does not obscure the knowledge it is trying to represent as a by-product of its codification.
Code that exists in isolation suffers from an implicit design, where it is attempting to converge back onto a hypothetical solution.
So when you talk about FDD using the domain model as a common ground for customer and developer alike, you have created a locus of knowledge, from which all code springs eternal. The knowledge acquisition process is enhanced through direct communication, collaboration and the expression of the problem domain in a fairly semantic-rich notation, and the knowledge transformation is enhanced because we are not shedding knowledge too early in the process, but feeding directly into latter processes. The refinement from process 1&2 through to the iterations during build, are designed to construct a knowledge path that is reversible. Since many other processes discard or fail to capture knowledge, the transformation is inherently one-way.
I fear I have raised too many points here that should be articles on their own, but I was on a roll :). Anyway, all this to say - I agree entirely!
:: Gavin Baker -- http://antonym.org
Agile and FDD
Scrum and XP implement the agile manifesto most radically. FDD's upfront analysis and design are "less agile", but another take on agile. I fully agree with the FDD approach its benefits. It is one of the good processes.
Ken Schwaber
Agile or agile?
I've not tried to apply FDD to the full manifesto in detail as people here are attempting to do. I think each person's comment in this thread has a point and there also things I can disagree with in most of the comments here.
FDD predates the Agile Manifesto. I was not the person who was there or proposed FDD or accepted it as Agile. Jon Kern was the person who put FDD forward and, I presume of course, that all the others at that "foundation" meeting accepted it as Agile - otherwise it would not be listed as one of the original Agile methods.
Having said that, I have mapped FDD against the four core values of Agile and I wrote a short paper on this here.
I do see a growing sense of Agile == XP and I don't think that's good for the Agile movement as a whole. I also see a growing sense that any design, even the minimal amount FDD does, described as too much and therefore is "heavy". I see the same "it has to be heavy" thinking in regards to class ownership.
Again, these things were known at the time FDD was blessed as one of the original Agile methods. Nothing about FDD has changed since then.
I think Jim Highsmith said it best in his book Agile Software Development Ecosystems.
"...But are these positions really so far apart? Jeff's guideline is to perform about 2-weeks of up-front "shape" modeling per six months of project time. So on a 6-month project, Ron Jeffries would start coding in week 1 and Jeff De Luca would start in week 3 - by the end of the first month, both would be continuously delivering features to the client every week or two. Differences? Yes. But I would offer that, in this case at least, the differences are secondary, particularly when compared to heavier methodologies in which abstract modeling can go on for months."
At the end of the day, I would refer people to my rule #1 on this site. If something else works for you - terrific! Keep using it.
We can all learn from each other and that is one of the main goals of this site. It's easy to fall into flamewars or post trolls. Try and establish the outcome of any submission you make here as "to educate those who visit this site." Before you click Submit - ask yourself that question. Is the primary purpose or outcome of my submission to educate those who visit this site?
Jeff