S. Mahadev, D. Petkovic1 Software Engineering CSc640/848 Fall 2009 Global SW Engineering –...

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

Transcript of S. Mahadev, D. Petkovic1 Software Engineering CSc640/848 Fall 2009 Global SW Engineering –...

S. Mahadev, D. Petkovic 1

Software EngineeringCSc640/848

Fall 2009Global SW Engineering – organization and

management

Prof. Dragutin Petkovic

With help of S. Mahadev, former grad student at SFSU

09/01/09

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 TeamsGlobal 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

Factors driving 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

A) 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 Factors1) 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 Factor1) 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.

D) Vision Factor1) 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

A) 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 BreakdownCoordination 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 hiringc) Centralization of decision making: through the hierarchy of formal authority.d) Standardization through written policiese) Planningf) 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 TeamnessA 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 typesa) 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 softwareProfessionals?

What do you think?

a) No, there is essentially no cultural differences amongst softwareProfessionals. Engineer, like software professionals, place high valueon work and on achievement and relatively low value on socialRelationship.

OR

b) Yes, there is certainly little bit of cultural difference amongst softwareprofessional. Software professionals are not attentive to explainingevents from cultural perspective, after a few probing questions,cultural stories emerged and eventually accumulated.

S. Mahadev, D. Petkovic 14

The Six Centripetal Forces for SuccessfulGlobal 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 ThroughTrust, Communication, And PersonalBridges

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

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.

HQ

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.

1. Try to solve the dispute between the team leads without involving the other team members.

2. If the dispute remains unresolved, informally explore the respective positions separately and then bring the team leads together.

3. 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.