The Coad Letter: Process Edition, Issue 85, Feature Driven Development - Projects and People, by Stephen Palmer
By: Coad Letter Process Editor
Abstract: The temptation when designing a process or managing a project is to treat people as if they are no more than "resources".
One of the fun things about working for a rapidly growing company like
TogetherSoft is that things are constantly changing as the company outgrows
procedures, processes, and techniques. One of the relatively few constants
of the Coad Letter over the years has been Frank Baker. Frank and his team
have diligently checked each Coad Letter issue before ensuring the issue is
correctly sent out to subscribers. This has saved contributors like myself
many times from embarrassing ourselves with bad typing errors. With last month's
upgrade in mailing servers, the marketing department has taken on this task
of proofing all items sent out on mailing lists. Therefore, I'd like to take
this opportunity to acknowledge and thank Frank and his team for their valuable
contributions behind the scenes of the Coad Letter.
Back to this month: here's a draft version of a large chunk from chapter
2 of A Practical Guide to Feature Driven Development, the book that Mac Felsing
) and I are writing. The first part of the chapter deals with the hardest
component of any non-trivial software development effort, the people involved.
The second part of the chapter examines the roles played by people in a Feature
Driven Development project.
ps As reported last month, the FDD book is part of a new short series
of books published by Prentice Hall. Peter Coad is the series editor and
the first book in the series is already available. Two of its authors, Jill
Nicola and Mark Mayfield, are previous co-authors of Pete. The new
Streamlined Object Modeling: Patterns, Rules, and Implementation
by Jill Nicola, Mark Mayfield, Mike Abney, Michael
Abney (published by Prentice Hall)
pps pps Exciting news for those in Japan: Togethersoft Opens
Tokyo subsidiary, sponsors first-ever Japan JavaOne conference and announces
plans to localize product (
From Chapter 2 of A Practical Guide to Feature Driven Development
Feature Driven Development - Projects and People
A software process must function within a context. That context is
a software development project. Any project of any sort is little more than
a collection of activities, resources, and communication channels, with
at least one specific purpose or goal to achieve within a time frame. However,
this is a very general definition and could define a project for building
a bridge, constructing an ocean liner, or landing a mission on mars. Therefore,
more specifically, what are the components of a software development project?
They certainly include:
The statement of purpose does need to be sensible. It is nonsense to define
a statement of purpose for a project that is not achievable within a reasonable
time frame. For very ambitious programs, it is often better to identify
several projects that can be run concurrently or as follow-on efforts. As
we’ll see FDD supports this need very nicely indeed. The statement of purpose
may also start off somewhat vague. Chapter seven suggests a useful exercise
to help refine the statement of purpose.
- Some statement of purpose, problem statement, or list of goals
or very high-level requirements describing what the system needs to do.
Without this there is no reason for the project to exist.
- A list of the roles that people play on the project. When written
down, this usually takes the form of an abstract organization chart. Each
different role requires a set of skills and a level of experience. Each
role defines responsibilities and accountability.
- People with the requisite skills and experience to play the roles
in the abstract organization chart. Assigning people to the roles within
the abstract organization chart produces a concrete organization chart for
- A set of well bounded processes describing how these people playing
their roles interact with each other to produce the desired software system.
- A set of technologies; programming languages, development tools,
ready-built components, modules and products.
- An architecture, a framework within which to construct the software
system. The project may reuse an existing architecture. Alternatively an
appropriate framework may not exist and one of the first activities of the
project needs to produce and prove the architecture.
The list of roles of a project team is like the players’ positions in a
sports team or the parts in a play or symphony. We need the software development
equivalent of players, actors and musicians to cast in those roles.
The processes describe the rules of the game, the acts of the play or the
movements in a symphony. They describe the framework through which all work
The technologies are the players’ equipment, the props used in the play
or the musicians’ instruments.
Likewise the architectural framework is the marked pitch, playing area
or the stage and scenery.
The Big Three
Coaches of sports teams are often spoken of as using a particular system,
theatrical directors and symphony conductors too. Lets consider a software
development project as a system, a system for creating software. If a project
is a system for building software, then the three biggest components of
that system are people, process and technology. Technology is obviously
important and so is process but it really is all about people.
Jeff De Luca’s (www.nebulon.com) first
law of information technology states:
“I.T. is 80% psychology and 20% technology”
In the anniversary edition of his book, The Mythical Man-Month, under a
section entitled ‘People Are Everything (Well, Almost Everything)’, Fred Brooks
“…the quality of the people on a project, and their organization and
management, are much more important factors in success than are the tools
they use or the technical approaches they take.”
The underlying thesis of Tom De Marco and Timothy Lister’s famous book,
Peopleware: Productive Projects and Teams, is:
“The major problems of our work are not so much technological as sociological
In Luke Hohmann’s book, The Journey of the Software Professional, we read
“Although technology is important, Jim McCarthy got it right when
he said: ’I see software development as primarily a sociological or cultural
Tom Fairley, in Software Engineering Concepts writes:
“Software project managers must be effective in dealing with the factors
that motivate and frustrate programmers…”
Finally Gerald Weinberg thought it important enough to write a whole book
called, The Psychology of Computer Programming.
Our own experience certainly does not disagree. Software development really
is all about people. If it were not, it would be much, much easier.
Process and People
The temptation when designing a process or managing a project is to treat
people as if they are no more than ‘resources’. Many traditional project
management tools unfortunately encourage this sort of thinking. It’s as if
the people in project teams are interchangeable, consistent, logical, software
producing machines but thankfully…
…otherwise it would be a dreadfully dreary industry to work in.
- People are emotional.
- People are fallible.
- People get tired.
- People get sick.
- People are all different.
- People are creative.
- People are innovative.
- People are resourceful
- People can be inspired
- People change, as they grow older.
- People have lives outside of work.
- People leave for one reason or another.
So to be successful, unless it is to be used only by extra-terrestrials,
our software development process needs to take into consideration the peculiarities,
strengths and limitations of human beings.
To make things even more interesting, some human beings are much more productive
than others. Results vary in the exact quantities but study after study
has shown that good developers can be between 10 and 20 times more productive
than poor developers (see almost every book in the References section for
Do the maths! Let’s say we hire four good developers instead of eight average
developers. Even if the good developers are only four times more productive
than the average developers and we have to pay the good developers twice
as much as the average developers, we are still twice as productive for the
…and we have not even considered the reduction in communication and coordination
headaches from managing half the number of people, the reduced cost of hardware,
software, furniture, and office space, etc.
If you staff a team with great people, the process and technology should
take care of themselves. It is not that great people do not need a formal
process or do not use process. No, a good team will create a process if
a useful one does not exist or tailor an existing process to fit. They know
they need a process and will therefore put one in place. They will also
select appropriate technologies and use them well. This is part of what
makes them great people.
OK. I’m sold! Where do I find these amazing developers? Ah! … The problem!
Great developers are not easy to find and how do you tell the good from
The big challenge is to attract good developers, recognize them and
then to keep them; after all there is little point in going to all the effort
of finding them if they are not going to want to stay.
The Roles People Play in Feature Driven Development
The reality of life is that we are members of development teams of mixed
ability and experience from varying walks of life. We work in less than
ideal environments and often have little power to change them. So we have
to make the best of what we have.
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 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 system, the project manager’s
job is to create and maintain an environment in which that system works best,
in which his or her team can work productively and excel. Part of that role
involves shielding the development team from distractions by forces external
to the project. Think of the project manager as operating the deflector
shield on the front of Star Trek’s USS Enterprise so that the project team
behind can go about their work safe from random elements floating in their
direction. Random elements like over zealous CTO’s or clients wanting to
visit the team at a crucial moment in the project, Human Resources wanting
a new form filled by everyone and wanting it done today, building maintenance
scheduling a fire-drill three days before a major milestone, the IT department
wanting to do a stock take of the project’s personal computers and printers,
upper management deciding to restrict internet access to a chosen few, an
exotic new requirement request and so on. An FDD project manager is there
not to force the team to work but to enable them to work.
The project manager has the ultimate say on scope, schedule and staffing
levels within the project. He or she steers the project through the administrative
and financial obstacles confronting the project.
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 responsible for running workshop design sessions where the team collaborates
in the design of the system. 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. 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 chief architect has the last say on all design issues. He or she steers
the project through the technical obstacles confronting the project.
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.
3. The Development Manager has the ultimate say on developer resourcing
conflicts within the project and steers the project through potential resource
Note: Remember these are role definitions and one person can play multiple
roles at once and vice versa. It is very common to see these three roles
shared by two people. 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.
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. Self-driven to produce quality results on time, chief
programmers combine great technical ability with enough people skills to
lead small teams to produce results every few days. Other typical characteristics
of a chief programmer are that they are trusted and respected by both their
managers and fellow developers, are determined to make the team succeed and
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 and other
important characteristics include seemingly infinite patience and endless
enthusiasm about the promise of the new system.
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.
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
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
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
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.
- Fred Brooks, The Mythical Man-Month, Addison Wesley
- Tom De Marco and Timothy Lister, Peopleware: Productive Projects
and Teams, Dorset House
- Luke Hohmann, The Journey of the Software Professional, Prentice
- Tom Fairley, Software Engineering Concepts, McGraw
- Gerald Weinberg The Psychology of Computer Programming, Dorset
Published on: 3/14/2002 12:00:00 AM
Server Response from: ETNASC01