Joel is doing a talk on Feature Driven Development. I had never heard the term so thought it might be good to check out.

-First appeared in 1999 (Java Modeling in Color with UML)
-A process to deliver frequent, tangible, working results repeatedly
-Book has 30 pages of process and the rest are examples (book is: "A practical guide to feature driven development")
-Characteristics:
    -Highly iterative (1-2 weeks long usually)
    -Emphasizes quality at each step
    -Delivers frequent, tangible, working results
    -Minimum overhead and disruption
-Developers get constant feedback and a fast velocity
-Clients like is because they get results early and often as well as highly visible status reporting
-Managers like FDD because it gives an accurate picture of progress and status
-FDD is a balance between the heavy (large volumes of text) and light (none?) process
-Joel made a fun parallel stating that Agile = Hippies. Screw the man and walls and process lets just hang out and code man
-Heart and soul of FDD is communication, complexity, process pain and relief, and quality
-A feature is from the lense of a customer. It is a requirement that will bring value to a user or client. (I missed the naming convention for this but I am sure Google will help)
-Features are small (able to be implemented within an iteration)
-If a feature is larger then decompose it.
-If a feature is too large then it serves as a litmus test that your grand scheme is too big.
-Everything you write should be consumed (i.e. code is consumed by the compiler). Process is usually consumed by no one and is therefore useless.
-Group similar features into a feature set. Naming convention would be actioning deliverable (i.e. approving a bank loan)
-feature sets are grouped into sections (i.e. bank loans would have approving a bank loan and canceling a bank loan feature sets within it)

Practices
-Domain Object Modeling
-Develop by Feature
-Individual class/code ownership
-Feature Teams (one team implements one feature set)
-Inspections (forced inspection and review of code, domain, and architecture)
-Regular Builds
-Configuration Management (missed this point apparently)
-Reporting/Visibility of Results
-Feature->Work decomposition model (Now that I have work how do I break that down to tasks to do the work)

Process
1. Develop an overall model
2. Build Feature List
3. Planning
4. Design by feature
5. Build by Feature (return to step 4 for next feature)

Joel has gone onto breaking this down in more detail but I have missed a bit due to phone calls unfortunately. This does seem like a really valid methodology that adds some simple process to help keep you on track.

-The talk has now broken into FDD in team system so I am going to zone out for a bit as I don't see having team system for a long time. I will have to look into FDD more though as it seems to be fairly balanced in its ideas.