Feature Driven Development defines six key project roles and implicitly suggests a number of supporting and additional roles.

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:

  1. 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.

  2. 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.

  3. 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.

  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. 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.

  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 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.

  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 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.

Follow me on Twitter...