2 Teamwork Abstract This chapter presents one of the basic eements of software projects teamwork. It addresses how to buid teams in a way that promotes team members accountabiity and responsibiity, and that fosters communication between teammates. One of the basic ways to start team buiding is by assigning roes to the team members. For this purpose a roe scheme is presented in this chapter, according to which each team member is in charge of a specific manageria aspect of the deveopment process, such as design and continuous integration, in addition to his or her deveopment tasks. Teamwork is not aways a simpe process, and sometimes it raises diemmas and conficts between team members. This aspect of teamwork is not negected in agie teams, and when a confict emerges, it is addressed openy by a the team members. In the section that deas with teamwork in earning environments, it is iustrated how the roe scheme and the discussion about diemmas in teamwork provide an evauation framework for software projects deveoped by student teams in academia. 2.1 Overview This chapter focuses on teams one of the main and most infuentia factors of software projects success. Consequenty, it is highy appreciated and supported by agie software deveopment methods. One practice which is highighted in this chapter is appying a roe scheme, according to which each team member has an additiona roe in the team in HOT O. Hazzan, Y. Dubinsky, Agie Software Engineering, DOI: 10.1007/978-1-84800-198-5 2, Ó Springer-Verag London Limited 2008
26 2. Teamwork addition to being a software deveoper. This roe scheme fosters the interconnections and dependencies between the members of agie teams and enhances creativity, responsibiity, accountabiity, diversity, and measure coection. Further, this roe scheme shows that each team member can contribute to software deveopment on the team eve, beyond his or her individua contribution, and that the mutua contributions of the individuas in the team create a whoe which is greater than the sum of its parts. To highight the importance attributed to teamwork in agie software deveopment environments, this chapter aso presents a set of activities that dea with roes, which may form the needed atmosphere for agie teamwork. In addition, we discuss potentia diemmas in teamwork and how agie deveopment may hep cope with such diemmas. Specificay, we examine how to satisfy the individua needs of each team member and, at the same time, achieve the needed contributions to the team s work. Based on this examination, an evauation scheme for student software projects, deveoped in teams, is presented in the section of this chapter that deas with teamwork in earning environments. This evauation scheme takes into consideration the various conficts that may arise. 2.2 Objectives Readers wi become famiiar with the characteristics of software teams in agie software deveopment environments. Readers wi earn how to aocate roes to members of agie teams and how to expoit the benefits of roe assignment at the individua, team, and organization eves. Readers wi discuss diemmas in teamwork and understand how agie teams can overcome them. Readers wi get a sense of how agie team spirit can be achieved, empowered, and maintained. Readers wi gain basic skis to expoit the strength of agie teams. 2.3 Study Questions 1. Find definitions for the concepts of team and teamwork. Discuss the definitions reevance for software teams. 2. What is the purpose of teams? Why are teams needed?
2.4 A Roe Scheme in Agie Teams 27 3. As a software team member, how woud you ike to fee in your team? What vaues woud you ike to pursue? What practices woud you want to see in your team deveopment environment to provide an atmosphere that fits you? 4. What roes do you have in your ife? How do you manage to perform them a? Describe two persona scenarios in which a confict emerged from the need to pay different roes and expain how the conficts were soved. 5. Why shoud roes be assigned to software team members? What roes woud you assign to your team members? 6. Look through the iterature for different approaches to roe assignments in software teams in genera and in agie software teams in particuar. Compare these approaches: What ideas do they share? How do they differ from each other? What are the specific characteristics and responsibiities of each roe hoder in the team? 7. Discuss at east three probems which software teams face. Suggest ways to sove these probems. 8. Suggest diemmas which software team members might face. Suggest ways to sove these probems. Suggest agie principes and practices that can support such cases. 2.4 A Roe Scheme in Agie Teams According to Humphrey (2000), a team consists of at east two peope who are working towards a common goa/objective/mission, in which each person has been assigned a specific roe to perform and in which a competion of the mission requires some form of dependency among team members (p. 19). In the case of a software project, a team is a group of individuas who have gathered to produce a software product. In software projects teams are needed for the accompishment of the compex task of software deveopment. It is however, not a trivia task to mange software teamwork. This is partiay because software deveopment is about an intangibe product, one that cannot be seen, smeed, or touched, and therefore, the deveopment status and the exact responsibiities are not aways cear. The unique situation of software deveopment can be approached in different ways. We wi start with roe assignment, which is one way by which agie software deveopment methods attempt to overcome the typica chaenges of software projects. Roe assignment means that each team member has an additiona roe besides that of deveoper.
28 2. Teamwork HOT? The assignment of roes serves as a means for spitting the responsibiity for project management and progress among a the team members. The rationae for this stems from the fact that one person (or a sma number of deveopers) cannot manage the entire richness and compexity invoved in software deveopment projects. When the responsibiity is spit among a teammates, each aspect of the process is treated by one teammate, and each teammate fees a persona responsibiity for that specific aspect. Both the software project as a whoe and each of the individua team members benefit from this kind of organization. Tabe 2.1 presents a roe scheme for an agie software team, which expands and integrates the roe schemes suggested by the different agie methods. It is based on the idea that the responsibiity for the software s progress and success shoud be transferred to and distributed among a teammates (Dubinsky and Hazzan 2004, 2006). There are four groups of roes. The first is the eading group, which consists of the coach, tracker, and methodoogist. It is important to note that the tracker and methodoogist in this group, as we as the other roe hoders, do not reduce the significance of the project eader/coach. To the contrary as it turns out, the roe scheme improves the project eader s position and provides him or her a better way to assess and ead the deveopment process. The second is the customer group, which consists of the user evauator, customer, and acceptance tester. If the project has a rea customer, the roes in the customer group shoud be conceived of as a bridge between the rea customer and the team. If the project does not have a rea customer, these roe hoders pay a rea customer. The third group is the code group, which is composed of four roes: designer, unit tester, continuous integrator, and code reviewer. This group of roes focuses on those aspects of software deveopment that are directy reated to the coding activity. The fourth group is the maintenance group, which comprises three roes: presenter, documenter, and instaer, and focuses mainy on the product s externa presentation and documentation. As can be seen, the different roes address different aspects of the deveopment process (eadership, customer, code, and maintenance), and together they encompass a the aspects of a standard software deveopment process. Hoding a roe, and thus being in charge of a specific aspect of the deveopment process, does not mean that the roe hoder performs a the activities reated to his or her particuar roe; instead, it impies that each roe hoder must ensure that the specific aspect for which he or she is responsibe wi be carried out propery by a team members. Since this idea appies to a team members, the project management is spit among a team members and, at the same time, is covered by a of them.
2.4 A Roe Scheme in Agie Teams 29 Tabe 2.1 Roes in an agie software team (Reprinted from Journa of System Architecture, 52, Dubinsky Y, Hazzan O. Using a roe scheme to derive software project quaity, 693{699, Copyright (2006), with permission from Esevier. Aso, with kind permission of Springer Science and Business Media.) Group of roes Roe Description Leading group Coach Coordinates and soves group probems, eads and guides deveopment sessions Tracker Measures the group progress by measures as defined by the team, the customer, and the organization; manages the workspace boards; manages the team diary/coective memory. See aso Chapter 5, Measures Methodoogist Makes sure that the team works according to the defined deveopment process, answers questions reated to the methodoogy, ooks for soutions to probems reated to the methodoogy Customer group User evauator Customer Acceptance tester Performs an ongoing user evauation of the product (coects and processes feedback received from rea end users), hods a user centric approach, serves as the user interface designer. See aso Chapter 3, Customers and Users If the project doesn t have a rea customer: tes customer stories, makes decisions pertaining to each iteration, provides feedback, defines acceptance tests. See aso Chapter 3, Customers and Users Defines (with the customer) and deveops acceptance tests, inspires a test-driven deveopment process. See aso Chapter 6, Quaity Code group Designer Maintains current design, works to simpify design, searches for refactoring tasks and ensures their proper execution. See aso Chapter 8, Abstraction Unit tester Estabishes an automated test suite, guides and supports others in the deveopment of unit tests, guides a testdriven deveopment process. See aso Chapter 6, Quaity Maintenance group Continuous integrator Code reviewer Presenter Documenter Instaer Estabishes the integration environment; pubishes and encourages rues pertaining to the addition of new code, incuding testing issues Maintains source contro, estabishes and refines coding standards, guides and manages the team s pair programming Pans and organizes iteration/reease presentations, demos, and roes; measures presentations Pans and organizes the project documentation: process documentation, user s guide, and instaation instructions Pans and ensures the deveopment of an automated instaation kit, maintains the coaborative workspace infrastructure
30 2. Teamwork For exampe, et us assume that one of the teammatesisadeveoperwhoasohas the roe of unit tester. As the unit tester, this team member is in charge of a the unit testing activities of the entire project, and of guiding other teammates in the deveopment of their unit tests. But this does not paint the entire picture: et s ook at this team member from the perspective of being a deveoper. As a deveoper, this team member shoud write quaity unit tests for his or her own deveopment tasks. As the person who is speciaized in unit testing, it makes sense that she or he wi write quaity tests, which can in turn serve as exampes for the other teammates of how unit tests shoud be written. In addition, as a deveoper, this team member is guided with respect to other aspects of the deveopment process by team members who hod the other roes. This scenario shows how the two hats of each team member a roe hoder and a deveoper are interconnected and contribute to the deveopment process, improve the software quaity, and reinforce the team members communication. Task In a way simiar to the anaysis presented above with respect to the unit tester roe, anayze at east three additiona roes from Tabe 2.1. The cumuative impact of a the roes increases the team members commitment to the project. In order to carry out a roe successfuy, each team member must gain a goba view of the deveoped software and to be invoved in a parts of the appication, in addition to carrying out his or her persona deveopment tasks. If a team member has a imited view and is aware ony of his or her tasks, he or she wi not be abe to perform the persona roe propery. The need to accompish the persona roe satisfactoriy actuay increases one s invovement and accountabiity, as we as the commitment to the deveopment process, and eads one to become famiiar with a the software parts. Consequenty, communication and knowedge sharing, which are vita for software deveopment, are once again increased among team members. In genera, in having a persona roe, the team members are expected to perform their deveopment tasks as we as the tasks reated to their persona roe. Thus, no teammate is merey a deveoper. The two activities have a mutua positive infuence, and consequenty the coaboration and communication between the team members is enhanced and the agie team s spirit is maintained. Further, the dua functionaity of each team member increases the transparency of both the software process and the product. The process becomes more transparent because it is cear who is in charge of each of its aspects; the product becomes more transparent because each team member is famiiar with a the product components and aspects, at east with respect to his or her roe. This perspective is different from the approach in which each roe hoder is responsibe for the entire impementation of the aspect of which he or she is in charge, whie the other team members do not perform it at a (e.g., the documenter is the
2.4 A Roe Scheme in Agie Teams 31 ony team member who is invoved in documentation activities). Whie this approach may ead other team members to reduce their responsibiity with respect to that activity, the roe scheme described above just inspires the opposite: a strong interconnection exists between the teammates. One team member cannot propery perform a the tasks invoved in a software project, even with respect to ony one aspect of the deveopment process; cooperation between teammates is essentia in order to accompish the deveopment process propery and on time. Further, since the roe scheme carifies the exact responsibiities of each team member, team members are committed to each other by ensuring that a of them are abe to perform their roes in the best way. A these messages deivered by the roe scheme increase the team members invovement and commitment to the project and to the team. To sum up: Roes are important for the estabishment and maintenance of agie teams. A cear roe scheme inspires an agie spirit and contributes both to the individuas, to the team, and to the project s success. Further, the roe scheme spreads the eadership and management of the software project among a the team members. It ets the deveopers know that not a the responsibiity is carried by one person. 2.4.1 Remarks on the Impementation of the Roe Scheme The set of roes that a software deveopment method incudes in its roe scheme refects the vaues that a software deveopment method attempts to inspire. Therefore, the roe scheme that a software deveopment method defines is one of the key eements of the method. Indeed, different agie methods suggest different roe schemes that support their vaues and conception of software deveopment processes. In addition to the roe definitions presented in Tabe 2.1, severa roes aso support communication between the four groups. For exampe, the instaer is aso in charge of communication with the code group. At the first stages of the deveopment process, or when the team is estabished, the roe hoders shoud earn their roes and estabish a procedure that wi enabe them to perform their roe propery. In the next stages of the agie project, roe hoders shoud maintain the spirit and the actua performance of the aspect that their roe focuses on. When teams consist of fewer than tweve deveopers, severa roes can be unified and assigned to one team member. There are different ways to unify roes, and each has its own advantages. In each case, however, the entire ist of roes shoud be assigned and performed by a team members.
32 2. Teamwork The team can choose whether each of its members wi speciaize in one roe for a ong period of time or, aternativey, whether the roes wi rotate among the team members. The exact way by which it is done in practice shoud be set by each team according to the team members preferences. For exampe, it can be decided that roes are reassigned at the beginning of each reease. Such a team organization eases project management, since it is cear who is in charge of what aspect of the deveopment project, what aspect shoud be treated by whom, and who shoud be approached when a specific probem, which beongs to a specific aspect of the deveopment process, arises. Even in cases when there are roe overaps, they wi not interrupt the process. Sometimes they can even foster project deveopment. One exampe is when the unit tester and the acceptance tester work together to introduce test-driven deveopment. Tasks 1. How does the roe scheme refect the HOT perspectives of agie methods? 2. Predict what attitudes and feeings such a roe scheme might raise in agie software teams. 3. What information does each roe hoder need in order to perform his or her roe successfuy? 4. In what ways does the roe scheme reate to the Agie Manifesto? 5. Describe how each of the Agie Manifesto principes is supported by the roe scheme. 6. What benefits does roe rotation have? 7. Suggest a mechanism for roe rotation in agie teams. What are its benefits? What are its pitfas? 2.4.2 Human Perspective on the Roe Scheme HOT Socia Aspect A persona roe increases teammates invovement, communication, accountabiity, responsibiity, and commitment to the software deveopment process and to their team. Team members wish to have a specific roe in addition to their deveopment tasks in order to increase their infuence and invovement in the project management.
2.4 A Roe Scheme in Agie Teams 33 Cognitive Aspect Since each team member approaches the product from one specific perspective, each can focus on this one specific aspect without being distracted by the mutifaceted nature of software product deveopment. In other words, on the goba eve, the roe definition encourages each team member to treat the software product from one perspective. Consequenty, each graduay improves his or her understanding about that aspect. The roe scheme supports the thinking of the deveopment process on mutipe eves of abstraction (see Chapter 8, Abstraction). Since abstraction is a key component of software deveopment, every mechanism that supports team members thinking in terms of different eves of abstraction shoud be enhanced. On the one hand, each team member sees his or her deveopment task on a reativey ow eve of abstraction; and on the other hand, the persona roe of each team member enabes each of them to gain a goba overview of the deveoped system on a higher eve of abstraction. Agie methods support thinking at different eves of abstraction in additiona ways, such as short reeases (see Chapter 3, Customers and Users) and refactoring (see Chapter 8, Abstraction). The roe scheme enhances knowedge distribution, since each team member speciaizes in one domain and shares his or her knowedge with the other team members. In addition, since the roe scheme eads to knowedge distribution, no harm happens when one team member eaves the team. Indeed, he or she has gained expertise in his or her roe; at the same time, however, parts of this knowedge have aready been spread. Thus, if a team member eaves the team, the other team members have a reasonabe amount of knowedge to continue with respect to that roe. The roe scheme supports the individua s professiona deveopment. Team members perform their roes and improve their roe performance whie earning the practice that their roe represents. In turn, they become experts in the specific aspect of software deveopment on which their persona roe focuses. In addition, when a team member fees that he or she has exhausted one roe s contribution to his or her professiona deveopment and wishes to hod another roe in the team, as has aready been mentioned, roe rotation can take pace. Tasks 1. To each of the ideas presented in the human perspective on the roe scheme, add its organizationa and technoogica view. 2. Anayze the roe scheme from the organizationa and the technoogica perspectives.
34 2. Teamwork 2.4.3 Using the Roe Scheme to Scae Agie Projects HOT The roe scheme aso supports the scaing up of agie projects. Suppose we have five agie teams as part of one software project, and each of them appies the roe scheme. In this setting, weeky roe meetings are set for each roe, in which a the roe hoders from a the teams participate. For exampe, a weeky meeting of a testers of the project takes pace; a biweeky meeting of a the integrators takes pace, etc. It is recommended that these roe meetings be schedued at the same time, in order not to coide with the deveopment sessions of the project teams. In these meetings project-wide issues are discussed, so that the project management proceeds in one direction. The use of the roe scheme for scaing up purposes aso enhances knowedge distribution. On the individua eve, each team member has the opportunity to communicate with other deveopers, beyond his or her team, to present the knowedge his or her team has gained so far with respect to a given roe, and to serve as a bridge between the team and the organization with respect to that aspect of deveopment of which she or he is in charge. On the team eve, each team may benefit aso from the wisdom and experience gained by other teams. For exampe, the team representatives may bring into the roe meetings a probem which their team faces, and ask the other roe representatives whether their experience can contribute to a soution. Such a diaogue creates a knowedge infrastructure for the deveopment process from which a teams can benefit. On the organization eve, and based on the individua and team eves, knowedge is distributed, managed, and maintained. The roe scheme aso supports measures reated to the project s progress (see Chapter 5, Measures). The measures and poicies that shoud be appied by a the teams enabe the project s management to know on an ongoing basis the project s status, progress, and quaity. Based on this information, management monitors and contros the project s progress. 2.5 Diemmas in Teamwork One of the probems that can arise with respect to teamwork is the question of how to aocate incentives, rewards, and bonuses among team members. This question is reevant with respect to many professionas and kinds of institutions. However, reward aocation in software engineering is important mainy, but not ony, because teamwork is essentia in software deveopment. As a resut, conficts between the required cooperation on the one hand, and one s desire to exce as an individua on the other, may intensify. The discussion is
2.5 Diemmas in Teamwork 35 especiay reevant with respect to agie teams since teamwork is one of the basic working assumptions of agie software deveopment, and team members are asked to cooperate, share information, and exchange ongoing feedback with the other payers in the deveopment environment. Task This task is based on Hazzan (2003). It aims at eevating the deveopers awareness to these potentia conficts and to encourage discussing them openy. This approach is in agreement with the first principe of the Agie Manifesto: individuas and interactions over processes and toos. Perform the task presented in Figure 2.1 with your team. Step 1 of the task focuses on the individua s preferences; step 2 examines how team members face possibe conficts between their own preferences and the preferences of the other team members. Thus, in the case of new teams, this activity aso fosters the team members acquaintance with each other. The discussion that takes pace at step 3 focuses on the team preferences at the individua and at the team eve. This discussion can be promoted by the foowing refective questions. Step 1: Individua work You are a member of a software deveopment team. Your team is tod that if the project it is working on is successfuy competed on time, the team wi receive a bonus. Five options for bonus aocation are outined beow. Pease expain how each option might infuence team cooperation, and seect the option you prefer. Persona Bonus (% of the tota bonus) Team Bonus (% of the tota bonus) A 100 0 B 80 20 C 50 50 D 20 80 E 0 100 How this option may infuence teammates cooperation Step 2: Teamwork (to be faciitated with the deveopment team) Each team decides on one option that a team members, as a group, prefer. Step 3: A teams discussion Discuss with a the teams the processes that took pace in the above two steps. Figure 2.1 Bonus aocation activity [#2003 ACM, Inc.].
36 2. Teamwork Refective Questions 1. What were your considerations when choosing your persona option for bonus aocation? 2. Did you face conficts whie working on this task individuay (Step 1)? What was their source? How did you overcome these conficts? 3. Did you face conficts whie working on this task with your team (Step 2)? What was their source? How did you overcome these conficts? 4. What questions, emotions, and diemmas with respect to software teams were raised during individua and team work? 5. Predict what considerations woud cause deveopers to prefer a different option for bonus aocation than yours. 6. What characterized the discussion in your team about the agreed upon option for bonus aocation? How did the team agree about the preferred option? 2.6 Teamwork in Learning Environments The studio meeting this week focuses on activities reated to the introduction of the roe scheme, the roe assignment, and the grading poicy that is used for the evauation of the students work. The detais appear in the continuation of this section. 2.6.1 Teaching and Learning Principes The foowing teaching and earning principe deas with the roe scheme. (In our ist of teaching and earning principes presented in Chapter 14, Deivery and Cycicaity, this is principe number 7.) Teaching and Learning Principe 7: Assign Roes to Team Members. According to this principe, each team member has both an individua roe, chosen by the member from a given ist (for exampe, coach, unit tester, acceptance tester, code reviewer, etc.), and deveopment tasks for which he or she is responsibe.
2.6 Teamwork in Learning Environments 37 Such a roe scheme does not impy that each roe hoder carries out a activities reated to the domain for which he or she is responsibe; rather, each roe hoder makes sure that the activities reated to hir or her domain are accompished satisfactoriy by a team members. Accordingy, the assignment of roes heps divide the responsibiity for project progress and management among a team members. The rationae for this principe is that one person (or a sma number of team members) cannot be responsibe for the entire richness and compexity invoved in software deveopment. When the responsibiity is divided among a team members, each aspect of the entire process is addressed by one team member, and at the same time each team member fees persona responsibiity for that specific aspect. Both the project itsef and the team members benefit from this arrangement. Furthermore, the need to perform one s roe successfuy actuay forces a the team members to be invoved in, and to become famiiar with, a parts of the deveoped appication. Consequenty, knowedge sharing, communication, and invovement are enhanced among team members. 2.6.2 Roe Activities We present the actua appication of the roe scheme through three kinds of activities. The first kind deas with the roe assignments. Second, activities that maintain the roe performances on a daiy basis are described. Third, an activity that aims at improving the roe performances is presented. The activities can be performed in both academic and industria settings. 2.6.2.1 Roe Assignment Activities The first two activities introduce the roe scheme to the team members. If the activities are carried out in an industria setting, they shoud be faciitated when the agie team is estabished, in order to et the team members fee the interconnection among themseves, and their mutua responsibiity as an agie software deveopment team. The other activities shoud be faciitated as deveopment proceeds. Figure 2.2 describes the first activity reated to roe assignment. It focuses on the creation of one agreed upon roe ist. Since in this studio meeting the academic coach sits together with ten to tweve students who do not know each other but wi soon start working together on many tasks reated to software deveopment, this activity initiates the students reationships as teammates.
38 2. Teamwork Time: In academia: second meeting; in industry: when an agie method starts to be impemented. Task description: You are going to deveop a software product as a team. Write down the roes that in your opinion shoud be performed as part of your project. Individua work (10 minutes): Students/deveopers write down their ists. Team discussion (20 minutes): Students/deveopers discuss their suggestions, trying to generate one agreed upon ist. For students: Students are asked to prepare a prioritized ist of roes they woud prefer to perform during the semester. Summary: The academic coach/agie faciitator presents the roe scheme (Tabe 2.1). Figure 2.2 Activity 1: roe ist generation (Reprinted from Journa of System Architecture, 52, Dubinsky Y, Hazzan O. Using a roe scheme to derive software project quaity, 693{699, Copyright (2006), with permission from Esevier.). In industry, this activity signas the beginning of a change in the team structure with respect to persona responsibiities. It can be faciitated when the team is first introduced to agie software deveopment, as part of a workshop that the team attends (see Chapter 12, Change) or at the beginning of the impementation phase of agie software deveopment. In both cases, Activity 1 improves the team members acquaintance of and famiiarity with their teammates. Activity 2 (Figure 2.3) describes the roe distribution. In academia, the fu set of roes is determined for the entire semester. This fu impementation is needed for the evauation process, presented ater in this chapter, which is based on the fact that a students have the same oad. Aso, according to the roe scheme presented in this chapter, the students are responsibe for the software s progress and success. Therefore, it is important to note that the academic coach shoud not be the team coach, and that the roe of coach shoud be given to one of the students. The academic coach is in charge of Time: In academia: second meeting; in industry: foowing the previous activity. Discussion (10 minutes): In your opinion, how shoud we assign roes to teammates? Task description (20 minutes): Distribute the roes among the teammates. At the end of the task suggest a ist of roe-teammate pairs. Discussion (15 minutes): Discuss what portion of your time you shoud dedicate to the performance of your persona roe and what portion shoud be devoted to the accompishment of your deveopment tasks? Refection (after the second meeting in academia; during a team discussion in industry): - Express your opinion about the process of roe assignment in your team. - How do you conceive of your roe? What input woud you expect to get from your teammates with respect to your roe? Figure 2.3 Activity 2: roe distribution (Reprinted from Journa of System Architecture, 52, Dubinsky Y, Hazzan O. Using a roe scheme to derive software project quaity, 693{699, Copyright (2006), with permission from Esevier.).
2.6 Teamwork in Learning Environments 39 project evauation and contro from the academic perspective, but does not ead the actua deveopment process. This perspective gives the academic coach a better way to assess the deveopment process and the teammates work by means of the grading poicy, presented ater in this section, that supports the roe scheme and is based on both an individua component and a team component. In an industria setting, the roe scheme shoud be appied in a gradua fashion. It is recommended that the team decide with what roes they woud prefer to start the agie impementation phase. The team chooses severa roes to start with, and team members vounteer to carry out these roes. It is recommended that the team start at east with the roes of coach, tracker, and unit tester, and graduay add roes according to the team preferences, needs, and adjustment to the agie process. The actua roe assignment itsef has a direct infuence on team communication. For exampe, in an industria setting, it opens new horizons to team members: they are exposed to new facets of their teammates of which they were not aware, even though they may have worked together for many years. This activity aso infuences and enhances earning. For exampe, team members may suggest that roes shoud be assigned not according to what is appeaing, but rather according to what area one is not skied in. In this way, in order to perform their roe propery team members wi have to communicate about the various aspects of their roe with other teammates who are more knowedgeabe. Thus the team members wi earn new topics. 2.6.2.2 Roe Maintenance Activities The activities in this part are performed on a reguar (daiy, weeky, iteration) basis. In academia this enabes the academic coach to be aware of the project s progress and to improve the students work assessment; in industry it enabes the entire team to be aware of the project status. Stand-up meeting: Stand-up meetings take pace every day in industry, and on a weeky basis in academia. It can be decided that some portion of the brief persona report (one or two sentences) be dedicated to the persona roe. Each team member reports about his or her roe performance and about his or her expectations from teammates with respect to persona roes. Presentations to customers: The foowing task fits for an academic setting; when appropriate, it can be adjusted for an industria setting. Specificay, each presentation to the customer consists of two parts. In the first part, the deveopment tasks of the iteration are presented; in the second part, each student briefy presents how he or she improves product quaity by the accompishment of his or her roe. The preparation for these presentations takes pace one week before the presentation of each iteration to the customer. The students can discuss what the presentation shoud contain, how much time wi be dedicated for each part, and how the persona
40 2. Teamwork roes wi be presented. Since students usuay do not have previous experience in presenting software products, they wi benefit a ot from this activity. Feedback after presentations: In academia, there are three presentations to the customer during the semester: at the seventh, eeventh, and fourteenth (the ast) meetings (see Chapter 1, Introduction to Agie Software Deveopment, for a semester schedue). After each presentation two refective activities are carried out: the first is a feedback session that takes pace with the a team members; the second is a persona refection that encourages the students to evauate their work in the ast iteration. As part of this refection, students are requested to evauate their roe performance as we as to grade it. 2.6.2.3 Roe Improvement Activity The foowing activity can be requested by the academic coach periodicay when she or he observes that it is needed. Such a need occurs mainy in cases when the academic coach fees that some roes are not being performed propery. The students are asked to summarize their roe activities, to pubish their summaries in the eectronic forum, and to provide feedback to the summaries presented by the other team members. 2.6.3 Student Evauation One outcome of the team discussions that take pace in the bonus aocation activity (Figure 2.1) is an agreement that each individua s contribution shoud be considered on the basis of his or her persona accompishments (no matter how the team performs), as we as the team performance. Accordingy, in an academic setting, if the course is accompanied by a software deveopment project, we propose to make the project evauation of each student be based on a persona evauation (independenty of how the team performs), and on an evauation of the team performance. In order to promote teamwork as we as persona contributions to the project, the two components shoud be baanced in some way. For this purpose, the students evauation is composed of two parts: one the persona component and one the team component. The evauation of the individua roe performance is used for the persona evauation. The proposed evauation scheme, presented in Tabe 2.2, appies these concusions. It is composed of an individua component (35%) and a team component (65%); the team component is identica for a members of the team. The main criterion of the individua component of the grading scheme is the persona performance of the student (50%) as we as his or her persona roe (25%). The main criterion of the group component is the presentation of the customer stories as we as the time estimations given by the students at each of the three deveopment iterations.
2.6 Teamwork in Learning Environments 41 Tabe 2.2 Grading poicy Individua component (35%) Group component (65%) 50% 60% 3 Weeky refection Answer the customer stories and 3 Pair programming experience meeting the schedue according to 3 Test-Driven-Deveopment exercise the group time estimations: 3 Weeky presence 3 (10%) for iteration 1 25% 3 (25%) for iteration 2 Performance of a persona roe: 3 (25%) for iteration 3 3 Actua impementation 25% 3 Further deveopment and enhancement Project documentation 25% 15% Persona evauation of the academic coach Group evauation by the academic coach This student evauation scheme shows that both teamwork and individua contribution count. Accordingy, it is assumed that on the one hand, students wi be encouraged to contribute to their team s work, and that on the other hand, those wishing to exce wi have the opportunity to improve their grade through the persona component. Consequenty, the persona responsibiity of each student is increased. The grading poicy presented in Tabe 2.2 aso fosters gradua improvement. This is accompished by the main parts of each grade component. In the group component, 60% of the grade is achieved by meeting the customer requirements according to the students own estimations. The first iteration (out of the three iterations) receives the owest portion (even though it asts haf a semester), thus demonstrating that this iteration is dedicated to earning about the environment, the teammates, the method, and the project. In the individua component, about 75% of the grade is achieved by presence and refection, for specific exercises, and for performing the persona roe. These parts are aso characterized by gradua earning. Students are more open to give feedback as the semester proceeds, and roe performance is improved after the earning iteration, which is the first iteration of the semester. Tasks 1. In your opinion, shoud different kinds of teams be evauated in different ways? 2. Shoud teams be formed of students with simiar preferences, with different preferences, or according to a specific combination of preferences, with respect to bonus aocation? What considerations shoud guide each of these options? 3. In what ways is bonus aocation simiar to course grading? In what ways is it different?
42 2. Teamwork 2.7 Concuding Refective Questions 1. What were your considerations when choosing a persona roe? Why? 2. What were your teammates considerations when choosing a persona roe? Why, in your opinion, were these their considerations? 3. How wi you accompish your roe successfuy? 4. What are the three main goas of agie software teams? 5. In your opinion, what are the three most important characteristics of agie software teams? How do these characteristics enabe them to achieve their goas successfuy (Question 4)? 6. In Chapter 9, Trust, we wi meet two ideas reated to agie teamwork: diversity and ethics. If you are famiiar with these concepts, suggest connections between them and the way agie teams are buit and function. 2.8 Summary This chapter introduces the first steps of agie teams by estabishing their structure and some of their deveopment habits and processes. This is done by assigning persona roes to team members, which on a persona eve improves their understanding of the deveoped product, and on the team eve improves the process and product quaity. The roe scheme that guides the roe assignment achieves these goas by defining persona roes and cross-project roes; that is, each roe hoder is responsibe for the management of a specific aspect throughout the entire project. This chapter aso introduces diemmas in agie teamwork and how they can be addressed. In the spirit of the Agie Manifesto, diemmas and conficts associated with teamwork shoud be discussed openy by a team members, and a soution that meets the needs of the individuas as we as the entire team shoud be estabished. This idea has been iustrated by an evauation scheme for student projects. References Dubinsky Y, Hazzan O (2004) Roes in agie software deveopment teams. 5th internationa conference on extreme programming and agie processes in software engineering. Garmisch- Partenkirchen, Germany, pp 157{165
References 43 Dubinsky Y, Hazzan O (2006) Using a roe scheme to derive software project quaity. J Syst Architect 52 (11): 693{699 Hazzan O (2003) Computer science students conception of the reationship between reward (grade) and cooperation. 8th annua conference on innovation and technoogy in computer science education (ITiCSE 2003), Thessaoniki, Greece, pp 178{182 Humphrey W (2000) Introduction to the team software process. Addison-Wesey, Reading, MA
http://www.springer.com/978-1-84800-198-5