A comparison of the various types of team organization appears in Figure 4.7 , which also shows the section in which each team organization is described. Unfortunately, no one solution solves the problem of programming team organization or, by extension, the
Team Organization Strengths Weaknesses
sch76183_ch04_107-123.indd 120 04/06/10 12:49 PM04/06/10 12:49 PM
problem of organizing teams for all the other workfl ows. The optimal way of organiz-ing a team depends on the product to be built, previous experience with various team structures, and most important, the culture of the organization. For example, if senior management is uncomfortable with decentralized decision making, then it will not be implemented.
In practice, most teams are currently organized as described in Section 4.4. That is, some variant of the chief programmer team is the usual practice.
Not much research has been done on software development team organization, and many of the generally accepted principles are based on research on group dynamics in general and not on software development teams. Even when studies on software teams have been conducted, the sample sizes have generally been small, so the results have not been convincing.
Until experimental results on team organization have been obtained within the soft-ware industry, it will not be easy to determine the optimal team organization for a spe-cifi c product.
Chapter Review
The issue of team organization (Section 4.1) is approached by fi rst considering democratic teams (Section 4.2) and chief programmer teams (Section 4.3). The success of The New York Times project (Section 4.3.1) is contrasted with the impracticality of classic chief programmer teams (Section 4.3.2). A team organization that uses the strengths of both approaches is suggested in Section 4.4. Synchronize-and-stabilize teams (used by Microsoft) are described in Section 4.5.
Teams for agile processes are discussed in Section 4.6 and for open-source software in Section 4.7. The people capability maturity model (P–CMM) is described in Section 4.8. Finally, Sec-tion 4.9 describes the factors involved in choosing the optimal team organizaSec-tion for a given project.
For Further Reading
The classic works on team organization are [Weinberg, 1971], [Baker, 1972], and [Brooks, 1975].
Newer books on the subject include [DeMarco and Lister, 1987] and [Cusumano and Selby, 1995].
An interesting description of how team interactions evolve is found in [Mackey, 1999]. Chapter 11 of [Royce, 1998] contains useful information on the roles played by team members. A promising approach is the use of personality type analysis in selecting team members; see, for example, [Gorla and Lam, 2004].
Synchronize-and-stabilize teams are outlined in [Cusumano and Selby, 1997] and described in detail in [Cusumano and Selby, 1995]. Extreme programming teams are described in [Beck, 2000].
The May–June 2003 issue of IEEE Software includes a number of papers on extreme programming, especially [Reifer, 2003] and [Murru, Deias, and Mugheddue, 2003].
Views on agile processes are expressed in [Boehm, 2002] and [DeMarco and Boehm, 2002], and in the May–June 2005 issue of IEEE Software . Williams, Kessler, Cunningham, and Jeffries [2000]
describes an experiment on pair programming, one component of extreme programming. Pair pro-gramming is evaluated in [Drobka, Noftz, and Raghu, 2004], [Flor, 2006], and [Lui, Chan, and Nosek, 2008]. The results of [Arisholm, Gallis, Dybå, and Sjøberg, 2007] regarding the possible benefi ts of pair programming should be studied in detail.
P–CMM is described in [Curtis, Hefl ey, and Miller, 2002]. Globally distributed (remote) pair programming is put forward in [Flor, 2006].
122 Part A Software Engineering Concepts
4.2 How would you organize a team for developing state-of-the-art military communications soft-ware? Explain your answer.
4.3 State Brooks’s Law. Explain why it holds.
4.4 You have just started a new software company. All your employees are recent college gradu-ates; this is their fi rst programming job. Is it possible to implement democratic teams in your organization, and if so, how?
4.5 A student programming team is organized as a democratic team. What can be deduced about the students in the team?
4.6 A student programming team is organized as a chief programming team. What can be deduced about the students in the team?
4.7 To compare two different team organizations, TO 1 and TO 2 , within a large software company, the following experiment is proposed. The same software product will be built by two different teams, one organized according to TO 1 and the other according to TO 2 . The company estimates that each team will take about 18 months to build the product. Give three reasons why this experiment is impractical and unlikely to yield meaningful results.
4.8 The company you own has just taken over a smaller competitor, and you discover that one of their programmers is a superprogrammer. How do you ensure that she does not leave and take a job in another company?
4.9 Why do teams for agile processes have to share a computer?
4.10 What are the differences between a democratic team and an open-source team?
4.11 How would you organize an open-source team?
4.12 Would you like to work in an organization that uses synchronize-and-stabilize teams? Explain your answer.
4.13 Which team organizations conform to P–CMM?
4.14 You are the vice president for software development in a large company. How would you imple-ment P–CMM in your company?
4.15 (Term Project) What type of team organization would be appropriate for developing the Choco-holics Anonymous product described in Appendix A?
4.16 (Readings in Software Engineering) Your instructor will distribute copies of [Arisholm, Gallis, Dybå, and Sjøberg, 2007]. What are the implications of this paper for agile processes?
[Arisholm, Gallis, Dybå, and Sjøberg, 2007] E. ARISHOLM, H. GALLIS, T. DYBÅ, AND D. I. K. SJØBERG,
“Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise,”
IEEE Transactions on Software Engineering 33 (February 2007), pp. 65–86.
[Baker, 1972] F. T. BAKER, “Chief Programmer Team Management of Production Programming,”
IBM Systems Journal 11 (No. 1, 1972), pp. 56–73.
[Beck, 2000] K. BECK, Extreme Programming Explained: Embrace Change, Addison-Wesley Long-man, Reading, MA, 2000.
References
sch76183_ch04_107-123.indd 122
sch76183_ch04_107-123.indd 122 04/06/10 12:49 PM04/06/10 12:49 PM
[Beck et al., 2001] K. BECK, M. BEEDLE, A. COCKBURN, W. CUNNINGHAM, M. FOWLER, J. GRENNING, J.
HIGHSMITH, A. HUNT, R. JEFFRIES, J. KERN, B. MARICK, R. C. MARTIN, S. MELLOR, K. SCHWABER, J. SUTHERLAND, D. THOMAS, AND A. VAN BENNEKUM, “Manifesto for Agile Software Develop-ment,” agilemanifesto.org, 2001.
[Boehm, 2002] B. W. BOEHM, “Get Ready for Agile Methods, with Care,” IEEE Computer 35 (January 2002), pp. 64–69.
[Brooks, 1975] F. P. BROOKS, JR., The Mythical Man-Month: Essays in Software Engineering, Addison-Wesley, Reading, MA, 1975; Twentieth Anniversary Edition, Addison-Addison-Wesley, Reading, MA, 1995.
[Business Week Online, 1999] Business Week Online , www.businessweek.com/1999/99_08/
b3617025.htm , February 2, 1999.
[Curtis, Hefl ey, and Miller, 2002] B. CURTIS, W. E. HEFLEY, AND S. A. MILLER, The People Capability Maturity Model: Guidelines for Improving the Workforce , Addison-Wesley, Reading, MA, 2002.
[Cusumano and Selby, 1995] M. A. CUSUMANOAND R. W. SELBY, Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People , The Free Press/Simon and Schuster, New York, 1995.
[Cusumano and Selby, 1997] M. A. CUSUMANOAND R. W. SELBY, “How Microsoft Builds Software,”
Communications of the ACM 40 (June 1997), pp. 53–61.
[DeMarco and Boehm, 2002] T. DEMARCOAND B. BOEHM, “The Agile Methods Fray,” IEEE Com-puter 35 (June 2002), pp. 90–92.
[DeMarco and Lister, 1987] T. DEMARCOAND T. LISTER, Peopleware: Productive Projects and Teams, Dorset House, New York, 1987.
[Drobka, Noftz, and Raghu, 2004] J. DROBKA, D. NOFTZ, AND R. RAGHU, “Piloting XP on Four Mission-Critical Projects,” IEEE Software 21 (November–December 2004), pp. 70–75.
[Dybå et al., 2007] T. DYBÅ, E. ARISHOLM, D. I. K. SJØBERG, J. E. HANNAY, AND F. SHULL, “Are Two Heads Better than One? On the Effectiveness of Pair Programming,” IEEE Software 24 (November–
December 2007), pp. 12–15.
[Flor, 2006] N. V. FLOR. “Globally Distributed Software Development and Pair Programming,” Com-munications of the ACM 49 (October 2006), pp. 57–58.
[Gorla and Lam, 2004] N. GORLAAND Y. W. LAM, “Who Should Work with Whom?” Communica-tions of the ACM 47 (June 2004), pp. 79–82.
[Lui, Chan, and Nosek, 2008] K. M. LUI, K. C. C. CHAN, AND J. T. NOSEK, “The Effect of Pairs in Program Design Tasks,” IEEE Transactions on Software Engineering 34 (March–April 2008), pp. 197–211.
[Mackey, 1999] K. MACKEY, “Stages of Team Development,” IEEE Software 16 (July–August 1999), pp. 90–91.
[Mantei, 1981] M. MANTEI, “The Effect of Programming Team Structures on Programming Tasks,”
Communications of the ACM 24 (March 1981), pp. 106–13.
[Murru, Deias, and Mugheddue, 2003] O. MURRU, R. DEIAS, AND G. MUGHEDDUE, “Assessing XP at a European Internet Company,” IEEE Software 20 (May–June 2003), pp. 37–43.
[Reifer, 2003] D. REIFER, “XP and the CMM,” IEEE Software 20 (May–June 2003), pp. 14–15.
[Royce, 1998] W. ROYCE, Software Project Management: A Unifi ed Framework , Addison-Wesley, Reading, MA, 1998.
[Weinberg, 1971] G. M. WEINBERG, The Psychology of Computer Programming , Van Nostrand Reinhold, New York, 1971.
[Williams, Kessler, Cunningham, and Jeffries, 2000] L. WILLIAMS, R. R. KESSLER, W. CUNNINGHAM,
AND R. JEFFRIES, “Strengthening the Case for Pair Programming,” IEEE Software 17 (July–August 2000), pp. 19–25.