collaborative software design & development coordination...
TRANSCRIPT
1
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Collaborative Software Design & Development
Coordination 4
Laura NaymanJason VanFickell
2008/04/01
2
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
The Impact of Time Separation on Coordination in Global Software Teams: a Conceptual Foundation
J. Espinosa and Erran Carmel
3
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
OverviewDecreased efficiency from time separation results from:
Time-zone differences
Non-overlapping weekends, holidays, manufacturing shifts and work schedules
Teams employ different tactics for dealing with this inefficiency:
Synchronous
Asynchronous
Education
Coordination between developers in teams consists of four main components:
Communication
Clarification
Delay
Rework
4
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Overview Continued…Vulnerability costs which increase inefficiency and costs are incurred
as a result of:Resolving misunderstandings
Rework. (These increase with time separation.)
Reasons for decreased/inefficient coordination in the presence of time
separationInsufficient communication media
Difficulties in resolving unclear messages
Reduced opportunities for spontaneous interaction
5
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Motivation
Why are cost benefit trade-offs of higher coordination costs and lower
productions costs important to understand?
Time separation has a huge impact on coordination costs
Team work is increasingly carried out globally for the following reasons:
Transportations costs for digital products are low (software, documents)
Delivery time for these products is effectively zero
Production costs in many “offshore” locations is significantly lower
Geographic dispersion enables firms to access software talent and technical resources
6
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
BackgroundPractices used by developers to overcome difficulties resulting from time separation:
Asynchronous: Teams compensate for non-overlapping work hours by using different methods
Asynchronous tactics: email, voice mail, shared databases, wikis, code-versioning tools with
comments sections.
Teams also learn to structure their comments and information in such a way as to avoid
clarification.
Synchronous: Teams plan for the overlap times and enlarge the windows of overlap time
Synchronous tactics: Teams expand overlap times by working longer or assigning certain
people on the team to work longer or communicate with people in different time zones.
Education: Individual developers become more efficient working with time differences, with better
information.
Education tactics: Make team members aware of time separation issue and give them
resources to help them schedule meetings and make schedules taking into account the
different time zones.
7
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination Model: Mathematical Perspective
Objective of Coordination Model:
Models costs due to time differences in dispersed software teams
Evaluate how total cost of carrying out a task is influenced by :
cost and effectiveness of different communication
mechanisms in various collaboration modes (i.e. co-located and separated
by distance and/or time)
delays caused by time separation
8
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Distributed coordination assumptions within Mathematical Coordination model
Assumption: No distinctions between complexities of a task request encapsulated in a message
Problem with Assumption: Both, a large task which perhaps requiring several days of effort,
or small such as yes or no answer are treated the same
Assumption : Media choices for time separated team members are limited to email when work hours
don’t overlap and phone calls otherwise
Problem with Media Choice Assumption:
Requests are often not clear, requiring additional clarification communication, further
delaying the whole process.
Working face-to-face, clarification may be nearly instantaneous.
Even when members are distant, but in same-time zones, clarifications can be made very
quickly through phone calls, instant messaging (IM), or videoconference.
Time separated communication requires the need to clarify messages and will introduce
further delay, unless this happens during work-overlapping hours.
9
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination Model:Workflow dependency
Costs calculated based on single collaboration between two developers:Task Requestor makes a request to another developer who is the task Producer
because of a workflow dependency,
i.e. the work of the Requestor cannot continue until the work of the Producer is finished
Requestor must communicate the task requirements to the Producer, and the Producer must communicate an acknowledgement to the Requestor when the
dependent task is completed
Team members may be interacting in any of four possible collaboration
modes:Time and/or Distance Separate – 4 possibilities
10
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Major points
of coordination theoryDevelopers should communicate a lot early in the development process !!!
Communication is costly and time separation introduces asymmetries.
Coordination between N developers separated by distance can be substantialThese issues compound further with time separation
Overlap in work hours between any two members who collaborate can take
place either at the beginning or at the end of one’s workday.
The synchronous or asynchronous solutions to time separation will have to be
worked out differently, depending on when the work-time overlap occurs in
one’s workday
11
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Argument for Coordination Model
Effect of time separation on global software team coordination can be
modeled by analyzing timing issues:
When interaction between developers occur
Frequency of interaction between developers
Task duration times
Amount of overlap in work hours
Evaluating how these variables affect :
production costs (i.e. the cost of carrying out individual tasks)
coordination costs (i.e. the cost of managing the dependencies between
individual tasks)
12
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Breakdown of Coordination Costs:
Coordination Costs mainly composed of production costs and communication costs.
Coordination costs can be further decomposed into the following costs:
communication costs – the cost of maintaining communication links and the cost of sending and
receiving messages
delay costs – the cost of delays caused by the dependency requiring communication
Affected by latency inherent in the communication media and working-time differences
clarification costs – the cost of further communication required to repair miscommunication
rework costs – the cost of further production necessary for work that was completed before the
miscommunication was discovered
Differences from Malone’s coordination model:
some adjustments to take into account delays resulting from distance separation
time zone differences
Model time and distance separation between actors.
Malone’s model analyzes different coordination structures for a set of developers
13
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination Costs: Terminology
Production Costs: Costs of carrying out task
Coordination costs are essentially communication costs :Costs of maintaining communication links and sending and
receiving messages.
Delay costs: Incurred because one developer is waiting for
another to complete the task.
Clarification costs: additional cost of communication and delay
because of miscommunication.
Rework costs: additional production costs resulting from
miscommunication.
14
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination FormulasProduction Costs (Pc) is the cost of carrying out tasks
Pc = λCpTt
λ = Daily frequency of task arrivals (messages)
Cp = Daily production cost rate for the Producer
Tt = Time for Producer to complete task
Cost component only involves individual production time
and costs incurred by the Producer
Unaffected by time or distance separation.
15
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination FormulasCommunication Costs (Cc) = Cl + 2λCm (2)
Cl = Daily cost of maintaining a communication link between two time-separated
developers
Cm = Daily cost of sending individual single messages.
Cls = Cost of maintaining a synchronous communication link
Cla = Cost of maintaining an asynchronous communication link
Cms = Cost of sending a synchronous message
Cma = Cost of sending an asynchronous message
Several Permutations of Communication Costs Equation
Both members communicate synchronously
Cl + 2λCms
One member communicates asynchronously and one synchronously
Cl + Cla + λ(Cms + Cma)
16
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination FormulasDelay Costs (Dc) = λTdCd
Td = Delay experienced by task Requestor while Producer completes task
Cd = Daily rate of cost delay for the task Requestor
Measured from perspective of the task Requestor, because this is the developer who has a
dependency, whose work is delayed while the Producer completes the task.
If Producer carries out task during Requestor’s off hours, Td is zero, which is the motivator
for software work organized in follow-the-sun arrangements
if Producer does all work during overlapping work hours, Td is identical to the time it takes to
carry out the task Tt
Degree of time separation or work-time overlap has substantial effect on delay costs
17
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination Formulas
Clarification Costs (Cf ) = Cf = Pu(Cc + Dc)
Pu = Probability that task-request message will be unclear
Incurred when task request messages are not clear
Task Requestor and task Producer need to communicate again to
resolve misunderstanding,
Further communication and delay costs are incurred
18
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination Formulas
Rework Costs (Rc) = PuPrRwPc
Pr = Probability given unclear message will lead to rework
Rw = Proportion of total task that needs rework
Rc = Rework costs
Incurred if need for clarification occurs after Producer has started to
work on task and some software work needs to be redone.
19
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Vulnerability CostsFollow-the-sun and round-the-clock programming arrangements
ideal if:
Cost of carrying out task = Pc + Cc + Dc
Substantial delay costs savings by maximizing the amount of
task production that takes place during the Requestor’s off hours
Malone’s ‘vulnerability’ costs = clarification and rework costs
Problem surfaces when vulnerabilities materialize, requiring
further communication to clarify issues and possible rework
20
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Vulnerability Costs EvaluatedVulnerability costs affected by quality of communication
medium
Pu is dependent on the particular medium used
Pu for face-to-face communication is very low
Pu increases as teams move to leaner communication media
like video/voice conference and email
Pu increases as global team members span more boundaries
(e.g. cultural, functional, language) (Watson-Manheim et al. 2002, Espinosa et al. 2003)
21
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Vulnerability Costs EvaluatedVulnerability costs affected by time separation
Longer delays are introduced
Team forced to use asynchronous communication tools at times
when such communication media may not be the most effective
Lean communication media (e.g. electronic mail) may not be the
most appropriate form of communication for equivocal tasks
that contain more uncertainties (Dennis and Kinney 1998)
22
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Summary of Coordination ModelCoordination Model involves the following costs:
Individual production costs (Pc) necessary to carry out individual software development task activities
Coordination costs (Co) necessary to manage the dependencies among different task activities. These costs
are composed of:communication costs (Cc)delay costs (Dc)Clarification costs (Cf)Rework Costs (Rc)
Application of these formulas will vary substantially in complexity depending on:Timing of team members interaction (when request and response occur relative to each other)
Coordination costs are sensitive to time at which a request is initiated and the time at which
that request is responded to.
23
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Practical Applications for ModelCoordination model decomposes total cost of collaboration between developers with time
and/or distance separation.
Model can be helpful to project managers when creating budgets and schedules for
software projects.
Model is practical because it gives users the ability to change parameters and
relax/tighten assumptions
Possible practical expansions to the model:
Include the presence of multiple synchronous and asynchronous communication
tools
Would reduce communication costs by reducing the delay in exchanging
information
Different types of tasks (longer, more complicated) can be modeled by
increasing the task duration variable (Tt) and/or the frequency of task requests
(gamma) and/or increase the clarification variable (Pu).
Possible to add delays and assign priorities to tasks and then recalculate costs
24
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Coordination Model LimitationsMajor Limitations of model which affect its use in practical applications:
No distinction between task complexity:
Complex tasks need to be modeled as sequence of communication events which would increase the
communications costs on many levels.
Production cost estimate for a software project is way off without some knowledge about
complexity of task
Assumption made on mode of communication
Assumption that face-to-face communication occurs instantaneously
E.g. People in the same building have different schedules and meetings and other priorities
Coordination model needs to be adjusted to change communication delays based on task priority.
Higher priority tasks will involve multiple modes of communication to resolve the problem quickly
Less rework might be required as a result
Important issues get dealt with quickly and with quality because peoples jobs are on the line
25
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Issues in Global Software Development affecting Coordination Model
Time separation is reduced overlap in work hours and not necessary time zone differences
Reduction in overlap reduces the time during which synchronous communication can occur
Work schedules, holidays, weekends, and other scenarios increase overlap in work hours.
The model focuses more on time separation rather than time zone differences because it
many scenarios software development projects create overlapping work hours in spite of
different schedules to increase efficiency and decrease development costs due to
communication delay costs.
Time separation leads most teams to change their work norms
Components of Coordination model can be decreased
26
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
ConclusionModel contains five cost components:
production, communication, delay, clarification, and rework costs.
If a given time-separation configuration is not cost-effective,
developers will make decisions:
Change work schedules of some or all of its members to either
increase time overlaps to reduce clarification and rework costs
Reduce time overlap to reduce delay costs (e.g. shift work,
follow-the-sun)
• All decisions made provided that the timing of task requests can
be programmed optimally.
27
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Global Software Development in Practice Lessons Learned
Rafael Prikladnicki,Jorge Luis Nicolas Audy, and
Roberto Evaristo
28
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Motivations for GSD
Global Software Development is lucrative to commercial endeavours, not just for open source projects
What are some of the benefits to GSD that have motivated corporate organizations to start using it
29
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Motivations for GSD
Proximity to more customers
Software products easily delivered globally
Reducing time to marketUsually by employing 'follow-the-sun' development
Ability to select resources from a larger pool
Improve efficiency using resources where they are available
30
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
What makes GSD so unique?
Time-zone differencesReal-time communication is limited to small windows
Physical distanceOnline coordination tools inefficientNo face-to-face meetings
Cultural differencesLanguageTraditionsNorms of behavior
31
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Challenges of GSD
Strategy decisionsHow do you divide up the project?Which site has the resources to do each part?Which sites have the necessary experience and infrastructure?
Cultural DifferencesMiscommunication most often caused by cultural differences
What are some ways that these risks can be mitigated?
What are the major challenges of GSD?
32
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Challenges of GSD (contd.)
Knowledge managementBecause communication during GSD is so expensive, missing documentation results in lost productivityCompared to co-located projects, documentation provides a much higher return on investment due to the decrease in risk
What types of methods or tools could be used to improve knowledge management?
33
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Challenges of GSD (contd.)
Technical issuesProject management requires more effort, because synchronization of milestones is more difficultData network performance can impede project work
Intranet mechanisms that are fast on a single site may be painfully slow for a remote site due to latencyLarge project artifacts can take on the order of hours for remote sites to download, leading to lost productivity
34
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Related Work
GSD significantly affects how software is produced, so new mechanisms are needed to support it (Herbsleb and Moitra 2001)
(Karolak 1998) discussed a software life cycle tailored to GSD
Centripetal and centrifugal forces that affect GSD teams (Carmel 1999)
35
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Related Work (contd.)
Centripetal forces:Coordination breakdownLoss of communication richnessGeographic dispersionCultural differencesLoss of 'teamness'
What types of activities are needed to help hold teams together?
36
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Related Work (contd.)
Centrifugal forcesTelecommunications infrastructureStrong product architectureTeam buildingManagerial techniquesCollaborative technologyDevelopment methodology
37
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Related Work (contd.)
(Evaristo 2003) describes several dimensions to any distributed project where management should watch out for problems
TrustLevels of dispersionSynchronicityComplexityTypes of stakeholdersSystems methodologyType of projectsPolicies and standardsPerceived distanceCulture
38
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Studies
2 international corporations, both SW-CMM level 2
2 projects at each organization were interviewed
Data sources:1 manager and 5 developers in each project interviewedOrganizational and project surveys used separatelyDocumentation reviewsMission analysisBusiness processMeeting minutesSoftware process descriptions
39
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Study: Organization 1
Headquarters in Brazil with branches in Latin America, USA and Europe
9 units were responsible for consulting, training, and software development
80 people
RUP & PMI processes used in ISO 9001 organization
GSD chosen because of cost reduction/competitiveness, creating units of specialization
40
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Study: Organization 1 (contd.)
Project AApplication for a large US companyManaged on both the client and company side
Project BBanking application for company in BrazilSubcontracted to the group from another subcontractorFirst subcontractor represented the customer and sometimes the project team
41
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Study: Organization 2
Company headquarters in the US
180 people from 3 groups in 2 different continents
Responsible for worldwide internal computer demand
Microsoft Solutions Framework, RUP, PMI used
Applications used by international organization
GSD done for cost reduction, global strategy, and international trademark consolidation
42
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Study: Organization 2 (contd.)
Project CHuman Resources applicationCustomers in the US officeDevelopers in US and Brazil
Project DManufacturing applicationUsers and customers in USDevelopers in multiple branches but based in Brazil
43
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Studies: Results
What factors do you think would have affected the level of success of each of these projects
Table 2. GSD difficulties found
GSD difficulties Dimension Organization
Requirements engineering Technical 1, 2Software development process Technical 1, 2Software configuration Technical 1Knowledge management Technical 1Communication and language Nontechnical 1, 2Culture and context sharing Nontechnical 2Trust Nontechnical 1, 2
44
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Studies: Results
Problem areasLack of standards or processDifficulty in sharing information without a knowledge management systemRequirements phase consistently more difficult
More detailed requirements had to compensate for lack of information sharing
Software configuration managementEach site was working with different versions
Trust issues developedMiscommunication was common
45
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Studies: Results
SolutionsWork standardizationPlanningImproved formal software process
Especially requirements engineering
Risk management process (only used by Organization 1)
Process was specialized for distributed projects
Increasing trust through training on several topics
Leadership, Communication, Culture, Context Sharing,
46
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Case Studies: Results
Determining success factorsFormal processTrainingPlanning appropriate sites for each projectFirst interteam contactActivities to improve trust, communication, and feedback
47
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Lessons Learned : 1 & 2Project and risk management need more attention
GSD causes these tasks to take more timeProblems are able to go unnoticed for a longer timeThese problems will become serious threats to success
More detailed processes are needed
All projects without good processes sufferedAt the start of the project agree on the following:
Coding standardsCode ownershipToolsActivities
48
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Lessons Learned : 3 & 4Knowledge management causes information sharing and learning from experience
Co-located teams do this naturallyGlobally distributed teams must encourage this process
Requirements phase is the biggest challenge in GSDOften are unclear or have errorsWasted time results in increased project costsMitigation strategy
Spend much more time in requirements meetingEnsure all stakeholders are present in these meetingsFully document the results for all to see
49
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Lessons Learned: 5 & 6
Planning is the key to distributed projectsMatching the right project to the right teamIdentifying the associated risks before starting
Recruiting and training global teams minimized non-technical problems
Training before starting the project minimizes the chance of miscommunication
50
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Lessons Learned : 7
Tools help distributed interaction, particularly communication tools
Seek out the best collaboration tools you can findTeach everyone how and when to use themTeach the team when communication escalation is appropriate
51
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Lessons Learned : 8
Distributed Software Development is a maturity process
It takes organizations time to mature (much like with CMM) Most organizations are experiencing basic problems now, because they are at a lower maturity level
They could learn a lot from more the more mature
organizations, possibly preventing the same mistakes
52
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Analysis & Critique
High level of detail in case studies
Time zone differences not prevalent in all projects
Validated theory
Only observational
Other comments?
53
Collaborative Software Design and Development Coordination 4
EE 382V – Spring 08
Conclusion & Discussion
GSD will become the normImproved facilitating technologyContinued cost pressuresSmaller independent groups can specialize their process
Challenges will persistManaging non co-located teams is a continued challengeLargest challenge is reducing the problems that asynchronous communication create
Future work could focus on specific aspects
Requirements, Risk Management, or Project Allocation