Adopting Agile Methods: Can Goal-Oriented Social Modeling Help?

Hesam Chiniforooshan EsfahaniDepartment of Computer Science

University of TorontoHesam@cs.toronto.edu

Jordi CabotNRIA

Ecole des Mines de Nantesjordi.cabot@inria.fr

Eric YuFaculty of InformationUniversity of Toronto

yu@ischool.utoronto.ca

Abstract

The heavy reliance on the human factor in agilemethods poses new challenges for organizations intenton adopting them. Improper role assignment, neglectedteam dependencies, and overlooked required skillshave all been reported as reasons for failures duringthe introduction of an agile method. Current processmodelling languages are not designed for describing oranalyzing such human-related issues, and thus, providelittle assistance to organizations in the process ofadopting an agile method. This paper advocates theuse of goal-oriented modeling techniques for depictingsocial aspects of agile methods. These social modelscan be used to identify the key factors that contributeto the success or failure of an agile method, thusproviding guidance early during the introduction of themethod in an organization. The approach is illustratedusing the Scrum process.

1. Introduction

The introduction of a new software process in anorganization is a difficult and often risky proposition.This is especially true when adopting agile processessince they usually imply radical departures from tra-ditional team structures, cooperation styles and re-lationships [1], [2]. Experiences on the introductionof agile methods in different types of organizationshighlighted the difficulty of instilling a clear and sharedunderstanding of the new process among all teammembers [4]–[6].

In software process modeling, many types of processmodels have been introduced, focusing on differentaspects of software processes (e.g. activity, product,resource, etc.) [7], [28], [29] . However, none of thesecommonly-used process descriptions focuses on thesocial aspects of a software process such as moti-vations for performing an activity, needed skills for

playing a role, or dependencies among team members.Therefore, current process modeling techniques pro-vide inadequate assistance to organizations, willing toadopt an agile process, where a clear understanding ofall these factors is key to successfully integrate agilepractices within the organization.

This paper proposes to complement existing processmodeling approaches with a new perspective aimed atdescribing and analyzing the social and human aspectsof a software process. This approach makes use of thei* modelling framework [19] for visualizing and an-alyzing relationships among social actors, particularlyhow they depend on each other to achieve individualand team goals.

We believe this explicit representation of the socialrequirements (in terms of people, skills, dependenciesand tasks) of a process facilitates its adoption and,furthermore, enables software companies to assess thechances of successfully enacting it by checking (priorto process adoption) whether the social aspects of theprocess will be a good fit for current team members.In this sense, an additional benefit of our approach isthat it helps in the customization phase of softwareprocesses. Most organizations will need adaptations[10], rather than following the exact practices of aprescribed process (as in If one fits all, it doesn’t fitany). Typically, adapted processes are obtained by wayof tailoring existing methods [11], and should take intoaccount the people aspects of both the target organiza-tion and the candidate software process. Refining thesocial model of a process with respect to the currentsituation of the organization facilitates the introductionof the process to the organization, and the identificationof vulnerabilities that are specific to the organization.

As a running example, we will illustrate our proposalby focusing on the social aspects of Scrum - an agileprocess with emphasis on the importance of teamworkin software development [9]. We used the social modelof Scrum to build a customized process for a classroom

case study, analyzed it to identify its key vulnerabil-ities, and evaluated process goals to predict to whatextent they will be satisfied. We compared our model-based evaluation to what was observed in reality. Thefavorable comparison that our social models can indeedbe used to predict the main (organizational) problemswhen adopting a new development process. The socialmodels presented in the paper can be constructed usingOpenOME 1, an open source, Eclipse-based modelingtool to support i* modeling.

The rest of this paper is organized as follows.Section 2 motivates the need for social models ofsoftware processes. Section 3 presents a goal-orientedapproach for the specification of such models. Section4 presents the results of applying our approach on acase study. Finally, Section 5 discusses related workand Section 6 presents conclusions and future work.

2. Why social modeling?

The shift of concerns from technical to social issuesin agile methods suggests the need for systematic waysof modelling and analyzing human-related aspects ofagile methods [16]. This representation and analysisshould be done by means of graphical models, since avisual representation of a software process (even if stillrequiring accompanying textual descriptions) is betterwhen trying to understand a software process [12].

Current graphical depictions of agile methods aremostly informal diagrams or activity-oriented models,which focus on the activities and artifacts of theprocess. For instance, Figure 1 shows an informaldiagram, and Figure 2 an activity-oriented model of theScrum process. When these kind of process descrip-tions are used to describe an agile method, they stillconvey important information but, clearly, importantaspects, particularly those concerning human relation-ships, are not represented and are therefore missed inthe analysis. As a consequence, with current processmodeling languages, the often crucial social aspectsof agile methods would generally remain hidden inthe textual descriptions and argumentations [15] ofthe process, which hinders their comprehension andsystematic analysis.

To better encompass the social considerations thatcan make or break the enactment of an agile process,we need modeling techniques that can represent humanrelated issues as required by the agile method. Suchmodels can help organizations evaluate whether aprocess is socially compatible with their philosophyand inherent structures. Thus, the risk of adopting a

1. Available online at https://se.cs.toronto.edu/trac/ome

Figure 1. Informal SCRUM representation from [9]

Figure 2. Activity-oriented representation ofSCRUM (using SPEM 2.0 notation [13])

new process will be reduced, as the vulnerabilities ofthe process can be highlighted (and thus, minimized).For instance, when adopting an agile method, theorganization and the team members participating in thenew development process will have concerns such as:

• Which other actors will I depend on in order tosucceed in my goals? What do I depend on themfor?

• What are the process objectives that I have tofulfill?

• What are the skills required to perform each role?• Which are the most critical roles? What are the

consequences if these roles do not successfullyfulfill their tasks?

• What are the rationales of performing certaindevelopment activities?

These questions (and many others that typicallyarise in a process-change scenario) cannot be easilyanswered by studying models such as those in Figures1 and 2. Therefore, next sections introduce a socialmodeling perspective for software processes to com-plement the current description of software process andimprove the chances of successfully adopting an agileprocess within an organization.

3. Goal-Oriented Social modeling of Soft-ware Processes

When adopting a social perspective, process rolesbecome the central modeling construct. We treat rolesas being intentional in that they have goals and strate-gic interests. Besides, process roles can have multipledependencies to each other in order to collaborativelyachieve their goals. These kinds of complex multi-role problems have been successfully addressed inthe requirements engineering community by means ofagent- and goal-oriented techniques (AGORE) such asi* [19]. AGORE emphasizes the analysis of actors’goals and how they might be impacted by other actors’decisions. This analysis considers the collaboration ofactors in reaching domain goals, through social chainsof dependencies.

The i* framework can be used to represent processroles (as a kind of actor in the i* notation), their socialdependencies, their goals, tasks, and resources. Goalscan be hard-goals, representing the functional objec-tives, or softgoals, expressing qualitative objectives.One of the distinguishing capabilities of i* modelingframework is its capability of modeling the differentways that a softgoal can be contributed (positivelyor negatively). This capability is quite helpful formodeling qualitative objectives of a social actor, sincethey might receive heterogenous contributions, show-ing the trade-offs that should be resolved prior toprocess adoption. For instance, for a Project Manager(a process actor), documentation (a process task) con-tributes positively to his/her softgoal Facilitated CodeMaintenance, and at the same time negatively to theReduced Development Cost. In [32] the i* frameworkhas been used to address the problem of trade-offanalysis.

Therefore, we propose to make use of the i* mod-eling framework to model the social perspective ofa software process. This framework has been pre-viously used for representing intentional aspects oforganization-specific software processes [18]. The pur-pose of that work was to extract a descriptive processmodel of a software company to clarify the organiza-tional complexities of actors’ interactions. This workis intended to present prescriptive process models of apre-defined software process, to facilitate its adoptionand analysis by companies interested in it.

We will follow a two-step process. First, we will de-fine a Strategic Dependency (SD) model. An SD modeldepicts the dependencies between the different (social)actors without delving into their internal intentions.Then, we will refine this model by defining a StrategicRationale model to represent a more microprocess

view [3] of the agile method. SR diagrams modelactors’ internal goals, and their supporting rationales,that is, the combination of activities, artifacts, quali-tative attributes, subgoals, and dependencies that helpthe actor to achieve its major goals. Once we havethe models defined, it will be easy to highlight themajor vulnerabilities of the process (important to payspecial attention to them before adopting a process),and to answer different kinds of social/organizationalquestions about the process, as the ones pointed out inthe previous section.

A complete description of the i* notation is outsideof the scope of the paper (see [19] for details) butTable 1 provides a summary of its main elements andour proposed interpretation in the context of socialmodels of software processes. The graphical symbolcorresponding to each element is shown in the legendsaccompanying the figures of this section.

Table 1. The i* notations and their role in themodeling of social aspects of software processes

i* notation Process InterpretationGoal Process functional objective (state that

should be reached during process enact-ment) with clear-cut achievement criteria

Sofgoal Process qualitative objective, including ex-pected quality attributes of activities orproducts (e.g. meetings be Effective ), aswell as needed skills and objectives with noclear-cut satisfiability

Task Activities and practices prescribed by theprocess

Resource Resources needed for, and artifacts devel-oped during the enactment of process

Actor Roles defined in a process, and agents whoplay those roles

Means-Ends Link Alternating tasks for achieving a goalDecomposition Link Constituting elements of a taskContribution Link Effect of different elements on a softgoalDependency Link Dependency relations between process ac-

tors

3.1. Modeling intentional dependencies be-tween actors

The SD model is used for this purpose. An SDmodel focuses on visualizing the roles defined bya process, and the dependencies among them. Forinstance, Scrum introduces three roles: Team, ScrumMaster, and Product Owner. As an example, Figure 3along with modeling these three roles, represents somedependencies that exist between them. For example,the Product Owner depends on Team to develop prod-uct increments, and Team depends on Scrum Masterto remove its obstacles and to guide it in transitionto the new method. (Although ”Team” sounds to be a

Figure 3. Actor dependencies in a Scrum process

position rather than a role, in order to follow the Scrumterminology, we avoided to change the role names, yet”Team Member” is what actually implied by ”Team”)

Apart from (soft)goal-dependencies, in which thedependee actor is in charge of attaining the (soft)goalsdelegated by the depender, an SD model can representtask- and resource-dependencies, respectively referringto tasks to be performed and resources to be providedby dependee on behalf of depender.

Systematic representation of social interdependen-cies can help organization members to have betterunderstanding of the process, by clarifying their re-sponsibilities and expectations. This alone can preventsome cases of process failure. For instance, it hasbeen reported that one of the Scrum failure pointshappens when the Scrum Master does not remove theTeam’s obstacles [17]. In our model, it is clearly statedthat this is a responsibility that the Scrum Mastermust take care of. Furthermore, modeling intentionaldependencies also highlights the critical roles, whichshould be then carefully assigned to the most eligiblemembers. Critical roles are those with notable numberof incoming dependency links (e.g. Figure 3 accentsthe criticality of the Scrum Master role, as the numberof its incoming dependency links is notably higher thanthe others). We would like to remark the importanceof softgoals in social dependencies. Even if there is noclear-cut measurement scale to evaluate their successor failure, the dependee is supposed to do his/herbest to satisfy the softgoal. This issue should also becarefully considered while assigning process roles toorganizational actors.

Following the dependency relations, we may alsodetect how the poor performance of an actor, mightaffect the achievement of process goals and the func-tionality of other actors - what project managers seek toknow [6]. Finally, dependencies assigned to a role alsoimply that the role should have certain skills to suc-cessfully fulfill the dependency relation. For instance,

the Scrum Master has to be an Scrum expert, since itis expected to teach Scrum to the team members. Thisissue will be further elaborated while modeling actors’goals and rationales.

3.2. Modeling Actors’ Goals and Rationales

A more detailed analysis of a software processand the implications of poor performance of actors,required skills,... requires a more micro-process viewof the process [3]. To do so, we refine the previousSD model with SR models that include all internalactivities, artifacts, qualitative attributes, subgoals, anddependencies, which help process actor to achieve theirmajor goals. All these elements are specified within theboundaries (dashed-line circles) of the actor symbolcorresponding to the role.

As an example, Figure 4 depicts an SR model ofScrum, focusing on the Scrum Master. It is easy to seethat this SR model contains much more detailed infor-mation about the Scrum process. It adds new internalgoals that are required to satisfy the external depen-dencies for the actor (e.g. Facilitated Customer/TeamCollaboration), explicits additional skills (e.g. softgoalStrong in Communication) and can specify hierarchicaldecomposition of high-level goals/tasks into lower-level ones (e.g. Coach team requires training the team,monitoring its progress and chairing the meetings).More importantly, an SR model also shows how thedifferent intentional elements of the actor contribute toeach other to achieve the actor’s goals. As an example,being Strong in Communication helps achieving theFacilitated team collaboration goal. Other kinds ofcontributions are Make (the strongest positive one),Hurt and Break (the most negative one). These val-ues will be used in the next section to evaluate thefeasibility of adopting a software process in a givenorganization.

3.3. Analyzing the risks of adopting an agileprocess based on its social models

One of the benefits of intentional models is theability of revealing important social aspects of agilemethods that will help organizations trying to adoptthem. We have already hinted before the ability ofmodels in this area, for instance, to clearly visualizeresponsibilities, dependencies, critical roles,... In thissection we take a closer look to this topic and focus onthe use of our models to analyze the risks of adoptingan agile process, in terms of vulnerability points thatpotentially threat any adopting organization.

Figure 4. Representing the internal rationales of process actors

Social models can be analyzed to highlight two typesof vulnerabilities in agile methods. The first categoryof vulnerabilities, are those rooted in dependenciesand can be identified looking at SD models. Havingwell-trained and qualified actors for a certain roledoes not ensure the successful achievement of theirmethod goals, as other actors they rely on may fail.For instance, the SD model of Scrum (Fig. 3) expressesthat even a Team of skilled programmers might fail toadopt Scrum if the Scrum Master fails to guide themin their transition to Scrum.

The second category is rooted in the process soft-goals and can be identified in SR models. As men-tioned earlier, the softgoal notations can refer to social

qualifications, as well as technical expectations. Ifany of the softgoals fails (which generally deal withhuman capabilities), the overall process goals mightbe affected. For instance, if an Scrum Master doesnot have Acceptable Leadership Skills or fails to beCommitted to the Process, the achievement of itssoftgoal Participants Guided will be threatened, andthe problem will be even propagated to the other actors(through dependency relations).

Table 2 summarizes a list of identified vulnerabilitiesof the Scrum process, based on analysis of SD andSR models. It also represents the corresponding Scrumfailure points reported in [17]. Our models helped topredict most of the failure points reported in [17], and

even some new potential vulnerabilities.Intentional models can be used to systematically

analyze the conflicts between the current organizationalsetting and the method requirements. In other words,they can be used to evaluate the satisfaction (or denial)degree of each method goal, in the presence of specificsituational factors. By the end of analysis, and giventhe list of method goals/requirements the organizationis unable to satisfy with the current structure, theorganization can decide on the feasibility of adoptingthe process. The i* forward evaluation strategy [20]can be used to propagate and anticipate the effectsof situational factors on process goals. The evaluationprocess starts by tailoring the process model based onthe situation of organization/project, and then proceedsby assigning initial values to the leaf-node elementsof the SR model, which their achievement degreecan be estimated based on situational criteria. Afterinitializing all of the possible leaf nodes, the evaluationprocess completes by propagating the initial values upto the other model elements. Detailed description of i*forward evaluation can be found in [20].

4. Case Study: Adopting Scrum for anundergraduate course project

To validate the benefits of our social perspective onprocess modeling we applied our approach on an ex-perience of adopting Scrum in a classroom study. TheScrum process was used for the programming projectof an undergraduate course in Computer Science. Thecourse had about 160 second-year students, groupedin 40 teams, with 10 teaching assistants (TAs). Eachteam had to develop the same mobile application forBlackberry devices using Scrum as the developmentprocess. The TA in charge of each team played therole of Scrum Master for the team. All TAs and stu-dents were being trained in Scrum (during a one-hourlecture), and the lecturer played the role of ProductOwner. The first author of this paper was assignedas a head TA, responsible for tailoring, adopting, andmonitoring the Scrum process.

The goal of this section is to illustrate 1 - how wetailored Scrum to this specific context by analyzing theconstraints of our scenario; 2 - how we analyzed thepossible risks of adopting the tailored process, basedon the social model of Scrum; and 3 - to what extentour analysis results were substantiated in practice. In areal scenario, the organization should try to find propersolutions for all potential risks, before enacting theprocess. Due to the constraints of our course-basedscenario, fixing all possible risks was not possible.However, for the purpose of this article, this has been

useful to compare the observed problems the teamshad when adopting the process with the risks detecteda priori with our model-based analysis.

4.1. Tailoring Scrum Process, based on situa-tional constraints

In our scenario, we encountered the following re-strictions:

1) Most of TAs were not so familiar with mobileapplication development.

2) TAs were accessible only at certain times (theiroffice hours).

3) Development cycles were supposed to be exactlythree weeks (with possible extension of at most24 hours).

4) Students had little experience in programming.5) Students could not have regular daily meetings.6) Students could not always come together and

work at the same time/place.To adapt the process to these restrictions, we decided

a list of actions to be performed before the start ofthe course. An expert mobile programmer conducteda training session for TAs to become familiar withmobile programming (though this was not enough);the course lecturer asked the TAs to stay in emailcontact with their teams out of office hours, and set upa bulletin board to improve the communication withstudents; we reduced the length of sprints from thedefault 4 weeks to 3; students were supposed to usea wiki page to reflect upon their daily activities, as areplacement for daily Scrum meetings and a solutionto the problem of not being always co-located.

Taking into account the restrictions of our classroomsetting and the partial corrective actions we couldconduct, we then went to specify the social models forour specific enactment of the Scrum process (Figure5) and proceeded with the analysis of those models todetect those goals of the generic method that we werepotentially unable to achieve, which would highlightthe risks of our particular development process.

To generate the organization-specific version of theprocess model we first built the generic social model ofScrum process, and then refined it based on situationalconstraints and corrective actions. As shown in Figure5, symbols depicted in red represent our refinementsto the social model of Scrum process. We added thesoftgoals Tech Knowledgeable and Availability (withtheir corresponding contributions) to the SR model ofScrum Master; and the softgoal Programming Experi-ence and taks Use Email, Use Bulletin Board, and UseWiki to the SR model of Team.

Table 2. Identified Scrum vulnerabilities; Source Model: SD Strategic Dependency, SR StrategicRationale; Corresponding category of Scrum failure reported in [17]

Vulnerability Source Model CategoryProduct Owner Not to be Engaged in Development SD Product OwnerProduct Owner Fails in Ordered Product Backlog be Prepared SD Product OwnerTeam Not being Guided in Transition to Scrum SD TeamTeam Not to have Obstacles Removed ASAP SD N/AScrum Master Not to be Trained in Scrum SD Sprint PlanningScrum Master Fails to run Effective Scrum Meetings SD Daily MeetingScrum Master Not to be Strong in Communication SR Scrum MasterScrum Master Not to be Committed to the Process SR Scrum MasterScrum Master Fail to achieve Facilitated Customer/Team Collaboration SR N/AScrum Master Not to have Acceptable Leadership Skills SR Scrum MasterScrum Master Not respecting Macromanaging SR N/AScrum Master Fails to keep Participants Guided SR N/AScrum Master Fails to have Effective Customer Collaboration SR N/ATeam Fails in Time-Boxed planning SR Sprint PlanningTeam Not having Correctly Estimated backlog SR Sprint PlanningTeam Not to be Self-Managing SR TeamTeam Not to be Self-Organizing SR TeamTeam Not to be Cross-functional SR Team

4.2. Analyzing the social model of tailoredprocess

Apart from the generic vulnerabilities identified inTable 2, the customization of the Scrum process hasalso introduced some new possible points of failurethat may affect our capacity to effectively adopt theScrum process. For instance, adding the softgoal Tech.Knowledge to the boundary of Scrum Master , high-lighted the point that Scrum process might fail, ifthe Scrum Master does not have adequate technicalknowledge. similarly, the poor availability of ScrumMasters can have negative impact on the satisfactionof process goals.

As explained before, for evaluating the satisfaction(or denial) degree of process goals, possible leaf nodesshould be initialized with satisfied or denied labels (de-pending on our particular enactment constraints), andthen those values be propagated up to the other modelelements. Figure 5 shows the result of initialization andevaluation of tailored Scrum process. For instance, forthe subject case study, we initialized the softgoal Pro-grammers be Experienced of Team to Partly Denied,since students had very limited experience of softwaredevelopment.

After propagating the initial values through the SRmodel, we gained a prediction of how well eachmethod goal can be satisfied (see the resulting labelsin root goals in figure 5). For instance, the evaluationresults foresaw that the softgoal of Team for havingAccurate Sprint Plan would become Partly denied, dueto the predictable failure of its dependency to ScrumMaster, as well as poor evaluation of its contributing

softgoal. As another example, consider one of themain objective of Scrum Master, which is the softgoalParticipants Guided. Even if we tried to improve theavailability of TAs by adding email support, whichfavors the Committed to the process softgoal, thelimitations in the technical domain knowledge couldresult in weak denial of the softgoal ParticipantsGuided .

Social models of agile processes can also be an-alyzed with respect to their common problems. Forinstance, one of the typical conflicts with what agilemethods require is the poor participation of customersin the development process. As sown in Figure 5,this limitation would deny the goal of Product Ownerto be Engaged in Development, which, in its turn,endangers the softgoal of Scrum Master for FacilitatedCustomer/Team Collaboration. Consequently, this is-sue causes the Scrum Master to fail at satisfyingits own softgoal of Improved Productivity, and thedependency of Team for having Obstacles Removed.This chain of negative impacts can be further analyzedwithin the SR model of Team.

4.3. Credibility of analysis results

To test the credibility of this kind of analysis, wecompared the results of the systematic (model-based)evaluation of process goals, with what the processhead-TA observed regarding the average results ofeach group. In most cases, the observed values ofprocess goals were the same as model-based ones.For example, we observed that student teams weresomehow successful in being Self Managing, which

Figure 5. Tailored Scrum model for our classroom scenario

was in accordance with the model-based analysis re-sults. However, there were some cases of deviationas well. For instance, based on our model evaluationwe expected that the softgoal (quality attribute) ofteam members in being Cross Functional would beWeakly Denied. However, we observed that this qualityof team members gradually improved, as they wereapproaching final iterations. Therefore, at the end ofproject, we evaluated this softgoal as Weakly Satisfied.Table 3 summarizes the results and justifies the givenvalues.

If we take a closer look at the comparison (Figure6), we see for 6 out 10 process goals, the results ofsystematic evaluation was the same as the observedvalues. This analysis also shows that the frameworktends to evaluate process goals conservatively, sinceit made (in this case) 4 out of 10 under-estimations(observed value better than model-based value), yetmaking no over-estimation. however, It should bementioned that in 3 out of 4 under-estimated cases,the model-based values were Weakly Denied, whereasthe observed values were Weakly Satisfied. A possiblejustification to this slight deviation could be the lackof strongly distinctive definition for these two values,regarding the qualitative nature of the i* framework.

Figure 6. Analysis of the expected vs obtainedresults

5. Related Work

As mentioned before, most of the current processmodeling approaches are activity-oriented, as they fo-cus on ordering of process activities and products.Weerd et al. in [6] introduced Process-Data Diagram(PDD), which is a process modeling technique, de-veloped by integrating UML Activity Diagrams andClass Diagrams. Although PDD supports the defini-tion of process roles, it has no feature to representqualifications expected from roles, or their objectivesand social dependencies. The social aspects of software

Table 3. Analyzed vs. Observed values of Scrum method (soft)goals, applied in the case study. (WS:Weakly Satisfied; S: Satisfied; UD: Undecided; WD: Weakly Denied; D: Denied)

Actor Goal/Softgoal Expected Observed DescriptionTeam member Accurate Planning WD WS Earlier Sprint plans were faulty but their planning capability

improved, as they became more familiar with technology andneeds

Team member Collocated WS WS Wiki-based communication helped teams to overcome theproblem of not being always collocated

Team member Productivity Improved WD WS Productivity improved during the last iterationsTeam member Functionalities Developed UD S Our analysis did not reach any conclusive result for this goal

but teams ultimately developed the functionalitiesTeam member Effective Customer Collaboration S S Email contact and bulletin board were enough for this projectTeam member Cross-Functional WD WS During the semester, team learned different topics in program-

ming, testing, and designing???.Team member Correct Estimation WD WD Teams usually fall into under or over estimationTeam member Self-Managing WS WS From the beginning, students tried to divide the work, how-

ever it was not always adjustedScrum master Participants Guided WD WD Due the incomplete tech knowledge, TAs could not guide the

students by rapidly removing their obstacles.Scrum master Facilitated Customer/Team Collaboration WS S The bulletin board plus the rapid response to emails proved

to be enoughScrum master Committed to the Process WS WS TAs tried to be responsive to the teams

processes is also overlooked in the standard processengineering metamodel (SPEM 2.0) [13], as it doesnot deal with interactions among team members, ortheir contribution to the process goals.

Goal-oriented process modeling has been widelyadvocated for business process modeling [21], [22].This modeling approach has been also proposed forsoftware processes [23], [24], [30], [31]. Lee in[23] described a systematic method for process re-design called Goal-based Process Analysis (GPA).This method takes advantage of goal hierarchies toidentify missing objectives, and propose alternativesfor reaching a goal. Leijen and Baets in [24] proposeda framework for reengineering knowledge-intensiveprocesses in which the organization is modeled as agoal-directed planner for exhibiting proper responsein reaction to a stimulus. However, neither of thesetechniques is concerned with the representation andanalysis of social aspects of software/agile processesnor on the analysis of their vulnerabilities and key suc-cess or failure elements. [30], [31] are proposed to takeadvantage of method rationales for improving the pro-cess of method engineering. Rolland and Gorsz in [33]proposed an intention-based language for representingsoftware processes, in which process fragments weremodeled as pairs of (situation, decision). However, thefocus of that work was on assisting process designerswith situational solutions, rather than modeling socialaspects of software processes.

On the other hand research on social aspects of agilemethods studies the effect of social factors such asknowledge sharing, motivation and customer collab-oration on agile practices [25], the social issues that

hinder the process of introducing an agile method to anorganization [1], [2], [4], [5] and the impact of culturalfactors on software development [26]. Our approachallows an explicit representation of all these socialfactors, which can be analyzed and incorporated intothe decision-making process of an organization whenselecting a software process for a given project. Thispaper goes beyond the earlier use of i* for processmodeling [19], by focusing on agile methods and theprescriptive presentation of their social aspects.

6. Conclusions and further work

A complete understanding of a software processis hard to achieve by having a single model of theprocess [7]. This paper proposed a goal-oriented ap-proach for modeling social aspects of agile methodsto complements other more activity-oriented views.It focuses on the representation of the relationshipsand dependencies between the roles involved in theprocess, the responsibilities of each role, and the skillsneeded to play each role. It also aims at analyzingseveral kinds of possible vulnerabilities of the methodthat may endanger its successful introduction in anorganization. This view can also be helpful in moretraditional software processes.

With our approach, organizations may visualize andevaluate how well the different agile methods mayfit with their existing internal structure and minimizethe possible risks derived from their adoption. Oncedecided to implement a given method, our approachalso provides a common understanding of the methodto all different actors: what are their responsibilities,

what are the consequences of not doing their job, andhow to collaborate to fulfill their goals.

As a further work, we plan to first develop a libraryof goal models for agile processes to facilitate theevaluation and comparison of different agile methodsfrom a social perspective. We are also interested informalizing the method for adapting a given softwareprocess to the reality of each organization by matchingthe organization structure to the process goal-modeltemplate. This affects the development of softwareproject management tools that must take into accounthow a process is really applied within an organizationin order to provide a customized support for theprocess. Finally, we would like to extend the result ofour work to the field of Method Engineering wheresoftware processes are built by combining severalmethod fragments [27]. We believe that understand-ing the social aspects of method fragments can helpmethod engineers in assessing the vulnerabilities ofnew processes.

Of course, tailoring a method is still a manualtask and the quality of the results may depend a loton the ability of the method expert to identify andrepresent in the social model and the constraints ofeach specific organization. However, we are currentlyin the process of developing an evidential repositoryof method fragments to support the the credibility ofprocess social models. This repository is based onempirical studies and contains the situational evidencesof enacting method fragments in different situations.Besides, we are working to develop a customized i*forward evaluation procedure, which considers someof the specific concerns that arise during the analysisof software process models.

References

[1] Cohn, M., Ford, D.: Introducing an Agile Process to anOrganization. Computer, vol. 36, No. 6 pp. 74-78 (2003)

[2] Boehm, B., Turner, R.: Management challenges to im-plementing agile processes in traditional developmentorganizations. In: Software, IEEE, vol. 22, No. 5, pp.30-39 (2005)

[3] Osterweil, L.: Unifying Microprocess and MacroprocessResearch. SPW 2005, Vol. 3840, pp. 68-74. Springer,Heidelberg (2005)

[4] Harald, S., Martin, H.: Introducing an Agile Processin a Software Maintenance and Evolution Organization.In: Proceedings of the Ninth European Conference onSoftware Maintenance and Reengineering, pp. 256-264.IEEE Computer Society (2005)

[5] Abdelnour-Nocera, J., Sharp H.: Adopting Agile in aLarge Organisation. In: Lecture Notes in Business In-formation Processing, vol. 9, pp. 42 – 52, Springer,Heidelberg (2008)

[6] O’Donnell, M.J., Richardson, I.: Problems EncounteredWhen Implementing Agile Methods in a Very SmallCompany. In: Software Process Improvement. Vol. 16,pp. 13-24, Springer Berlin Heidelberg (2008)

[7] Derniame, J.C., Kaba, B.A., Wastell, D.G. (eds.): Soft-ware Process: Principles, Methodology, Technology.Springer-Verlag (1999)

[8] Agile Manifesto (2001). Manifesto for agile softwaredevelopment, http://www.agilemanifesto.org, visited atDecember (2008)

[9] Schwaber, K., Beedle, M.: Agile Software Developmentwith Scrum. Prentice Hall PTR (2001)

[10] Boehm, B., Turner, R.: Balancing Agility and Disci-pline, a Guide for the Perplexed. Addison-Wesley (2003)

[11] Colette, R.: A Comprehensive View of Process Engi-neering. In:Proceedings of the 10th International Con-ference on Advanced Information Systems Engineering,LNCS, pp. 1-24, Springer-Verlag (1998)

[12] Soderstrom, E., Andersson, B., Johannesson, P., Per-jons, E., Wangler, B.: Towards a Framework for Com-paring Process Modelling Languages. In:Proceedings ofthe 14th International Conference on Advanced Informa-tion Systems Engineering, pp. 600-611, Springer-Verlag(2002)

[13] SPEM 2.0: Software Process Engineering Metamodel,Version 2.0. Object Management Group (OMG) (2008)

[14] Kolcz, K.: Using SPEM/UML profile to specificationof IS development processes. Master Thesis, School ofSoftware Engineering, Blekinge Institute of Technology,,Sweden (2006)

[15] Abrahamsson, P., Warsta, J., Siponen, M., T. ,Ronkainen, J.: New directions on agile methods: acomparative analysis. In:Proceedings of the 25th Interna-tional Conference on Software Engineering, pp. 244-254,IEEE Computer Society (2003)

[16] Cockburn, A., Highsmith, J.: Agile Software Develop-ment: The People Factor. In: Computer, vol. 34, No. 11,pp. 131-133 (2001)

[17] Sutherland, J.: Seven ways to fail with scrum. In: TheJournal of Defense Software Engineering, vol. 20, No.4, pp. (2007)

[18] Yu, E., Mylopoulos, J.: Understanding “Why” in Soft-ware Process Modelling, Analysis, and Design. Pro-ceedings of 16th International Conference on SoftwareEngineering, Sorrento, Italy, pp. 159-168, (1994)

[19] Yu, E.: Towards modelling and reasoning support forearly-phase requirements engineering. In:Proceedings ofthe Third IEEE International Symposium on Require-ments Engineering, pp. 226-235, IEEE Computer Soci-ety (1997)

[20] Horkoff, J., Yu, E.: A Qualitative, Interactive EvaluationProcedure for Goal- and Agent-Oriented Models. InProceedings of CEUR Workshop in CAiSE,09 (2009)

[21] Lapouchnian, A., Yu, Y., Mylopoulos, J.:Requirements-Driven Design and ConfigurationManagement of Business Processes, In Proc. 5thInternational Conference on Business ProcessManagement (BPM 2007), LNCS Vol. 4714, pp.246-261, Springer-Verlag, Berlin Heidelberg (2007)

[22] Greenwood, D., Rimassa, G.: Autonomic Goal-Oriented Business Process Management. In: proceedingsof third International Conference on Autonomic andAutonomous Systems (2007)

[23] Lee, J.: Goal-Based Process Analysis: A Method forSystematic Process Redesign. In: Proceedings of theconference on Organizational computing systems, pp.196 - 201, ACM, New York (1993)

[24] Hans van, L., Walter, R.J.B.: A Cognitive Frameworkfor Reengineering Knowledge-Intensive Processes. Pro-ceedings of the 36th Annual Hawaii International Con-ference on System Sciences (HICSS’03). IEEE Com-puter Society (2003)

[25] Michael, J., Frank, M., Bj, rnar, T.: Human and socialfactors of software engineering: workshop summary. In:SIGSOFT Software Engineering Notes, vol. 30, No. 4,pp. 1-6 (2005)

[26] Sridhar, N., RadhaKanta, M., George, M.: Challengesof migrating to agile methodologies. In: Commun. ACM,vol. 48, No. 5, pp. 72-78 (2005)

[27] Weerd, I.v.d., Brinkkemper, S., Souer, J., Versendaal,J.: A situational implementation method for web-basedcontent management system-applications: method engi-neering and validation in practice. In: Software Process:Improvement and Practice, vol. 11, No. 5, pp. 521-538(2006)

[28] UML 2.0: Unified Modeling Language, Superstruc-ture Specificatyion. Object Management Group (OMG)(2003)

[29] BPMN: Business Process Modeling Notation. ObjectManagement Group (OMG) (2006)

[30] Agerfalk, P. J., Fitzgerald, B.: Methods as ActionKnowledge: Exploring the Concept of Method Rationalein Method Construction, Tailoring and Use. 10th Inter-national Workshop on Exploring Modeling Methods inSystems Analysis and Design (2005)

[31] Rossi, M., Tolvanen, J. P., Ramesh, B., Lyytinen, K.,Kaipala, J.: Method rationale in method engineering.Proceedings of the 33rd Annual Hawaii InternationalConference on System Sciences (2000)

[32] Elahi, G., Yu, E. . A Goal Oriented Approach forModeling and Analyzing Security Trade-Offs. (Ed.).In:Conceptual Modeling - ER pp. 375-390, (2008)

[33] Rolland, C., Grosz, G. A general framework for de-scribing the requirements engineering process. IEEEInternational Conference on Systems, Man, and Cyber-netics, ’Humans, Information and Technology’. pp. 818-823 (1994)