Study Questions

Study Questions

  1. What software development methods use democratic teams ?

  2. What software development methods use hierarchical teams?

  3. What type of team makes you feel the most comfortable, and why?

  4. What considerations should one address when constructing a software team?

  5. As a software project leader, what roles would you assign to team members ?

  6. Where is delegation evident in software development?

  7. In your opinion, would software developers prefer equal allocation of bonuses among team members? Explain your opinion.

  8. How does outsourcing work in the software industry?

Relevance for Software Engineering

This chapter is about software development teams : how they are structured, how they encourage communication, their roles, and some of their problems. As mentioned previously, software engineers spend most of their working life as members of a team, so it is important that they know why they are organized in a certain way, what the nature of their role is, and how to fit in well with other team members . Software engineers are likely to have others from different nationalities and cultures on their team, and they should know how to act toward them as well.

As it turns out, cooperation is an essential attribute of the process that guides the development of software. At the same time, it may raise some conflicts between one s wish to excel and one s need to contribute to the teamwork. Thus, it is important that software engineers be familiar with dilemmas that this need for cooperation may raise and with different approaches to cope with such dilemmas.

Types and Structures of Software Development Teams

The three types of teams that we discuss in this chapter are democratic , hierarchical, and virtual. It is true that virtual teams can be organized either democratically or hierarchically, but this type is of such growing prevalence that we treat it separately. To highlight the idea that the creation of a software team should not be random, but rather based on some kind of analysis, several factors (for example, the development method used and the teammates level of experience) on which team structure is dependent are emphasized .

Democratic Teams

Democratic teams are characterized by everyone being a peer, or equal in another way. Student teams are often democratic, since peerism is more obvious. The organizational structure of a democratic team is a regular polygon (see Figure 3.1). Each programmer is an equal member of this circle; the decisions a programmer makes or the opinions a programmer holds are considered of weight equal to the others.

click to expand
Figure 3.1: A democratic organization.

Obviously, beginners like democratic teams, because they are often treated like more experienced team members . This is patently impractical , so a virtual hierarchy is set up, where the beginner often does not go against senior engineers . Another way to keep the advantages of a democratic team but not lose the effects of seniority is to put the beginner in a pair with a more experienced engineer (see Chapter 2, Software Engineering Methods ). This way, the pair can establish a hierarchy together, yet appear and act democratically in a group .

Engineers will form democratic teams out of nearly any method. In some ways, the Team Software Process (TSP) is the most democratic [Humphrey00]. Each role in the process has appended Manager, as in Development Manager. Humphrey hardly assumes each member has equal experience (example tasking is Development Manager, Planning Manager, Quality Manager, Process Manager, and Project Manager). A Development Manager decides on the number of iterations a team does in building software and develops a strategy to produce the product. The Planning Manager takes charge when iterations are planned, to assist the team in estimating and load balancing. The Quality Manager produces things like the configuration management plan and the acceptance tests. A Process Manager is like a Coach in an agile process, having the answer to most questions about TSP. The Project Manager has fewer responsibilities than on a non-TSP project, as the other managers do some tasks that lie in traditional methods. However, finding resources, running the meetings, and risk management are tasks still under the Project Manager s purview.

If a team has five or fewer members, then this TSP approach lends itself to a democratic organization. Otherwise, it lends itself to a hierarchical approach, as we discuss in the next section.


How is the code development allocated to TSP team members?

One time when everyone has roughly equal experience is in school. No matter which method the instructors or the team uses, it quickly takes on the aspects of a democratic method when used in an academic environment. This tendency to seek out democratic organizations is counterintuitive for some methods, such as those used for large-scale projects. However, the fact that they are sought out demonstrates student desires. Reward techniques may also affect team organization (see Forming and Rewarding Student Teams in this chapter).

The biggest problem with democratic teams is that no one is in charge. Actually, we should say everyone is in charge, and no one is responsible. Anyone wanting a decision from a democratic team must wait for it to achieve consensus. This may take some time.

  1. Suggest pros and cons of the last described phenomenon (that decision-making processes of democratic teams may be long).

  2. How can a decision-making process be enhanced in democratic teams? Suggest at least two mechanisms.

Another advantage to a democratic team is ease of replacement. Any engineer can be replaced by nearly anyone. The democratic team has a competence measured by the sum of its parts. Therefore, the loss of a member does not change the overall competence much. A further positive to a democratic team is the rapidity of jelling. A jelled team is one that finds working with others a more positive experience than working alone. It is when the team becomes greater than the sum of its parts . Many software managers emphasize jelling. A team that works closely together is easier to deploy.


What problems can a democratic team structure raise?

A team using agile processes probably functions better as a democratic team. There are no layers between the manager and the engineers, and communication, valued by many agile processes, is enhanced. Looking at agility from the perspective of team structure, a democratic team fits agile processes better. Collective ownership is an XP practice that ensures the democratic approach. As a practice, collective ownership means that anyone on the team can change the code. Obviously, this is difficult to set up in a hierarchy. A large amount of trust and a small amount of ego are necessary for this to work.

Actually, we think a small ego is necessary for any democratic team. Otherwise, consensus takes forever to achieve, and frustrated team members act independently. Chaos can result. However, small egos are seemingly difficult to come by in the software business. Many programmers are evaluated by individual achievement. These people often are too selfish to be suited for democratic organizations. This issue is further covered in this chapter under the discussion about rewards in software teams. Still, most XP teams operate democratically. This is due to collective ownership and to the nature of agile processes in general.

  1. Based on Chapter 2, what additional XP practices may support the creation of gelled teams?

  2. What stages in software development are appropriate to be managed using a democratic organization?

Hierarchical Teams

Hierarchical teams are organized like a tree (see Figure 3.2).

click to expand
Figure 3.2: A hierarchical organization.

Hierarchies are common. Many groups use such an organization outside of software development. Certainly, Mills Chief Programmer Team [Mills83] and Brooks Surgical Team [Brooks95] are software development groups using this organization. It is very easy to scale up hierarchical teams ”one can just add a layer. Unfortunately, this hampers communication, requiring the overall manager to cross many layers to get to the workers.

Delegation is part of a hierarchical management. It can be accomplished in a positive way by preparing some engineers to move to management. It can also be done in a negative way by passing unwanted tasks down the hierarchy.

Self-esteem is often more difficult to obtain in hierarchies. Depending on the number of layers, the Grunts (low-level programmers) may feel powerless. Moreover, layers create distance, which makes the Grunts feel they are not really contributing to the company. This is especially true if two or more layers are in a different geographical location. At the lowest level, there is more loyalty to the team than to the company. The home company is often an abstraction of the same sort as the competition. Besides, Grunts in such team organizations may miss the big picture of what goes on and may have only a narrow understanding of the development environment in general and the developed software in particular. This fact may influence decisions they make during the development process.


How can a company increase its employees loyalty when two or more layers are in different geographic locations?

Additionally, in hierarchical teams, the manager has to be respected, not necessarily liked . Otherwise, few workers would make the sacrifices necessary to follow in modern workplaces. There are five sources of power, in order of increasing desirability: punishment , reward, legitimate , identification, and expert.

The least effective of these, punishment and reward, are the way humans train dogs. Punishment, at the lowest level of power, can be either physical or psychic. If physical, like hitting a dog with a paper (good luck later training the dog to get the paper!), pain is caused by the manager whenever the employee does something judged wrong. Unless employees are somehow constrained, they will not stay long in this type of atmosphere. Punishment is like speaking sharply to a dog. Since the dog is genetically primed to please humans, a rebuke is like striking it. Oddly enough, some people, especially those whose self-esteem is wrapped up in pleasing elders and bosses, put up with this kind of treatment for years . Nevertheless, it is the weakest source of power.

Next highest is reward. If either a dog or a human gets some positive reinforcement for doing something right, we are using reward. Both dogs and humans are affected by rewards, as simple as a treat for a dog to monetary rewards for a human. Pavlov s dog and Operant Conditioning prove these points. This is where many companies stop. They might have a variety of rewards, and that is it. Dogs cannot go any further along this scale, due to a lack of intelligence. In the continuation of this chapter, we discuss connections between rewards and student teams in the university. However, in that context, rewards are used to raise dilemmas in software development and not as a means for gaining power or respect.

The next most effective source of power is legitimate power. This is like a replacement in a military unit. If the replacement is a common soldier, then the replacement fits into the unit without much fanfare. If it is a new platoon leader, then the replacement is obeyed like the former platoon leader. This works for a while, due to legitimate power, since officers are in charge of troops (note that this is easier in a hierarchical team). However, if an officer regresses to the level of punishment or reward, the officer quickly loses the advantages of legitimacy . In a software, or other, team, a manager is considered in charge when appointed. Thus, we have the honeymoon period, while the new leader s personality comes out.

The next highest source of power is identification. This is the source used by the most liked managers. Workers follow these managers because they can identify with their style and personality. They want to be like the manager some day. These types of managers seems relaxed with their power. They are easier to get along with, but there is no doubt who is the boss.


Identify five characteristics of a team leader with which software developers may identify. Why are these characteristics important in the case of software development?

The final source of power is expert. This is not necessarily a more effective source than identification, but it is powerful. Experts are very smart and may have 1,000 ideas a day. They are also very quick to think, jumping from topic to topic, and are very unpredictable. Of their 1,000 ideas, 999 are garbage, but one is worth seven figures. The problem is that someone, usually a slower, less intelligent underling, has to go through the entire list trying to find the valuable one. The next day there are another 1,000 ideas. The only reason people put up with this is the expert source of power. These managers are so obviously brilliant and a cut above even the intelligent people around them, that people follow the managers like puppies. When they do not want to follow, it is easier to work around or anticipate the moves of the manager rather than depose this manager from the current position.


Identify five problems with a software team leader who is an expert.

A larger team is able to use TSP to overcome the vagaries of single leadership. It may combine the effort distribution of TSP and democratic teams with some advantages of hierarchical teams. The Project Manager has some new responsibilities. Among other activities, the Project Manager must now communicate for the team, insulate the members, and generally represent the team. The other members can delegate parts of their tasks, although everyone still estimates.

We said that bigger TSP teams could lend themselves to a hierarchical approach. This means that under every manager are one to many Grunts. A Project Manager can have the other managers as underlings in a purely hierarchical team, thus fulfilling the three layers depicted previously. Otherwise, a hybrid team can be formed : democratic at the named manager level, hierarchical below. Delegation techniques are necessary for this type of team. The objective of delegation ought to be training of the Grunts to be Lesser Pooh-Bahs and so on up the scale. There is, of course, the motive of getting things done in parallel. For example, the Grunts assigned to the Process Manager can each be assigned one or more subteams to observe their process, and flag any deficiencies. The Process Manager can observe the other Managers for the same reason.

Often, there is a reluctance to delegate. This reluctance can have several origins. One is that people are afraid to appear replaceable . This is a big problem, because some younger members worry about being cast aside. Another disincentive is the belief that it is only done well if you do it yourself. This is generally evidenced by the delegator s spending time cajoling the delegate. The reason is subtly different from appearing incompetent as a person; often the team appears incompetent as a group.

Ego size is a factor in the success of hierarchical teams. If Grunts are seen and not heard , valuable feedback is lessened. Grunts or any other underlings need a significant ego to speak up in a crowd . However, even though a somewhat larger ego is needed for communication, if the ego is too big, following directives from above is problematic . If someone with a large ego is saddled with a superior using reward measures to lead, the egotist will see right through his superior and ignore his authority. This causes -low-level cooperation to fail, and makes a subteam essentially leaderless.

Mills and Brooks have an answer to this. Mills Chief Programmer team organization [Mills83] seems typically hierarchical. The team is small, consisting of only three members: the Chief Programmer, the Backup Programmer, and the Librarian. There is a very strict pecking order: Librarian, Backup, and Chief, from bottom to top. The Librarians used to punch cards, keep them in order, maintain version control, and pick up and distribute output. They still maintain version control and are expert in Integrated Development Environments ( IDEs , like Code Warrior). The Backup Programmer does everything the Chief Programmer does, but is sort of a Boswell. The Chief Programmer is more experienced and obviously in charge. The Chief Programmer is responsible for the architecture, and most of the nonroutine code. The routine or reused code is done by the Backup. Thus, the Chief can use the Backup to bounce ideas off, but remains responsible for the decisions.

Brooks [Brooks95] expanded the Chief Programmer team to become the Surgical Team and encompass 10 persons. These include the familiar Chief Programmer, Backup Programmer, and Librarian. Brooks added an editor, two secretaries, a tool smith, an administrator, a tester, and a language lawyer. The editor is for documentation produced by the team; the secretaries are divided between editor and administrator for routine tasks such as setting up travel. The administrator is to keep ordering items and other tedious nonproduct- related tasks from the Chief, enabling that person to concentrate on what he or she does best. The toolsmith knows more about the operating system and tools than anyone else does. The tester does functional testing. The language lawyer seemingly knows more about the language chosen than anyone on the planet [1] . Obviously, these seven additions are underlings. They may even be only part-time group members.


Identify benefits and disadvantages of a Surgical Team.

How is a hierarchical team scaled up? Add several Surgical Teams together to produce the code for each component. This way, we keep subteams relatively small (10), with the entire team being of indefinite size. People report that they can handle interactions with about eight others. If you eliminate the secretaries in a Surgical Team, you are left with eight people.

  1. Why does the number of team members matter? What are the main problems with too-big teams? With too-small teams?

  2. Identify and discuss instances of hierarchies we encounter in everyday life. What can we learn from these hierarchies about the working and management of hierarchical software teams?

  3. What is a downside to delegation? Discuss.


  1. Why are many people comfortable with democratic teams?

  2. For what types of software are democratic and hierarchical teams useful? For what types of software are democratic and hierarchical teams not useful?

Virtual Teams

Virtual teams can have either a democratic or a hierarchical organization. In a virtual team many of the team members are not co-located physically. For example, part of the team can be in Bangalore, India, another part in Palo Alto, California, and another in Haifa, Israel. A team like this has roughly an hour of work time overlap between Bangalore and Palo Alto, and later between Palo Alto and Haifa.

The adoption of these types of teams is mostly inspired by cost. Indian programmers are paid only about a quarter what Americans are paid, but even their managers worry about outsourcing to Thailand or China, where programmers are paid even less! Typical gross savings rates are between 50 percent and 80 percent. Due to the more elaborate overhead of many virtual teams, U.S. companies realize a net savings of only 15 percent to 25 percent. Nevertheless, 80 percent of IT shops are discussing outsourcing in 2004 [King03].


What ethical and cultural problems may members of a virtual team face?

Running a distant second as a reason for adopting virtual teams nowadays is their more efficient use of equipment. When computer centers were anchored by mainframes, it was more sensible to pass their use to others in a different time zone once most of the workers in one time zone went home. Now, most computing is done by desktops, which are about the same price wherever you get them.

Even though many virtual teams are now formed to save money, a person who is a member or leader of a virtual team has many possible problems. These include distance, which means less context, and cultural inequalities .

Cultural difficulties can include such problems as members being unable to operate in a democratic team, making consensus difficult. Many are trained to be solicitous of Pooh-Bahs, and take every wish as a command. They are not used to giving, or getting, negative feedback.

Virtual teams also can use some relatively ponderous methods. For example, many virtual subteams work from a finished statement of work, like a waterfall software life cycle. They negotiate based on requirements, so any changes are far-reaching and a problem. Members of the agile software development community claim that they code faster (thus, less expensively) and handle change, claiming that they obviate the need for outsourcing offshore.

Moreover, it is difficult to measure outsourced progress. Virtual teams can hide behind documentation. They can produce design documents or architectures that are massive in scope and give the appearance of progress. These documents have to be useful, no matter how far apart the subteams are, which means the documents must be short and to the point. No one will read a 330-page document.

Remote outsourcers usually begin work once the requirements are settled. They can stall code production by hiding behind documentation, as described previously. Frequently, an absent client will see releases so rarely they cannot tell whether to cancel a late one. Basically, then, agile processes are difficult, if not impossible to install in a virtual team, due to the need for co-location.

Despite their drawbacks, virtual teams appear to be the wave of the future, mostly for cost reasons. Still, some investment is necessary. It is often better to have one or more team members cross oceans to be present at the first meeting so that during later meetings, held using shared desktops and Voice over IP (VoIP), the widely separated members can visualize each other. The strength of this type of live contact cannot be stressed enough for building a gelled team at a distance. It turns out that outsourcing to Ireland or Northern Ireland results in a travel expense of less than $1 per hour per team member, with the savings from going off-shore built in. With travel costs as low as these, jelling is facilitated.

In Chapter 6, International Perspective on Software Engineering, the discussion of software engineering from an international perspective is widened.

[1] Jim Tomayko once worked at a plant that combined manufacturing computers and engineering. A language lawyer worked there as well. When a program failed, he could read the hexadecimal inside the registers and tell you what was happening. He was very sharp.