The five processes of Feature Driven Development (FDD)
explicitly mention six key project roles and implicitly suggest a
number of supporting and additional roles.
FDD was originally designed for a team of mixed ability
(although the average ability in the carefully chosen team was
still well above industry average because that is so woefully low),
mixed experience, mixed race (Singaporeans, Indians,
mainland-Chinese, plus a handful of Ang Mo's:Australians,
Americans, and Europeans) and mixed ages.
Few projects have the luxury to handpick all their team members
from the best in the industry. Most development teams comprise a
mix of ability, experience and background. and experience. We also
frequently work in less than ideal environments and have little
power to change them. So we have to make the best of what we
have.
Therefore, the FDD roles are designed, when combined with the
FDD processes, to organise a project so that individual strengths
are fully utilised and support is available in areas of
weakness.
It is important to always keep in mind that the roles are like
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. For example, in a
smaller team often the same person will play the chief architect
role and the development manager role. At other times a
master/apprentice relationship may be at work. For example, 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 perform the
day-to-day chief architect and development manager duties. On very
large projects a master/apprenticeship pairing may play each of the
roles.
The six key roles are:
- Project Manager: He or she is the administrative lead of
the project responsible for reporting progress, managing budgets,
fighting for headcount, managing equipment, space and resources
etc.
If the project is thought of as a system for building a piece of
software, then the FDD project manager role is that of an operator
and maintenance engineer for that system. Their job is is to create
and maintain an environment in which that system performs at an
optimal level of sustained productivity. In other words, they are
responsible for providing and maintaining an environment in which
their team can work productively and excel. An FDD project manager
is there less to force the team to work and more 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
allocations and other resourcing constraints.
- Chief Architect: He or she is responsible for the
overall design of the system. In FDD, although the Chief Architect
has the last say he or she is essentially responsible for
facilitating the design of the system through collaborative working
sessions. They are not an elite designer who single-handedly
produces the whole system design in glorious detail for other mere
mortal members of the team to implement and test. They are,
however, responsible for guarding the conceptual integrity of the
design as a whole ensuring individual feature designs do not
compromise it. This is a deeply technical role requiring excellent
technical and modelling 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.
- The Development Manager has the ultimate say on the
day-to-day developer resourcing conflicts within the project and
steers the team through potential resource deadlock
situations.
The Development Manager is responsible for leading the usual
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.
- 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. The team works
collaboratively on the analysis and design for each feature. The
Chief Programmer facilitates this work but also makes the final
call if the team cannot decide between between two options.
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.
In comparison with Scrum, a Chief Programmer covers the scrum
master role for a feature team because they lead the team in
applying the design by Feature and Build By Feature activities. The
Chief Programmer also owns his backlog of features to be developed
so the role also encompasses some of the prioritising work of the
product owner role in Scrum. The chief programmer can draw on
domain experts to cover the other aspects of the Scrum Product
Owner role. The Chief Programmer role also is also ultimately
accountable to the other Chief Programmers on the project for the
design and quality of the code that is delivered by their feature
teams.
The chief programmer role is critical to the success of an FDD
project, and it is also the means by which FDD scales so easily to
projects with team-sizes larger than single figures.
- 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 flavours
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. Some of the
best class owners I have known have turned up at 9:00am every day,
participated fully in the collaborative activities of feature
teams, produced high-quality code in every sense of the word, and
gone home at 5:00pm every day to enjoy their life outside of
work.
- 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
organisations have a centralised IT team that provides a generic
service; the toolsmith writes tools that are specific to their
project. It is often 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 organisations 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 Coad Letter
newsletter.