The role of collaborative support to promote participation and commitment in software development teams

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2007; 12: 229–246

Published online 4 January 2007 in Wiley InterScience(www.interscience.wiley.com) DOI: 10.1002/spip.314

The Role of CollaborativeSupport to PromoteParticipation andCommitment in SoftwareDevelopment Teams Research Section

Renata Mendes de Araujo1*,† and Marcos R. S. Borges2

1 Department of Applied Informatics-UNIRIO, Av. Pasteur 458, Rio deJaneiro, RJ, 22290-240, Brasil2 Graduate Program in Informatics-UFRJ, Rio de Janeiro, RJ, PO Box 2324,20001-970, Brasil

This work discusses the use of collaborative technology as an element for extending softwareprocess culture within development teams. This discussion starts with the idea that collaborationsupport comprises an important element for software process improvement (SPI) and anagent for process learning. We argue that improving awareness information about workprocesses and about the collaboration intrinsic to it may help software development teams tobetter accept the idea of defining, standardizing and continuously improving their work. Ourapproach relies on the use of workflow systems for software process support. We have built anenvironment – PIEnvironment – by extending a commercial workflow system with awarenessinformation mechanisms and participation channels. Through case studies, we have evaluatedits use for the enactment of software process activities. Copyright 2007 John Wiley & Sons,Ltd.

KEY WORDS: collaboration; software process improvement; awareness mechanisms; workflow systems; group learning

1. INTRODUCTION

More than ever, organizations have been facingthe challenge of improving the quality of theirwork processes as a strategy to remain alive andcompetitive. Many companies are struggling toreengineer, automate, and improve the way they

∗ Correspondence to: Renata Mendes de Araujo, Department ofApplied Informatics-UNIRIO, Av. Pasteur 458, Rio de Janeiro,RJ, 22290-240, Brasil†E-mail: [email protected]

Copyright 2007 John Wiley & Sons, Ltd.

perform their business. In the software develop-ment area, this movement has been expressed bythe growing research in software process supportand by the wave of software process improvement(SPI) (Humphrey 1987, Paulk 1993, Zahran 1998,Conradi et al. 2006).

In spite of all this effort, reality has shown thata great number of organizations dealing with soft-ware development remain immature. Techniquesfor process modeling, assessment and improvementare not adopted, in many cases are even unknown,and may require a great deal of effort to be carriedout (Goldenson and Herbsleb 1995, Jiang et al. 2004,PMPSC 2006).

Research Section R. M. de Araujo and M. R. S. Borges

Introducing the idea of defined and formal-ized work processes in an immature organizationmeans changing the way of working, making peo-ple follow guidelines, tracking and measuring workperformance and knowledgeably distributing tasksamong developers. Therefore, it is widely arguedthat the successful introduction of new work prac-tices into an organization requires the establishmentof a positive culture towards the idea of hav-ing a defined process (Paulk 1993, Zahran 1998,Humphrey 1999). It is also argued that this newculture and its maintenance in an environment ofcontinuous change must be supported accordingly,which includes the use of techonology (Levine 2001,Levine and Monarch 1998, Conradi and Fuggetta2002).

Our work discusses the possibilities of helpingworkers in creating this new culture through theuse of technologies bearing the potential of reduc-ing the distance between teams and their workingprocesses, as well as supporting them in the per-forming of their tasks. Groupware (Coleman andKhanna 1995) and, in particular, workflow (Chaf-fey 1998) are the technologies we use. In our view,collaborative technology offers resources that allowprocess participants to have an extended notionand visualization of their work practices. One ofthe aims of groupware technology is making col-laborative processes more explicit to their usersby offering awareness resources (Sohlenkamp 1998,Gutwin et al. 2004, Nutter and Boldyreff 2003).Awareness resources provide groupware userswith information which helps them to understandwhat takes place during group work, and, con-sequently, providing context to their individualactivities. We argue that an extended notion andvisualization of work processes through aware-ness resources can render workers more com-mitted toward the improvement of their prac-tices, toward continuously learning about theirown processes and having a balance betweenautonomy and responsibility in process execu-tion.

In our earlier work (Araujo and Borges 2001),we provided a first step of this discussion andpresented the PIEnvironment – a software pro-cess support environment aimed at providingimproved awareness of working processes andcollaboration. The present work extends our pre-vious findings by reporting the results of morecase studies on the use of PIEnvironment and

its effects on group learning, participation, andcommitment. The case studies results show usthat, by improving process awareness, participantsreported better satisfaction, credit and acceptanceabout using defined processes to guide their workactivities.

The next section outlines the main aspectsrelated to changing software process culture inorganizations and how collaborative technology canbe seen as an agent for change. Section 3 presentsthe concept of awareness information and resourcesand discusses our idea of how they can be usedto help organizations in gaining process maturity.In Section 4 we present the PIEnvironment, asoftware process support environment based onworkflow technology, which implements resourcesfor providing the awareness information discussedin the previous section. In Section 5 we describethe design, execution and results of four casestudies using the PIEnvironment. Section 6 presentsrelated work and Section 7 is the conclusion of thearticle.

2. CHANGING SOFTWARE PROCESSCULTURE

One of the first steps for the establishment of aprocess culture within an organization is the selec-tion of software engineering best practices whichwill bring improvements in the organization pro-cess development performance and quality. Guid-ing organizations in choosing the practices thatbest fit their needs has been the aim of the pro-cess reference models – Capability Maturity ModelIntegrated (CMMI), International Organization forStandardization (ISO), Software Process Improve-ment and Capability dEtermination (SPICE), etc.Process culture also involves carrying out an overallapproach for continuously introducing the selectedbest practices and making people aware of theirneeds and benefits. These have been the aims of theproposed process improvement approaches Initiat-ing Diagnosing Establishing Acting and Learning(IDEAL 2006) (Briand et al. 1999). The establishmentof a process culture also implies appropriate sup-port for the execution of the selected best practices.As a result, the software process automation areahas dedicated a great amount of work in devel-oping environments and tools to support software

Copyright 2007 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2007; 12: 229–246

230 DOI: 10.1002/spip

Research Section Collaborative Technology for Software Process Culture

engineering workers (Christie 1995, Conradi andFuggetta 2002).

However, in spite of the model or approachadopted, many of the possible risks associatedwith process improvement are directly relatedto the acceptability of and commitment to theinitiative. Along with the implementation ofan improvement initiative in an organization,changes are expected to occur not only inthe process but also in team members’ atti-tudes, values and behavior. Unfortunately, prac-tice usually shows us that cultural issues areoften overlooked, and improvement initiatives areclearly enforced upon workers by higher manage-ment.

2.1. Collaborative Technology – Agent forProcess Improvement and Culture Change

Groupware technology aims at assisting groupmembers in communicating, sharing informationand resources, and coordinating tasks and respon-sibilities through the use of networks and com-puters (Ellis et al. 1991). Since today’s business isstrongly dependent on communication and interac-tion between inter and intraorganization members,groupware technology has often been associatedwith work reengineering initiatives and the newway of conducting global business (Coleman andKhanna 1995).

The software development area has also beenfacing the challenge of ‘reengineering’ the waypeople work. Research in software process automa-tion and support has already acknowledged theimportance of the collaboration aspect in softwareprocesses and the need to support this collaborationaccordingly (Araujo et al. 1997, Fuggeta 2000, Con-radi and Fuggetta 2002, van der Hoek et al. 2004).Encouraging, supporting and enforcing collabora-tion becomes an essential aspect of SPI, althoughthere is still the issue of how this improvementcan be asserted according to each work group’senvironment and context.

One kind of groupware application – workflowmanagement systems (WFMs) (Coleman andKhanna, 1995) (WFMC- Workflow ManagementCoalition) – emerges as a potential infrastructurefor supporting software processes (Fuggeta 2000,Barnes and Gray 2000). Although WFMSs have theirorigins in the business area, they can be considered

as an enabling technology for process automa-tion in general, and as software process centeredenvironments.

2.2. Gaining Maturity Through CollaborationSupport

All the effort applied by the software developmentorganization in improving their working processesis turned toward achieving higher production matu-rity. The maturity concept is usually associated withpassing time, evolution, learning, knowledge accu-mulation and experimentation. Judging somethingor somebody as mature brings forth the connota-tion of independence, balance, responsibility andtrust in one’s own actions, all result from one’sacquired learning, vision and knowledge. There-fore, one of the elements for reaching maturity isthe ability to learn. Organizations in higher matu-rity levels are those that have already developeda culture where people know about their pro-cesses, and where an infrastructure allowing forexisting processes to be learned and improvedexists. As stated by Levine (2001): ‘When we askpeople to change the way they do their work,we are asking them to learn’. Process maturityalso comprises the growth of the participants’responsibility with respect to their actions anddecisions, i.e. people’s participation and commit-ment to change. It seems that immature organi-zations need an effective and present management,while mature organizations have more self-directedteams.

Given its supporting characteristics, groupwareis a technology with potential to promote pro-cess learning within groups and organizations. Ourhypothesis in this work is, that groupware is apromising technology for: (i) facilitating processenactment, by conveniently supporting the col-laboration intrinsic to it; (ii) helping developmentteams to change their work structures; (iii) makingteams more aware of the process they participatein, and of the collaboration therein. One of thebasic supporting elements provided by cooperativetools is related to how the work being conductedby the team can be made explicit to the group.This concept – named ‘awareness’ – is an importantsource of knowledge and a useful instrument forcollaborative process learning. This concept andits associated information resources turn out to be


DOI: 10.1002/spip 231


key aspects in our proposal (Araujo and Borges1999).

3. IMPROVING COLLABORATIONTHROUGH AWARENESS

Our work focuses on how to provide developmentteams with the resources for being aware of theprocess they execute. These awareness resourcesplay a fundamental role in helping people recognizeand learn the way they actually work, as well asrecognize problems and improvement possibilities.Awareness is the concept through which wewill attempt to promote the establishment of aprocess culture, helping organizations to introduceand accept the idea of process definition andformalization. Most of all, our study is concernedwith how collaboration awareness can improveprocess learning and stimulate commitment, which,as mentioned above, are important aspects forachieving process maturity.

3.1. The Awareness Concept

In groupware, awareness can be defined as beingconscious of the presence of other users and of theiractions while interacting through the application(Sohlenkamp 1998, Dourish and Bellotti 1992,Gutwin and Greenberg 1999, Gutwin et al. 1995).

‘Being aware’ of an interaction through group-ware comprises understanding what is happeningduring the interaction and, through this under-standing, each user can establish the context andimpact of their own activities and contributions tothe group. Understanding the interaction includesbeing aware of its objectives, identifying the con-tributions made by others, identifying who thepartners in the interaction are and being aware ofone’s own contributions with respect to the overallgroup work. In group tasks, this understanding isessential for the natural flow of work and for groupproductivity and results.

Groupware applications implement awarenessmechanisms, i.e. interface resources through whichparticipants can have awareness information aboutthe interaction or collaborative work being per-formed. These mechanisms usually attempt toreproduce the awareness elements existing in areal – face-to-face – interaction: presence, positionsin the shared workspace, different colors for dif-ferent participants, and so on. However, what is

interesting in this area is that the awareness mech-anisms provided by groupware can be designed togo further ahead from reproducing the real world.These mechanisms can be designed to augmentuser perceptions, allowing them to be aware ofinformation they would not possibly be aware ofin a real context, or information that they wouldnot possibly recognize as relevant for their work(McEwan and Greenber 2005, Storey et al. 2005). Forexample, awareness mechanisms can present statis-tics about participants’ contribution to a discussion,the impact of a contribution to the task being per-formed, or a summary of the interactions whichhave occurred.

3.2. Awareness, Collaboration and ProcessLearning

Knowledge is defined as tacit knowledge when it‘resides within us, and manifests itself through ouractions, and we therefore need not document it forour own sake. We just use it’. (Stenmark 2000). Whenwe decide to make this tacit knowledge availableto someone else to use, we have to, metaphoricallyspeaking, put it in ‘words’, which means, codifyingit and making it explicit. Therefore, the first stepto make an organization learn is by turning thetacit knowledge existing in each department oremployee’s mind to its explicit state, so that othersectors or employees can be aware and learn aboutit (Nonaka and Takeuchi 1995).

In software development contexts, it is necessaryto explicitly introduce the concept of a processbeing an important element and create resourceswhich will aid teams perceive the process inwhich they are involved. Many studies suggestthat work processes are important componentsfor promoting organization learning. As per thisperspective, process automation technology hasbeen considered as an element for helping workerslearn about organizational processes (Levine 2001,Zhao 1998, Berger et al. 1998, Levine and Monarch1998, Conradi and Fuggetta 2002). By providingresources for process definition, modeling andenactment, process technology can be useful forshowing and explaining how work is carried out.In PIEnvironment, the awareness of work processeswill be achieved through the information usuallyprovided by WFMSs.

WFMSs main functionalities comprise processmodeling and enactment. Basically, they offer


232 DOI: 10.1002/spip


resources for modeling processes based on activ-ities, performers and products. From the definitionof a process, the WFMS controls its enactment byfollowing the defined flow of activities in the pro-cess and delivering the execution of each activityto the assigned participant at the right moment. Atany time, each participant may have access to his‘work list’ where he can find all the tasks under hisresponsibility at the moment, attached with instruc-tions on how to proceed to complete the latter. Oncethe participant completes a task, the WFMS engineproceeds to the next step of the defined processflow.

Regarding this work, the main factor of attractionin WFMS is its collaborative nature. The conceptbehind WFMSs is integrating users (process partic-ipants) to the process itself, and distributing workresponsibilities within the team according to thedefined process. Thus, WFMSs helps participantsto become aware of their responsibilities insteadof only strictly controlling their work. Moreover,the new generation of WFMSs relies strongly onopen and interoperable architectures as well as onthe WWW, making these systems highly flexibleand accessible. High accessibility is a strong featurewhen we are concerned about integrating peopleinside an organization as well as when we are inter-ested in bringing people ‘closer’ to their processes.

Software processes are usually visualized fromthe point of view of the set of activities andpractices which comprise them. Nevertheless, oneneglected aspect in software process definition andsupport is its collaborative dimension. A researchconducted by Perry et al. (1994) has shown thatsoftware developers spend, on average, more thana half of their working time interacting with others.The above work also reported that developers oftenneeded to apply efforts to find out whom theyshould contact for solving problems.

Unless the development group is very small,process actors often do not have an explicitperception of how they contribute to one another.In many cases, participants may have a clear idea oftheir individual responsibilities, according to theirroles: ‘I am a programmer and I codify classes’.Sometimes, they may have the idea of being part of ateam and of other participants’ responsibilities: ‘I’ma programmer and I’ll codify the classes broughtby the analysts, and they will be tested by someoneelse’. Very often, knowledge about collaborationis restricted to those ‘who share the same artifact

with me’ and not in respect to: ‘who I need tointeract with to have my work done’ or ‘who willbenefit from my work’ or even ‘how does thewhole team collaborate’. This lack of knowledgeabout collaboration reduces process learning andmay bring barriers to its execution, acceptance andimprovement. PIEnvironment enhances processparticipants awareness of their collaboration byproviding information about group composition,roles and responsibilities and the main interactionsperformed among participants.

3.3. Awareness, Collaboration, Participation andCommitment

As mentioned before, one of the factors lead-ing to success in improvement initiatives is thelevel of commitment of the team involved. Studiesrelated to organizational commitment (Abrahams-son 2000, 2002) identified three kinds of commit-ment: (1) affective – refers to participant attachmentto, identification with, and involvement withinthe entity in question; (2) continuance – reflects thecosts associated with leaving or staying in theinitiative; and (3) normative – reflects a feeling ofobligation to continue membership with the entityin question. A person might be committed to some-thing (e.g. a SPI project), in all three forms. However,authors in organizational commitment researchsuggest that the most desirable form of commitmentis affective commitment – the one developed inter-nally and naturally where participants feel involvedand participate in a voluntary form.

Abrahamsson (2000, 2002), suggests that oneimplication for building affective commitment iscreating an environment which enables commit-ment to develop. The main characteristics of thisenvironment should be open communication, effec-tive collaboration, taking on responsibility, havinga shared vision and an active experimentation.

In our work, we explore the possibilities of partic-ipation and collaboration leading to commitment.When we are aware that we comprise part of agroup, and that this group is attempting to col-laborate somehow, we may become voluntarilyinvolved in it. When we are aware that this collabo-ration needs our participation and that we are ableto comment and suggest changes in the work beingperformed, we may become committed. Thus, whileparticipating in a process, people may turn out tobe voluntarily involved with it. Next, with feelings


DOI: 10.1002/spip 233


involved and keeping up participation, people mayfeel responsible for or committed to it.

We believe that, when aware of his or herprocesses and, most of all, being aware of the factthat he is working in a collaborative context, asoftware developer may be stimulated to effectivelyparticipate in this process and contribute to it. Thatis something like the differences of working ingroups or alone. Usually, while working in groups,people tend to be more participating. Some maysay that it is just because ‘others are watching you’,so you have to contribute somehow. However, wealso believe that, while in a group, we may be moreconscious about our own responsibilities and aboutthe impact of our activities in the overall group,thus encouraging us to participate.

We also believe that, by providing augmentedawareness about their working processes and col-laboration, workers may feel involved and willingto participate in the process. Additionally, work-ers can also identify problems and inconsistencies,stimulating continuous process improvement. Forexample, an experimental study has found out thatwhen workers are allowed to communicate theirimpressions and observations about the work andfeel more participation regarding the task being per-formed, there is a feeling of additional satisfaction,commitment and responsibility toward their work(Janz 1999).

4. THE PIENVIRONMENT

In our effort to study how collaboration and aware-ness can contribute to process learning, acceptance,involvement and commitment, we visualized anenvironment for software process support – ProcessImprovement Environment – which focuses on theabovementioned aspects. It induces collaboration,provides mechanisms for making software processand collaboration explicit for the development team,and supplies a channel in which participants mayregister comments and suggestions.

In PIEnvironment, WFMSs will be the enablingtechnology for supporting the software processand the infrastructure for process awareness andlearning. Workflow systems provide awarenessresources that help participants understand processdefinition, and the responsibilities of each partici-pant, as well as to allow them to be aware of andtrack the processes they take part in. These features

are the starting point for supporting the ‘dialogue’between processes and performers and are the coreof our proposal for providing process awareness.

PIEnvironment has as its main core a commercialworkflow system–WebDeploy (WDWF) waveletdomain Wiener filtering in which a software pro-cess can be defined, implemented and executed.This system was extended to provide other func-tionalities, basically the awareness resources aboutprocesses, groups, interactions; and a discussionforum (Figure 1).

4.1. Awareness of Work Processes

Through the awareness resources provided bythe workflow system, PIEnvironment users canobtain information about their and others’ worklistscontaining the activities/responsibilities they havetoward the process at a given moment (Figure 2); alist of process instances being enacted; the activitiescomprised by the process and its execution flow(Figure 3); the status of each of those instances(Figure 3) and the documents used along the work.

4.2. Awareness of Collaboration – Groups, Rolesand Interactions

The workflow system provides the main resourcesfor viewing processes from the perspective oftheir activity composition. However, the existingcollaboration is still troublesome to recognize, sincemost workflow systems do not explicitly handlethis issue. For instance, when a group is assignedto perform an activity, each member of the groupwill only be aware that he will be interacting withother group members when he actually performsthe activity.

We extended the workflow system by developingadditional awareness resources extracting informa-tion about the defined processes in the workflowdatabase and presenting it to users. The informationprovided by these resources includes the awarenessof group composition, an overview of individualand group responsibilities, and an idea about theexisting interactions in the process.

4.2.1. Groups, Roles and ResponsibilitiesThe first step to understand the possibilities forcollaboration along process execution is providingparticipants with knowledge about the team whichhe or she belongs to, and to recognize each member’srole and responsibility. Participants should be able


234 DOI: 10.1002/spip


Figure 1. PIEnvironment main window

Figure 2. Individual worklist


DOI: 10.1002/spip 235


Figure 3. Process map and status of execution of an instance of a system scenario definition process

to recognize the groups and roles assigned tocontribute to the process, and what activities theyperform.

As shown in Figure 4, for each defined process,the PIEnvironment displays information about pro-cess participants and a list containing all processactivities. Process performers can be either individ-uals or groups, so the PIEnvironment allows forthe visualization of the components of each groupparticipating in the process. This composition ispresented as a tree where one can see the definedroles within the group and the individuals assignedto each role. From this tree, the user can also beaware of his participation in each group (Figure 4).The information presented in Figure 4 correspondsto the enactment of an instance of a software inspec-tion process defined and being enacted through theworkflow system.

One can view the activities in the process underthe responsibility of each tree node (groups, rolesor individuals). When a tree node is selected, theactivities executed by the performer represented bythe node are highlighted (Figures 4, 5).

4.2.2. InteractionsTo provide participants with awareness about teamcollaboration, we have adopted a solution based onCain and Coplien’s approach for process modeling,

mentioned earlier in this article. This approachfocuses on modeling processes using roles andtheir relationship or interactions during processexecution (Cain and Coplien 1996).

In PIEnvironment, an interaction graph is con-structed by following the process definition imple-mented in the workflow system. Each node on thegraph represents a performer (a group, a group roleor an individual). The distinction between each kindof performer (group, role or individual) is obtainedby using different colors (green, yellow and red,respectively) (Figure 6). The user can also visualizehis participation in the interaction graph. The rolesand groups in which the user takes part, as well asthe nodes in which he appears as an individual arehighlighted in the graph.

The arcs on the graph represent the potentialinteractions and/or collaboration which may existamong process participants. We have said potential,because the interactions on the graph are collectedfrom the defined process in the workflow systemand do not represent the interactions which mayoccur outside the workflow enactment.

Thus, the interaction graph was built under anumber of assumptions of what could be theunderlying collaboration existing in a workflowdefinition. One criteria used to build the interactiongraph is related to the definition of the performer


236 DOI: 10.1002/spip


Figure 4. Group composition and user participation in groups. Roles and responsibilities

Figure 5. Individual responsibilities


DOI: 10.1002/spip 237


Figure 6. Example of an interaction graph

of each activity. If an activity in the processwas assigned to a group, the graph displays thepossibility of a potential collaboration among theroles constituting this group.

The PIEnvironment also considers that perform-ers of subsequent activities in the process flow ofexecution have some degree of collaboration. Weassume that if one performer has to await the exe-cution of a previous activity to execute his ownactivity, this may be an indicator that the precedingperformers’ results/products are needed for theirwork. In other words, performers of contiguousactivities ‘interact’ through the results/products oftheir activities, and this interaction may be repre-sented in the graph.

4.3. Participation

The awareness information provided by the mecha-nisms detailed above helps participants build theirown notion of participating in the process. Theyare aware of the process structure, status, resourcesand, most of all, of the group he takes part in andwho he interacts with.

To reinforce participation, the PIEnvironmentprovides participants with a channel for input anddiscussion of ideas and suggestions for improve-ment for the process. For each process, the PIEn-vironment provides a discussion forum in whichparticipants can bring up topics for discussion, withthe others being able to comment on these (Figure 7).Participants’ contributions must be publicized forthe whole team. By making these comments publicand allowing discussion, we may extend improve-ment possibilities, as well as team satisfaction andcommitment.

5. CASE STUDIES

To ascertain the augmentation of process cultureinside an organization using PIEnvironment, itwould be necessary to use our proposal extensivelyin many development contexts for a long period oftime. As a starting point for this verification, wehave concentrated on observing the potential of ourproposal in providing awareness, knowledge andconsciousness to process participants about theirwork, and on ascertaining if they felt satisfied and


238 DOI: 10.1002/spip


Translation: “ -Time spent in describingsystem vision - About the System Vision - Brainstorm - System Vision - Following the processenactment”

Translation:“As a system specification user, Ishould be able to follow theprocess enactment in detail, being aware, for example, about what scenariosare being developed.”

Figure 7. Discussion forum

in favor of the idea of using a defined process.To start this study, we have conducted four casestudies, the design and main results of which willbe described in the next sections.

5.1. Design

5.1.1. MeasurementTo analyze these questions, we have defined a setof variables to be measured throughout the casestudies: (i) the level of process understanding byparticipants, (ii) the number of contributions to pro-cess improvement registered by participants, and(iii) the level of acceptance of process formaliza-tion. These variables can be modified accordingto participants’ previous experience and culture.The existence of an established process culture inthe organization can also be a facilitating factorfor helping participants accept the use of defined

processes. Therefore, we have considered the pre-existing process culture of each participant as anindependent variable in our evaluation.

We designed a questionnaire to be filled outby each participant after the execution of the casestudy. This questionnaire contained several ques-tions to evaluate the variables outlined above, quan-titatively and qualitatively. In the questionnaire, wehave measured each participant’s process cultureby asking about their areas of interest and work,previous experience with software development,knowledge and use of existing reference processmodels (Capability Maturity Model (CMM), ISOetc.) and their personal impression and feelingsabout previous experiences in using defined pro-cesses to guide their work.

To measure the level of process understanding,we have formulated questions in which partici-pants can say how confident they were in describ-ing process objectives, activities, products, existing


DOI: 10.1002/spip 239


collaboration and their own responsibilities. Thenumber of contributions was measured by countingthe topics and comments recorded in the PIEnvi-ronment discussion forum, in addition to specificitems in the questionnaire. We asked participantsto enumerate suggestions for process improvementand indicated the relevance of their suggestions.Finally, to measure the level of acceptance of processformalization, we asked participants about theirlevel of satisfaction with the process enactment,and whether they were encouraged with the idea ofhaving their processes formalized in the future.

5.1.2. ScenarioIn each case study, a group executed softwaredevelopment tasks using the PIEnvironment. Twoprocesses were modeled and implemented in PIEn-vironment. The first process comprised activitiesfor identifying system requirements based on sce-narios. The second process comprised activitiesfor conducting software inspections. We modeledthe processes to guide each case study based onsuggested software development practices in the lit-erature (Baker et al. 2001, Frankovich 1997, Hickeyet al. 1999, Krutchen 1999, Pressman 1997), adaptedto include some activities/aspects to encouragecollaboration throughout the process, such as dis-cussion activities using discussion tools, and votingmeetings.

5.1.3. The SamplesIn all case studies, the groups consisted of post-graduate students and researchers in software engi-neering and groupware. In the first case study, thePIEnvironment was used in enacting a process forspecifying the requirements of a new version of acollaborative application. Participants in this groupdid not have hard experience in software devel-opment and had no work experience on definedprocesses. Additionally, the working cultures theyhad come from, although distinct from one another,did not have any process culture or enforcementtoward using defined processes. Only one partici-pant in this group had undergone an experience insoftware process definition in a development orga-nization but, as he stated, this did not cause a goodimpression and did not generate good outcomes.

Four postgraduate students made up the secondcase study group, some of whom also workedin software development organizations. The aimof this group was to execute the inspection of a

business model for an information system beingbuilt in our department. The participants in thisgroup had, in general, great experience in softwaredevelopment, despite not having worked withdefined processes before. The participants reportedthat their working cultures enforced the importanceand use of process definitions.

The last two case studies involved the studentsof a postgraduate course on groupware evaluation.The class was divided in two groups with approxi-mately four participants. Each group had to performtwo processes: the usability evaluation of a group-ware application and the requirements specificationof a brainstorm tool based on scenario descriptions.The first process performed by each group was tobe performed without PIEnvironment assistance.After passing this first experience, both groups hadto perform the second process with PIEnvironmentsupport.

People who had experience in software devel-opment, albeit without process formalization, com-prised the two groups. They also reported that theirwork cultures enforced the importance of having aprocess and its improvement.

5.1.4. Enforcing Collaboration, Participation andCommitmentCollaboration was an aspect we wanted to empha-size. Hence, we tried to encourage and explicitlyintroduce the collaborative aspect into the processmodels. We defined many activities involving dis-cussions and decision-making by the team andoffered some tools for supporting their accom-plishment (for instance, discussion forums in LotusNotes). Additionally, before being performed, eachprocess model was presented to the team in ameeting. In this meeting, participants were ableto discuss process objectives and suggest changesto the initial process model. The changes suggestedby the group improved the process in many ways.First, by making it more suitable and attractive forthe team, based on the participant’s experience andculture. Second, it was an opportunity for partici-pants to take a first look at the process, to discuss itsdefinition, to clear up some doubts and to presentsuggestions.

5.2. Results

The results of the four case studies are summarizedin Table 1. From the data and observations collected,


240 DOI: 10.1002/spip


Table 1. Case studies results (EG – experimental group using PIEnvironement; CG – control group not using PIEnvironment)

Casestudy 1

Casestudy 2

Case study3

Case study4

EG CG EG CG

Level of process understanding High High High High High MediumDegree of participation by suggesting changes Medium Medium Low Low Low MediumLevel of acceptance of process definitions High High Low High High High

we were able to answer our preceding questions inthe following way:

5.2.1. Process UnderstandingWe asked participants to describe how they sawthe process they executed and, in most cases,this reflected the actual process. Participants wereable to clearly describe activities, products, groupcomposition and interactions. Groups which per-formed processes without PIEnvironment supportalso reported a high degree of process understand-ing. We believe that this is due to the fact that theprocess performed was not too complex, helpingparticipants to be aware of it even without processvisualization resources.

Participants were also asked if they were ableto recognize the collaboration occurring duringprocess performance. In the first and second casestudies, groups reported that they were able torecognize collaboration as well as those with whomthey interact during the process.

We observed an interesting feature with oneof the groups that reported a very low degree ofcollaboration while performing their tasks with andwithout PIEnvironment support. Our observationwas that this group was definitively not able tocollaborate at all. They had several problems inunderstanding each other, in communicating and,most of all, in trusting each other. This groupwas commited to the work in a continuance ornormative level, i.e. they had a job to do tobe evaluated in the course. They had to worksomehow, but technical differences between themled to a feeling of dissatisfaction and distrust amongthem. Even though they did not trust each other,they completed their tasks and participated inthe process as defined in the workflow systemwhile using PIEnvironment. They did not feellike collaborating with each other. However, theexperience of using the PIEnvironment was lessdistressing than the one without PIEnvironment

support. We have observed that one cause ofmaking the group have fewer discussions could bethe fact that the work had already been distributedamong members through the workflow system andthey could be aware of how to do their work withouthaving to decide it among themselves.

Another important observation was that,although awareness can show how work and col-laboration flows, it can also show how the workdoes not flow during group work. It was easier tosee when one participant was having problems tocomplete his task. Making these problems explicitcaused rumors and dissatisfaction. However, it isimportant to make problems explicit, since this leadsto process learning and improvement possibilities.

5.2.2. Participation by Suggesting ChangesThe first case studies showed us that the degreeof participation with improvement suggestions waslow. This result may have many reasons. First, par-ticipants reported satisfaction with the quality ofthe process they performed, which could limit thenumber of suggestions for improvement. Also, thetime spent using the environment was short, andthis may have constrained participants in havingenough time to outline possible problems in pro-cess enactment. Also, one fact that contributed tothe small number of comments on the process wasthe fact of having an initial meeting before pro-cess enactment. This discussion aided participantsin feeling more intimate and committed towardtheir processes. However, among the reported sug-gestions, many of them were highly relevant forimproving the process.

5.2.3. Acceptance of Process DefinitionsIn the first case study, we could observe that par-ticipants reported a high degree of acceptance ofthe idea of using formally defined processes toguide their work. These evidences are reinforcedby the fact that the participants in both case studies


DOI: 10.1002/spip 241


had neither the habit nor the experience of follow-ing defined processes but, however, they reporteda high degree of process acceptance. Participantswere satisfied with its execution, feeling involvedand engaged in the process. One group, after com-pleting their work using PIEnvironment, reportedthat the process did not help the work of the groupand that they felt dissatisfied with the process per-formance. We believe that this dissatisfaction wasdue to technical problems encountered during PIEn-vironment use.

5.3. Limitations

The case studies lasted a short period of time.They took approximately 2 months, and partici-pants were not exclusively allocated to that activity.Therefore, we could not observe how partici-pants change their attitude while performing manyinstances of the same process definition during thetime. Our observations were focused on just oneexecution of a process within the same group.

Almost all participants had previous knowledgeabout the basic workflow concepts, but they werenot formally trained in the use of the PIEnviron-ment. Although the processes used in each casestudy were not complex, technological barriersprevented participants from executing and, con-sequently, understanding their processes.

The case studies were not conducted within aprocess improvement initiative. The teams used theenvironment for executing their activities withoutbeing involved in a ‘movement towards change’.We believe that, participants would report differentfeelings as well as a greater number of suggestionswithin an initiative for improvement.

6. RELATED WORK

Dourish et al. (1999) discuss the issue of ‘workintelligibility’ in shared interaction workspaces.They discuss how to make the collaborative workvisible, understandable and interpretable. Theybelieve that the systems, which make processdescriptions available, although they bear no suchintention, can be used to explain the work beingperformed.

Ellmer (1995) (1998) states that the representationand modeling of software engineering practices canbe used as elements for establishing knowledge

about an organization’s processes and promotingorganizational learning. This knowledge comprisesnot only the view of a process as a sequence of activi-ties, but also the organizational aspect involved in itsuch as individuals, groups, organizational entities,roles, responsibilities and so on.

Becattini et al. (1999) proposes helping processawareness through the mapping of the conceptsof tasks, roles and artifacts to rooms, objects andother typical elements of virtual environments.Their objective is to create a virtual environmentwhere process actors can perform their activities(individually or collaboratively) in a more intuitivemanner. The idea is providing other awarenessinformation about the process besides the usualvisual representation as a sequence of tasks. Byentering the rooms in the virtual environment,process actors can view the process under differentperspectives (tasks, artifacts and workspaces) andinteract with each other inside the available rooms.

Some studies focusing on the social aspect of soft-ware processes have been reported, reinforcing theneed for making participants aware of the collab-oration occurring among them. Christie and Staley(2000), for example, reinforce the importance ofmodeling existing interactions in software processesthrough what they called ‘social simulation’. Thissimulation aims at modeling interactions betweenindividuals in respect of the influence they have onone another, the level of acceptance of others’ ideasand their understanding of the process.

Cain and Coplien (1993) (1996), propose anapproach for studying software processes in orga-nizations based on interaction patterns existingamong process participants. Their basic aim wasunderstanding development as a social activity.The motivation for this approach relies on the factthat understanding the interaction patterns dur-ing development leads to a better understandingnot only of the process itself but also about eachparticipant’s role and responsibility in the process.

Their approach focused on modeling processesusing roles and their relationship during processexecution. They used cards to make employeeswrite down their roles, responsibilities and interac-tions with other roles in an organization. Cards areassigned to each role (actor), and its responsibilitiesare enumerated and their relationships (collabora-tion) with other cards are identified. The techniqueis highly participative in its nature, involving all


242 DOI: 10.1002/spip


actors in collecting data about interactions occur-ring during the process. As a result, a graph canbe generated using the information provided byactors, in which each node of this graph is a card(an actor) and the arcs are the collected interactionsamong them.

As shown by Cain and Coplien’s studies, thenotion about the overall interaction between actorsoffers valuable information on how collaborationis viewed in the organization. The great majorityof process participants felt surprised to find thatthe perception they had about the way the processwas executed was very different from the resultingmodel being presented. They also reported that thistechnique made participants modify the way theyviewed their work.

7. CONCLUSION

This work proposes the use of groupware tech-nology for supporting teams and their work-ing processes, aiming at increasing their cultureand commitment with respect to process defini-tion, use and improvement. We discussed howsupporting, inducing and making collaborationexplicit may help participants understand the waythey work, relate to other members in the team,and better accept the idea of using and contin-uously improving their working processes. Wehave particularly focused on WFMSs for support-ing software process execution and on awarenesscomputational mechanisms as resources for mak-ing the process explicit to its users. An envi-ronment – PIEnvironment – was built and put intoevaluation through case studies.

Our case studies are a first attempt to validateour hypotheses. They were conducted withoutrigorous and formal variable manipulation. Ourmain objectives were to observe the first impactof PIEnvironment in use and collect some datathat could guide us in new observations and inthe design of other case studies in the future.Conducting and reporting case studies is especiallyimportant in groupware evaluation, because of thedifficulties that are inherent to groupware andcollaboration evaluation through laboratory andrigorous experiments.

The results obtained could not lead us to the con-clusion that the PIEnvironment changes softwareprocess culture in organizations. But they were very

interesting in allowing us to observe that teams thathad only some kind of ‘theoretical’ process cultureand that they had almost no previous experiencewith software process definition, use and improve-ment, reported satisfaction, credit and acceptanceof this initiative.

Although acceptance and agreement with the useof defined processes do not guarantee commit-ment toward process improvement, overcomingthis obstacle is of great importance to processimprovement initiatives, mainly in immature orga-nizations. Hence, we believe that the PIEnvironmentcan be even more enhanced and used as a helperfor process learning and acceptance.

Our studies have also helped us to conclude thatthe use of collaborative technology must be tunedwith the sensibility and experience of managementsupport. Technology takes on an important role inshowing problems and benefits in a process, butthis awareness must be managed to contribute tothe improvement and commitment of the group,and not to cause distress.

The influence of technology usability was anotherimportant finding. Usability affects commitment,since technical problems and difficulties in using atool to complete the work lead to dissatisfaction.On the other hand, commitment affects usability,since people committed to their work usuallyovercome usability problems. Our research groupis conducting studies on how we can evaluate andreduce usability problems in groupware design.

For future work, we intend to conduct furthercase studies to collect additional data and evidenceof the impact of our proposal in process learning,participation and commitment. The support of morecomplex or long processes is another issue to bediscussed. We would also like to analyze howour approach impacts team productivity and theproduct quality.

We also intend to suggest new mechanisms thatcan be used to increase participants’ awarenesswhile being supported by workflow systems. Stud-ies for analyzing how and when people collaboratewhile working through workflow systems shouldalso be conducted.

ACKNOWLEDGEMENTS

The authors would like to thank FAPERJ (grant noE-26/152.176/2000) for financial support and CA


DOI: 10.1002/spip 243


and TDI-USA for Jasmine and WebDeploy demoversions.

REFERENCES

Abrahamsson P. 2000. Commitment development insoftware process improvement: critical misconceptionsProceedings of the International Conference on SoftwareEngineering – ICSE 2000, Toronto, Canada, 2000, 71–80.

Abrahamsson P. 2002. Commitment nets in softwareprocess improvement. Annals of Software Engineering 14:407–438.

Araujo RM, Dias MS, Borges MRS. 1997. A frameworkfor the classification of computer supported collaborativedesign approaches. Third CYTED-RITOS InternationalWorkshop on Groupware (CRIWG’97). Madrid: Spain,91–100.

Araujo RM, Borges MRS. 1999. The role of awarenesssupport in collaborative improvement of softwareprocesses. Proceedings of the 5th International Workshopon Groupware (CRIWG’99). Cancun: Mexico, 343–347.

Araujo RM, Borges MRS. 2001. Extending the softwareprocess culture – an approach based on groupwareand workflow. In Proceedings of the Third InternationalConference on Product Focused Software Process ImprovementPROFES’2001. Kaiserlautern: Germany, 297–310.

Baker K, Greenberg S, Gutwin C. 2001. Heuristicevaluation of groupware based on the mechanics ofcollaboration. Proceedings of the 8th IFIP Working Conferenceon Engineering for Human-computer Interaction. ECHI’01:Toronto, Canada, 11–13.

Barnes A, Gray J. 2000. COTS, Workflow, and SoftwareProcess Management: an exploration of softwareengineering tool development. Proceedings of the 2000Australian Software Engineering Conference. Gold Coast,Queensland: Australia.

Becattini F, Di Nitto E, Fuggetta A, Valetto G. 1999.Exploiting MOOs to provide multiple views for softwareprocess support. International Process Technology Workshop(IPTW’99). Villars de Lans: France.

Berger M, Ellmer E, Merkl D. 1998. A learning componentfor workflow management systems. Proceedings of the31stHawaii International Conference on System Sciences(HICSS’98). IEEE Computer Society: Kohala Coast,Huwaii, USA.

Briand L, El Eman K, e Melo WL. 1999. An inductivemethod for software process improvement: concretesteps and guidelines. In Elements of Software ProcessAssessment & Improvement, 1st edn, capıtulo 7, El

Eman K, Madhavji NH (eds). IEEE Computer Society:Los Alamitos, California.

Cain BG, Coplien JO. 1993. A role-based empirical processmodeling environment. Proceedings of the 2nd InternationalConference on the Software Process Berlin, Germany,February.

Cain BG, Coplien JO. 1996. Social patterns in productivesoftware development organizations. Annals of SoftwareEngineering 2: 259–286.

Chaffey D. 1998. Groupware, Workflow and Intranets –Reengineering the Enterprise with Collaborative Software.Digital Press: Boston, MA, USA.

Christie AM. 1995. Software Process Automation. Springer-Verlag: London, UK.

Christie AM, Staley MJ. 2000. Organizational and socialsimulation of a software requirements developmentprocess. Software Process Improvement and Practice 5:103–110.

Coleman D, Khanna R. 1995. Groupware Technology andApplications. Prentice Hall: Upper Saddle River, NJ.

Coplien JO. 1994. Borland software craftsmanship: a newlook at process, quality and productivity. Proceedings ofthe 5th Annual Borland International Conference, Orlando,FL, June, 1–11.

Conradi R, Fuggetta A. 2002. Improving software processimprovement. IEEE Software 19(4): 92–99.

Conradi R, Dyba T, Sjoberg DIK, Ulsund T. 2006. SoftwareProcess Improvement: Results and Experience from the field.Springer: Berlin, Heidelberg, NY.

Dourish P, Bellotti V. 1992. Awareness and coordinationin shared workspaces. Proceedings of the Conference onCSCW. ACM Press: Toronto, Canada, 107–114.

Dourish P, Bentley R, Jones R, e Maclean A. 1999. Gettingsome perspective: using process descriptions to indexdocument history. Proceedings of GROUP’99. ACM:Phoenix, AZ.

Ellis C, Gibbs SJ, e Rein GL. 1991. GROUPWARE: someissues and experiences. Communications of the ACM 34(1):39–58.

Ellmer E. 1995. Improving software processes.Proceedings of Software Engineering Environments. IEEE:Noordwijkerhout, The Netherlands, 74–83.

Ellmer E. 1998. A learning perspective on softwareprocess technology. Software Engineering Notes 23(4):65–69.


244 DOI: 10.1002/spip


Frankovich J. 1997. The Software Inspection Process,Advanced Information Services, http://sern.ucalgary.ca/courses/seng/621/W97/johnf/inspections.htm,accessed on April/2000.

Fuggeta A. 2000. Software process 2000. A RoadMap. 22ndInternational Conference on Software Engineering, Limerick,Ireland, June, 27–34.

Goldenson DR, Herbsleb JD. 1995. After the Appraisal: ASystematic Survey of Process Improvement, its Benefits, andFactors that Influence Success, CMU/SEI-95-TR-009 ESC-TR-95-009. SEI, Carnegie Mellon University: Pittsburgh,PA.

Gutwin C, Greenberg S. 1999. A framework of aware-ness for small groups in shared-workspace group-ware. Technical Report 99-1. Department of ComputerScience, University of Saskatchewan: Canada, (avail-able at http://www.cpsc.ucalgary.ca/papers/1999/99-AwarenessTheory/html/theory-tr99-1.html, accessed onMarch/2000).

Gutwin C, Stark G, Greenberg S. 1995. Support forworkspace awareness in educational groupware.Proceedings of the Conference on Computer SupportedCooperative Learning (CSCL’95), September, 1–8.

Gutwin C, Penner R, Schneider K. 2004. Group awarenessin distributed software development. Proceedings of theACM Conference on Computer Supported Cooperative Work(CSCW’04): Chicago, Illinois, USA, November, 72–81.

Hickey AM, Dean DL, Nunamaker JF Jr. 1999. Settinga foundation for collaborative scenario elicitation.Proceedings of the 32nd Hawaii International Conference onSystem Sciences (HICSS’99), Hawaii, January, 1–10.

Humphrey WS. 1987. Characterizing the Software Process:A Maturity Framework, CMU-SEI-87-TR-11 ESD-TR-87-112. Software Engineering Institute, Carnegie MellonUniversity: Pittsburgh, PA.

Humphrey WS. 1999. Changing the software culture. Soft-ware Engineering Process Group 1999 Conference. SoftwareEngineering Institute, Carnegie Mellon University: Pitts-burgh, PA, (Available at http://seir.sei.cmu.edu/, lastaccessed on March/2000).

IDEAL 2006. The IDEALSM Model, www.sei.cmu.edu/ideal/ideal.html, last access on May.

Janz BD. 1999. Self-directed teams in IS: correlatesfor improved systems development work outcomes.Information & Management 35: 171–192.

Jiang JJ, Klein G, Hwang H, Huang J, Hung S. 2004.An exploration of the relationship between softwaredevelopment process maturity and project performance.Information & Management 41: 279–288.

Krutchen P. 1999. The Rational Unified Process – AnIntroduction. Addison Wesley: Boston, MA, USA.

Levine L. 2001. Integrating knowledge and process ina learning organization. Information Systems Management18(1): 21–33.

Levine L, Monarch I. 1998. Collaborative technologyin the learning organization: integrating process withinformation flow, access and interpretation. Proceedings ofthe 31st Annual Hawaii International Conference on SystemSciences, Kohala Coast, Hawaii, USA, 444–459.

McEwan G, Greenber S. 2005. Community bar: designingfor awareness and interaction. Proceedings of the ACM CHIWorkshop on Awareness Systems: Known Results, Theory,Concepts and Future Challenges, Portland, Oregon, USA,1–5.

Nonaka I, Takeuchi H. 1995. The Knowledge-creatingCompany: How the Japanese Companies Create the Dynamicsof Innovation. Oxford University Press: USA.

Nutter D, Boldyreff C. 2003. Historical awareness supportand its evaluation in collaborative software engineering.Proceedings of the 20th International Workshops on EnablingTechnologies: Infrastructure for Collaborative Enterprises(WETICE’03), Linz, Austria, 1–6.

Paulk MC, Curtis B, Chrissis MB, Weber CV. 1993.Capability Maturity Model for Software, Version1.1, CMU/SEI-93-TR-24. Carnigie Mellon University,Software Engineering Institute: Pittsburgh, PA.

Perry DE, Staudenmayer NA, Votta LG. 1994. People,organizations, and process improvement. IEEE Software11(4): 36–45.

PMPSC. 2006. Process Maturity Profile of the Soft-ware Community, http://www.sei.cmu.edu/appraisal-program/profile/profile.html, Accessed on May.

Pressman RS. 1997. Software Engineering – A Practitioner’sApproach, 4th edn. McGraw Hill: New York, USA.

Sohlenkamp M. 1998. Supporting group awarenessin Multi-user environments through perceptualiza-tion. MSc Dissertation, Fachbereich Mathematik-Informatik der Universitat, Denmark, (availableat orgwis.gmd.ed/projects/POLITeam/poliawac/ms-diss/, Access on Sep/1999).

Stenmark D. 2000. Turning tacit knowledge tangible.Proceedings of the 33rd Hawaii International Conference onSystem Sciences. IEEE Press: Maui, HI.

Storey MD, Cubranic D, German DM. 2005. On the useof visualization to support awareness of human activitiesin software development: a survey and a framework.Proceedings of the ACM Symposium on Software Visualization(SoftVis’05), St. Louis, Missouri, USA, 193–202.


DOI: 10.1002/spip 245


van der Hoek A, Redmiles D, Dourish P, Sarma A,Filho AS, Souza C. 2004. Continuous coordination: a newparadigm for collaborative software engineering tools.Proceedings of Workshop on WoDISEE IEEE: Scotland.

WFMC. 2001. Workflow Management Coalition,www.wfmc.org, last access in June.

Zahran S. 1998. Software Process Improvement – PracticalGuidelines for Business Success. Addison-Wesley: UK.

Zhao JL. 1998. Knowledge management and organiza-tional learning in workflow systems. Proceedings of theAIS – Americas Conference on Information Systems. Balti-more, MD, 647–649.


246 DOI: 10.1002/spip

Documents

The role of collaborative support to promote participation and commitment in software development teams