SAM, Slovenska akademija za management ...sam-d.si/wp-content/uploads/2018/04/DRMJv02n02a03.pdfand services solutions to services providers world - wide. The company oﬀers customer

Dynamic Relationships Management Journal, November 2013 29

IMPLEMENTING SCRUM USING BUSINESS PROCESS MANAGEMENT

AND PATTERN ANALYSIS METHODOLOGIES

Ron S. Kenett

KPA Ltd., Raanana, Israel

University of Torino, Turin, Italy

Center for Risk Engineering, NYU, New York, USA

[email protected]

Abstract

The National Institute of Standards and Technology in the US has estimated that software defects and problems an-

nually cost 59.5 billions the U.S. economy (http://www.abeacha.com/NIST_press_release_bugs_cost.htm). The study

is only one of many that demonstrate the need for significant improvements in software development processes and

practices. US Federal agencies, that depend on IT to support their missions and spent at least $76 billion on IT in fiscal

year 2011, experienced numerous examples of lengthy IT projects that incurred cost overruns and schedule delays

while contributing little to mission-related outcomes (www.gao.gov/products/GAO-12-681). To reduce the risk of such

problems, the US Office of Management and Budget recommended deploying an agile software delivery, which calls

for producing software in small, short increments (GAO, 2012). Consistent with this recommendation, this paper is

about the application of Business Process Management to the improvement of software and system development

through SCRUM or agile techniques. It focuses on how organizational behavior and process management techniques

can be integrated with knowledge management approaches to deploy agile development. The context of this work is

a global company developing software solutions for service operators such as cellular phone operators. For a related

paper with a comprehensive overview of agile methods in project management see Stare (2013). Through this com-

prehensive case study we demonstrate how such an integration can be achieved. SCRUM is a paradigm shift in many

organizations in that it results in a new balance between focus on results and focus on processes. In order to describe

this new paradigm of business processes this work refers to Enterprise Knowledge Development (EKD), a comprehen-

sive approach to map and document organizational patterns. In that context, the paper emphasizes the concept of

patterns, reviews the main elements of SCRUM and shows how combining SCRUM and EKD provides organizations

with a comprehensive framework for managing and improving software and system development.

Keywords: SCRUM, agile development, business process management, organizational patterns, enterprise knowledge

development (EKD)

1. INTRODUCTION

In the past, service providers focused onachieving top-line growth through customer acqui-sition. Although this is still a top priority, serviceproviders are currently facing new challenges, suchas service commoditization, market saturation andnew competition. Customers currently have morechoices than ever before and, in their relationshipswith service providers, customers demand simplic-

ity, convenience, value and new products. In addi-tion, telecom, media, and software companies arenow competing on each other's traditional turf, withcable companies offering phone service, Telco pro-viding satellite TV, and software developers tying itall together. If telecommunications giants are tothrive in this highly competitive landscape, they willneed to cut operating costs dramatically while learn-ing to be brisk innovators of new products and serv-ices. Large carriers with extensive legacy systemstend to reduce their overall list of suppliers. They

Dynamic Relationships Management Journal, November 2013

Ron S. Kenett: Implementing SCRUM using Business Process Management and Pattern Analysis Methodologies

30

should select one strategic best-in-class supplierthat addresses their requirements and businessgoals in each of their key solutions areas.

Service providers are required to continuouslyenhance their products and services helping to en-sure maximum operational efficiency is achievedthrough alignment, innovation through agility andtime to market, and customer loyalty through theintentional customer experience. Information sys-tems have a major influence on the agility of a com-pany. They can inhibit or enhance it. Agility meansthe time it takes to adapt to environmental shiftsquickly by changing products, systems and businessprocesses. The agility of company information sys-tems cannot be achieved by acceleratingproduct/system development using traditional de-velopment processes and architecture. Agility mustbe built into the core development processes, rolesand architecture taking into accounts the complex-ity of large global development organization thatneed to support very large service providers.

ABC Inc. is a typical large supplier of softwareand services solutions to services providers world-wide. The company offers customer relationshipmanagement, order management, service fulfill-ment, mediation, and content revenue manage-ment products, collectively known as IntegratedCustomer Management (ICM) enabling systems.These ICM Enabling Systems support various linesof business, including wireline, wireless, cable, andsatellite, as well as a range of communications serv-ices, such as voice, video, data, Internet protocol,broadband, content, electronic, and mobile com-merce. ABC Inc. also supports companies that offerbundled or convergent service packages. In addi-tion, it provides directory sales and publishing sys-tems for publishers of both traditional printedyellow page and white page directories, and elec-tronic Internet directories. In addition, the com-pany's information technology services compriseconsulting, business strategy, system implementa-tion, training, integration, and modification. Further,ABC Inc. provides managed services that includesystem modernization and consolidation, operationof data centers, ongoing support, maintenance serv-ices, system modification, provision of rating andbilling services, and communications facility man-agement services. Its customers include communi-

cations providers, and network operators and serv-ice providers. The company was founded in 1982.

The company's workforce of more than 16,000professionals are located in more than 50 countries,with development and support centers in Brazil,Canada, China, Cyprus, India, Ireland, Israel and theUSA. ICM requires improved software development ca-pabilities. This paper is about the application of newsoftware development paradigms in large global or-ganizations such as ABC Inc. Specifically; this work fo-cuses on the application of Business ProcessManagement to the improvement of software and sys-tem development through SCRUM. Implementing ICMusing SCRUM or any other agile approach in large mul-tisite organizations with highly demanding customers,is a significant challenge. Governance in such a contextwhere knowledge management is critical and dissem-ination of best practices across teams and cultures isrequired, poses problems of capturing process pat-terns, storing this knowledge and ensuring knowledgereuse needs to occur. This paper presents a frameworkfor addressing this challenge in a practical way. Themain elements of SCRUM are reviewed in the next sec-tion that also shows how combining SCRUM and EKD(Enterprise Knowledge Development), a BusinessProcess Management methodology, provides organi-zations with a comprehensive framework for managingand improving software and system development.

2. AGILE SOFTWARE DEVELOPMENT

2.1 Background

Many software projects do not achieve theirgoal with respect to time to market, budget, qualityand/or customers expectations. The National Insti-tute of Standards and Technology in the US has es-timated that software defects and problemsannually cost 59.5 billions the U.S. economy. Thestudy is only one of many that demonstrate theneed for significant improvements in software de-velopment processes and practices (http://www.v3.co.uk/v3-uk/news/1973196/software-bugs-cost-bil-lions). See also GAO (2012). The main root-cause forthis was found not in the technology arena but inthe development process methodology (see Figure1 based on data from a research conducted in 2003by Forrester Research).


One possible response to this phenomenon is tomake developing methodologies more disciplinedand predictive, i.e., more planning, greater attentionon analysis of requirements, formal sign-off, detailedand documented design before coding, strict changecontrol etc... This approach is known as the "waterfallprocess" (Kenett & Baker, 1999). Under this approachthe organization gets better control but project suc-cess rates does not necessarily improve. Many organ-izations have found that, by this approach:

• Methodologies simply prove bureaucratic andslow to deliver.

• It is hard for the business to completely concep-tualise all requirements in one pass.

• It is even harder to capture all the requirements ina document in a completely detailed and unambiguous form, The customer does not under-stand UML and specs, that's lead to free interpre-tation of the requirements by the different playersthrough the development downstream (e.g. sys-tem analysts, designers, developers, testers).

• Businesses constantly change - requirements andbusiness priorities constantly change, the longerthe project the greater the risk. If change is suc-cessfully suppressed, the business gets soft warethey can’t use.

• Its hard to completely design a system in one ex-ercise and not of great value if the requirementschange anyway.

• Developers do not know how to estimate the im-pact of complex requirements.

For more on problems in software develop-ment processes see April et al., 2005, Berntsson-Svensson & Aurum, 2006 and Kenett & Baker, 2010.An alternative to the waterfall process, that encour-ages software development involving a high degreeof innovation, is a software development paradigmlabeled the "agile process" (http://en.wikipedia.org/wiki/Agile_software_development). The next sub-section provides an introduction to the agileprocess.

2.2 The Agile Process

One of the main ideas behind agile methodolo-gies is that evolutionary processes that seek tomove by a large number of small steps, on schedulebased cycles (30-90 days), each of which deliversome benefits that are stable and workable solutionis more effective. A common rule of thumb is that20% of the features of a system delivers 80% of thebenefit, so earlier more frequent releases can bringsignificant gains. A particular important observationabout agile processes is that they seek to shortenor eliminate feedback loops. For example, bringingempowered users into contact with the develop-ment team can remove much longer cycles of tryingto describe what is needed, developing it and tryingout the product (Takeuchi & Nonaka, 1986, 1995).

Figure 1: Corporate Executives’ Reasons For Project Failures



32

Similar observations can be made about otheragile practices such as establishing a joint cross dis-cipline team that accountable as a team to deliverthe feature. The communication is mostly face toface, with minimal unnecessary documentation(versus the waterfall model were the main mean ofcommunication between the disciplines are throughdocumentation that leads to the need of interpre-tations). Also other agile practices such as automaticunit testing, pair programming (versus peer re-views), daily stand-up meetings for planning, auto-mated build and regression testing derived from thenotion that getting better feedback sooner improvesboth quality and control. Finally priority-driven plan-ning is an essential feature of most agile methods.Managing requirements individually, rather than asa composite document, allows the high benefit, lowcost features to be rolled out to users sooner. Alsofixing timescales for deliveries rather than fixing therequired features and allowing timescales to slip, isa far more effective means of ensuring continuousenhancement of business performance.

In systems development, an evolutionary ap-proach requires investment – particularly in test-dri-ven design, continuous integration andcomprehensive automated build facilities from aconfiguration management system. Such invest-ment is nearly always worthwhile since it can elim-inate a separate integration and test phase andallow early release of useful functionality. The tra-ditional Quality Gates are not applicable to the newagile process since now activities are not dividedinto phases, but rather focused around implemen-tation of individual features or stories. To replaceQuality Gates the new agile framework proposes aset of repeating checkpoints. Some checkpoints re-peat only once in iteration, for example the check-point that marks the end of the iteration planning,or the iteration review at the end. Other check-points are associated with individual requirementsor features, such as the checkpoint that marks com-pletion of a feature. While these checkpoints occurmuch more frequently than Quality Gates, and in anagile process must be much lighter weight in termsof ceremony (For more on agile development seeSchwaber & Beedle, 2001; Kenett & Baker, 2010).

For agile methods to scale up, the most impor-tant thing is to establish a suitable framework that

is sufficiently generic to apply across the organiza-tion whilst providing detailed guidance. This frame-work in itself has the power to improve agilitythrough helping programmers to structure their de-liveries into shorter cycles while also steering themtowards a more iterative and collaborative approach(Cohn & Ford, 2003). The next section describes thebasic elements of the agile process.

2.3 SCRUM

One of the most common agile methodologiesis SCRUM that mainly focus on the way agile projectshould be managed. It was first described in 1986 byTakeuchi and Nonaka. SCRUM is not an acronym,name taken from the sport of Rugby, where everyonein the team pack acts together to move the ball downthe field. Analogy to development is the team workstogether to successfully develop quality software. Inparticular: “SCRUM” refers to the entire team band-ing together for a single aim: getting the ball!

2.3.1 The SCRUM Process

Figure 2 presents conceptually the SCRUMprocess (adapted from Kenett and Baker, 2010).

Key SCRUM practices include:

• Focus on schedule based cadence, sprints are it-erations of fixed 30 days duration.

• Work within a sprint is fixed. Once the scope of aSprint is committed, no additional functionalitycan be added except by the development team.

• All work to be done is characterized as productbacklog which includes requirements to be deliv-ered, defect workload, as well as infrastructureand design activities.

• The product Backlog is the basis for the Sprintbacklog as defined by the sprint team and theproduct owner. The team decides what it can de-velop.

• A SCRUM Master mentors and manages the selforganizing and self accountable teams that are re-sponsible for delivery of successful outcomes ateach sprint.

• A daily standup meeting is a primary communica-tion method.


• A heavy focus on time boxing. Sprints, standupmeetings, release review meetings and the likeare all completed in prescribed times.

• SCRUM also allows requirements, architecture anddesign to emerge over the course of the project.

SCRUM lifecycle phases are Planning, Staging,Development, and Release. There are typically asmall number of development sprints to reach a re-lease. Later sprints focus more on system level qual-ity and performance as well as documentation andother activities necessary to support a deployedproduct. Typical SCRUM guidance calls for fixed 30day sprints, with approximately three sprints per re-lease, thus supporting incremental market releaseson a 90 day timeframe (Schwaber & Beedle, 2001).

2.3.2 Roles in SCRUM

Agile development is carried out by individualswith specific roles and responsibilities. These are de-scribed below:

• SCRUM MasterMain focus is to safeguard the process, removingthe barriers between development and the cus-tomer, enable close cooperation between rolesand functions across the organization, facilitatingcreativity and empowerment.Improving the productivity of the developmentteam in any way possible; and, Improving the en-gineering practices and tools so each incrementof functionality is potentially shippable.

• SCRUM TeamThis is a cross-functional group of people with allthe different skills that are needed to turn re-quirements into something that is an incrementof potentially shippable functionality. The SCRUMTeam responsible for the project, committed todeliver. Has the right to do everything within theboundaries of the project guidelines to reach theiteration goal. The team consists typically from 5-10 people, Cross-functional team (QA, Program-mers, Designers, etc.).Members should be full-time as possible. Teams

Figure 2: The SCRUM process



34

are self-organizing, ideally, no titles but rarely apossibility. Membership can change only betweensprints.

• Product OwnerThe 'Product Owner' is responsible for the finan-cial success of the project. So this is the personwho is investing or representing everyone's inter-est in the project and serves as the ultimate ar-biter on any requirements issues and accepts orrejects work results. The product owner definesthe features of the product, decides on releasedate and content, prioritizes features accordingto market value, can change features and priorityevery Sprint, this requires high bandwidth com-munication and transparency into the team’sprogress.

• Management Management is in charge of final decision making,along with the charters, standards and conven-tions to be followed by the project. Managementalso participates in setting the goals and require-ments.

2.3.3 Meetings/Activities in SCRUM

Work in an agile development environment re-quires a high degree of synchronization. To achievethis one carries out a series of well-orchestrated andactively managed meetings and activities. These aredescribed below.

• Pre-game – High level design and ArchitectureIn the architecture phase the high level design ofthe system including the architecture is plannedbased on the current items in the Product back-log. In case of enhancement to an existing systemthe changes needed for implementing the Back-log items are identified along the problems theymay cause. A design review meeting is held to goover the proposals for the solution and decisionsare made. In addition, preliminary plans for thecontents of releases are prepared.

• Pre-Game - Release PlanningThe Product Backlog lists all the functionality thatthe product or solution could have in it. If all ofthis functionality is built before a release to pro-duction it may waste the opportunity that SCRUMprovides for seeing an early return on investment

and useful production feedback. For these rea-sons it is common practice to divide the ProductBacklog into "Releases" or collections of usefulsystem capability that make sense when put intoproduction.

• Sprint PlanningUsually every sprint has a goal or main theme thatexpress the Product Owner’s motivation for thissprint, embodied as specific measurable exit cri-teria. Each Sprint must include some businessfunctionality. The sprint planning session consistof 2 segments (usually around 4 hours each). Seg-ment 1 - The Product Owner selects the idealbacklog for the coming Sprint and communicatesits meaning and importance to the team. Seg-ment 2 - Team decides what they can commit todelivering in the Sprint. The Product Owner an-swers questions but does not direct the team’schoices. The Team decides how to turn the se-lected requirements into an increment of poten-tially shippable product functionality. The teamself-organizes around how they’ll meet the SprintGoal, The Team devises its own tasks and figuresout who will do them. The outcome is the SprintBacklog.

• SpikeA spike is an experiment that allows developersto learn just enough about something unknownin a user story, e.g. a new technology, to be ableto estimate that user story. A spike must be time-boxed. This defines the maximum time that willbe spent learning and fixes the estimate for thespike.

• Daily SCRUMA short status meeting that is time-boxed to 15minutes and is held daily by each Team. Duringthe meeting the Team members synchronize theirwork and progress and report any impedimentsto the SCRUMMaster.

• Sprint ReviewThe Sprint Review provides an inspection of proj-ect progress at the end of every Sprint. The teampresents the product increment that it has beenable to build. Management, customers, users, andthe Product Owner assess the product increment.Evaluation possible consequences: Restoring un-finished functionality to the Product Backlog and


prioritizing it. Removing functionality from theProduct Backlog that the team unexpectedly com-pleted. Working with the SCRUMMaster to refor-mulate the team. Reprioritizing the ProductBacklog to take advantage of opportunities thatthe demonstrated functionality presents. Ask fora release Sprint to implement the demonstratedfunctionality, alone or with increments from pre-vious Sprints. Choosing not to proceed furtherwith the project and not authorizing anotherSprint. Requesting that the project progress besped up by authorizing additional teams to workon the Product Backlog.

• Sprint RetrospectiveThis is a meeting facilitated by the SCRUMMasterat which the Team discusses the just concludedSprint and determines what went well and whatcould be changed that might make the next Sprintmore productive. While the Sprint Review looksat "What" the team are building whereas the Ret-rospective looks at "How" they are building.

• Post-Game – Release sprint (integration, systempackaging)When the Product Owner and Stakeholders iden-tify that there is sufficient functionality in the sys-tem to provide immediate business value theymay choose to put this into production. Typically,a "Release Sprint" will follow that contains all thenecessary Sprint Backlog tasks to put the systeminto production. These tasks shouldn't contain ad-ditional functionality but they may include: Fullend-2-end system test, integration, performanceand regression test if necessary. Finishing re-quired documentation, Deploying the code to theProduction Environment, production data popu-lation, setting up management and operationalsystems and processes, training and handover forsupport staff and Cutover and fallback planning.

2.3.4 SCRUM Artifacts

Artifacts are concrete deliverables that are pro-duced and maintained during software develop-ment. We list here the five most important artifactsassociated with agile development.

1. Product Backlog A product backlog is a prioritised list of project

requirements with estimated times to turn

them into completed product functionality. Es-timates are in days and are more precise thehigher the item is in the Product Backlog prior-ity. Priority should be assigned based on theitems of most value to the business or that offerthe earliest Return on Investment. This listshould evolve, changing as the business condi-tions or technology changes.

2. Sprint Backlog The Sprint backlog is a list of tasks that defines

a Team's work for a Sprint. The list emerges dur-ing Sprint planning. The tasks on the Sprintbacklog are what the Team has defined as beingrequired to turn committed Product Backlogitems into system functionality. Each task iden-tifies who is responsible for doing the work andthe estimated amount of work remaining onthe task on any given day during the Sprint.

3. Impediment list Anything around a SCRUM project that impedes

its productivity and quality is an impediment. Itis the responsibility of the SCRUMMaster to re-move any impediment that is stopping the teamfrom producing production quality code. Theimpediment list is simply a set of tasks that theSCRUMMaster uses to track the impedimentsthat need to be solved.

4. Task List Tasks to turn product backlog into working

product functionality. Tasks are estimated inhours, usually 1-16. Tasks with more than 16hours are broken down later. Team's membersign up for tasks, Team members shouldn’t signup for work prematurely (until actually startingthat task). Estimated work remaining is updateddaily, any team member can add, delete orchange the Sprint Backlog. Work for the Sprintemerges, if the team believes that this becometoo much, they can meet again with the ProductOwner.

5. Product Burndown Chart The Product Burndown chart gives an indication

of how quickly the team are "Burning" throughthe work and delivering Product Backlog re-quirements. It is a useful tool for helping to planwhen to release or when to remove require-ments from a release if progress is not rapidenough.



36

2.3.5 Scaling SCRUM in big projects

The primary way of scaling SCRUM to work withlarge teams is to coordinate a "SCRUM of SCRUMs".With this approach each SCRUM team proceeds asnormal but each team also contributes one personwho attends SCRUM of SCRUM meetings to coordi-nate the work of multiple SCRUM teams. Thesemeetings are analogous to the Daily SCRUM Meet-ing, but do not necessarily happen every day. Inmany organizations, having a SCRUM of SCRUMsmeeting two or three times a week is sufficient.

Implementing SCRUM is basically an organiza-tional change. Implementing such a change in alarge organization is a complex task that requires afiled tested methodology. The next section de-scribes, EKD, a Business Process Methodology thathas been used to transform major organizationssuch as electricity supply companies (Rolland et al.,1998, 1999). In particular, it describes the conceptof "patterns" as an approach to capture knowledgeand allow for organizational learning and re-use.The following section shows how to implementSCRUM in the context of a large organization usingEKD. The final section concludes with some discus-sion and directions for future research.

3. BUSINESS PROCESS MANAGEMENT

3.1 An Introduction to Enterprise Knowledge

Development (EKD)

Enterprise Knowledge Development (EKD) wasdeveloped in the FP4 ELEKTRA project supported bythe European Commission as a Business ProcessManagement methodology for large organizations(http://crinfo.univ-paris1.fr/PROJETS/elektra.html).It provides a controlled way of analysing and docu-menting an enterprise, its objectives and supportsystems. The approach represents an integrated setof techniques and associated tools for the purposeof dealing with situations of mapping businessprocesses and re-engineering of information sys-tems. At the centre of the approach is the develop-ment of enterprise knowledge models pertaining tothe situations being examined (Rolland et al., 1998,1999). The definition of such models is carried outusing appropriate modelling techniques and tools.The process followed in developing these models,

and subsequently using them, is the subject matterof the guidance component. During the process ofdeveloping these models, the participant parties en-gage in tasks that involve deliberation and reason-

ing. The purpose is to provide a clear, unambiguouspicture of how enterprise processes function cur-rently in an "as is" model or in a modified "shouldbe" model.

The EKD approach considers the concept of an‘enterprise process’ as a composite of four key en-terprise components: (a) the roles that are playedby enterprise actors in order to meet the processgoals; (b) the activities involved in each role; (c) theobjects that are involved together with their evolu-tion from creation to extinction (within the contextof the enterprise process); and (d) the rules that de-termine the process components. In other words,an enterprise process may transcend any functionaldivisions and presents a dynamic view of an enter-prise system. Systems are composed of interfacingor interdependent parts that work together to per-form a useful function. System parts can be anycombination of things, including people, informa-tion, software, equipment, products, or raw mate-rial. In effect, operational models should describewhat a system does, what controls it, what it workson, what it uses to perform its functions, and whatit produces.

Actor-role modelling is about representing theorganisational and behavioural aspects of an enter-prise. This aspect of modelling is concerned with theway that a business process is performed throughthe involvement of enterprise actors in dischargingtheir responsibilities through their role in a processand the interaction of their role with other roleswhich collectively bring about the realisation of thebusiness processes. Through enterprise actor-rolemodelling, EKD encourages the identification of thekey operational components which can be meas-ured (activity duration, actor skills, resource costingetc.). Such measurable components can then besubjected to ‘what-if’ scenaria in order to evaluatealternative designs for the operation of an enter-prise. A high-level view of the association betweenactors and their different roles is supported throughthe actor-role diagram. The actor-role diagram de-picts the actors of the enterprise and the roles thatthey play. For each role involved in the model, infor-


mation is given about the responsibilities that areassigned to the role in terms of the activities thatthe role carries out and the enterprise resourcesthat the role requires. The diagram also presents thedependencies that exist between the roles. An ad-ditional element represented in this view is the goal(or goals) that the role must satisfy. The actor-rolediagram can be used to get a ‘first-cut’ view of theorganisational aspects regarding the responsibilitiesof individuals or groups in their involvement in theoperation of a business process.

A detailed view of the activities in which a roleis engaged is supported by the role-activity diagram.This diagram describes in detail how the role per-forms each of its responsibilities, in terms of activi-ties undertaken and is based on the notation of theRAD (role activity diagram) approach . An importantpoint to note is the distinction between the actor,i.e. the physical enterprise entity, and the role, a no-tion which expresses the responsibility of perform-ing the various activities within the enterprise. Rolesare assigned to actors and summarise a set of skillsor capabilities necessary to fulfil a task or activity. Arole can be acted by a person or a group. A role canbe acted by person X on one day and person Y onanother day. The role is separate from the actorsthat play the role. For example, a managing directormay play multiple roles such as ‘setting the budget’‘approving expenses’, etc. A role is a collection ofcomponents of either operational or structural na-ture expressing responsibilities. Operational compo-

nents represent the activities that the role has toperform. Structural components represent resourceobjects that are required by one or more activitiesbeing carried out by the role. These may be physicalor informational. The role can thus comprise behav-ioural aspects of the organisational life as well as hi-erarchical and social aspects. The notation for a roleand its goals is shown in Figure 3.

3.2 EKD Actor and Role Components

3.2.1 The Actor

It is essential to distinguish between the roleand the carrier of the role, i.e. the actor who at aspecific moment might play the role. The role existsindependently of what organisational entity is cho-sen to play it; this particular choice can be changedover time, as particular actors may change in carry-ing the responsibilities of a role. A role should there-fore be considered as a stable and accountableconcept, one that summarises a set of responsibili-ties and the activities that are performed in orderto fulfil these responsibilities. An actor is the physi-cal entity that personifies an instance of the role atany given moment; an actor may play several rolesat the same time. In that sense, while the selectionof roles and their responsibilities can be consideredas a design choice, the selection of actors for playingindividual roles can be considered as an implemen-tation strategy. In EKD, the notation for the actorconcept is the actor box (Figure 4).

Figure 3: The role box and its goals

3.2.2 The Actor-Role Relationship

The relationship between a role and the actorthat, at a particular time, incarnates this role is rep-resented by the plays relationship which is shownas an arrow (Figure 5). The arrow connects an actorbox with a role box and illustrates that the actorplays the particular role.

3.2.3 The Role-Role Relationship

Roles are often dependent upon other roles inorder to perform the duties assigned to them. Thereare two parties involved in the dependency: the re-

quester role, i.e. the one that needs something inorder to fulfil its responsibilities, and the provider

Figure 4: The actor box

Figure 5: The actor-plays-role arrow



38

role, i.e. the one that can provide the missing com-ponent.

This relation can be of various types:

Authorisation dependency: this denotes hierarchi-cal dependencies that can exist between roles; theprovider role gives authorisation to the requesterrole. For instance, in order to for changes to somecustomer accounting data to be performed, an au-thorisation of the responsible manager must begiven.

Goal dependency: this relationship reflects the factthat the achievement of a goal that the role bringsabout is dependent on the achievement of a goal ofanother role. For instance, the goal of the customerservice provision to satisfy customers promptly de-pends on satisfaction of the goal on immediateavailability of programmers expressed by thehuman resource FTE numbers. Generation of arti-facts or deliverables is also considered a goal.

Coordination dependency: this type of dependencyexpresses the need for one role to wait for comple-tion of another role’s responsibilities before it cancomplete its own. For example, in order for the ma-terial provision service to purchase material, an ap-propriate invoice must first be prepared by theaccounting service.

Resource dependency: this illustrates the need forone role to use a resource that can be provided byanother role. For instance, the construction servicerequires material that is under the supervision ofthe warehousing service.

The dependency relationships are representedby the dependency arrow, as depicted in Figure 6.The dependency arrow is accompanied by the initialof the dependency type and superscripted by anyadditional details on the dependency. The initials ofthe dependency types are A for authorisation de-pendency, R for resource dependency and C for ac-tivity coordination dependency [the “ARC”dependency]. The dependency arrow is directedfrom the provider role towards the requester role.

3.2.4 Using the Notation

The role box consists of the name of the roleand its components, which are drawn within itsboundary. A sample role box and the actor thatplays the role is presented in Figure 7.

Figure 6: The dependency arrow

The dependency relations, is shown by drawinga dependency arrow between the two role boxes. Asample actor-role diagram comprising two roles,their respective actors and a coordination depend-ency is illustrated in Figure 8.

3.2.5 Guidelines for the Actor-Role Diagram

1. An actor cannot exist without playing any role,i.e. at any moment every actor within the or-ganisation should be assigned at least one role.

2. If more than one dependencies are identifiedbetween roles, multiple arrows are drawn, eachannotated by the respective dependency typeand details.

3.2.6 Examples of Actor-Role Diagrams

A number of examples in this section demon-strate the concepts (and the use of the notation) foractor-role modelling.

Figure 7: A sample of actor-role relationship

Figure 8: A sample actor role diagram


The actor-role diagram of Figure 9 represents asituation of two actors each playing a different rolewith different goals and the dependency of the “ser-vice customer” role on “supervise local support”role. The former requires the latter in order to per-form certain activities. This kind of dependencyshows the structural relationship between the tworoles as being one of authorisation (indicated by the“A” on the dependency line).

Activity Refinement

Apart from sequential execution of activities, onecan also have parallel execution of more than oneactivities. Moreover, selection can be made be-tween two or more activities , according to whethera condition is satisfied or not. These controls overactivities are called part refinement and case refine-

ment, respectively, and they are illustrated in Figure11 Part refinement and case refinement.

In part refinement two or more parallel activitysequences are initiated with circles, while in case re-finement the alternative activity sequences are ini-tiated with triangles, which also indicate the valueof the criterion that determines which of the alter-natives is executed. With respect to 11, in the leftpart activities A2 and A3 are executed in parallelafter activity A1; in the right part one of the two ac-tivities is selected according to the answer to thequestion posed.

3.3 EKD Role-Activity Diagram

3.3.1 Basic Concepts and Notation

The Role

The concept of a role is also used in the role-activitydiagram. In this case, however, it is used to group to-gether the details of the activities being carried outwithin the enterprise, including information on theirorder of execution and their interdependencies.

Activity Sequence

The activities that a role performs are representedas sequences of nodes. Nodes are drawn as blacksquares, which are connected with a straight verticalline. These primitives are illustrated in Figure 10.

Figure 9: An example actor-role diagram with

“authorisation” dependencies

Figure 10: Activity sequence components

Role interaction

At some point during an activity sequence a rolemay need to interact with another role. This meansthat both roles will be involved in activities thatmake their respective actors communicate in vari-ous ways. The notation for this interaction is repre-sented as a horizontal line connecting the twoactivities across the boundaries of the roles, asshown in Figure 12.

Figure 11: Part refinement and case refinement

Figure 12: Role interaction



40

The level of detail of the interaction is not spec-ified, nor is the duration of the interaction. Depend-ing on the case, an interaction can be decomposedinto smaller, more detailed activities and interac-tions, or it can be represented as a single interac-tion. This choice, however, is left to the modeldesigner and is related to the importance of the spe-cific interaction in the overall model.

3.3.2 Using the notation

The activities of which a role consists are re-fined in this level. The role box now contains a se-quence of activities, possibly refined according toone of the refinement schemes previously pre-sented, as illustrated in Figure 13.

covered within a particular domain with the purposeof being useful in many similar situations. A patternis useful if it can be used in different contexts.

3.4.1 The Notion of Pattern

Alexander defines a pattern as describing “aproblem which occurs over and over again in our en-vironment and then describes the core of the solu-tion to that problem, in such a way that you can usethis solution a million times over, without ever doingit the same way twice" in (see Alexander, 1979,http://www.c2.com/cgi/wiki?TimelessWayOfBuild-ing). Here, the emphasis is put on the fact that a pat-tern describes a recurrent problem and it is definedwith its associate core solution. According to Alexan-der, what repeats itself is a fabric of relationships.For example, when a statistical consultant is first ap-proached by a customer and gets a first look atsome data, or a detailed description of it, the statis-tical consultant is initiating a basic investigation tounderstand the context of the problem. This exam-ple represents a structural pattern which is repeat-able in many different settings; for example in atroubleshooting assignment in manufacturing, or amarket research study. Aligned to this structural pat-tern, there is a pattern of events which is also re-peatable, in our example the basic investigationpreceding the statistical analysis takes place timeand time again within a company.

It is important to note that a pattern relates aproblem to a solution.

3.4.2 Pattern Template

A pattern is more than just a description ofsome thing in the world. A pattern should also be a‘rule’ about when and how to create that thing.Therefore, a set of desirable properties for a patternmay be the following:

A pattern should be made explicit and preciseso that it can be used time and time again. A patternis explicit and precise if:

• It defines the problem (e.g. ‘we want to improveyield in a manufacturing process’) together withthe forces that influence the problem and thatmust be resolved (e.g. ‘managers have no sense

3.3.3 Guidelines for the Role-Activity Diagram

Dependencies identified at the actor-role levelmodel are represented as interactions at the role-ac-tivity level; indeed, interdependencies between rolesare translated into specific activities at this level,which constitute the interface between the roles.

3.4 An Overview of Patterns

The software development community is a use-ful source of examples of pattern use, in particularby those advocating and practising object-orientedapproaches and re-use. What these efforts have incommon is in their attempt to exploit knowledgeabout best practice in some domain. Best practiceknowledge is constructed in ‘patterns’ that are sub-sequently used as the starting point in the program-ming, design or analysis endeavours. Patternstherefore, are not invented but rather they are dis-

Figure 13: A role-activity diagram


for data variability’, ‘collaboration of productionpersonnel must be achieved’ etc.). Forces refer toany goals and constraints (synergistic or conflict-ing) that characterise the problem.

• It defines a concrete solution (e.g. ‘how shouldbasic problem investigations be done’). The solu-tion represents a resolution of all the forces char-acterising the problem.

• It defines its context (e.g. ‘the pattern makessense in a situation that involves the initial inter-action between the statistical consultant and hiscustomer’). A context refers to a recurring set ofsituations in which the pattern applies.

A pattern should be visualisable and should beidentifiable, so that it can be interpreted equallywell by all who might share the pattern. In this sense“visualisation” may take the form of ‘statements innatural language’, ‘drawings’ conceptual models’and so on.

In the literature there are many different pro-posals for the description of those desirable prop-erties (Alexander, 1979; Coplien, 1994; Rumbaugh,1995). One general example is the pattern templatepresented in Table 1.

There exists a growing collection of document -ed patterns, even if these as yet mainly consist ofsoftware patterns, for example:

Software development patterns:

• http://hillside.net/patterns/

• http://www.cmcrossroads.com/bradapp/docs/

patterns-intro.html

• http://c2.com/cgi-bin/wiki?JimCoplien

The Process Patterns Resource Page:

• http://www.ambysoft.com/processPatterns

Page.html

OrganizationalPatterns:

• http://www.bell-labs.com/cgi-user/

OrgPatterns/OrgPatterns?Organizational

Patterns

• http://people.dsv.su.se/~js/ekp/ekp.html

• http://crinfo.univ-paris1.fr/EKD-CMMRoad

Map/index.html

Antipatterns Repository:

• http://c2.com/cgi/wiki?AntiPatterns/

Anti-patterns are defined as telling you how togo from a problem to a bad solution, telling you howto go from a bad solution to a good solution or,something that looks like a good idea, but whichbackfires badly when applied. Recognising "bad"business practice may provide knowledge or impe-tus for identifying and describing the relevant goodpractice.

4. EKD, PATTERNS AND SCRUM

This section revisits the SCRUM componentsusing the EKD description of patterns. Some exam-ples are used to describe the basic elements of aSCRUM patterns repository, how it can be popu-lated, maintained and used.

4.1 SCRUM, EKD and Pattern Description

SCRUM patterns consist of SCRUM activities,roles and artifacts. Figure 14 lists key SCRUM activ-ities. After describing these elements using EKD no-

Name: it should be short and as descriptive as possible

Examples: one or several diagrams/drawings illustrating the useof the pattern,

Context: it focuses on the situation where the pattern is ap-plicable,

Problem: it is a description of the major forces/benefits of thepattern as well as its applicability constraints

Solution: it details the way to solve the problem, it is com-posed of static relationships as well as dynamic onesdescribing how to construct an artefact according tothe pattern. Variants are often proposed along withspecific guidelines for adjusting the solution with re-gards to special circumstances. Sometimes, the solu-tion requires the use of other patterns.

Table 1: A Pattern Template with instructions

The structure of the pattern includes informa-tion describing the pattern, examples of use alongwith information describing the relationships thatthe pattern has with other patterns and so on.



42

tation (see for example Figure 15 and 16) the elici-tation and organisation of patterns in a patternrepository is discussed.

progress as provided in traditional development. Itfeels risky to do so; there is no guarantee that theteam will deliver. Often, by the time systems are de-livered, it is obsolete or it requires major changes.The problem is that input from the environment isFigure 14: High level view of SCRUM activities

A sample Sprint pattern:

Context: You are a software developer or a coachmanaging a software development team where thereis a high percentage of discovery, creativity or testinginvolved. Sprints are applicable for building systems,both new and existing, that allow partitioning ofwork, with clean interfacing, components or objects.We want every person on the team to understandthe problem fully and to be aware of all the steps indevelopment. This limits the size of the team and ofthe system developed. Trust is a core value inSCRUM, and especially important for the success ofSprints, so SelfSelectingTeams is a plus. During asprint, we optimize communications and maximizeinformation sharing in DailySCRUM. Each Sprint

takes a pre-allocated amount of work from the Back-log. The team commits to it. As a rule nothing isadded externally during a sprint. External additionsare added to the global backlog. Issues resulting fromthe Sprint can also be added to the Backlog. A Sprintends with a Demonstration of new functionality.

Problem: We want to balance the need of develop-ers to work undisturbed and the need for manage-ment and the customer to see real progress.

Forces: For many people – project managers, cus-tomers, it is difficult to give up control and proof of

mostly collected at the start of theproject, while the user learns mostusing the system or intermediatereleases.

Solution: Give the developers thespace to be creative, and to learnexploring the design space, doingtheir actual work, undisturbed byoutside interruptions, free to adapttheir way of working using oppor-tunities and insights. At the sametime keep the management andstakeholders confident by showingreal progress instead of documentsand report produced as proof. Dothis in short cycles, Sprints, wherepart of the Backlog is allocated to

a small team. In a Sprint, during a period of approx-imately 30 days, an agreed amount of work will beperformed, to create a deliverable. During Sprint-

Planning a Backlog is assigned to Sprints by priorityand by approximation of what can be accomplishedduring a month. Chunks of low cohesion and highcoupling are selected. Focus is on enabling, ratherthan micromanagement. During the Sprint outsidechaos is not allowed in the increment. The team, asthey proceed, may change course and their way ofworking. By buffering them from the outside, weallow them to focus on the work at hand and on de-livering the best they can and the best way they can,using their skill, experience and creativity. EachSprint produces a visible and usable deliverable.This is demonstrated in DemoAfterSprint. An incre-ment can be either intermediate or shippable, butit should stand on its own. The goal of a Sprint is tocomplete as much quality software as possible andto ensure real progress, not paper milestones asalibi. Sprints set up a safe environment and timeslots where developers can work undisturbed byoutside requests or opportunities. They also offer apre-allocated piece of work that the customer, man-agement and the user can trust to get a useful de-liverable such as a working piece of code at the end


of the Sprint. The team focuses on the right thingsto do, management working on eliminating whatstands in the way of doing in better.

Rationale: Developers need time to work undis-turbed, they need support for logistics andmanagement and users need to stay con-vinced that real progress is made.

Examples: ABC has have been usingSprints since January 2006 on a number ofend-user-projects and for the develop-ment of a framework for database, docu-ment management and workflow. TheBacklog is divided in Sprints that lastabout a month. At the end of each Sprint

a working Smalltalk image is deliveredwith integration of all current applications.The team meets daily in DailySCRUM

Meetings and Backlog is allocated after the De-

moAfterSprint in a monthly meeting with the steer-ing committee.

Figure 15 presents the actor role diagram of theProduct Owner and System Architect. It indicates

that Product Owners need to be coordinated by theSystem Architect at the product architecture level.

Figure 15: The Product Owner and System

Architect actor role diagram

Figure 16: The Sprint role activity diagram

Running a Sprint requires coordination be-tween the Product Owner and the SCRUM Master.Figure 16 presents a role activity diagram for therole of the SCRUM Master, Product Owner andSprint Team, in the context of a Sprint.



44

4.2 Defining SCRUM Patterns

When defining patterns, one needs to continu-ally keep in mind two aspects. These are 1) how wepropose to introduce and implement the pattern inthe organisation and 2) the importance and rele-vance of issues being presented. Without these clar-ifying these two points for each pattern, they will beof no use. The purpose of the process of definingpatterns is to produce a description of reusablecomponents. This process is mainly concerned by(1) identifying potential reusable knowledge and (2)constructing the reusable component embeddingthis knowledge.

4.2.1 Identifying Reusable Knowledge

This activity is essential to the process of defin-ing reusable components. There are two problemsto be considered, namely: identifying the sources ofknowledge that shall be used as the starting pointfor defining reusable knowledge and selecting thetechniques that shall be used for extracting thereusable knowledge. Two types of technique havebeen proposed so far. One is based on the study ofwide variety of existing products whereas the sec-ond is based domain oriented meta modelling ap-proaches. The latter focuses on the definition ofspecific concepts for describing domain knowledge.

4.2.2 Constructing Reusable Components

This activity mainly concerns the problems ofspecifying and organising reusable components. Thespecification of reusable components is based ontechniques that facilitate reuse such as, abstraction,genericity and inheritance. These techniques try tobalance the degree of reusability of the componentswith the effort that shall be made while effectivelyreusing the component. The organisation of thereusable components is driven towards the facilita-tion of the search and the retrieval of reusable com-ponents.

4.2.3 SCRUM Patterns Elicitation

The following four-step procedure is proposedto define patterns. By “define” we mean the discov-ery, selection and demarcation of the relevant pat-terns. The stages are:

1. Collect candidates

2. Evaluate suitability

3. Derive structure

4. Validation

To minimise redundancy, it is not necessary toprovide a full description of all patterns as providedfor in the pattern template, already at stage one.The degree of detail should be increased as onemoves through the stages. A scorecard for each can-didate pattern should be completed (see Table 2).

Part of Pattern Stage Formal signature Informal signature Responsible actor Other

1. Collect candidatesProblemSolutionContext

Project Management Initial EKD Model

2. Evaluate suitability Initial draft

NameForcesRationaleConsequences

Domain expertsThesaurus, initialguidelines

3. Derive structure,context andrelationships

VerbObjectSourceResultManner

Related patternsRelated documentsContributing authorsHyperlinksAnnotationVersion

Knowledge engineer

4. ValidationAll attributes fullyvalidated

All attributes fullyvalidated

Project Management,Domain experts

Complete guidelines

Table 2: Stages in defining patterns


For each stage, the various stakeholders needto play specific roles, see Table 3.

tential patterns may be compared in a systematicway according to commonly accepted criteria, so asto enable a satisfactorily informed decision.

A commonly recurring problem is the trade-offwhich is often made between, having "easily organ-ised knowledge" which is inherently incomplete soas to be structured as compared to knowledgewhich reflects reality, which is often not easily struc-tured or even understood. The choice is then, whereon a knowledge continuum you wish to place your-self. Our approach tends to be somewhere betweenhighly structured and unrealistic knowledge at oneend and unstructured but realistic knowledge, in thehalf of the continuum towards the unstructured. Inpractical terms this means that when defining pat-terns it is more important that these reflect realproblems and solutions rather than flashy and tech-nically brilliant presentations.

Knowledge, expressed by generic patterns,should facilitate the creativity process by reducingthe need to "reinvent the wheel" when facing newproblems and situations. The essence of the use ofpatterns is that they are applied to recurring prob-lems. A pattern is of no use if it aims to solve a prob-

Role Tasks

ProjectManagement

Overall responsibility:• Initiate definition procedure• Facilitate communication between analysts

and domain experts.

Knowledgeengineer

• Provide EKD and Pattern methodologicalsupport.

• Ensure structure and consistency withobjectives, and method.

Domainexperts

• Provide domain knowledge• Ensure validity.

Table 3: Roles, tasks and actors for the stages in

defining patterns

4.3 SCRUM Pattern Repository and Reuse

In order to make the SCRUM generic knowl-edge easy to organise and access for the benefit ofthe organization one needs to systematise andstructure the knowledge and experience gained indifferent parts of the company. The knowledge en-gineer's task is to provide a framework where po-

Figure 17: The SCRUM Pattern indexing organisation (adapted from ELEKTRA project)



46

Criteria Sub-criteria High Value Medium Value Low Value

Usefulness

Degree of triviality

The degree to which the patternaddresses a problem which is oflittle importance because theproblem or solution is obvious.

The pattern is concerned withissues that are or most likely willbe of concern to other parts ofthe company.

While the pattern deals with apertinent problem, the solution isalready well known.

The pattern is concerned with aproblem which does warrant thecreation of a pattern since it is sotrivial with the proposed solutionbeing obvious to domain experts.

Grade of implementability

Extent that pattern is thought tobe practical and implementable.Is change compatible withbusiness strategy. Have trade-offsbeen taken into account

The pattern is useful in that itprescribes practical, easy tounderstand and implementsolutions.

The pattern may be of some usedespite some practical problemsin implementation and somedifficulty in understanding thesolution.

The pattern is not usable. Thesolution is impractical anddifficult to understand. Thepattern only proposes "paper-based" change rather than realchange

Degree of confidentiality The pattern does not disclose anyconfidential businessinformation.

Some information may be able tobe used by other projects.

The pattern discloses sensitiveproject information.

Quality

Degree of complexity

The number of factors and thetheir relationships.

The pattern addresses only a fewmanageable main concepts andideas.

The pattern is complex but maystill be useful in that thecomplexity is needed.

The large number of factors thataffect the implementation of thesolution minimises the chancesthat the solution can beimplemented.

Addition of Value

The local and global benefitsaccruing to the business with theimplementation

The consequences of a successfulimplementation are great valueto the project directly affected aswell as other projects

The local and global benefits areunclear, difficult to determine ormarginal.

There are no local or globalbenefits or there is a conflictbetween these so that in total novalue is added

Level of genericity

Abstraction level of the problemthat the pattern addresses

The pattern addresses a problemthat is general enough for all thecompany.

The pattern addresses a problemthat applies only to part of thecompany.

The pattern addresses a problemthat is only relevant to theproject in which it wasdiscovered.

Grade of understandability

Visualisable and identifiableThe pattern is easy for decision-makers, domain experts andthose to be affected, tocomprehend.

The pattern is only partiallyunderstandable to decision-makers, domain experts andthose to be affected.

The pattern is incomprehensibleto stakeholders

External compatibility

The extent to which the patterncould be used by othercompanies

The pattern has taken intoaccount differences in national,and organisational cultures andways of working amongstidentified future external users ofthe pattern.

The pattern has partially takesinto account differences innational, and organisationalcultures and ways of workingamongst identified futureexternal users of the pattern.

The pattern does not take intoaccount differences in national,and organisational cultures andways of working amongstidentified future external users ofthe pattern.

Cost

Level of experience in their use The pattern has beenimplemented within thecompany.

The pattern has been partially orsporadically used.

The pattern has never beenimplemented.

Economic feasibility of the

proposed solutions

Proposed solution is relativelyeasy to implement.Organisational support exists interms of sufficient resources aswell as managerial support. Thesolution is politically and sociallyacceptable .

Proposed solution is difficult butfeasible to implement.Organisational support islukewarm. Resources areavailable but may not besufficient. There may existpolitical and social difficulties inmaking the pattern feasible.

Proposed solution is not feasible.Organisational support will bedifficult to obtain. The resourceswill not be made available. Theexisting difficult social and/orpolitical climate would make animplementation impossible.

Table 4: Pattern evaluation criteria


lem that is extremely unlikely to occur within theforeseeable future for those businesses that are en-visaged to have access to the patterns.

To enhance reuse, patterns need to be evalu-ated and assessed periodically. Table 4 presents aset of criteria that can be used to classify a patternon a High-Medium-Low scale. The criteria focus onusefulness, quality and cost. Obviously each organ-isation should develop it’s own criteria, in line withit's strategy and organizational culture.

Using patterns is an approach describing re-peatable solutions to recognisable problems. In thiscontext, both the problem and the solution must beuniquely identifiable and accessible. The patternusage framework must therefore make the distinc-tion between product or artifact patterns andprocess patterns, and includes an indexing schemafor accessing them. The patterns typology aims todistinguish between the way to solve a problem andthe elements that will be used for the solution,while the indexing hierarchy characterise each pat-tern by the problem that it addresses through theusage perspective and the knowledge perspective.The template in Table 1 represents the usage per-spective and the EKD modelling presents the knowl-edge perspective. In order to enable reuse andpattern retrieved a signature is required in either aformal or informal format. An example of how thisSCRUM patterns can be indexed and used in prac-tice by specific projects within the enterprise is il-lustrated in Figure 17 which has been adapted fromthe ELEKTRA project. An example of an electronicpatterns repository based on EKD is available inhttp://crinfo.univ-paris1.fr/EKD-CMMRoadMap/index.html.

5. SUMMARY AND CONCLUSIONS

Implementing agile development in generaland SCRUM in particular in a large organization is amajor challenge (Nerur, 2005; Tan & Teo, 2007). Ifthis approach is considered a strategic initiative bythe enterprise, one needs to formalize the approachby creating both a common language and a reuserepository of knowledge and experience. This paperpresents a framework for applying EKD, a generalBusiness Process Management description language

to map SCRUM patterns. By creating an organiza-tion-wide accessible SCRUM pattern repository, weare providing the infrastructure for company-wideimplementation of agile development. Such a repos-itory provides both storage and updating featuresthat are critical for expanding SCRUM implementa-tion beyond local islands of excellence. The gainsachieved by this approach include improved knowl-edge management and increased efficiencies andcompetency model clarifications. The practical im-plications of integrating EKD and SCRUM are re-flected by better communication between variousrole functions and increased accountability as a re-sult of better defined job descriptions.

The approach described in this work can alsobe applied to user groups and networks of smallsoftware developers who share an interest in betterand faster software development practices. Specifi-cally this can applied to communities developingopen source software and help mitigates risks insuch environments (Franch et al., 2013)

In summary, the challenge of introducing struc-tural changes in how organizations work is generi-cally complex. The improvement of software andsystem development units is particularly challengingbecause of the abstract characteristics of theprocesses that require skills, experience, innovationand creative capabilities. Attempts to regulate suchprocesses using standards like ISO 9000 are usuallyinefficient. On the other hand, addressing the prob-lems of software and system development with aparadigm shift, like agile development, has proveneffective (GAO, 2012). In order to deploy agile meth-ods, the paper proposes an integration of SCRUMactivities, Business Process Management (BPM) andEnterprise Knowledge Development (EKD) methods.This integrated approach is demonstrated with areal life case study. In particular, it is shown how tocombine the elicitation and management of organi-zational patterns, as a basic element of knowledgemanagement supporting this transformation.

Process improvement in system and softwaredevelopment processes is a critical element in thecompetitive position of local and global organiza-tions in this business area. Future research in thesedirections includes studies of how the experience ofABC Inc. can be replicated and adapted and how or-



48

ganizational behavior and management experts canmake further contributions to organizations strug-gling to meet such challenges.

Acknowledgement: The author wishes to ac-knowledge the constructive comments of two ref-ereed that helped improve the paper.

REFERENCES

Alexander, C. (1979). The Timeless Way of Building. NewYork: Oxford University Press.

April, A., Huffman Hayes, J., Abran, A., & Dumke, R.(2005). Software maintenance maturity model(smmm): the software maintenance process model.J. Softw. Maint. Evol., 17 (3): 197-223.

Bach, J. (October, 1995). The Challenge of "Good Enough"Software, American Programmer.

Berntsson-Svensson, R., & Aurum, A. (2006). Successfulsoftware project and products: An empirical investi-gation. Proceedings of ISESE ’06, ACM/IEEE interna-

tional symposium on International symposium on

empirical software engineering. New York, NY, USA:ACM Press: 144-153.

Cohn, M., & Ford, D. (2003). Introducing an Agile Processto an Organization. IEEE Computer Society,http://www.mountaingoatsoftware.com/system/article/file/10/IntroducingAnAgileProcess.pdf

Coplien, J. (1994). Borland Software Craftsmanship: ANew Look at Process, Quality and Productivity. Pro-

ceedings of the 5th Annual Borland International Con-

ference, Orlando, Florida. Franch, X. (2013). Managing Risk in Open Source Soft-

ware Adoption, ICSOFT2013, 8th International Joint

Conference on Software technologies, Reykjavik, Ice-

land, http://riscoss.sites.ow2.org/bin/download/Events/WebHome/ICSOFT-EA_2013_78_PROCS.pdf

GAO 12-681(2012). Effective Practices and Federal Chal-

lenges in Applying Agile Methods, http://www.gao.gov/products/GAO-12-681.

Kenett, R., & Baker, E. (1999). Software Process Quality:

Management and Control. New York: M. Dekker.Kenett, R., & Baker, E. (2010). Process Improvement and

CMMI for Systems and Software: Planning, Implemen-

tation, and Management, Taylor and Francis, Auer-bach Publications.

Nerur, S. & Mahapatra, R. (2005). Challenges of Migratingto Agile Methodologies. Communications of the ACM

48 (5): 72-78.Rolland, C., Nurcan, S., & Grosz, G. (1998). A unified

framework for modelling co-operative design proces -ses and co-operative business processes, in the Pro-

ceedings of the 31st Annual International Conference

on System Sciences, Big Island, Hawaii, USA.Rolland, C., Nurcan, S., & Grosz, G. (1999). Enterprise

Knowledge Development: the process view. Infor -

mation and Management Journal, Elsevier 36 (3):

165-184.Rumbaugh, J. (1995). What Is a Method. Journal of Object

Oriented Programming.

Schwaber, K., & Beedle, M. (2001). Agile Software Devel-

opment with Scrum, Prentice Hall.Stare, A. (2013). Agile project management – a future ap-

proach to the management of projects?. Dynamic Re-

lationship Management Journal, 1 (2): 43-53. Takeuchi, H., & Nonaka, I. (1986). The New Product De-

velopment Game. Harvard Business Review, 69 (6):96-104.

Takeuchi, H., & Nonaka, I. (1995). The Knowledge Creat-

ing Company: How Japanese Companies Create the

Dynamics of Innovation, Oxford University Press.Tan, C. H., & Teo, H. H. (2007). Training Future Software

Developers to Acquire Agile Development Skills. Com-

munications of the ACM 50 (12): 97-98.

Documents

SAM, Slovenska akademija za management ...sam-d.si/wp-content/uploads/2018/04/DRMJv02n02a03.pdfand services solutions to services providers world - wide. The company oﬀers customer