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 (macfelsing@mindspring.com ) 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.

Have fun

Steve

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 book is:

Streamlined Object Modeling: Patterns, Rules, and Implementation
by Jill Nicola, Mark Mayfield, Mike Abney, Michael Abney (published by Prentice Hall)
ISBN: 0130668397

pps pps Exciting news for those in Japan: Togethersoft Opens Tokyo subsidiary, sponsors first-ever Japan JavaOne conference and announces plans to localize product ( www.togethersoft.com



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:
  • 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 the project.

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

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

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 says:

“…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 nature.”

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 phenomenon.’”

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…
  • 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.
…otherwise it would be a dreadfully dreary industry to work in.

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.

Individual Productivity

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

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

…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 average.
 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 deadlock situations.

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.

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


References

  • 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 Hall PTR
  • Tom Fairley, Software Engineering Concepts,  McGraw Hill
  • Gerald Weinberg The Psychology of Computer Programming, Dorset House

Published on: 3/14/2002 12:00:00 AM

Server Response from: ETNASC01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.