Presentation about FDD (Feature-Driven Development) for the "Alles Ausser Scrum" conference in Cologne, Germany, on 5th April 2019

1. Feature-Driven
Development
Adail Retamal
Software and Systems Engineer
@heptaman
Frequent, tangible, working results
ALLES AUSSER SCRUM
Ganztägige Unconference
5 April 2019 - Köln

2. Methodologies Timeline
Non-exhaustive list

3. True story!
• 1997-1998, Singapore
• Context: A big Java project for a new lending system for a
major international bank
• Previously, after 2 years of consulting, 3,500 pages of use
cases and other specs, and a domain model with hundreds
of classes, the project was considered impossible
• Decisions:
• Jeff De Luca as Project Manager
• Peter Coad as Chief Architect (OOAD method and UML in Colour)
• Results: after 15 months, 2,000 features delivered by a team
of 50 people!

4. FDD: People and Books
Jeff De LucaPeter Coad
Stephen Palmer John Mac Felsing
David Anderson

5. FDD: Birthplace
United Overseas Bank HQ David Anderson, the GUI-Man
Peter Coad and
the Domain Team
Paul Szego and
Stephen Palmer
Jeff De Luca and the
Development Team

6. FDD: Main Benefits
• Enough structure for bigger teams
• Emphasis on quality production software
• Frequent, tangible, working results
• Meaningful upfront work before becoming highly
iterative (invaluable for fixed-price contracts!)
• Simple and meaningful progress and status reports
• Common language and mindset across customers,
managers and developers

7. Do Bit by Bit
Think A Bit
Construction
Startup
FDD: Lifecycle
More content in shape
More shape than content
Domain
Model
Work Packages
Product
Requirements
Development
Plan
Progress Reports
Develop
an Overall
Model
1
Build
Features
List
2 Planning3
Design by
Feature
4
Build by
Feature
5
FBS

8. FDD: Roles
Project
Manager
Chief
Architect
Domain
Specialists
Development
Manager
Chief
Programmers
Class
Owners

9. FDD: Best Practices (Then and Now)
• Domain object modelling
• Development by feature
• Situational class/code ownership
• Feature Teams
• Inspections
• Regular builds
• Configuration Management
• Simple and meaningful progress reports
à UML in Colour à DDD
à User Story à Full Stack Slice
à Pull Request
à Spotify organisation (~ Squads, Guilds)
à Design & Code Reviews à Automated Testing
à Git à CI/CD à DevOps
à Kanban

10. Domain Neutral Components (DNC) or
Archetypal Domain Shape (ADS)
<<mi>>
Moment_Interval
Status
ID
StartDateTime
FinishDateTime
…
AddDetail
Complete
Cancel
ComputeAmount
…
<<mi-detail>>
MI_Detail
Order
Quantity
…
ComputeAmount
…
<<role>>
Role
Status
ID
PerformanceIndicator
…
EvaluatePerformance
AvailableInThisRole
…
<<party/place/thing>>
Party_Place_Thing
SerialNumber
Name
Address
…
IsAvailable
EvaluateAcrossRoles
…
<<description>>
Description
ID
Description
DefaultValue
…
ComputeAvailableQty
ComputeAmountForQty
…
0..*1
0..*
0..11
0..*
1

11. UML in B/W
Room
ID
Status
Guest
Score
LastVisit
Hotel
Name
Address
Stars
Person
Name
SSN
Phone
Stay
Start
Finish
TotalAmnt
*
Employee
StartDate
ID
*
*
Service
Date
Time
Amount
*
RoomType
Description
SingleQty
CoupleQty
Smoker?
*

12. UML in Colour
Room
ID
Status
Guest
Score
LastVisit
Hotel
Name
Address
Stars
Person
Name
SSN
Phone
Stay
Start
Finish
TotalAmnt
*
Employee
StartDate
ID
*
*
Service
Date
Time
Amount
*
RoomType
Description
SingleQty
CoupleQty
Smoker?
*
The Power of Archetypes!

13. FBS: Feature Breakdown Structure
System or
Application
Business Area Business Area Business Area
Business Activity
Business Activity
Business Activity
Business Activity
Business Activity
Business Activity
Business Activity
Business ActivityFeature
Feature
[Xyz] Management
<Noun>
<Verb In The Infinitive> ...
<Action> <Result> <Object>

14. Feature Team
• Dynamically formed
• Under the lead of a Chief Programmer
• Appropriate to the situational code ownership
• Multiple minds designing
• Compare among alternatives and select the most
appropriate
• Members are the relevant Class Owners
• Emphasise team work
• No one finishes until the Feature Team finishes

15. Progress Report: Proto-Kanban
• During the iterative cycles (process #4 and #5) progress is measured
according to well defined milestones (6 in the original definition)
• When each milestone is reached its respective percentage is aggregated to
the total progress of the feature (kind of earned value)
Domain
Walkthrough
1%
Design
40%
Design
Inspection
3%
Code
45%
Code
Inspection
10%
Promote
to Build
1%
#4: Design by Feature #5: Build by Feature
DOM BFL PBF
DBF BBF

16. The Parking Lot Report
Key: Not started In Progress Attention Complete
Sales Management (SM) – 34%
Purchase
Orders
(33)
Jul 2019
CP-1
Contract
Management
(13)
Oct 2019
Product
Selling
(22)
Mar 2019
CP-1
Product
Shipment
(19)
Oct 2019
CP-1
10%
Product
Delivery
(10)
Sep 2019
CP-3
30%
Sales
Reports
(14)
May 2019
75%99% 3%
Customer Account Management (CAM) – 90%
New Account
Proposal
(23)
Feb 2019
95%
Account
Transaction
Records
(30)
Mar 2019
82%
New Account
Opening
(11)
Dec 2018
100%
Stock Management (SM) – 94%
SKU
Management
(26)
Dec 2018
100%
Stock
Reconciliation
(19)
Feb 2019
82%
CP-3
SKU
Movement
(18)
Jan 2019
97%
CP-3
CP-2 CP-1
CP-2 CP-2 CP-2 CP-3
Commercial
System
(238)
Nov 2019
65%
Current Date:
05-Mar-2019

17. CFD: Leading and Historical Indicator
Cumulative Flow Diagram
Key:
Not Started
In Progress
Complete
Time (weeks)
Features
Lead Time
Work in ProgressProduct Backlog

18. FDD to the Rescue
8. Product Increment
(potentially shippable)
6. Daily
5. Iteration
(2 - 4 weeks)4. Tasks
detailed
by the team
1. Vision
(ROI, milestones,
releases)
2. Product Feature Backlog, prioritized
by the Product Owner
3. Iteration
Backlog
7. Standup
Meetings
Startup
1
DOM
3
PBF
2
BFL
Construction
4
DBF
5
BBF
9. Inspect
and Adapt

19. FDD: Where to Learn More
• A Practical Guide to FDD (the book)
• Excerpt chapter 3 “Integrating Best Practices”
• www.featuredrivendevelopment.com
• FDD @ Nebulon (Jeff’s old company)
• Stephen Palmer’s STEP-10 Blog
• Software Engineering Radio: Jeff De Luca on FDD
• FDD on Wikipedia

20. Thanks and Q&A
Adail Retamal
@heptaman
linkedin.com/in/adail