disd proceedings

8/2/2019 DiSD Proceedings

1/178

International Workshop onDistributed Software Development

1


2/178

Daniela DamianSchahram Dustdar

International Workshop on

Distributed Software Development

Paris, 29 August 2005

2


3/178

Workshop on Distributed Software Development

Workshop chairs: Daniela Damian (Univ. of Victoria, Canada) and Schahram Dustdar(Vienna University of Technology, Austria)

This volume contains the proceedings of the First International Workshop on DistributedSoftware Development (DiSD), co-located with the 13th International RequirementsEngineering Conference. This workshop is a merge of two major workshops in the area ofdistributed software engineering: the GSD (Global Software Development) and CSSE(Computer Support for distributed Software Engineering), organized at ICSE, ASE, and othermajor Software Engineering conferences in the past 5 years.

Software development in geographically distributed settings is increasingly becomingcommon practice in the software industry. More and more software companies use computer-supported cooperative tools to overcome the geographical distance and benefit from access to

a qualified resource pool and a reduction in development costs. However, the increasedglobalization of software development creates software engineering challenges due to theimpact of temporal, geographical and cultural differences, and requires development oftechniques and technologies to address these issues.

The processes of communication, coordination, and collaboration are key enablers ofsoftware development processes. In particular, one set of development activities directlyaffected by challenges in communication is Requirements Engineering (RE) activities that

pervade the entire development life-cycle. Industrial case studies reveal the significant impactthat distance has on the management of requirements and how well-known problems of REare exacerbated in DiSD. The majority of distributed projects are characterized by distributedcustomer-developer relationships, be they inter-organizational projects or projects internal to

multinational organizations. Failure to achieve a common understanding of system features,reduced trust and the inability to effectively resolve conflicts result in budget and scheduleoverruns and, ultimately, in damaged client-supplier relationships. Further, the developerteam itself is often geographically distributed and experiences significant problems inrequirements management and related activities such as testing and project management (e.g.

project planning, progress tracking).

The goal of this workshop is to provide an opportunity for researchers and industrypractitioners to explore both the state-of-the art and the state-of-the-practice in DiSD. Inparticular, we intend to explore the specific challenges experienced by DiSD projects inconducting effective Requirements Engineering.

Our call for papers elicited contributions on topics that included, but were not limited to:

Case studies describing experiences of challenges of DiSD and RE in DiSD inparticular

Theories of communication, coordination, collaboration and knowledge managementin DiSD

The multifaceted nature of challenges in requirements management in DiSD

3


4/178

Collaboration infrastructure to support DiSD teams and requirements managementactivities in particular

Requirements Engineering processes and tools specifically targeted for DiSD projects.Workshop program

We are pleased to create a program of paper presentation and discussion that includes anumber of contributions in the areas of theories as well as practice reports in DistributedSoftware Development. Twenty paper submissions were reviewed by the Program Committeefor relevance to the workshop topics as well as potential to generate discussion of importanttopics at the workshop. Sixteen papers were selected for presentation in the workshop. Theone-day program is structured to include three Experience Reports, five papers on Theories ofDiSD, five demos of collaborative tools for DiSD, and three reports of early research reportson investigations of processes of Requirements Engineering in distributed computer-mediatedsoftware projects. We hope you have enjoyed the workshop program this year. We kindlythank you for your continued interest in this area of research.

Daniela Damian and Schahram DustdarWorkshop Chairs

4


5/178

Organization

International Workshop onDistributed Software Development

(DiSD 2005)29 August 2005

co-located with the13th IEEE Requirements Engineering Conference 2005

Program Committee Co-Chairs

Daniela Damian (University of Victoria, Canada)Schahram Dustdar (Vienna University of Technology, Austria)

Steering Committee

Filippo Lanubile, University of Bari, ItalyHarald Gall, University of Zrich, SwitzerlandAndrea de Lucia, University of Salerno, Italy

Program Committee

Kevin Ryan, University of Limerick, IrelandChristof Ebert, Alcatel, FranceAndreas Braun, Accenture GmbH, GermanyHeather Oppenheimer, Lucent Technologies, USALerina Aversano, University of Sannio, ItalyCornelia Boldyreff, University of Lincoln, UKPaolo Ciancarini, University of Bologna, ItalyGianpaolo Cugola, Politecnico di Milano, ItalyRick Dewar, Heriot-Watt University, UKPaul Grnbacher, University of Linz, AustriaFrank Maurer, University of Calgary, CanadaPierluigi Ritrovato, CRMPA, ItalyAndre Van Der Hoek, University of California, Irvine, USARafael Prikladnicki, Pontificia Universidade de Rio Grande du Sul, BrazilLiam Banon, University of Limerick, IrelandBrian Fitzgerald, University of Limerick, IrelandAllen Dutoit, Technical University Mnchen, GermanyStephen Rank, University of Lincoln, UKBernd Bruegge, Technical University Mnchen, Germany


6/178

Table of Contents

Experience Reports

Adel TaweelA Case Study of a Successful Collaboration in Distributed Software Development...8

An Ngo-The, Kiem Hoang, Truc Nguyen, Nhien MaiExtreme Programming in Distributed Software Development: A Case Study..17

Mark SheppardOrganizational Pattern Mining - A Retrospective on XP in the Large Scale SoftwareDevelopment Project...23

Theories in Global Software Development

Pr J gerfalk, Brian Fitzgerald, Helena Holmstrm, Brian Lings, Bjrn Lundell, Eoin Conchi

A Framework for considering Opportunities and Threats in DistributedSoftware Development....43

Allan Scott, Luis Izquierdo, Sweta Gupta, Robert Elves and Daniela DamianLeveraging Design Patterns in Global Software Development: A Proposal for a GSDCommunication Pattern Language...58

Karin K. Breitman, Miriam Say, Leonardo M. CoutoUsing ontologies in Distributed Software Development..72

Gamel O. WireduCoordination as the Challenge of Distributed Software Development......80

Bernd Bruegge, Korbinian Herrmann, Axel Rauschmayer, Patrick RennerSituational Requirements Engineering gets distributed ........................................................................85

Collaborative tools: Tool demo

Fabio Calefato, Filippo LanubileUsing the EConference Tool for Synchronous Distributed Requirements Workshops.....91

Naoufel Boulila, Allen H. Dutoit, Bernd BrueggeBootstrapping Incremental Design: An Empirical Approach For Requirements Identification andDistributed Software Development....102

Timo Wolf, Allen H. DutoitSupporting Traceability in Distributed Software Development Projects.....111

Andrea De Lucia, Fausto Fasano, Rita Francese, Rocco OlivetoTraceability Management in ADAMS ...125

6


7/178

Muhammad Ali Babar, June VernerGroupware Requirements for supporting software architecture evaluation process..140

Brand new research

Daniela Damian, Filippo Lanubile, Teresa MallardoInvestigating IBIS in a distributed educational environment: the design of a casestudy.... .153

Luis Izquierdo, Daniela Damian, Daniel GermanTowards Requirements management in a special case of global software development: A study ofasynchronous communication in the Open Source community.....159

Tom O Regan, Valentine Casey, Ita RichardsonVirtual Team Implementation and Management - A Position Paper......174

7


8/178

A Case Study of a Successful Collaboration in Distributed

Software Development

Adel Taweel1

Abstract:

Market pressures and an increasingly reliable world-wide communications network have madegeographically distributed software engineering a reality. With organisations becoming moredistributed across several countries, and with the shortage and the need for better utilisation of

skills resulting in team members unavoidably distributed across sites. These factors are forcingorganisation to develop strategies and enabling technologies in need for more successful

collaborative working.The paper reports on a case study of such successful collaborative working with a focus ondistributed software development teams in a project. It studies three teams but looks particularly atone of these teams whose members are separated by distance and culture, and outlines theimportant factors to its success.

Keywords: global software development, collaborative working, distributed software engineering

1. Introduction:Software organizations, even in some cases more than others, are increasingly separated bydistance, time and cultural boundaries [1, 2, 6, 12, 3]. This puts challenges on the softwaredevelopment processes and organizations due to fewer direct communication and interactions

between team members, harder to use traditional team building measures and introduces evengreater possibilities for miscommunication and misunderstandings of technical details and commonobjectives and goals [1, 6, 3, 5, 13, 7].

This case study describes the software development life cycle of a project, from its inception to nearcompletion, whose team members distributed across the UK and Europe. Although there are notime differences between the team members, but they are separated by distance boundaries,nationality and cultural differences. Despite these differences, the software development team wasconsidered to be successful where other teams in the same project, who has similar

configuration, were not considered to attaint the same level of success.

The main purpose of this case study is to identify factors that contribute for successful teamcollaboration across geographical and cultural boundaries, and to study the impact of the managerialstrategy and effective use of collaboration tools in the different stages of the software development

process with a focus on requirement specifications, design and implementation stages.

1University of Manchester, Manchester, M13 9PL, UK, [email protected]

8


9/178

The study followed a number of main steps to establish and outline the main contributing factors tothis successful collaboration, these include: determining what the teams did during their work onthe project, identifying the used collaboration tools and determining what was seen a successfulteam and identifying the factors that contributed to creating successful collaborating teams.

Section 2 of the paper gives an overview of the study and the study project, its organizational andgeographical structure. Section 3 discusses the details of the followed software developmentprocess focusing on requirement specifications and coding phases outlining the developmentprocess and the used collaboration tools. Section 4 discusses the main identified contributing factorsto this successful collaboration working. The detailed discussion of the study, detailed analysis ofthe data and its evaluation is beyond the scope of this paper. Finally, section 5 summarises thelessons learned.

2. Overview of the study and the study projectThe study project is a 5 year programme funded to accomplish a set of pre-determined objectivesand goals. These objectives include research and software outputs and products. The projectincludes 30 members distributed across five separate locations with individuals located at each site.The development team includes five sub-teams: three software development team, one scientificand one management team. The focus of this study is on the software development teams.

The project aims to develop a new product development based on three legacy products. Theproduct itself is a software product for processing medical information integrating four maincomponents into a functioning system that eventually interfaces with clinical staff and other third

party hospital systems. Three of these four components are based on legacy systems that requirefurther development and the fourth component is built from scratch. The development teams aremade up of mainly new staff employed or brought in specifically for this project with some

members have application domain knowledge and some others with experience in the legacyproducts.

The main two characteristics of the development teams are the problems of geographical andcultural separation. The five sites are separated geographically by long distance boundaries. Theofficial language of the project is English, however cultural differences range from differentlanguages (five languages), to different work cultures (three different cultures) and institutionalwork regulations.

Although the objectives of the project were clear, the requirements (more specifically the functionalrequirements) have not been established. One essential and immediate task for the team was togather, refine and agree requirements. However, given that the project is developing a new product,

there were a set of unknown research and technical problems that needed to be looked at beforeconcrete requirements are established. Also the project suffered a number of usual start-upproblems: new people that are not used to working together, not well defined or understoodprocesses, and new yet to be established management style. In other words, developing a softwareproducts with untried organisational and management structures and further complicated bygeographical and cultural barriers.

The study has looked at the project from almost its start, although very early parts of the case werestudied retrospectively. Since we are focusing on the collaboration tasks, used technologies and

9


10/178

activities undertaken in the project, the study aimed to collect data about the critical factors in thesuccess of the software development team as a successfully multi site functioning team. Data werecollected from various sources including the project historical log, the project management team,the project evolving documents, and the project development teams.

One particular advantage was the structured documentation of the project and the collaborationtools used in the project, where significant amount of information was recorded about thedevelopment team activities, discussions, actions and so forth, from which factors were studied asto what made the software development team a successful multi-site collaborating team. Thisrecorded information provided a good indication of what have been considered done well andachieved their objectives and those done poorly and partially or failed to achieve their objectives.

3. Software development processThe following describes briefly the followed development process in general, with a focus on therequirement specifications and coding phases.

3.1. Eliciting requirementsOne of the major tasks of the project was to establish and refine requirements. The main source forthe preliminary set of requirements was from the scientific team and the involved users. However,due to distance and geographical separation traditional requirement engineering methods, such asface-to-face interviews, focused meeting etc., were not easily possible [11, 13]. The developmentteam initially started experimenting with different methods of eliciting requirements to overcomethese difficulties until a general methodology was established. The general approach was based onan iterative cycle that begins from a generic and moves towards a more specific and refined

requirement specifications. It follows three main stages: 1) preliminary general set, 2) defined andfiltered (and prioritised) sets and 3) finally refined, well-understood and confirmed sets. Toovercome the geographical separation, the first stage was done using collaboration tools, e.g.specifically web-based Wiki pages, with web forms that were specifically designed that allow usersand scientific team members to input their requirements. Although, this stage resulted in a long listof requirements, after studying them in some detail the software development team found more than26% were repeated requirements, 10% included partial repetition and 15% were spurious (toofuturistic or beyond the objectives).

To define, understand and prioritise these requirements, in the 2nd stage different collaboration toolswere used. A sub-team (includes four members) made up from senior members of the studieddevelopment teams, the project manager and the scientific team filtered and classified the initial set

of requirements into prioritised sets of categories based on the project set objectives. Because of thesize of this team and there is not a major time difference between members of the team, this stepwas done using collaborative teleconferences with traditional web-based presentation tools. Then ina wider community including other development teams, scientific team and selected users, focusingincrementally on a selected set of requirements, discussion web-based forums were used to analyseand discuss these requirements until have reached sufficiently the level for the development team tohave felt comfortable with the meaning, depth, importance and priority of each to carry to the nextstage. In cases where agreement (or consensus) was not reached, the decision was differed anddelegated to the management team to address in greater details with relevant stakeholders. Most

10


11/178

reported such cases were related to prioritisation of requirements opposed to expectations, forinstance. In cases where requirements where not clear or ambiguous, either relevant members orusers from whom these requirements originated were further consulted, and/or these requirementswere put in a separate list and carried to the 3 rd stage for more focused discussions. Becausecontributions in web-based discussion forums are in written forms and are asynchronous, these had

the advantage for the involved members to think about responses on their own pace and minimisepotential misunderstandings. This also has noticeably helped to reduce the impact of language andcultural barriers [1, 6, 14, 5, 13, 11]. On the other hand, it took longer than initially anticipated tocomplete this stage, mainly due to the nature of the asynchronous responses but also due to absenceor busy schedules of relevant users. In few cases, users did not contribute unless they wereindividually invited to do so, which caused further delay, although they were repeatedly asked toengage in the process.

In the 3rd stage on the other hand it was required to refine, well-understand and to confirm each ofthe requirements, especially the functional requirements, to carry forward to the softwaredevelopment teams to start the design and implementation. The aim of this stage was to takeseparate categories of requirements and discuss them in details sufficient for implementation. Two

main types of collaboration tools were used in this stage: video and teleconferences. However, itwas realised early on, in fact from the first few sessions, that large distributed teams are not

particularly productive for this type of activity using these tools, especially when disagreementsarise. To overcome this problem, similar to the 2nd stage above, requirements were re-categorised interms of domain and functionality for the work of focused smaller sub-teams. As noted, having asmaller team has helped to allow greater interaction between team members and create morecomfortable collaborative environment and noticeably greater contribution from (especially lessconfident or shy) members [3, 6, 14, 13].

Using available presentation tools, teleconferences or videoconferences, the software developmentteam produced prototypes for up-coming sessions, mainly using rapid prototyping tools [16], toillustrate and confirm understanding. Occasionally e-mails, and regularly both teleconferences andvideoconferences were used in this stage, however wherever and whenever possiblevideoconferences (such as Access Grid tools [17]) were used to allow greater interaction betweenmembers. This experience was also noted by other research reported in [1, 2, 15, 3, 13]. As noted insection 4.2, we noted an important element for using these collaboration tools effectively, the teamwill need to have established working relationship, perhaps through previous experience or througha number of face-to-face meeting. One of the noted effects of this experience is its contribution tothe performance of one of the software development teams compared to the other two softwaredevelopment teams [9, 1, 6, 11, 10]. On the other hand, the occasional breakdown of thecommunication networks or in the collaboration tools resulted, in few cases, in cancelling meetings,which caused significant delay. Therefore, it was essential to set up a long series of meetings as acontingency measure to help overcome this problem. In cases where input on requirements was

required from busy users or stakeholders who usually have busy schedule, face-to-face meetingswere the preferred choice, in most cases to avoid delays in others because of non-familiarity withthe tools. These face-to-face meetings were usually set after the relevant requirements have gonethrough several iterations of discussions.

Towards the end of this stage, a formal written document of the agreed requirement specificationswas produced from all teams and circulated for final amendments. The project manager followed upthis process with direct communication with individuals or teams to obtain general consensus fromall stakeholders. An added value of the 3rd stage was its positive effect on change management.

11


12/178

While the development strategy in the project was iterative to accommodate the inevitable changein requirements, however the collected data indicates that this stage has helped to minimise majorchanges in requirements in particular and to contribute to change management in general.

3.2. Software coding processAfter the completion of the first cycle of the requirement specifications process, softwaredevelopment teams with the system architect started the design and the implementation processes.As mentioned above, three components are based on legacy products and one was created fromscratch. These four components are partially dependent however each distributed softwaredevelopment team was working on a vertical sub system made up of at least two or more sub-components, with interdependency kept to minimum where possible. The initial phase of allocatingtasks to teams was therefore straight forward. Tasks, in this phase, were allocated to teams based onthe logical understanding of the system. This was made easier because of the existence of the legacycomponents which their dependency pattern was known and not complicated. The main dependencywas with the fourth component. In fact the major part of this phase was completed before or while

teams being formed. The general architecture of the system was initially created by the systemarchitect and iteratively refined and agreed with the development teams, however the detaileddesign of each vertical sub system was done by the members of the respective development team as

per the allocation. As mentioned above, in the 3rd stage of eliciting requirements, the requirementswere re-classified on domain and functionality which relatively coincided with each vertical subsystem, this resulted in members of each development team to engage early on in understanding and

prioritising the requirements, which greatly helped to facilitate the design stage.

A central source version control system was set up to hold developed source code, a long withenforcing an implementation strategy including coding convention, testing plans, source codeupdates and so forth, to keep coherent pattern of development. A central web-based bugs trackingsystem (such as Bugzilla [18]) was set up with guidelines to enable a systematic tracking andhandling of errors. Although there were general guidelines for the three teams, each team haddefined the details of their own individual conventions, their working patterns, their collaborationmechanisms per se.

4. Successful collaboration: contributing factorsSeveral factors were identified as contributing factors to the success of the collaboration of thedistributed software development teams including the design of the development process as outlinedabove, the choice and the effective use of collaboration tools and commitment of the team members.The following discussion concentrates on another two main factors that had significant effect as

noted by the team.

4.1. Managerial Strategy and team buildingThe impact of managerial strategy factors on determining the successful working of the team wasclearly visible in the teams responses. One advantage was the experience of the management teamand their awareness of the literature on virtual and distributed software teams geographical andcultural issues. This helped the management team generally to avoid some of the pit falls that can

12


13/178

be easily ignored in traditional co-located teams, some of the team building measures, assumingtrust, or ad-hoc discussions for example [9, 1, 4].

With most members of the development teams employed or brought in new, it was essential toestablish a working relationship between them, at least in each individual team. A managerial factor

that contributed significantly in the determining factors for the successful working of the team issetting up a pattern of initial face-to-face meetings. These working meetings helped to bridge gapsbetween members and establish social and working knowledge between them, and set the seeds fortrust in the teams [6, 10]. Other factors in building the teams, such as, selecting complimentaryskills, domain knowledge, and minimizing cultural barriers have also been taken into account [9, 1,6]. Also since there were no immediate software deliverable deadlines, this gave sufficient start-uptime for the software teams to form a trustful working relation. The importance of such factors inthe team building process has been noted elsewhere [9, 1, 6, 4, 13].

One of the noted managerial factors that contributed to successfully working together in such asetup is establishing a pattern of self management for each team and at each site. For example, foreach of the team leaders the objectives have been outlined at the beginning and each was given the

context in which they are expected to work and use their own initiative to derive the team to get thework completed. From teams responses, this approach has given the team the freedom andflexibility to derive their own work in the best way they see suitable for their own team working

pattern. This strategy has initially been set as a result of the management team experience of thepositive effect this strategy may have on teams self esteem and productivity, but its importance wasnot realised on its even greater effect on having a successful distributed team, as noted by themanagement team.

With this flexibility in hand, team leaders established their own working patterns, set their ownfocused vision of what needed to be done and the plan to achieve it. Thus the teams ended up withtheir own agendas but agreed on shared critical path (e.g. for dependent components), criticalresources (e.g. video/teleconferencing facilities, or shared staff) and meeting (intermediate and end)

points. Team leaders took the initiative to proactively work and plan ahead rather than wait to reactwhen crises arose. The software development team leaders fruitfully exploited the context for self-management by successfully managing themselves.

Another managerial factor that kept the system with a common vision was the bringing in of asystem architect that brought the systems various technologies and development threads together.The architect was a common point of contact for team leaders that helped to reduce frictions and theotherwise amount of interactions needed for interdependent components. Two main interfacingactions the architect established in the working pattern between members and teams: integrationfests and design fests. The latter was used to set a commonly shared vision of a technical designof interdependent (or in some case challenging) components, while the former was used, in initial

stages, to establish application interfaces patterns and, in later stages, to integrate components orresolve integration issues.

4.2. Collaboration and collaboration toolsVarious collaboration tools were used in the project at various stages of the development process.Initially, the focus was on using face-to-face meetings, mainly for the teams and team members toknow each others and help establish a working relation and trust - these factors have been seen

13


14/178

essential by the management team. During this period however, a limited combination of video andteleconferences and web-based collaborations were used. As the project advanced, the use of thesecollaboration tools became more common.

Wiki pages and discussion forums were used as the main web-based collaboration tools to share

documents, information, open discussion pages and discussion forums. Video and teleconferencestools were used to substitute face-to-face meetings. Also e-mails, shared repositories and other toolswere also often used.

The importance of using suitable collaboration tools was realised early on in the project by themanagement team. Their function has not only been seen to facilitate collaboration between teammembers, but also, if effectively used, to create a common hub of information that in a way

provides transparency in the project of all its components and teams (including the managementteam) actions, activities, output, work plans and so forth. This transparency was seen to at least

partly substitute for some of the activities that commonly exist in non-distributed teams, such as ad-hoc discussions, social or informal face-to-face meetings etc, which are important factors for theteam building process [1, 6, 4].

One essential factor for the successful working of the distributed team in general and the distributedsoftware development teams in particular is how successfully teams and members of eachdistributed team collaborate or work together. While the final goal is perhaps the quality of theoutput of each team and the output of teams collectively, the process of having a successfulcollaborating team was seen by the management team as the key to achieving this final goal. Theargument is that a successful working team, despite the geographical and cultural problems, willhave a higher chance of reproducing quality outputs, opposed to one that has done a good jobonce for instance. In other words, for a team being successful has greater implication than justhaving achieved their objectives once, the operational behaviours of the team are greaterdetermining factors for a possibly continuing successful collaboration.

Using the collaboration tools, the effectiveness of the tools, the way and how the tools are deployedor used, the teams effectiveness of planning their activities, the teams ability of self management,the working relation between teams or team members, how well done and the quality of the output

product, and the teams ability to overcome the geographical and cultural problems are the mainfactors derived from the recorded information or the interviews of the software development team.The management team on the other hand, although generally agree with the above factors, had lessemphasis on the first three factors. While they realise their importance, but they believe theirimportance is more as contributing factors rather than essential to achieve the latter factors. Thefollowed managerial strategy including the measures undertaken to creating the teams also wereidentified as contributing factors to successful working distributed team.

5. Lesson learnedA number of lessons have been learned from this study. These are summarised below. Suitable collaboration tools: It was clear that the use of suitable, robust, and simple but

effective collaboration tools is essential to the success of the team. Using tools that developersare not familiar with, need significant training, complex to use or have cumbersome interfaceswill only lead to eventually being abandoned. Team members were hesitate to use tools with

14


15/178

overloaded functionalities, as they usually take longer to set up and load, and most likelyconfuses and deviate users from its main functionality.

Established working relationships: Face-to-face meetings were essential at the beginning ofthe project to help establish working relationships, trust and work pattern between members of

the team. It was noticed that the studied team had more initial time to establish good workingrelationships, which later contributed to the team productivity as it was usually faster tofinding workarounds and resolving conflicts between team members, compared to other teams.

Documentation: precise and complete documentation is a critical factor for reducingambiguities and ensuring consistency. Using some of the collaboration tools provided part ofdocumentation, such as taken decisions, identified requirements or problems, as an addedvalue. Therefore it is very helpful to use suitable collaboration tools especially when it comesto finding or referring to information. Documentation includes details of requirementspecifications, design method and symbols and coding conventions.

Flexible planning, clear objectives and work schedules: while good planning is crucial for thesuccess of a distributed team, it is evident that less flexible plans add unnecessary pressures onthe team members which may well affect their productivity. One noticeable factor was themanagerial strategy that allowed each team self-management, which has provided a distinctadvantage for teams to feel in control and to better accommodate controlled deviation from

planned schedules.

Interfaces and development methods and tools: One of the factors that emerged during thisstudy was the importance of having defined set of interfaces between developed components.Design fests and integration fests proved very effective activities to achieve this aim. Alsohaving a compatible set of development methods and tools at participating sites reduced the

pain and difficulty in moving code between team members and facilitated code testing on

different machines.Although the above lessons give clear indication of some of the main contributing factors tocreating a successful collaboration in distributed software development teams, there remains anumber of issues and questions that still need further investigation. For example, team buildingmeasures do not clearly show methods of retaining successful teams, or rebuilding a team after ithas failed, or indicate the effect on the distributed team when staff leave or join in the middle ortowards of the task. One such example was recorded in one of the teams, although a slow

productivity was indicated this case was not sufficiently documented to analyse. But this does notonly depend on the new staff abilities and experience but also on the timing, the critical anddependency paths of development.

Acknowledgment

The author thanks all colleagues and team members who contributed to this study.

References

[1] CARMEL, E., Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall, Oct 1999

15


16/178

[2] GORTON, I., Motwani, S., Issues in Co-operative Software Engineering using Globally Distributed teams,Information and Software Technology, Vol. 38, pp.647 - 655, Jan 1996.

[3] GORTON, I. and Motwani, S. (1994), Towards a Methodology for 24-Hour Software Development Using GloballyDistributed Development Teams, Proc. of the 1st IFIP/SQI International Conference on Software Quality andProductivity, Hong Kong, pp 50-55.

[4] GERMAN, D., The GNOME Project: a Case Study of Open Source, Global Software Development, Software.Process Improve. Pract.2003; 8: 201215

[5] HERBSLEB, J. D., Grinter, R. E. and Finholt, T. A. (2001), An Empirical Study of Global Software Development:Distance and Speed, Proc. of ICSE'2001, Toronto, Canada, pp. 81 - 90.

[6] ISHII, I., Cross-cultural communication and CSCW, In L. Harasim (ed.), Global Networks: Computers andInternational Communication, Cambridge/London: MIT Press, pp.143-152, 1993.

[7] KRAUT, R. E. and Streeter, L. A. (1995), Coordination in Software Development, Communications of the ACM,Vol. 38 , No. 3, pp. 69 - 81.

[8] LAU, F., On Managing Virtual Teams, Technical report series 1999 No. 1, University of Alberta, URL:

http://www.bus.ualberta.ca/flau/Papers/cacm.htm. March 1999[9] MCGRATH, J. Time Matters in Groups, in [8], pp 23-61.

[10] PAETSCH, F, et al , Requirements Engineering and Agile Software Development, 12th Workshop on EnablingTechnologies: Infrastructure for Collaborative Enterprise, Austria, pp.308, 2003

[11] PRIKLADNICKI, R., Audy, J and Evaristo,R, Global Software Development in Practice Lessons Learned, Softw.Process Improve. Pract. 2003; 8: 267281

[12] SUZUKI, J. and Yamaoto, Y. (1999),Leveraging Distributed Software Development, IEEE Computer, Vol. 32,No. 9, pp.59-65.

[13] SEAMAN, C. B. and Basili, V. R. (1997), Communication and Organization in Software Development: An

Empirical Study, IBM Systems Journal, IBM Centre for Advanced Studies, Vol 36, No. 4, pp. 550 564[14] TAWEEL, A., Brereton, O. P., Developing Software Across Time Zones: An Exploratory Empirical Case Study,

International Journal Informatica, December 2002

[15] VAN FENEMA, P. C. (1997), Coordination and Control of Globally Distributed Software Development Projects:The GOLDD Case, Proc. Of The 18th Conference on Information Systems, Atlanta, GA, pp. 474 - 475.

[17] see www.accessgrid.org

[18] see www.bugzilla.org

16


17/178

EXTREME PROGRAMMING IN DISTRIBUTED

SOFTWARE DEVELOPMENT: A CASE STUDY

An Ngo-The1), Kiem Hoang, Truc Nguyen2), Nhien Mai 3)

Abstract

This case study reports an on-going effort to apply eXtreme Programming (XP) in Quantic, aVietnamese IT company specialized in subcontracting outsourcing software projects. While manyother case studies address distributed software development from the perspective of theorganization owning the projects, this study is special in that it approaches the problem from the

perspective of the organization subcontracting the projects (subcontractor). The study serves as the

preliminary experiment of a research program concerning the application of agile methodologiesin distributed software development. While one can argue that the lack of face-to-face contactmakes distributed software development irrelevant for agile methodologies, we believe that agilitywould be the best response to communication issues that are too complicated to handle with a rigid

process. Even when co-location is impossible, the agile approach can still inspire other flexible andefficient means to address issues concerning communication. It is still too soon to talk about any

solid finding, but what we have observed reinforce our belief in the ability of the agile approach toaddress difficult issues in distributed software development.

1. Introduction

Quantic Ltd. (http://www.quantic.com.vn) is a Vietnamese IT company specialized in outsourcingwith clients in North America, Europe and Asia, including Nortel, Cisco. Until now, the projectsreceived are either small projects or components of larger projects. Typically the size of a projectteam is no more than ten. The company has its own software process but is ready to followcustomized process when required. As a subcontractor, the challenges faced by Quantic are not thesame as those faced by the project owners such as Nortel, Cisco. For example, it does not have toface the problem of coordination different (sub)-project teams across many sites. The complexity ofcommunication is reduced to two sites (the customer and the team). On the other hand, while thedecisions concerning development process are crucial for both sides (customer and subcontractor),the voice of the subcontractors side is usually weak. Currently, one important concern of Quantic

is to improve the software development process: To increase the efficiency of the communication between the team and the customer (e.g.

understanding of the requirements, handling requirements changes on time); To increase the ability to comply with customized process.

1 University of Calgary, [email protected] Center for IT Development, Vietnam National University-HCM City, {hkiem, ntttruc}@citd.edu.vn3 Quantic Ltd, [email protected]

17


18/178

In order to achieve such flexibility, the agile methodologies [1] seem to be the most appropriatecandidates. The company, in cooperation with the Center for IT Development, Vietnam NationalUniversity at Ho Chi Minh City, has initiated a research program to investigate the application ofagile methodologies in the development of outsourcing software projects. It has decided then tostart with a partial deployment of eXtreme Programming (XP) [3] in a suitable pilot project.

Feedbacks from the project manager, the team members and the customer will be considered beforethe decision to continue to explore the application of XP. The paper reports this case study and isorganized as follows:

Section 2 describes the motivation of a research about methodologies at Quantic; Section 3 discusses the rationale of the choice of agile approach and XP; Section 4 present the deployment of XP in the pilot project; Section 5 discusses the lessons learnt and further research.

2. Motivation

In an outsourcing project, the customer has a decisive voice about the development process. This

means that there can be one different process for each customer. The positive side is that thecompany and its employees have a diversified portfolio of processes. The negative side is that it ismore difficult for the company to organize a simple framework to capitalize the experiences andknowledge obtained from its projects. Currently, research in software process concentrates on the

perspective of the organizations owning a project but little is done from the perspective of theorganizations subcontracting an outsourcing project. We see here a need to explore new approachesto face this challenge.

Furthermore, at Quantic, we observe that the customers have applied certain measures to addressthe challenges of DSD. Here are some examples:

Outsourcing projects are either independent or loosely couple with others. This reduces theneed of intensive collaboration and therefore alleviates the communication problem [4].

Liaisons, engineers who move from the development site to the customer site and stay therefor a certain time, are used not only to improve the technical understanding but also todevelop relationship [2].

Reduction of cultural distance [4] is achieved by the integration of a cultural liaison, anexpatriated Vietnamese or a foreigner living in Vietnam, in almost every team.

However, many of the processes used are mainly a variation of the waterfall model with someimprovements (e.g. dividing the project into small set of features so that each set can be finished ina shorter time). In this situation, despite all the measures to improve the communication,misunderstandings, changing or new requirements are frequently detected at the delivery. These

problems can easily be related to the deficit of communication which is almost unavoidable for anoutsourcing project. From the technological perspective, there is little we can do since the companyhas used every available technique such as: telephone conference, net meeting and groupware.Therefore, if there is a way to improve the situation, it must be sought from the methodological

perspective.

18


19/178

Until now, our voice in the decisions related to development process is weak. As a stakeholder, weargue that an active participation from our part would be beneficial to both sides. Conducting ourown research about methodology will help is to promote the idea and play this role moreeffectively.

3. Rationale of the choice of agile approach and XP

Before engaging in this experiment, we need a bit more consideration about the arguments for andagainst the application of the agile approach. The introduction of agile approach is not verywelcome in Vietnam due to the following reasons:

The market is dominantly outsourcing and it is widely believed that the lack of face-to-facecommunication make agile methodologies, particularly XP, irrelevant.

It is also believed that the deficit of communication should be compensated by moreformalized management processes, more comprehensive documents.

Agile methodologies are still very controversial, not yet establishedWe address these concerns by observing that:

Agility would be the best response to communication issues that are too complicated tohandle with a rigid process. Such principles as co-location, on site customer should beinterpreted in an agile manner and should not be used to invalidate the approach when theycannot be literally implemented.

As pointed out by Simons [10], Fowler [6], we do need more documents to compensate thisdeficit of communication, and this can be very well addressed in agile methodologies.

The fact that success stories are anecdotal is true not only for agile methodologies.

As for the appropriateness of agile methodologies for outsourcing project, our belief has beenreinforced by the experiences resumed by Simons [10] and Fowler [6]. Other authors have pointedout that practices of agile methodologies are applicable and efficient in the context of DSD, e.g.iterative and incremental processes [8], test-driven [9].

We have chosen XP because: The practices of XP are concrete, intuitive, convincing and can easily accepted by the

project managers and developers (of Quantic); XP can be deployed partially and incrementally. So the fact that certain practices are not

convincing enough to everyone and need more preparation does not prevent its application.Since the initial commitment is light, the risk is low too and therefore, people are morewilling to try.

4. Case study

4.1. Selection of pilot project

A Web application from a Japanese customer has been selected as the pilot project because: It is independent and small and its requirements are highly volatile; The cultural distance between Vietnam and Japan is small;

19


20/178

Most importantly, the customer is open to our suggestions concerning the developmentprocess and the commitment of the customers side.

4.2. Selection of XP practices

Since we have no previous experience with XP and neither formal training nor external coach isavailable, we have to be very careful in the selection of practices to deploy in this first experiment.We divide the 12 XP practices into three categories.

4.1.1 Strictly Applied

In this category, we clearly indicate that the practices must be strictly respected. There are fourpractices falling into this category:

Testing. Refactoring Coding standards.

Simple design.

The developers are trained and required to follow the guidelines in [3],[5],[7] to implement thesepractices at work. These practices are the best understood by the team members and almostcompletely under our control. No matter which process is imposed by the customer, these practicescan be applied and help to improve the quality and productivity of the developers. Coding standardsmust be understood at the project level, i.e. when there is conflict between our own standards andthose of the customer, the latter prevail.

4.1.2. Adapted

These practices are adapted to the specific context of the project. Some practices are not completelyunder our control, we can only apply them to the extent that they make sense and stay incompliance with customers standards. Others are not completely understood by everyone andtherefore the team is not ready for their application.

Continuous integration Coding assignments are broken up into small tasks, preferably ofno more than one day. When each task is completed, it is integrated into the collective code

base. As a result, there are many product builds each day. Small releases This practice and the previous one are strictly related. However, their

implementation depends on the customers collaboration. We try to have small releases, butsometimes, the customer is not available to give feedback on these releases.

On site customer This is obviously impossible. However, as suggested by Simons [10], aproxy customer is just good enough.

Pair programming This practice is subtle and needs an appropriate coaching program. Theteam is not ready. In general, few people (in Quantic) strongly believe in the virtue of this

practice. Therefore, we just explore by requiring that each developer spends about one half-day per week to pair with the project manager.

40-hour week The idea sounds attractive but not easy to rigorously apply. We keep themain idea that overtime should be exceptional. Developers need more preparation to be ableto this practice beneficial to everyone (the management, the customer, and the developer).

20


21/178

4.1.3. Recommended

These practices (collective ownership, metaphor, planning game) are not very well understood andneed more preparation. For example, collective ownership can only gradually achieve when the pair

programming practice becomes standard.

4.3. Deployment

The pilot project started on Feb 2005 and is planned to finish at the end of August 2005 (sixmonths). The team has six members. The customer has a representative in Vietnam who can playthe role of a proxy customer, but does not substitute the customer. The team communicates with thecustomer (in Japan) using email, telephone conference, documents, etc The proxy customersrole is to supplement this communications by clarifying the subtle points that are difficult to getthrough other means of communication, bridging the difference in terms of national andorganizational culture, materializing an informal relationship between the two sides. This person isnot 100% dedicated to the project but at least, a face-to-face meeting (even an informal meeting)with the team can easily be arranged. The official language is English. The proxy customer can

speak a little Vietnamese and the project manager can speak Japanese fluently.

The planning is still organized in a traditional manner with a blend of XP philosophy. The planningconsists of releases and iterations as suggested by XP but user stories are not used. The customerdoes not commit to writing them; and the project manager and the team are not eager to promotethem. Instead, just enough requirements documents are sent to the team and clarified throughdiscussion (telephone conference and/or with the assistance of the proxy customer). The team

breaks down the requirements into tasks. Task assignment and effort estimation are done bynegotiation between the project manager and developers. Past performances are used to estimateeffort.

5. Conclusions

We arenot yet at the end of the pilot project. It is still too soon to jump to conclusions about theappropriateness of XP in Quantic, let alone in Vietnam. However, following the progress of the

project, the feedbacks from the developers, the project manager and the client, what we can observeuntil now is very encouraging.

The average working time of the team is 44 hours/week, i.e. only 4 hours overtime. This isstill far from the ideal 40-hour week, but already a considerable progress. Putting it in thecontext of Vietnam, where overtime (in IT companies) is a social norm (though not paid),we consider this achievement very significant.

We observe that an important part of misunderstood issues are not due to the lack of face-to-face communication, which we can do little about, but the lack of product-user

communication, which is very efficiently addressed by an agile approach, XP in our case.Even without proximity between the customer and the team, many issues concerningrequirements have been detected early (not in the traditional sense, here early means thatlittle effort has been spent).

The team, with experience in other project developed in traditional methodologies, finds theXP practices practical and efficient. The teams morale is high during the project.

The customer is also happy with the progress of the project. The early and frequent contactwith the product is assuring to the customer. The customer establishes a sense of ownership

21


22/178

of the product soon after some initial releases, feels much more in control of the project,despite the lack of direct contact with the team. When it comes to the need to modify the

plan due to changes of requirements, this understanding facilitates very much thenegotiation. We find out that these releases are themselves a means of communication.

Even this project has not yet finished, Quantic has prepared to apply XP in other projects andcontinue to cooperate with CITD. Our future research will explore the following directions:

To fine tune XP in the context of a subcontractor, where the subcontractor has no fullcontrol on the decisions related to development process. This direction will investigate thequestion of adapting XP practices to different development process.

To investigate the role of releases as a means of communication.We see in the research concerning methodologies from the perspective of the subcontractor animportant role in DSD. It can also be useful to other form of DSD (offshore units within aninternational organization). As conclusion, globalization in software engineering is not the questionof a dominance of a global process, but the synergy of different processes existing harmoniously.

6. Acknowledgement

The authors gratefully acknowledge the financial support of the Alberta Informatics Circle ofResearch Excellence (iCORE), Quantic Ltd and CITD.

7. References

[1] http://www.agilealliance.com

[2] BATTIN, R.D., Crocker, R., Kreidler, J. and Subramanian, K., Leveraging Resources in Global SoftwareDevelopment, IEEE Software March/April 2001

[3] BECK, K., Extreme Programming Explained, Addison-Weslry, Boston, 2000

[4] CARMEL, E., and Agarwal, R., Tactical Approaches for Alleviating Distance in Global Software Development,IEEE Software, March/April 2001

[5] FOWLER, M. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.[6] FOWLER, M. Using agile software process with offshore development.http://www.martinfowler.com/articles/agileOffshore.html, April, 2004

[7] JEFFRIES, R., Anderson, A., and Hendrickson, C. Extreme Programming Installed. Addison-Wesley, 2000.

[8] PAASIVAARA, M., Lassenius, C., Using Iterative and Incremental Processes in Global Software Development, in

proceedings ICSE Workshop on Global Software Development, May 2004

[9] SENGUPTA, B., Sinha, V., Chandra, S., Sampath, S., and Prasad, K.G., Test-Driven Global SoftwareDevelopment, in proceedings ICSE Workshop on Global Software Development, May 2004

[10] SIMONS, M., Internationally agile, InformIT, 15.03.2002

22


23/178

ORGANIZATIONAL PATTERN MINING - A

RETROSPECTIVE ON XP IN A LARGE SCALE

SOFTWARE DEVELOPMENT PROJECT

Mark Sheppard

University of Limerick / LogicaCMG Mobile Networks

Abstract

This paper examines the role of XP on a large scale distributed software development project,highlighting how this agile method contributed to the successful delivery of a large scaletelecommunications messaging system. Additionally, it explores the organizational patterns thatare evident in the project and relates the relevance of these organizational patterns in the contextof distributed software development.

Using an effective and efficient development process can have a significant impact on a softwaredevelopment project. Employing a process that is lightweight, flexible and focused will contributeto the success of a project. An adapted form of XP was successfully applied to a large scaletelecommunications systems development project. The contribution of XP to this productdevelopment was significant. Thus one can conclude that XP can be applied to large scale

software product development but not without some level of adaptation. Additionally, the projectstructures and development process used for this project provide us with significant empiricalevidence for successful running of a large software development project. These structures and

process are worth capturing. In this respect the organization patterns described in [13] provide uswith a way of capturing this knowledge. Thus by examining the experiences in a successfuldistributed software project, it is possibly to capture and document this experience and provide an

insight to organizational design for GSD.

1. Introduction

In todays highly competitive and fast moving global economy there is a demand for the timelydelivery of high quality product. The emphasis is on reducing cost and time to market. The need foreffective and efficient software development process is therefore evident. This emphasis on costreduction and time to market is likely to lead, as with globalization in general, to the outsourcingof software development. Carmel [11] provides a taxonomy of structural arrangements fordistributed software development and Cockburn [12], also, highlights a range of possiblescenarios: multi-site, offshore, open source model. The significant characteristic is that there existsa virtual team, which is dispersed both in time and location.

The driving factors are many and they include mergers, strategic partnerships, cost reduction,increase productivity and faster product development, closeness to a market and so on [11]. Thecontext of geographically dispersed multi-site development introduces many challenges andimpediments. For distributed software development to be an effective (especially cost wise) methodfor software system and product development, these must be addressed and overcome. These

23


24/178

challenges span the issues of infrastructure, tools, communications, culture, trust, co-ordination,integration, culture and so on.

The use of agile development methodologies has been seen to successfully deliver high qualitylarge-scale software systems [42], [20], [45], [19]. Typically the application of XP has been

targeted at small to medium sized projects. In [42] pure XP model was adapted for application inlarge-scale software development project. This is summarized in section 3. Thus if XP (, and otheragile development methods,) can scale in terms of project size, then it is pertinent to ask if it is

possible to utilize aspects of this development approach in the context of distributed softwaredevelopment?

However, one of the central features or characteristics of XP and agile development, as highlightedin the agile manifesto [22], is that of interaction and communication. This occurs within the projectteam and with the customer. It is widely recognized that distance significantly impactscommunications [32], [18], [25], [11]. Additionally, many other factors identified as challenges to

be overcome, such as different time zones, culture (national, organizational), infrastructure impactcommunications and interactions. Thus significant challenges exist and must be solved tosuccessfully apply, adopt, adapt agile methods in a distributed context.

Nonetheless, these are not impossible challenges and there is evidence that agile techniques can besuccessfully employed in a GSD context [25], [43], [44]. The promise that XP and other agilemethods offer as an effective and efficient development process, such that they have a significantimpact on a software development project, is enticing for their consideration to this area ofdistributed software development. Employing a process that is lightweight, flexible and focusedwill be of significant benefit to any software development project.

In order to achieve this goal further, then it is necessary to look beyond pure process, tools, andinfrastructure. It is necessary to examine organizational structure, roles, relationships,

interdependencies, collaborations, communication networks and patterns among organizational unitsuccessfully engaged in GSD. It is necessary to explore, identify, extract and document theorganization and process patterns of GSD organizations as they overcome the barriers of time anddistance.

This paper explores the successful use of XP on a large scale software development project, whichwas also distributed in nature. This exploration is from an organizational pattern perspective. Thatis to say this paper provides a retrospective review of the software development project,highlighting the significant aspects of the approach taken, together with its successes and failures.This experience is then cast in terms of how it relates to the organization structures and processcaptured in Copliens organizational patterns [13]. The significance of this study is thatorganizational patterns are considered to embody and capture many of the important characteristics

and structures of an organization engaged in software development.

The structure of this paper is as follows: Section 2 provides background on global softwaredevelopment issues. It introduces organizational patterns. Section 3 describes the project context,together with the successful adaptation of XP to a large scale software development. Section 3.1summarizes the main conclusions from the project. Section 4 undertakes a pattern mining exercise,in that it examines the projects organizational structure and relates these to the organizational

patterns in [13]. This contributes to the validation of organizational patterns as structuring tools fororganizations which can lead to effective and efficient software development. Section 5 dicusses

24


25/178

the merits of this exercise and section 6 provides some conclusions and highlights the futruredirection of this work.

2. Background and Foundation

This section briefly examines the background streams to the case study project described in section4. There are fundamentally three streams of interest: agile development, distributed softwaredevelopment, and organizational patterns. The inter-relationship between the three streams isestablished by the fact that the project under review was a large scale software development

project, which used XP as its development methodology, and was distributed in structure.

2.1. GSD and The Distributed Software Development Challenge

A central theme in much of the literature is the impact of distance and time, i.e. geographicaldispersal, on the communications of a project or an organization [11], [17], [21], [32]. There are anumber of common issues and problems which is exist in many software development projects, but

which are amplified when considered in the context of distributed software development. Theseissues have been addressed extensively in the literature, for example, Carmel [11] provides us withan taxonomy of distributed organization structures and a number of strategies for overcoming theimpedance of distance on a development project: reducing intensive collaboration, reducingcultural distance, and reducing cultural distance; Herbsleb [32] examining the issues under thethesis of Conways Law, where the issue of integration and co-ordination come to the fore andwhere some of the informal activities which are an integral part of software development areseverely impacted by distance; Damian [17] examining the use of groupware technology toovercome the impact of geographical dispersal.

These challenges, stated briefly and incompletely, include:Infrastructure creating a distributed working environment that will promote easy and effective

collaboration on software development. Achieving agreement on the use common set ofdevelopment tools, SCM and integration strategies for the effective multi-site collaborativeworking is often a challenge, [4], [10], [36].

Cultural overcoming cultural differences, modes of working, approaches, ethos, trust, ownershipand so on. Establishing appropriate levels of trust among project participants is essential to a

projects survival and success, [11], [41], [35].

Communications essential to have effective and efficient communication mechanisms. Thisissue also has a cultural aspect. It is important that a common language and understanding existsamong the collaborating parties. Learning to communicate effectively in an open an transparentmanner is a significant challenge, [37], [36], [11], [44], [23].

Methodologies different approaches and processes can exist between sites. How do youharmonize these differences? How are the working practices aligned and harmonized? How agilemethods can be applied, for example, Distributed XP [19], [36], [40], [6], [23], [44].

Recent work of Fitzgerald [20] highlighted the use of XP as the development paradigm andSCRUM as the management methodology. Additionally in [21] the communications gap wassignificantly highlighted when transforming a co-located team to a multi-site inter-continental team

25


26/178

in different time zones. This is significant in that it highlights the difficulties with dispersing a teamgeographically even in situations where there is a strong foundation in terms of infrastructure,culture, and trust. The central issue and overriding common theme in all these issues is the impacton communications and the tools and strategies needed to overcome this impedance.

2.2. Agile Development The focused timely delivery of quality working software systems.

What is Agile Software Development? This is a far reaching and very broad question. It is aconcept that has been addressed extensively in the software development literature [1], [12], [22],[30], [24]. Not only is agile development concerned with effective and efficient ways of producingsoftware, it also embodies a philosophical approach to how software can be developed. This iscaptured in the Agile Manifesto [22], and is central theme in the writings of Highsmith andCockburn [30], [31], [12]. At this point it is worth recollecting the central assertion of the AgileManifesto:

we are uncovering better ways of developing software by doing it andhelping others to do it. Through this work we have come to value

individuals and interactions over processes and toolsworking software over comprehensive documentationcustomer collaboration over contract negotiationsresponding to change over following the plan.

The value emphasis is on the items on the left hand side. The right hand side items are importantand an integral part of any project, but they are not the most important and should be considered as

being supportive of the main development activity. There are a number of methods andmethodologies under the agile umbrella, such as XP, SCRUM, ASD, Crystal and these aredescribed, compared and contrasted succinctly by Abrahamsson in [1].

One of the main characteristics of agile development is, a focus on the delivery of working (highquality, tested ) software system or products, that are inline with customers expectations. In thisrespect, the software deliverables are produced in a timely fashion, they work as per what thecustomer has asked for and what they want ( sometimes these are not congruent). In achieving thisgoal, agile software development embraces change, and produces the deliverable products in anevolutionary manner. With this approach, the overall development cycle is divided into a numberof iterations. Each iteration contributing a certain amount of working functionality. Agile methodsdo not attempt to develop systems in monolithic phases, as characterized by waterfall method.Agile avoids the BDUF (big design up front) and the big bang integration syndromes.

This is achieved in agile development through the use of iterations. The iteration and its associateddelivery provide a focal point for obtaining feedback. Additionally, in the context of GSD, they

provide a synchronization and integration point. Iterations force decisions to be made [38];decisions about what should be developed; decisions on what has been developed. They areessential in controlling risk and in managing a project progress.

Thus, agile methods are seen to have a strong emphasis on communication and interaction, oncontinuous integration and delivery of working software, on close collaborations and co-locations,and so on. It is also seen that geographical dispersal in time and distance impacts significantly onmany of the core aspects of agile methods. Therefore some significant questions are posed: do agilemethods scale appropriately and can they scale in time and space? Can they can be applied to

26


27/178

globally distributed software development?; Additionally, is it appropriate that they are applied inthe context of distributed software development?; Or should some other agile paradigm ormethodologies for use with GSD?

The desire or objective is to make distributed software development effective and efficient.

Establishing effective communications poses a significant challenge to multi-site development andglobally distributed software development. We are seeing the emergence of empirical informationon the use of agile methods in a DSD context [23], [43], [44]. These projects have used XP for theiroff-shore development and report some significant findings. From this we can see some patternsfor GSD emerge, which we look at in section 6. The finding from these projects include: the use ofsite ambassadors, use of wiki web as a common repository for information, separate teams byfunctionality not by activity (Conways Law), expect more process and documentation, dont underestimate the impact of culture, use synchronous communication as much as possible (phone andinstant messaging).

2.3. Organizational Patterns building organizations that produce quality software.

In [25] Martin Fowler presents us with proposals for consideration when using XP and how it ispossible to adapt it as a process to a particular project context. The approach being analogous tosoftware re-use within OOAD. This leads us to generalize on this idea of variation on a themeand to consider using OOAD techniques when composing, evaluating and structuring adevelopment process. OOAD has espoused the theme of software re-use from its inception. Thisconcept of re-use has been cultivated in the context of software design and software architecture bythe application of Alexanders design pattern ideal to software architectural domain, as detailed inthe GOFs [27] Design patterns elements of object oriented software re-use. Similarly Coplien[13] has taken the concept of design pattern and used it in his study of organizational structure.

Patterns span a multitude of domains. The focus of this work is on organizational structure and

development process. In this sense we are interested in aspects described in a range of processpatterns, for example, SCM patterns [9], [10], Analysis and design in Catepillar Fate [33],Requirements capture in RAPPeL [46], development process SCRUM [8], Episodes [16], ProcessImprovement [5], A Development Process Generative Pattern Language [15], Customer interaction

patterns [39] and Organizational Patterns [13], [28], [29].

The origins of software patterns and organization patterns come from the work of Alexandersarchitecture patterns used in the design of buildings, towns and cities as related in the muchreferenced works Timeless Way of Building [2] and A Pattern Language [3]. Coplien [14] providesa definitive briefing on the patterns concept. These concepts are also explored in the writing ofGabriel [10]. In this he refers to the concept of quality without a name which patterns seem toespouse. In Alexanders work there is a human element to patterns in terms of their use and

application; That this leads to a improvement in the quality (of life) through piecemeal growth andincremental repair. Similar sentiments are expressed with organization patterns [13], but thecontext is that of the social structures of software development orgnaizations. This the foundationfor the research described in this paper.

In essence, a pattern can be considered the documentation of a problem and its solution. Thedocumentary form has a specified structure composed of its name; The intent which summarizeswhat the pattern does; The context describing the scope and area of application of the pattern; A

27


28/178

statement illustrating the problem domain, thus providing greater understanding to the pattern andits use the issues or forces that are involved and addressed; A description of the solution and thereasoning behind why the pattern works. Names are very important for patterns. Good names areessential.

A Patterns name should encode the meaning of the pattern and evoke the essence of the problemand its solution. This is especially important in the domain of organizational structure anddevelopment process design. It is desirable that Pattern names have an immediate impact, that theyencapsulate the essence of the problem and solution addressed in the pattern. There should be acertain semantic resonance from the pattern name in this respect. Pattern names should becommunication enablers, that form part of the design vocabulary. Coplien [13] describes patternsas:a recurring structural configuration that solves a problem in a context contributing to thewholeness of some whole or system that reflects some aesthetic or cultural value.

A pattern in itself provides a solution to a particular design problem. When they are broughttogether as a collection and relationships between them established, then they can be used to buildsystems, define architecture, establish framework, create structures and so on. In this way thecollection of patterns defines or establishes a pattern language. When considering patterns asdesign problem/solutions pairs, it is seen that they are empirical in origin, in the sense that patternsare not invented or created, but found on a recurring basis. As such, they capture importantempirical knowledge. This knowledge relates to design structures, practices, and techniques. Thisknowledge, captured as patterns is then available for re-use and can be applied in new contextualsettings. Patterns capture important practice and often hidden structure.

Patterns per se dont exist in isolation. They have relationships with other patterns in the domaincontext. They inter-work with other patterns, which means that patterns build on each other,establish a flow of problem resolution that help build systems in this case systems of human

endeavour. The connectedness, relationships and collaborations among patterns help weave apattern language. A pattern language enhances the power of a pattern through which a network ofsolutions are created and evolved by means of piecemeal growth and incremental repair. Thussystems architectures are generated. The path taken will depend on the context in which the

patterns are being applied and on what forces are being resolved.

A pattern language takes you on a journey. A journey leading to a solution through theinterconnections among patterns in the language. With respect to organizational patterns, theygenerate structure and behaviour of an organization. This is through the interplay and workingtogether of the patterns. The pattern language links the patterns together, and provides the rules bywhich the patterns work together in meaningful ways. Coplien [13] describes it as analogous to aroadmap and a journey: a pattern language is an outline of the many ways that patterns may

be put together. How they are put together depends on the context So, while a pattern languageis a roadmap, there are many ways from the start onwards to a journey into organizational growth. Patterns promote awareness of the sociological human forces that have a bearing on softwaredevelopment activities.

The basic tenet of organizational patterns is that an organization is a system, and as such it has bothstructure and behaviour. It is a social system, and the activity of software development is primarilya social activity. Thus how we structure our organizations, to enable this activity, will have asignificant bearing on the outcome and success of this development activity.

28


29/178

The structure of an organization is reflected in the roles, relationships, collaborations, the networkof communications, and the processes used to carry out the development activity. Culture will,also, have a significant bearing on the structure of an organization. Thus, when considering anorganization as a system necessitates contemplating its architecture. The architecture is composed

of structures and relationships between structures. From case studies in the context of GSD we canextract patterns, create relationships between patterns, which will help us create, grow, repairdistributed software development organizations. Coplien and Harrison detail four patternslanguages which focus on different facets of an organization: Project management, Piecemealgrowth, Organizational style, and People and Code. In section 4 we will reflect on the case studyMMSC development project and examine the patterns that can be identified to exist within this

project. Additionally, we look at some problems encountered in this project and explore how theapplication of certain patterns could have helped.

3. XP in the Large A Project Summary

About 2nd

quarter 2001 Logica LMN embarked on the development of a large scaletelecommunications product for multimedia messaging system targeted at the 3G market. Theemphasis for this development on high quality both in terms of the system structure and design andin the levels of testing.

About this time the eXtreme Programming (XP)[7] methodology was gaining significant attentionand credibility. Logica LMN had used XP on a sub-project for a year prior to this. The results ofthis pilot were very positive and it was deemed that XP was worth using on the next large scaleMMSC development project. This was to replace the then Logica LMN Cortex process whichfollowed, in the main, the traditional waterfall methodology.

The key drivers for the adaptation of XP were: initial time to market, phased releases, quality

deliverables, system evolution, good design practice, functionality adaptability in an evolutionaryproduct market. It was perceived that XP could assist in meeting these goals.

Typically the essence of XP is based on the scenario that requirements and functionality arecaptured in User Stories. The user stories are reviewed by the developers. After a conversation orconversations with the customer they are prioritized by the customer. Then the stories areimplemented and delivered over the course of a number of iterations.

In the MMSC product context there are a number of potential customers and product managementwould usually converse with them. So an adaptation of the customer/developer relationship wasneeded. For this a number of project stakeholders were identified: Potential Customers, ProductManagement, Product Architect team, Product Development Manager, Product Component teams,Product End-to-End test team, System test team. This effectively provides you with two virtualteams: Customer team and Development team. In essence we had a proxy customer.

The Architecture team provides an overlap between the two virtual teams. This overlap isconceived to assist the communications process between the two domains and additionally withinthe product development teams.

29


30/178

The component team based structure for the overall development team was used to allow for thepractice of XP in its purer form at a fine granularity of development. The End-to-End test team wasput in place to facilitate component integration and a continuous integration strategy. Additionallyin this mix, there were two development sites, one in Dublin and one in Cork. This added anotherdimension in terms of communications overhead, co-ordination and synchronization of

development activities.

The adaptation of XP in this context saw the introduction of the Team Story concept. This is toensure that any team can work in an XP way. The relationship between User Stories and TeamStories is as follows: A Team Story is associated with exactly one, unique, User Story. A UserStory has one or more Team Stories. When all the Team Stories associated with a User Story arecomplete, then the User Story is complete. A Team Story requires work from one team only.

Tracking of stories and metrics is necessary in a large project. An online tools web basedapplication was used for recording User Stories, Team Stories and corresponding test coverage.This kept the administrative overhead to a minimum.

Thus the adaptation of XP to MMSC product development project included the following projectelements and artifacts: Team based component development, User Stories, Team Stories, Unittesting, Acceptance tests, End-to-End testing, System tests, Engineering releases, Iterations, Start ofiteration meeting and end of iteration meeting, Online capture of user and team stories, Onlinecapture of acceptance tests.

2.3. Main Conclusions from MMSC Project.

The project delivered a high quality MMS within the expected time frames and with the expectedfunctionality (as dictated by the customer) and quality. This can be attributed to the adoption of XPand its adaptation to suit large scale product development.

Iterative development facilitates tractable product development and project management. The useof unit tests, extended unit tests, in team acceptance test and end-to-end testing contributed to highquality software deliverables.

By using a component team based approach allows XP to be applied in its purer form at amicroscopic level. This approach together with End-to-End testing produced a very usable andeffective development process.

Continuous integration is an integral part of XP. Regular integration testing at all levels (teamstory and user story, End-to-End test) was fundamental to avoiding big bang problems.

In short XP in its purest form cannot be applied to large scale high grade product development. Itneeds to be augmented with some additional project management artifacts at a macroscopic level.The use of test first design is difficult to achieve, as is the practice of pair programming. Theserequire significant effort in terms of mentoring, tutoring and coaching.

Yesterdays weather became an effective mechanisms for estimating the effort for a piece of work.However, care must still be taken to avoid under estimating and over committing in an iterations.

30


31/178

By keeping metrics for each iteration it was possible to check the project progress at any time. Thisis important for global visibility within an organization.

The developer - customer communications needs careful attention. The use of the architect team asa proxy customer, while contributing to architectural consistency of the product, didnt quite

achieve the developer/customer dialogues espoused with XP. Nonetheless, the two virtual teamstructure contributed strongly to the projects forward progress.

The distributed software development aspects of the project didnt achieve the desired objectivesand it is worth looking at this aspect of the project. This had a number of classic symptoms and

pathology associated with it: culture differences, lack of trust, political issues, differences inapproach and methodology, lack of buy in, infrastructure , and communications problems.

4. Pattern Mining Identifying Organizational Patterns

This section explores the application of XP from an organization structure and process perspective.

It sets about identifying the set of organizational patterns which can be found in the project underreview. The organization patterns identified are briefly described in Appendix A. Many softwareprojects are composed developers, designers, software architects, testers, systems engineers, qualityengineers, project leads, managers, customers, product managers, and various other roles.Additionally, a typical organization will be composed of people, developing products using a

particular process. The product development takes place in the context of a project which executesa plan according to a set of objectives and produces a set of deliverables, while adhering tomonetary controls imposed by a development budget.

The organizational structure used in the MMSC development project was a DivideAndConquerapproach which had the overall development divided amongst an number of component teams(TeamPerTask, or TeamPerComponent which is a derivation of OwnerPerDeliverable). The project

used XP as its development process from which an number of patterns immediately fall out, suchas, EngageCustomer, IncrementalIntegration, CodeOwnership, StandUpMeeting, DevelopInPairs.

The overall release and development cycles were organized in an iterative way: engineeringreleases focused on the GA release (DevelopmentEpisode), composed of a number of iteration(ProgrammingEpisode) which implemented user stories and progressed the working functionalitytowards the Product Management goal. Product management and the customer team selected userstories for an engineering release. These were prioritized and mapped iterations within theengineering release. Prior to each engineering release as part of the planning activity, roughestimates of all the user stories for that release were made. This helped SizeTheSchedule to obtain aball park figure for the development effort. This enabled the development manager and thecustomer team to make a judgement as to the veracity of what was being undertaken. The feedbackfrom this exercise was in turn used to manage the expectation of the customer i.e. productmanagement and to decide on a realistic WorkQueu

disd proceedings

Documents