Feature Driven Development Roles
Feature Driven Development defines six key project roles and implicitly suggests a number of supporting and additional roles. The FDD roles when combined with the FDD processes organize a project so that individual strengths are fully utilized and support is available in areas of weakness. The roles are hats that are worn. In some projects some people may share the wearing of a particular hat, in others a person may wear multiple hats. Although this might conjure up some interesting mental images, the fact remains that roles can be split between people and people can play multiple roles on a project. Often the same person will play chief architect and development manager. At other times a master/apprentice relationship may be at work with one person playing the majority of the project manger role, a high level chief architect role, and mentoring/training another who gets to do project management tasks on occasions, and play chief architect and development manager on a day to day basis. On very large projects a master/apprenticeship pairing may play each of the roles.
The six key roles are:
1. The Project Manager is the administrative lead of
the project responsible for reporting progress, managing budgets,
fighting for headcount, managing equipment, space and resources etc.
As operator and maintainer of the project as a system, the project
manager’s job is to create and maintain an environment in
which that system works best, an environment in which his or her team can work
productively and excel. An FDD project manager is
there not to force the team to work but to enable them to work. He or she steers the project
through the administrative and financial obstacles confronting the
project. The project manager handles things like budget predictions and allocations, staffing alloactions and project headcount.
2. The Chief Architect is responsible for the
overall design of the system. Although the Chief Architect has the last
say, in FDD he or she is more responsible for facilitiating the design
of the system through collaborative working sessions. This
is a deeply technical role requiring excellent technical and modeling
skills and also good facilitation skills. The Chief architect resolves
disputes over design that the chief programmers cannot resolve
themselves. The chief architect has the last say on all design
issues. He or she
steers the project through the technical obstacles confronting the
project. For projects with both a complex problem domain and
complicated technical architecture, the role may be split into Domain
Architect and Technical Architect roles.
3. The Development Manager has the ultimate say on
developer resourcing conflicts within the project and steers the
project through potential resource deadlock situations.
The Development Manager is responsible for leading the day-to-day
development activities. A facilitating role requiring good technical
skills, the development manager is responsible for resolving everyday
conflicts for resources when the Chief Programmers cannot do it between
themselves. In some projects this role is combined with the Chief
Architect or Project Manager role.
4. Chief Programmers are experienced developers
that have been through the whole software development lifecycle a few
times. They participate in the high-level requirements analysis and
design activities of the project and are responsible for leading small
teams of 3-6 developers through low-level analysis, design and
development of the new software’s features. Chief Programmers
also work with other chief programmers to resolve day-to-day technical
and resourcing issues. Motivated to deliver high quality results on time,
chief programmers combine great technical ability with enough people
skills to lead small teams producing results every few days. Trusted
and respected by both their managers and fellow developers, they are
determined to make the team succeed. They usually live the work.
5. Class Owners are developers that work as members
of small development teams under the guidance of a chief programmer to
design, code, test, and document the features required by the new
software system. Class owners come in two stereotypical flavors and a
myriad of shades in between; they are often talented developers who,
with more experience, will become able to play chief programmer roles
in the future, or they are talented developers who are content to be
master programmers and want nothing to do with leading or managing
other people.
6. Domain Experts are users, clients, sponsors,
business analysts or any mix of these. They use their deep knowledge of
the business to explain to the developers in various levels of detail
the tasks that the system must perform. They are the
knowledge base that the developers rely upon to enable them to deliver
the correct system. Domain experts need good verbal, written, and
presentation skills. Their knowledge and participation is absolutely
critical to the success of the system being built. Other important
characteristics include seemingly infinite patience and endless
enthusiasm about the promise of the software.
Supporting Roles
For larger teams the Domain Manager leads
the domain experts and is responsible for resolving differences in
opinions about requirements. In a small project this role is often
combined with the Project Manager role.
The Release Manager represents someone fussy
enough to ensure Chief Programmers report progress each week. They are
thorough, ensure planned and actual dates are all entered properly, and
charts are printed and distributed correctly. The release manager
reports directly to the Project Manager. The name for the role comes
from a regular, short progress meeting where Chief Programmers report
on what has been ‘released’ into the build since
the last meeting. The role is analogous to the Tracker role of Extreme
Programming, and Scrum Master in Scrum. The Release Manager may combine this role with a more
general administrative assistant role to the Project Manager.
A Language Lawyer or Language Guru
is a person who is responsible for knowing a programming language or a
specific technology inside out. This role is especially useful on a
project where a programming language or technology is being used for
the first time and is often played by a consultant brought in for the
purpose. Once the team is up to speed with the language or technology
this role can be reduced until it disappears altogether.
The Build Engineer is responsible for setting up,
maintaining and running the regular build process. This includes
managing the version control system, publishing any generated reports
or documentation, and writing any build or deployment
scripts. On larger projects, the version control manager or
configuration manager may be a separate role, or possibly part of
another department.
The Toolsmith creates small development tools for
the development team, test team, and data conversion team. Where
necessary this may include setting up and managing a database and
website that acts as the team’s knowledge repository. Many
organizations have centralized IT team that provides a generic service;
the toolsmith writes tools that are specific to their project. It is a
role that a fresh graduate or junior programmer can play.
The System Administrator configures, manages and
troubleshoots any servers and network of workstations specific to the
project team. This includes the development environment and any
specialized testing environments. The System Admin is also often
involved in the initial deployment of the system into production.
On small systems, a single person may play all three of the Build
Engineer, Toolsmith and System Engineer roles. In larger
teams multiple people may play each of these roles and the System
Administrator role may be split into Server Administrator,
Network Administrator, and Database
Administrator.
Additional Roles
There are three more obvious roles required in any project:
Testers are responsible for independently verifying
that the system’s functions meet the users requirements and
that the system performs those functions correctly. Testers may be part
of the project team or part of an independent QA department.
Deployers convert existing data to the new formats
required by the new system and work on the physical deployment of new
releases of the system. Again the deployment team may be part of the
project team or part of some sort of Operations and System
Administration department
Technical Writers write and prepare online and
printed user documentation. Technical writers in some organizations
will have their own department that services all projects.
Chapter 2 of A Practical Guide... covers each of these roles in a little more detail. An early version of this material also appeared as an edition of the CoadLetter newsletter in 2001.