General Framework for Factors that Affect Team Performance

Guinan et al. (1998) studied 66 software development teams in one site at the requirements stage using a framework to classify factors affecting team performance. This framework is depicted in Figure 5.1.

Figure 5.1 Framework for Factors Affecting Team Performance

This classification framework consisted of internal and external group processes and their antecedents, which were divided into two world views: behavioural factors and

technical factors. Internal group processes include relationship processes and

production processes, where relationship processes refer to the emotional well-being of the team, cooperation, motivation, atmosphere of sharing, trust, and working toward a common goal which is similar to the cohesive ‘jelled’ team, forwarded by DeMarco and Lister (1987). Team production processes are concerned with processes such as team schedule, effective coordination, problem identification and team size with smaller teams having less communication problems than larger teams (Brooks, 1995). Goal alignment is also an important production process because ‘when a team is fulfilling its purpose team members are more effective because they are more directed’ (DeMarco & Lister, 1987, p. 18). The schedule needs to be realistic, as tight deadlines can be demotivating, ‘people under time pressure don’t work better they just work faster’ (ibid, p. 18). External group processes are concerned with external dependencies (Katz & Tushman, 1981) in the form of communication across departments, where the necessity to communicate with individuals who are not formal team mates across boundaries is critical to team success.

The two types of antecedents identified by Guinan et al. (1998) were behavioural

factors dealing with experience spread, team skill and managerial involvement, and technical factors covering structured methods, production technology, and coordination.

Experience spread is essentially demographic diversity. On the one hand, this diversity is thought to increase conflict and has a negative effect on internal communications, cohesion and coordination (Kiesler, 1978). On the other hand diverse teams when well managed have the ability to look beyond their boundaries for help in problem solving (Guinan, et al. 1998). This suggests that managerial involvement is directly related to increased performance (Guinan, et al. 1998). It is also argued that the leader should be distinct, and responsible, with everyone knowing where the buck stops (O’Connell, 2001; Henderson & Lee, 1992). Teams need to be highly skilled for optimum performance, because there is a chasm between the productivity of the most effective performers and the least effective, a ratio of 10:1 (Brooks, 1995, DeMarco & Lister, 1987). Guinan et al. (1998) concluded that relationship process was more important than production technology in optimising team performance. They concluded that effective plans, good communication, clear goals and procedures were critical and that behavioural factors were more consequential than technical factors such as structured methods and the use of CASE tools in influencing team performance. They also found that teams with the ability to communicate across department boundaries were also more successful.

5.6

Issues for the Management of Software Development Teams

Edwards (2003) argues that ‘software engineering is knowledge work, and hence knowledge management is of high importance in software engineering’ (p. 11). Issues of KM were addressed in Chapter 3, where the confusion between knowledge and information was outlined, corresponding broadly to the management of personalised (tacit) and codified (explicit) knowledge respectively. This has implications for the management of knowledge in software development. There are technological, people and process-based solutions to the management of software developers and their knowledge. According to Edwards (2003), the best approach is a combination o f all three within one overall knowledge management strategy that includes both personalization and codification elements (Hansen et al. 1999).

The software project manager’s job is to ensure that the software project meets the schedule and budget constraints and delivers software that contributes to business goals including meeting user needs. According to Sommerville (2004), good management cannot guarantee project success, but poor management usually results in project failure.

The discourse of knowledge management is becoming more evident in the project management literature. Turner (1999) observes that project teams consist o f ‘knowledge workers’. Knowledge workers are characterised as individuals who have high levels of education and specialist skills combined with the ability to apply these skills to identify and solve problems (Drucker, 1993). Members of software development teams represent intellectual capital and software managers need to ensure that the organisation gets the best possible return on its investment in people. Knowledge workers have specific individual expertise characterised by their job title, but there is also a cross-over of knowledge boundaries and ‘because software development is knowledge work, its most important resource is expertise’ (Faraj & Sproull, 2001, p .1554). Researchers have determined that software developers have much higher achievement needs than the general population (Couger & Zawacki, 1980; Couger, 1988).

According to Edwards (2003), managers need to abandon traditional methods of managing these workers, since knowledge workers enjoy greater power and autonomy at the workplace because their expertise is both more difficult to control and more marketable to other employers. Furthermore, management approaches from other disciplines are not appropriate for managing software projects (Sommerville, 2004). Software engineering is distinct from other types of engineering because the product is intangible, progress is not explicit, and team members rely on the documentation of others to review progress. In addition, there are no standard processes, which makes it difficult to predict which process will cause development problems.