Teams and Communications

Almost all software is created by a development team. The size and complexity of the system and the time allowed for development are usually the basis on which the team is assembled and staffed. It's important to get the right mix of team members for the project and to insure that all team members can work together.

The first step to take in creating a team is to analyze and understand the roles and responsibilities of team members. The members of the team are then selected and assigned duties to fulfill the various roles. Some projects may not need all team roles to be filled. The team manager will have to determine who is needed and when. Cost and time constraints will also affect selection of the team members.

Roles and Responsibilities

Each member of a software development team has one or more roles that they fulfill. Each role defines a set of responsibilities. A team member may take on more than one role and may even change roles over the course of the project. It is not unusual in small teams for one person to be architect, designer and coder. Likewise, the team manager may also be technical lead and customer advocate. Roles are not the same as job titles either. Whatever the person's job title, the roles he fulfills may vary considerably. Multiple team members may also fill a role. For example, most teammembers will be coders at some point in the project.

In larger organizations, one person may take on the same role for multiple teams. This is often the case for analysts, specialists, architects and technologists. These roles are most important early in the project, or are only needed for a short time during the project's schedule. Once the project is further along, their responsibilities and workload declines allowing them to concentrate most of their effort on new projects.

The names given below are commonly used. We don't have unique names for software developers and thus usually borrow names from other fields. However, the names have specific meanings in software development and shouldn't be confused with the use of the name in other fields.

The order given below is not intended to indicate importance. Roles will have different levels of importance depending on the specific project's needs. For example, a maintenance project may have little need for an architect or designer, but will rely heavily on coders and testers.

Role Responsibility
Architect The architect is responsible for the overall system design and integrity. The architect creates the system structure, defines the top most components and the interfaces between them, and chooses the appropriate technology.
Designer The designer is responsible for one or more modules in the system. The designer creates the software model for the module and chooses the appropriate data structures and algorithms.
Coder The coder creates program code to implement the design.
Technical lead The technical lead is the team member responsible for making technical decisions. Often team members will disagree on an approach. The technical lead is the final arbiter of the choice.
Analyst The analyst studies user requirements and converts them into software functions. The analyst must understand the users' systems, processes and knowledge so that he can choose the appropriate software functions.
Specialist The specialist has expert knowledge of a special area such as database, UI, communications, etc.
Technologist The technologist studies new developments and directions in computer technology and provides insight to the team as to how the technology can be best applied.
Tool builder The tool builder constructs software tools that assist the other team members in their work. This may include special utilities and libraries. A good software tool is the most difficult type of software to create. If mistakes are made, they propagate throughout the system. The tool builder must have extensive experience and a highly developed abstract thinking ability.
System Builder The system builder has the responsibility to collect all the code and libraries into one place and insure that a working system can be built from them. This role is arguably the most critical role of all for software product development. If you can't build the system, you've got nothing to show for all the team's efforts.
QA designer The QA designer develops test plans, test code, and test data for the system.
Tester The tester performs tests on the software using the test plan developedby the QA designer.
Team manager The team manager is responsible for team coordination, scheduling, staffing, work assignment, equipment acquisition, etc. The team manager controls all non-technical aspects of the project. On large teams, there maybe multiple managers for coding, Q/A, documentation etc., with the team manager acting as overall coordinator. Such a role is often called a project manager or director.
Product expert The product expert has knowledge of the history of the system the team is developing or modifying. His responsibility is to help team members understand why the system is as it is so that they do not make changes that will adversely affect existing installations.
Customer advocate The customer advocate represents the user of the software to the development team. The customer advocate insures that the team's decisions will fulfill the user's real needs and also communicates requests and other information from the customer to the team.
Document Designer The document designer creates the structure of user documentation. This person is the documentation equivalent of the software architect.
Technical writer The technical writer writes documentation for the team. This is usually end user documentation but may also include internal documents for training, maintenance, etc.
Marketing/Sales The marketing/sales role is responsible for insuring that the system matches the requirements of the market and also plans advertisement, distribution and sale of the software if appropriate. The person in this role locates the potential need that initiates the project.

Communication

The moment you have two or more people working together you have a need for effective communications. It's not enough to just tell the team members they have to communicate with each other. There must be systems in place to allow for effective communications. Communication between team members becomes increasingly difficult as the size of the team increases. In addition, if the teammembers are geographically separated communication of information may become a major block tothe team's success.

Communication is much more than simple face-to-face conversation or e-mails betweenteam members. It includes any specifications or documentation that are written and any presentations of requirements or design to team members or customers. Unfortunately, very few programmers have any training in writing and speaking. When required to communicate information, they fall into a rambling technical discourse that only they can understand. It is beyond the scope of this book to teach effective writing and speaking, but the following principles may be of some help.

The first principle to understand is that you must communicate what the audience needs to hear not what you want to say. Most people assume that writing or speaking involves determining what you want to say. As a result, the listener often ends up with the feeling that nothing of importance was said and, quite possibly, that the speaker or writer is incompetent. Any effective communicator will tell you that you must "speak to your audience." This means that you adjust your language, technical level, mannerisms, and even the clothes you wear to fit the expectations and level of understanding of the audience.

The second principle is that you don't write or speak in a way to be understood. You must communicate in a way that you cannot be misunderstood. If there is ambiguity in what you communicate you can assume that at least some of your listeners will misunderstand. Thus, you must be precise and complete.

Next, use lots of diagrams. A single diagram can often demonstrate a complex system better than pages of text explanation. It simply helps to "see" the system. Diagrams don't need to be complex and are usually better if they are simple and direct. In addition, where possible you should use standard symbols and figures in the diagram. If a circle has a standard meaning, you should not use a circle for anything else. Sometimes a standard diagram doesn't cover the area you need to describe and you have to use some non-standard symbol. In those cases it is important to explain what the symbol means within the context of your diagram.

The next important principle is to be prepared. This is especially important if you are not familiar with speaking in front of groups. Don't just try to "wing it" with a lot of jargon and complexity. Make an outline of what you will say, review it and then stick to your outline. When communicating in writing, get your facts together first, make an outline, and then fill it in. When possible, have someone else review your outline or complete presentation.

Finally, you always have to be ready to say "Honestly, I don't know," or, "I need some time to think about that before I give you an answer." For some reason technical people seem to think they have to always have an answer or that if they don't know the answer immediately they will look incompetent. Most people understand that there are open questions that need careful investigation and appreciate someone who will communicate their ignorance rather than just feeding them a line that later proves to be false.

Personalities

Each member of the development team brings a unique perspective, background and set of skills to the team. Often there will be vastly different personalities involved as well. These differences are of great benefit to the team if they are understood and managed. Otherwise, conflicts due to different personality and perspective can lead to serious conflicts that interfere with the team's success. It is always important to remember that just because you disagree with someone doesn't mean that his idea has no merit. Usually, the combination of ideas that different team members suggest will result in a better overall result.

The greatest difference in personality is usually between technical and non-technical people. Programmers will develop a view that everything is binary: yes/no, on/off, possible/not-possible. After all, you can't negotiate with a computer. It does what you instruct it to do and nothing more and nothing less. Non-programmers in general, and salesmen especially, usually solve problems through negotiation. Each side presents its opinion and then attempts to find a compromise position that satisfies both sides. To non-technical people, programmers will appear obstinate, arrogant and uncooperative. To programmers, the rest of the world appears ignorant and unwilling to understand the complexities of what they arerequesting. Programmers cannot expect people who are not programmers to understand these complexities. Otherwise they probably would not need the services of the programmer in the first place. Often, a non-technical person will have heard of some technology or learned a little bit of the programmer's jargon and then attempt to talk to the programmer on those terms. Programmers need to be especially alert to this. In the end, it is the programmers that have to learn to be better negotiators. Rather than just responding, "No you don't understand, that's not possible" you will have to explain the problems in non-technical terms and ask questions to get a better understanding of what the other person is requesting.

Among the technical team members the biggest difference in personality is between abstract thinkers and detailed thinkers. Abstract thinkers tend to "look at the big picture" and are very good at seeing conflicts between various parts of the system. Unfortunately, abstract thinkers accomplish this by ignoring details. The person who tends to be more detailed in thinking will tend to worry about how all the problems will be solved at the lowest level. They often miss inconsistencies at a larger scope because of this. However, the detailed thinker's ability to question small details can bring the abstract thinkers "down out of the clouds" and help them restrict their designs to what is doable. Once again, the combination of the two types yields a better result. However, if team members are not aware of these different thinking patterns, the team can end up with endless disputes and frustration.

Links: