Software Engineering CSc640/848 Fall 2009 Global SW Engineering – organization and management

1. 09/01/09 Software EngineeringCSc640/848Fall 2009Global SW Engineering – organization and management Prof. Dragutin Petkovic With help of S. Mahadev, former grad student at SFSU S. Mahadev, D. Petkovic

2. Class plan • Address issues related to global SW engineering: development of SW with teams that are geographically distributed (whether they are from the same company or not) • Organizational issues • Communication issues • Teamwork issues • Technical issues (I.e. how to architect the system so tasks can be done as independently as possible) • Tools to help • Suggestions for global and local groups in our class • Reading: • These slides (courtesy of SFSU Grad. Student Satish Mahadev who summarized the book below, pkus D. Petkovic’s edits) • “Global Software teams” by E. Carmel, Prentice Hall, 1999 (hard to get. The slides are sufficient) S. Mahadev, D. Petkovic

3. Global Software Teams Def: Global Software Teams are spread over the national borders while actively participating in the development of a system/software project Nature of Global Software Teams Global Software Teams posses a “utopian” social organization, in which individuals communicate and collaborate with each other across boundaries by sending trusted information among themselves. This is not easy (even local teams have problems) so expect this, plan for this and deal with this S. Mahadev, D. Petkovic

4. Factorsdriving Global Software Teams Fifteen factors at different analysis levels are driving the new form of global software development. The fifteen factors are merged in to four main categories namely A) Catalyst Factor B) Sustaining Factor C) Size Factor D) Vision Factor S. Mahadev, D. Petkovic

5. Catalyst Factors 1) Specialized talent: Software companies want to deploy the best software designers and developers in the world regardless of their geographic location. 2) Acquisition: Software Companies are filing gaps and expanding product families through acquisition. 3) Reduction in development cost: Software Companies in high-wage nations like Japan and the United States are seeking low-wage countries like China, India and Mexico for getting their work done. 4) Globalized presence: Software executives need to position their organization as a global firm recognizing themselves as global players. 5) Reduction in time-to market: With different time zones, the ideal dispersed project can be productive round the clock. 6) Proximity to the customer: Software development requires a great deal of interaction with the customers so the maxim of the best corporation, the best salespeople, and the best designers is to stay close to the customers. S. Mahadev, D. Petkovic

6. B) Sustaining Factors 1) Development Rigor: Distance drives greater formalisms. 2) Internal freshness: Diversity brings new creativity and inspiration to the software organization. 3) Distance from distractions : Distant units are far from the numerous distraction from the headquarters. 4) Professional cadre of software globalists: 5) Experience: In most cases the remote sites have increased upon their experience curve and are performing well in software development. S. Mahadev, D. Petkovic

7. C) Size Factor 1) Scale: At some point of time co-located centers become too large and unwieldy to manage. 2) Evolving synergies of scale: Scale brings about opportunities for global collaborations that are unanticipated. • Vision Factor 1) Location Transparency : Eliminating the perception of distance through technology. 2) Virtual Organization : Organizing entities from different organization around a structure resembling a network that has a weak hierarchy and a weak center. S. Mahadev, D. Petkovic

8. The Five Centrifugal Forces of Global Software Teams A Centrifugal force is a physical force that propels an object outward from the Center. The five centrifugal forces that pull apart (I.e. create obstacles) for the global software team are A) Dispersion B) Coordination Breakdown C) Loss of Communication Richness D) Loss of Teamness S. Mahadev, D. Petkovic

9. Dispersion: Co-location and dispersion are tied to the old-age continuum of centralization and decentralization of organization. Centralization is the concentration of decision making at a single point in the organization. Co-location has several disadvantages leading to inbreeding, groupthink, and other group pathologies Development Managers concentrate on centralized organization for the following reasons: 1) Control 2) Less duplication of effort and wasted effort 3) Better ability to maintain a corporate culture S. Mahadev, D. Petkovic

10. B) Coordination Breakdown Coordination is the act of integrating each task and organizational unit so that it contributes to the overall objective. Control is the process of adhering to goals or policies or standards. Common mechanism of Coordination and Control are: Structured and formal mechanism: a) Departmentalization: shaping the form of the organization. b) Employee selection: through hiring c) Centralization of decision making: through the hierarchy of formal authority. d) Standardization through written policies e) Planning f) Control through measures such as technical reports, sales reports, financial performance. Informal mechanisms: a) Lateral relations through direct contact. b) Informal communication via personal contact, conferences and job rotation. c) Socialization through organizational culture and team culture, shared values, training and reward system. S. Mahadev, D. Petkovic

11. C) The Loss of Communication Richness Humans prefer different kinds of communication transmission or different media for different kinds of task Given a different development cycle stages, some task require richer communication than do others. Customer contact should be face to face during requirement gathering and later during prototyping. Designers need richer media to collaborate with one another during analysis and design phases. With recent study dispersed software teams found that team members always wanted richer medium no matter what the task. S. Mahadev, D. Petkovic

12. D) Loss of Teamness A good team encompasses a set of benefits that is sedative to any organization. a) It creates creative ideas and innovations. b) It is better at objectively evaluating ideas and finding mistakes . c) It provides greater access to expertise and experience d) It enhances motivation and commitment to the task. e) It has greater access to information. Teams are of different types a) Multifunctional: Includes members that traditionally were in other organizational functions and roles. b) Self-empowered: Members make decisions about their own work. c) Self-managed: Members take over management tasks such as scheduling and performance. d) High-performing: Outperforms other teams. S. Mahadev, D. Petkovic

13. Do Cultural differences affect software Professionals? What do you think? a) No, there is essentially no cultural differences amongst software Professionals. Engineer, like software professionals, place high value on work and on achievement and relatively low value on social Relationship. OR b) Yes, there is certainly little bit of cultural difference amongst software professional. Software professionals are not attentive to explaining events from cultural perspective, after a few probing questions, cultural stories emerged and eventually accumulated. S. Mahadev, D. Petkovic

14. The Six Centripetal Forces for Successful Global Software Teams The centripetal forces move objects toward the center, I.e. help. For global software teams they are: • Telecommunication Infrastructure • Collaborative Technology • Development Methodology • Managerial Techniques • Product Architecture • Team Building They will help only if they are done appropriately S. Mahadev, D. Petkovic

15. Architecture & Task Allocation – one technical activity critical for success Product architecture determines whether dispersed sites can work with each other harmoniously. Three task allocation strategies are identified for designing a software component. a) Module-based allocation, assigns task-modules to each site. b) Phase based allocation, assigns which work is passed from site to site at the end of a major phase in the development process. c) Integrated allocation, task re tightly integrated between sites and work is passed, as often as daily, between sites. Product architecture are a necessity for managing complex projects performed by globally dispersed teams. Proper product architecture is based in part on the principle of modularity. Modularity is one way to solve and allocate big complex tasks. Modular design reduces complexity and allows for easier parallel development. S. Mahadev, D. Petkovic

16. Task allocation strategies Three different allocating strategies are identified for allocating development tasks between sites • Module-based allocation, site A and site B are each assigned one of two modules to develop from the beginning of the system development cycle to the end. • Phase- based allocation, site B performs the first phase (design) while site a performs the next phase (build) and so on. OR: development vs. QA • Integrated allocation takes place when (dispersed) sites work closely together, both across modules and across the development cycle. Both module and phase task allocation strategies were common among the global software development projects developing packaged software of various categories. According to one study, only 25% approached the extremes of either module-based or phase-based allocation and rest of the other projects used more complex task allocation: combining module with phase, module with integrative, phase with integrative; and two projects had properties of all three approaches-phase, module, and integrative. S. Mahadev, D. Petkovic

17. Building The Dispersed Team Through Trust, Communication, And Personal Bridges • Building relationships means meeting face to face, shaking hands, sharing a drink, building trust. • Personal, face to face relationships are formed in kick-off meetings, milestones meetings celebratory meetings, and through bridges: the traveling manager, the short foreign assignments, the cultural liaisons, the expatriate assignments. Building trust • A team whose members do not trust each other will not function effectively- or even fail miserably. Trust means placing confidence in another’s character, ability, strength, and reliability. The Kick-off and other milestone meetings • The kick off meeting builds trust, builds team spirit, addresses some of the cultural differences, and also accelerates communication at the outset . S. Mahadev, D. Petkovic

18. Communication • The global team must address two communication objectives simultaneously. First, it must move from traditional reliance on informal coordination ( and communication) to increased reliance on formal mechanisms. Second, it must encourage the informal communication across distance. Lateral communication • Lateral communication means communication among team members across the organization rather than up and down the hierarchy. It is the lateral communication that creates effective integration of tasks and fully and quickly addresses task problem that crops up. Everyone gets a 360° view • Each developer can view what people are doing above him, below him, and laterally, on both sides of him. This is called a 360° view. The 360° view is closely related to the notion of organizational transparency, which requires a clear definition of individual tasks, and group tasks. Team communication protocols • Effective communication requires some protocols or rules. Team-wide communication protocols include response protocols, predictability, reliability and consistency which are important when a colleague can never be observed with one’s own eyes. Another application for communication protocols are conference calls that bring together different cultural meeting styles. S. Mahadev, D. Petkovic

19. Specialized Management Techniques Designing the team structure The stage model of global software teams Stage 1: One location Stage 2: Central Coordination HQ HQ S. Mahadev, D. Petkovic

20. HQ Stage 3: Globally Integrated A Generic team structure is based on several design principles. • First, it represents a balance between a centralized and a decentralized structure. • Second, some essential centralized roles are preserved, such as architecture, planning, budget, and standard setting. • Third, hierarchy is not discarded entirely: some internal decision-making hierarchy needs to remain: in the roles of the project manager, team leads, and so forth. • Fourth, the structure facilitates the all important intra-team communication and lateral communication. S. Mahadev, D. Petkovic

21. Managing Conflict • Collaboration is a constant process of negotiation and problem resolution. • The first step in conflict management is to set the groundwork for future inevitable conflict. Identify a trusted third party within or outside the team who can be called in to resolve inter-site disputes. • Once a conflict does arise, the first law of conflict resolution is: Separate the people from the problem. • Software Engineering teamwork best practices suggest three-step process for handling inter-site disputes. • Try to solve the dispute between the team leads without involving the other team members. • If the dispute remains unresolved, informally explore the respective positions separately and then bring the team leads together. • The third step in handling inter-site disputes is to bring in an expert third party, a neutral, or a committee to resolve the dispute. Similar three-step process will be implemented for CSC 640/848 global teams S. Mahadev, D. Petkovic

22. Research of Profs. Petkovic, Thompson, Todtenhoefer, Huang • Done in CSC 640/848 since 2004 base don objective and subjective measurements (this is why you fill out time cards and surveys) • Global and local student team in the class achieved about the same quality • Global teams spent more effort • Key impediments: • Time zone differences • Distance (lack of personal contact) • Grading of the class final project is taking into account this for global groups S. Mahadev, D. Petkovic

23. Suggestions and guidance for CSC 640/848 teams (Note that even local groups for most of the time work on “distributed” or “global” fashion so this is also important for them) • Focus immediately on establishing good rapport and communication among team members. Use face to face if you can, phone/skype and share the photos and professional bios over the WWW • Use modern collaborative tools that keep records of the meetings • Team leads: summarize meetings (no more than a page) with tasks and milestones • Good project docs (requirements and design, specs, APIs) are essential • Follow up of all participants is a must • Establish some common meeting times • Task allocation: minimize global communications • Conflict resolution: try to do it yourselves, then if not working involve team leads, then if not working involve instructors • This is hard but also a great experience. Grading will be adjusted accordingly S. Mahadev, D. Petkovic

24. Summary • Catalysts for helping global SW teams happen • Specialized talent: • Acquisition: • Reduction in development cost: • Globalized presence: • Reduction in time-to market: • Scale • Impediments in successful managing of global teams • Dispersion • Coordination Breakdown (project management, technical decisions) • Loss of Communication Richness • Loss of Teamness • Culture S. Mahadev, D. Petkovic

25. Summary • Issues that need utmost care: • High level project management, organization and coordination • Centralized decisions and coordination for key high level issues (i.e. requirements,specs, architecture) • Communication: teamwork, trust, written and verbal communication, conflict resolution • Culture • Tools: for communication, project management, SW development • Technical management: • Task allocation vs. modular architecture, well defined interfaces and functions etc. • Source control and management • QA and integration testing • Lower-level project management including risk management S. Mahadev, D. Petkovic

26. References: • Global Software teams” by E. Carmel, Prentice Hall, 1999 (book) • Papers: • Yang, M.; Jin, Y.: “An Examination of Team Effectiveness in Distributed and co-located Engineering Teams.” Int. Journal of Eng. Education, Vol. 24, No 2, pp. 400-408, 2008. • Richardson, I., Moore, S.; Paulish, D., Casey, V., and Zage, D.:“Globalizing Software Development in the Local Classroom.” 20th Conference on Software Engineering Education & Training, pp.: 64 – 71, 2007. • Petkovic, D.; Thompson, G.; Todtenhoefer, R.: "Assessment and Comparison of Local and Global SW Engineering Practices in a Classroom Setting." Proceedings of the Thirteenth Annual Conference on Innovation and Technology in Computer Science Education, Madrid, Spain, June 2008. • Krishna, S.; Sahay, S,; Walsham G.; “Managing Cross-Cultural Issues in Global Software Outsourcing.” Comm. Of ACM, April 2004, Vol. 47, No. 4. • Herbsleb, J.; “Global Software Engineering: The Future of Socio-technical Coordination”, Future of Software Engineering FOSE’07,May 2007, pp 188-198 • Herbsleb, J.; Mockus, A.; Finholt, T.; Grinter, R.: “An Empirical Study of Global Software Development: Distance and Speed”, Proceedings of the 23rd International Conference on Software Engineering, 2001,Toronto, Canada, pp 81-90. • Grimheden, M.; Van der Loos, H.F.M.; Chen, H.L.; Cannon, D.M.; Leifer, D.M., “Culture Coaching: A Model for Facilitating Globally Distributed Collaboration.” Proceedings of the 36th ASEE/IEEE Frontiers in Education Conference, Oct. 2006, San Diego, CA. S. Mahadev, D. Petkovic

27. References • Gopal, A.; Mukhopadhay, T.; Krishnan, M.: “The Role of Software Processes and Communication in Offshore Software development.” Comm. Of ACM, April 2002, Vol. 45, No. 4. • Gotel, O.; Scharff, C.; Seng, S.: “Preparing Computer Science Students for Global Software Development.” Proceedings of the 36th ASEE/IEEE Frontiers in Education Conference, Oct. 2006, San Diego, CA. • Gotel, O.; Kulkarni, V.; Phal, D.; Say, M.; Scharff, C.; Sunetnanta, T.: “Evolving an Infrastructure for Student Global Software Development Projects: Lessons for Industry.” Proceedings of the 2nd Annual Conference on India Software Engineering Conference, pp. 117-126, 2009. • Ebert, C.; De Neve, P.: “Surviving Global Software Development.” IEEE Software, Vol 18 (2), 2001, pp 62-69. • Keith Edwards, H.; Sridhar, V.: “Analysis of the Effectiveness of Global Virtual Teams in Software Engineering Projects.” Proceedings of the 36th Hawaii International Conference on System Sciences, 2003. S. Mahadev, D. Petkovic