This article looks to discuss Feature-Driven Development within Agile projects. Focussing on Feature-Driven Development, the article looks to discuss how Feature-Driven Development can interact with the different Agile Frameworks.
The Agile Fundamentals
A 59 Seconds Agile Video Animation
Feature-Driven Development & Agile -Part 2
A 59 Seconds Agile Article
Feature-Driven Development & Agile Scrum
In July 2016, Scrum also came up with its own set of values:
- Courage (not being afraid to do the right thing and work on tough problems)
- Focus (focusing on the Sprint goal and Product Vision)
- Commitment (personally committing to the Scrum Team goals)
- Respect (trusting and respecting all team members to be independent and capable)
- Openness (agreeing to stay open to work and its challenges)
Scrum can be used in any form of product development and is best used for emergent projects that can prioritize and deliver work in batches.
Initially designed for a banking client, Feature-Driven Development (FDD) is a framework that focuses on client needs as well as the architecture of the product. Teams who use FDD first come up with models of the product, then create a feature list – somewhat like a Product Backlog in Scrum – based on the models. Planning and designing are done per feature, and once a feature has passed inspections and unit tests, the FDD team will proceed to build it.
An FDD team is made up of the following roles: Project Manager, Chief Architect, Development Manager, Chief Programmer, Class Owner, and Domain Expert. Unlike in XP, classes are assigned to different individual developers, who will own that particular class and will collaborate with other Class Owners when a feature will be comprised of several classes. Other roles included in the team are testers, technical writers, language gurus, domain manager, build engineer, deployer, and release manager.
Feature-Driven Development and Product Delivery
FDD delivers features every two weeks. If anything is deemed to take longer than that, then that feature must be further broken down into more features. Documentation, quality control, and employment of strict processes are heavily important in FDD, making it appropriate for projects that require process maturity.
Feature-Driven Development & The Agile Crystal Framework
The Crystal Framework that centers on people and their interactions as they go through software development together. It is also called “Crystal Family”, as it covers smaller agile frameworks: Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond and Crystal Sapphire.
The different Crystal frameworks are differed by the following characteristics: team size, system criticality, and project priorities. And depending on the system criticality, a project will be categorized into the following levels: Comfort (C), Discretionary Money (D), Essential Money (E), and Life (L). Team size and team roles will depend on the project size.
The following describes this agile framework as the following:
- Human-powered – Crystal works on the assumption that teams are capable of streamlining and optimizing processes, and that therefore, people are the most important aspects of a project.
- Adaptive – Crystal does not have a set of prescribed tools and techniques, and approaches will depend on the project nature and needs.
- Ultra-light – Crystal focuses on building a functioning product with business value more than documentation, reporting, and management.
Crystal is one of the most flexible agile frameworks and recognizes that each project is unique, and should have processes tailored to the people who are part of the project.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.