Risks, Challenges and Issues in a Possible Scrum

Download PDF
3 downloads 0 Views 227KB Size Report
Comment
has dominated software development almost since its inception and has a co-occurrence ... processes and tools, working software over comprehensive ... Scrum teams deliver products via iterative and incremental ..... increased complexity) can arise in Scrum. ... project manager roles which have no place in Scrum model.
Risks, Challenges and Issues in a Possible Scrum and COBIT Marriage Necmettin Ozkan IT Governance Division Turkiye Finans Participation Bank Istanbul, Turkey [email protected] Abstract—Today’s turbulent business environment is compelling software development providers to face several challenges. As a response to this case, adoption of Scrum methods is increasing. COBIT, on the other side, has domination in information technology (IT) and is a de-facto standard providing an IT governance model with international set of generally accepted IT control objectives. Considered the coverage of SCRUM and COBIT (version 4.1 in this case), a coexistence of them in a same organization has a possibility of emergence for organizations that want to use SRCUM in their COBIT environments. While a rationalized, engineering-based approach has dominated software development almost since its inception and has a co-occurrence and similarities with COBIT, melting COBIT and Scrum in an organization is very new and can be an intriguing subject. This study holds the aim of shedding light on organizations by focusing on the identification of risks, challenges and issues of Scrum implementation within a COBIT environment. This study works as a risk map for organizations that have opportunity to tailor COBIT. It also exhibits a list of challenges for organizations that must fully comply with COBIT framework. Keywords— Agile; Scrum; COBIT; software development

CHALLENGE OF COEXISTENCE Today’s turbulent business environment is compelling software development providers to face several challenges. Adapting to rapid and unpredictable changes in appropriate ways has caused a movement towards reengineering current software development methods [10], [11]. As a response to this case, adoption of agile systems development is increasing [33]. Agility principles value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan [1]. As the most prominent and used agile method, Scrum is the subject of this study [18], [22], [23]. On the other side, COBIT (Control Objectives for Information and Related Technology) has domination in information technology with its more than 40 integrated standards worldwide and is itself a de-facto standard providing information technology (IT) governance model with international set of generally accepted IT control objectives to help in delivering value from IT and understanding and managing the risks associated with IT [2]. Many countries listed in [4] including USA, Canada, Australia, India, Japan,

Philippines, UAE-Dubai, Brazil, Colombia, Costa Rica, Guatemala, Mexico, Paraguay, Uruguay, Venezuela, Botswana, Greece, Israel, Lithuania, Mauritius, Nigeria, Poland, Romania, South Africa, Turkey, Zambia facilitate COBIT for their public sector, governmental agencies and regulatory bodies. Considered the coverage of SCRUM and COBIT, a coexistence of them in a same organization has a possibility of emergence for organizations that want to use SRCUM in their COBIT environments. While a rationalized, engineering-based approach has dominated software development almost since its inception [28] and has a co-occurrence and similarities with COBIT, melting COBIT and Scrum in an organization is very new. And, it can be an intriguing subject when considered the following points: • While COBIT is process-centric and designed to standardize people to the processes, SCRUM relies on people and their creativity rather than processes, thus, people trump process in agile methodologies [27]. • Instead of over-optimized processes targeting ‘bestpractices’ in COBIT, ‘just enough’ principle is enacted in Agile, to reduce any unnecessary effort towards over-optimization [10]. • Conformance to plan is important in COBIT processes, supporting the belief that sources of variations are identifiable and may be eliminated, but SCRUM asserts that demanding certainty in the face of uncertainty is dysfunctional [27], and uncertainty is a part and parcel of software development [9]. Therefore, Scrum concentrates on responding to change rather than on creating a plan and then blindly following it [1]. • COBIT regards documentation as a means of storing, sharing, conveying, replicating and backing-up knowledge, planning, codifying and standardizing for practice, and creating logs for further use. Agile methods discourage heavy documentation and prefer to invest time in producing working software rather than in producing comprehensive documentation [6], [28]. • Planning and control accomplished by a command and control style of management are practices of COBIT, but, agile teams are characterized by self-organization and intense collaboration, within and across

organizational boundaries [27]. Scrum encourages teams with the resources they need and then trust them to do their jobs well [6]. • Instead of managing risks with high assurance in COBIT, agile development confronts risks to tackle them empirically [10]. At this point, if COBIT is regarded as a best practice and baseline, this study produces the gap and risk analysis of Scum. If Scrum is regarded as a good practice, this work shows how much COBIT is suitable to support being agile. The first option was selected in this study, deeming COBIT as a baseline, and exposing the major gaps of Scrum from the baseline. Thus, this study holds the aim of shedding light on organizations which may face this COBIT and Scrum coexistence. The focus is on the identification of risks, challenges and issues of Scrum implementation within a COBIT driven environment. This study works as a risk map for organizations that have opportunity to tailor COBIT. It also exhibits a list of challenges for organizations that must fully comply with COBIT framework, as in the example of organizations from banking sector in Turkey. From another point of view, the study addresses the point stated by COBIT control practice AI2.7.8 that recommends to “consider the effect of dynamic, non-sequential development techniques (e.g., rapid application development, extreme programming) on the monitoring of the application development progress and approval of application software by stakeholders.” In the next section Scrum is introduced. Then, the research methodology and the results are delivered. It is assumed that the reader is already familiar with the COBIT structure and content; hence a dedicated title for COBIT introduction was not devoted. I. WHAT AND HOW OF SCRUM Scrum teams deliver products via iterative and incremental model [17] allowing early and continuous delivery of valuable software. Incremental design means organic growth of the system being developed [20]. In iterative models, rather than visiting each step only once, all steps are iterated through until the system is deemed complete [20]. Projects are divided into brief and snappy work cadences, typically fixed in duration from one week to four weeks, known as sprints. A sprint typically involves planning, development, integration, testing, and delivery [28]. Developers and customers (or their surrogates) are actively involved in the development process and dynamically prioritize features in the sprint planning meeting (the beginning of each iteration). Each sprint ends with a working system as a deliverable at the end [17]. During the sprint, intense 15 to 30 minute daily meetings allow participants constantly adjust to the realities of high-change projects [27]. Stakeholders including developers and end users go through repeated cycles of thought-action-reflection at the end of each iteration that foster an environment of learning and adaptation [28]. These sprint review meetings provide an opportunity facilitating feedback and reflection on what worked and what did not [32]. Sprint retrospective occurs after the sprint review and prior to the next sprint planning to

inspect the development team itself and create a plan for improvements to be enacted during the next sprints. A scrum team consists of a product owner, a development team, and a scrum master [17]. Scrum master is an enabler for the team [20]. He/she is responsible for the meetings and for resolving impediments encountered during the sprints in order to assure smooth running of the development process [25]. Product owner serves as the mediator between the customer and the development team and is responsible to maximize the value of the product by managing the product backlog [20] [17]. The development team consists of professionals who do the work of delivering a potentially releasable increment of “done” product at the end of each sprint [17]. Scrum encapsulates the development effort in the development team with self-organizing and cross-functional principles [10]. Selforganizing teams, with no hierarchical constraints, choose how best to accomplish their work, rather than being directed by others outside the team [24] [10]. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team [17]. Scrum recognizes no titles for development team members other than developer, no sub-teams in the development team and gives accountability to the development team as a whole, regardless of particular domains [17]. II. RESEARCH METHODOLOGY For the Scrum side, the pure Scrum is used meaning that the study is free of extended and costumed version of Scrum models or implementation issues of any kind of Scrum. For that, related Scrum resources of Scrum creators and ones based on them were chosen. Plus to this, findings regarding the agile principles were considered same as for Scrum in account of the fact that Agile holistically and inherently affects Scrum in a way. For the COBIT side, while the newest derivative is COBIT 5, COBIT 4.1 was selected to guide the organizations that use and practice this version. Among the COBIT products, COBIT framework 4.1 [2] and COBIT Control Practices [3], that sustains each related control objectives with detailed control practices, were chosen in line with the context of this study. Related processes in COBIT were selected according to their direct and intense relevance with points that Scrum touches. It was then checked with other works’ results studying Scrum and COBIT together for any purpose. For the notations used in this study, corresponding control objectives are remarked as in the example of “AI2.1” and control practices as in the example of “AI2.1.3” and related ones are expressed between parentheses in appropriate places in the text . COBIT intentionally repeats some control objectives to ensure appropriate coverage of IT controls [2]. Nevertheless, this study was kept away from such repeats, preferably mentions the related control objectives and practices only in the proper places. III. RELATED WORKS In order to reach a set of related works, a search with the keyword of “scrum cobit” was conducted throughout of libraries of Google Scholar, IEEE Xplore, DBLP, arXiv,

Microsoft Academic Search, Springer, ACM, and ScienceDirect in the date of 05/29/2015. Among 245 total results returned in English, three of them are related to this study. In the study [25], and similarly in [34], the authors use only the indicators of COBIT for measuring Scrum-based software development. The study [26] maps SOX (Sarbanes Oxley) regularity requirements with Scrum practices. Similar to COBIT, SOX is a regulation for all public listed companies in the United States and provides controls over financial data and its access. ISACA first released COBIT in 1996, and Jeff Sutherland and Ken Schwaber conceived the Scrum framework in the early 90’s. As far as the researcher knows, it is the first meet of Scrum and COBIT now in a study in this context. IV. COEXISTENCE OF SCRUM WITH COBIT It is a fact that Scrum more or less touches all COBIT processes that are 34 in number, with 210 control objectives and 990 control practices. As COBIT presents a huge area to work with, it is a must to focus on the processes that Scrum affects directly. The following provides the selected COBIT processes and the reasons to select. Raison d’être of Scrum, first and foremost, is to manage and direct all IT resources in line with the business strategy and priorities, to provide optimal value from project and service portfolios. The same concern is explicitly conveyed in COBIT process PO1 (Define a Strategic IT Plan). A change to agile methodologies also entails major alterations to several aspects of an organization including its structure, processes, communication channels, roles of people, management style and culture [5],[28]. That is the subject of COBIT process PO4 (Define the IT Processes, Organization and Relationships). The focus in Scrum shifts from process to people which is the subject covered in COBIT process PO7 (Manage IT Human Resources). Definitely, Scrum brings fundamental changes to project cycle and development model of SDLC [28]. These are the subjects of COBIT process PO10 (Manage Projects) and some AI (Acquire and Implement) processes. From the list of AI processes, AI1 (Identify Automated Solutions), AI2 (Acquire and Maintain Application Software), AI4 (Enable Operation and Use) and AI7 (Install and Accredit Solutions and Changes) were selected and collected under the same title in this study as they are correlated. Contents related to process AI5 (Procure IT Resources) were mentioned in other corresponding processes and this process was excluded from the list, same as AI6 (Manage Changes). Acquisition, implementation and upgrade of the technology infrastructure are out of the scope in this study as Scrum does not have a direct effect on these matters. It is also assumed that Scrum does not have a direct relation to any of Deliver and Support (DS) or Monitor and Evaluate (ME) processes. Thus, the list of processes studied in this work consists of: • PO1 (Define a Strategic IT Plan) • PO4 (Define the IT Processes, Organization and Relationships)

• PO7 (Manage IT Human Resources) • PO10 (Manage Projects) • AI1 (Identify Automated Solutions) • AI2 (Acquire and Maintain Application Software) • AI4 (Enable Operation and Use) • AI7 (Install and Accredit Solutions and Changes) In order to cross-check the list with other studies’ results, the results from the related works were considered. It was recognized that two of the studies explicitly lists the COBIT processes in their works. Among these two, study [25] considers and contains the processes in [26], the other one, and provides a suitable basis for comparison. The differences between study [25] and this study in terms of the process coverage are the followings: • PO8 (Manage Quality) governs all COBIT processes in terms of quality ingredients. Corresponding contents derived from this process were addressed in other appropriate COBIT processes in this study. • AI6 (Manage Changes) relevant matters related to Scrum development model were also concerned in other corresponding processes and this process was excluded from the list. • DS5 (Ensure Systems Security) was excluded because it is included in [25] based on ISACA IS Auditing Guideline for System Development Life Cycle (SDLC) Reviews [14]. The audit focus, one way or another, should cover systems security regardless of the development model. Thus, it is believed that this COBIT process has not enough priority to be included in this study as it has a weak relevance with Scrum. • DS10 (Manage Problems) mostly designates the procedural approach including identification and classification of problems, root cause analysis and resolution of problems. PO1, and IA processes give enough place to maintenance activities if the occasion arises. • PO1 (Define a Strategic IT Plan) and PO4 (Define the IT Processes, Organization and Relationships) were added to the content of this study for the reasons mentioned before. A. PO1 Define a Strategic IT Plan In this process, there are two relevant and important topics to discuss addressed in PO1.1 (IT Value Management) and in PO1.2 (Business-IT Alignment). PO1.1 put forwards that it is required to “establish fair, transparent, repeatable and comparable evaluation of business cases.” It stresses the importance and criticality of a steady, consistent and fair evaluation method that maximizes business value and serves for a common understanding of business valuation of both project requests and requests in projects. Defining business value of a project cannot always create tangible results, may include subjectivity issues, and

dependence on the observer perception, leading to win-lose satiations at the end [10]. The issue in the project selection phase becomes deeper especially when the full project scope is not defined in advance of project initiation. Even with an intensive customer involvement, with these challenges mentioned, finding consensus on prioritizing projects based on their clear values, in the abundance of the uncertainty may propel organizations to some hardships. When it comes to the business-IT alignment and integration, PO1.2 states that reciprocal involvement in strategic planning should be established. Scrum paves the way of customers to align IT to the business by providing more involvement in processes and a closer position to IT. To be integrated, differently, reciprocal and bi-directional channel from IT to the business and the business to IT is needed. IT in Agile is prone to be utility/commodity provider for the business [10]. To make contributions for the integration in Scrum, a platform is needed in decision making and governance processes to give idea and feedback from IT specialists to the business. B. PO4 Define the IT Processes, Organization and Relationships This process draws the border line between Scrum teams and senior executives. It points out a strategy committee to ensure board oversight of IT, and one or more steering committees in which business and IT participate to determine the prioritization of IT resources in line with business needs [2]. Albeit Scrum teams have a freedom inside the team, they one way or another still have an interaction with the remaining parts of organizations which have authorities over the same subject which is maximizing the value. Scrum should gain recognition throughout the organization, and be applied appropriately. Otherwise, conserving and protecting the natural structure and mechanism of the teams becomes a challenge. While the Scrum teams have a voice and right to say on projects to maximize the value during the development, at the top, the major effects of boards in selecting projects may easily overwhelm their relatively minor effects. Thus, Scrum should put forward who constitutes such boards, who directs them how and their relationships with the Scrum organization and processes. The fair position of PO and fair operations of processes under his/her reasonability, in this manner, plays very critical role as well. PO4.4.2 (Organizational Placement of the IT Function) emphasizes the similar concern by saying “define and fund the IT function in such a way that individual user group departments cannot exert undue influence over the IT function and undermine the priorities agreed upon by the IT steering committee”. PO4.4.3 entails to ensure that the IT function is appropriately resourced to support the business. The workload and resource capacity management among and inside the Scrum teams has not been detailed out in terms of who is responsible for deciding on the staff capacity of the teams, in order to response adequately to business needs. Inside the teams, the team pulls a static set of items of projects for a sprint with their initiatives. However, for the volume regarding to software maintenance activities (AI2.10.1), the product

backlog list can be very dynamic in a way not allowing a proper workload management during the sprint. PO.4.5.2 extends this resource management approach with “flexible resource arrangements to support changing business needs, such as the use of external contractors and flexible third-party”. The question comes in when to work with external contractors and third-parties that do not have Scrum capabilities. The issue becomes stronger with the consideration that customers in organizations regard IT as monolithic unit and expect consistent methodologies across in-house and third-party teams. AI2.7.5 concerns the same point by stating that “when third-party developers are involved with the applications development, establish that they adhere to contractual obligations and organizational development standards…” Scrum recognizes no titles for development team members other than developer [17]. Therefore, there is no specific tester, business analyst or coder roles; instead Scrum gives accountability to the development team as a whole [17]. The roles of the team members are interchangeable, and developers can choose roles that are not in their area of specialty [35]. This level of role description means that the roles for analyst, tester, coder, and so on disappears for inside and outside of the teams. This approach of Scrum allows a person to make functional tests for the functions he/she codes. From the window of COBIT, this restricts the controls to preclude full segregation of duties as mentioned in PO4.11. Similarly, AI7.6.1 clearly states that “”ensure that the testing is designed and conducted by a test group independent from the development team.” Decision-making in Scrum is entirely at the hands of the teams [6]. It brings the advantages of flexibility and human initiative, yet opens gates to the diversity and unpredictability of people which at the end may inhibit to achieve a level of consistency and quality with repeatable processes perceived to contribute to the maturity of an organization [6], [21]. As another criterion of maturity, documentation is one of important items for COBIT. COBIT regards documentation as a means of storing, sharing, conveying, replicating and backing-up knowledge, planning, codifying, and standardizing of practice, and creating logs for further use. Scrum software development methods, on the other hand, suggest “just enough” documentation on projects. However, for practitioners of these methods, it still remains unclear how much “just enough” documentation is [8]. The aspects of documentation and process approach are just two examples. Eventually, Scrum should develop its own process maturity model to guide organizations and PO4.1 (IT Process Framework) already calls for a process maturity model in place. C. PO7 Manage IT Human Resources Scrum development focuses on the talents and skills of individuals, molding the process to specific people and teams, and people trump process in Scrum [27]. Adversely, the focus migrates from people centric management to product centric management by Scrum methods. The structure of Scrum shapes around the product concept. Line managers, who have primary responsibilities over people, disappear. However, still someone should watch over people who are prone to be forgotten somewhere in the product lines, aggressively

designed for continuous and unremitting delivery. Furthermore, findings by [31] and [30] stress the importance of competency management and assert that there is little evidence to suggest that agile principles will work in the absence of competent and above-average people. Accountabilities and responsibilities of functions of teams related to personnel recruitment, retention (PO.7.1), termination (PO.7.8), competencies management (PO7.2), adhering to codes of ethics (PO7.3), performance evaluation (PO7.7) and administrative operations directed and managed by line managers in the traditional methods should be addressed in Scrum as well. Furthermore, for the teams that are expected to trust each other, the concept of codes of ethics plays a critical role for the success of agile methodologies and deserves a special attention, especially considered that politics (as one of the twelve most common factors for project failure [15]) may trump people [27]. And, organizations should be aware of that it may take enormous effort, time, and patience to build a culture of trust and respect among the employees [28]. For the continuity of organization’s functions, dependence upon key individuals should be minimized through knowledge capture (documentation), knowledge sharing and staff backup (PO.7.5). As an advantage, rotation of development team members ensures that knowledge is not monopolized by a few roles [28]. On the other hand, documentation as useful artifacts for the backup of information is discouraged in Scrum [1]. Thus, much of the knowledge in agile development resides in the heads of the development team members [28]. This may make the organization heavily dependent on some development team members who accrete knowledge in their sides. Therefore, the team still requires defining and identifying key IT personnel and minimizing reliance on a single individual performing a critical job function (PO4.13). Plus to the development team, in Scrum team PO is a critical person because of three reasons: (1) He/she performs a critical job function like maximizing the value (PO4.13). (2) He/she has accountability to manage relationships between IT and key stakeholders effectively (PO4.15.2). (3) He/she must be a sole person according to the Scrum framework. For such a critical individual, as pointed out in (PO4.13.4), Scrum should additionally assure this critical person’s appropriate availability during time-off periods, vacations and leaves of absence (PO7.5). Scrum development relies on teamwork, as opposed to individual role assignment. Performance measurement (PO7.7) and reward systems, therefore, must be suitably designed [28] team based, where collective goals supersede individual accomplishments [32]. Plus to this, Scrum metrics are in general designed from product point of view, and a special attention should be paid in using them for the personal performance assessment. Otherwise, it may damage the teams’ transparency for the sake of personal favors. In general, it is a challenge for Scrum to adapt its unique human resource management practices compatible with the organization’s human resources process and policies. Specifically speaking, career path development, mentioned in PO7.2.4, as an opportunity for personal advancement and promotion, is a field to study for Scrum which provides a flat

structure of organization rather than a hierarchy including steps to managerial positions. Put organization wide perspective aside, for sectors that regard people management experience valuable, Scrum does not provide this opportunity via its practices in this flatness. D. PO10 Manage Projects COBIT’s general approach for project management as “plan and control” is altered in Scrum to collaborative efforts of those involved in development, thus ensuring that the creative ideas of all participants are reflected in decisions [29]. Scrum encourages supplying developers with the resources they need and then trusts them to do their jobs well [6]. There are some models in practice in order to support project management framework with details of practices. Scrum excludes these models; however it does not dispel the presence of the need. Therefore, one of the other huge study areas for Scrum adopters is to fulfill the blankness in “how” side of project management (PO10.2). According to [7], Scrum starts with the premise that software development is too complex and unpredictable to be planned exactly in advance. The nature of this assumption, in some degree, precludes assessing whether the project is on schedule, within budget and aligned with the agreed-upon scope (PO10.6.3) and reviewing and approving cost, schedule, scope and quality changes in the project baseline (PO10.11) by key stakeholders and project sponsors (PO10.5.2). Moreover, customers may be uncomfortable with the flexible budgets and schedules and may prefer an up-front contractual obligation to deadlines, and costs [32] that allows making and following their usual plans. After all, if the customers need and want to know estimates of what timescale and at what cost the product will be delivered, it burdens to significant regular ongoing planning and reporting process in the Scrum project management. PO10.7 entails an integrated project plan including resources required, time requirements for all individuals involved in the project, clear work breakdown structures, and identification of a critical path. Other involved parties, such as finance, legal, procurement, human resources, internal audit, compliance departments and other IT specialists should also be considered in this plan (PO10.8.3). For such an integrated project plan, steps in forming and acquiring a project team with its competent staff members (PO10.8), in such a dynamic and adaptive environment, should be work on, with a consideration of that resource conflicts are possible especially when keeping the same core team members during a Scrum project [36]. PO10.3 calls for a project management approach commensurate with the size, complexity and regulatory requirements of each project. However, scaling issues (continually identifying and removing dependencies created by increased complexity) can arise in Scrum. In the case of occurrence of corporate or organization size distributed area, subcontracting, developing large and complex systems, there are some limitations with respect to the nature of Scrum [24]. The study [13] has also shown that organization of large development efforts, variability factors in scaling, inter-team coordination, key performance indicators in large development

efforts, scaling agile practices and agile contracts are still the hot topics of the area. Control objective PO10.3 also anticipates a project governance structure including project office and project manager roles which have no place in Scrum model. For organizations that must comply with this item it is a clear challenge. When it comes to project risk management the team must eliminate or minimize specific risks associated with individual projects through a systematic process of planning, identifying, analyzing, responding to, monitoring and controlling the areas or events (PO10.9). According to [7], assessment, classification and prioritization of risks occur in a casual way in Scrum without detailed practices for defining sources, parameters to analyze, risk management effort and policies for critical risks. E. AI1 Identify Automated Solutions, AI2 Acquire and Maintain Application Software, AI4 Enable Operation and Use and AI7 Install and Accredit Solutions and Changes The diversity and unpredictability of people who engage in software development process exhibits some challenges in terms of requirement management [28]. The unpredictability is further compounded by the complexity of software development activities [27]. As a result, requirements present some degree of variability on the course of a project. The reasons behind this may be listed as the following: • The nature of software development is so complex that allowing upfront requirement gathering is not feasible. • Things change on the way because of highly volatile business environments. • Human use distortion, deletion and generalization to express their thoughts and such cognitive issues may cripple requirements’ elicitation process [12]. • Incapacity of people involved in the corresponding processes may cause things change when things get closer. Scrum brings proposals to the first and second items. The last two still stay there as bigger issues to deal within Scrum models. Using an agile approach entails formidable responsibility on the client’s part [32]. Customers actively shape and guide the evolution of the software product [9] by identifying and prioritizing features, providing feedbacks, and guiding change through the course of the development [32]. Empowering incapable customers with more initiatives on software development, and regarding customer’s change requests born of distortions, deletion and generalization as absolute, innocent and harmless demands may danger the quality, cost and time scale of projects. Therefore, the success of agile development relies on finding customers who are expected to be collaborative, representative, authorized, committed, and knowledgeable (CRACK) [30]. And, it is not an easy task to find such persons, especially for complex systems [28]. This highly dependence on customers may also cause failures if the customers are misaligned with the stakeholders’ goals [32]. For the same concern, control practices AI1.4.2, AI2.1.6 and AI1.4.1 explicitly call for business sponsor’s approval for the proposed solution approach

and high-level design specification and involvement of business sponsors and other stakeholders in quality reviews of project increments. It is also the case for product owners who are the customer representative and expected to identify and prioritize the stakeholders’ most success-critical expectations and potential sources of business value [10]. Realizing what Scrum promises to bring for organizations rests heavily on capable and successful PO’s. Thus, great Scrum needs great product owners as well [19]. The requirement elicitation process in any software development may hide some difficulties like in identifying and analyzing second and sometimes third level effects, outflanking their cognitive barriers [10], and anticipating how the requirements will evolve on the course of the project [16]. Scrum presents a risk of losing creativity somewhere among small pieces of repeatable works without a big picture of the system being designed. It makes hard for business and IT to identify and analyze dependencies, constraints, assumptions, issues and second and sometimes third level effects across the requirement (AI1.4.1) and software maintenance (AI2.10.1) developments. Additionally, customers, in general, are prone to neglect or not to see non-functional requirements of systems like performance and system security requirements (AI1.1.3 in relevant). Clarity, completeness and comprehensiveness of requirements play an important and critical role in designing architecture that meets specifications derived from requirements. Instead of trying to understand users’ needs with upfront requirements gathering, requirements in Scrum are emergent discovered during the project. Architecture in Scrum designed for current requirements may exhibit some degree of issues because not all requirements are gathered [6] during early stage of the projects. Without an upfront requirements gathering, lacks of completeness and comprehensiveness of requirements with the second and third level effects is a source of issues in designing architecture of software (AI2.1) and creating key alternative courses of actions of solutions in the feasibility study (AI1.3.1). Thus, eventually development of software may end up exponentially rising costs as time passes in the development life cycle, making the cost of empirical process model of Scrum high. For the clarity and traceability of requirements, Scrum adopters should define their requirements definition procedure (AI1.1.1) and address epic, feature, and story’s equivalents in software requirement engineering terminology. According to AI2.2.10, detailed design specifications must be in accordance with organizational and industry-accepted specification standards. Scrum provides insufficient guidance with respect to the structure of the backlog [24] and someone should study how a requirement is elaborated from the customer’s definition of need, through design documents, to code parts of working product using the Scrum documents. In Scrum, the product owner provides the first point of interaction with the customers as a person that serves as the mediator between the customers and the team [20]. And, Scrum assumes PO’s do not necessarily need business analyst or system analyst responsibilities when selecting most

appropriate requirements with the customers. The powerful front end of IT with adequate business analyst or system analyst capabilities, therefore, is not at the first touch point to the customers at all. It must be the duty of the development teams, and a special care should be paid in isolating potential business/system analyst attitudes of PO’s in doing his/her works. Iterative and incremental development also means iterative and most probably incremental development of the software development documents including requirement specifications (AI2.9), high level design (AI2.1), detailed design (AI2.2) and test plans. It requires also formal approvals of these iteratively and incrementally developed documents by related business process owners and IT stakeholders as well (AI2.9.3), (AI2.1.5), (AI2.2.11), (AI7.2.8). Continuous integration means newly constructed part of the system is integrated with the current system as often as possible [20]. Each additional build has to incorporate into the existing structure without degrading the quality [6]. For multiteam projects, each team checks in their newly constructed part of the system within the entire system and all tests probably including performance, stress, usability, security, system, integration, user acceptance, operational readiness, backup and recovery tests (AI7.2.5) must pass for the changes to be accepted. Without a right balance between automated scripted tests and interactive user testing (AI7.6.3), this iterative, incremental and continuous testing can be hard, time consuming and risky. All tests may not be performed properly all the times, as it requires a lot of time of a sprint for testing and quality assurance [24]. Organic growth of the system also means the creation and integration of complete, accurate and usable supporting documents (AI4.2) with promptly updates to the existing environment in production for the use of end users (AI4.3), operations and support staff (AI4.4), and business management (AI4.2). If required, adequate trainings must be provided to the related people including business end users, IT operators, support and IT application development teams, and service providers (AI7.1.2) to learn how to use the new and continuously changing system. In the promotion to the production, sprint deployment can be one of the major concerns for teams [24]. Establishment of secure and sanitized test environments as a representative of the future operating landscape (AI7.4) with the deployment frequency that Scrum anticipates can be challenging with cumbersome and non-agile infrastructures. V.

CONCLUSION AND FUTURE WORK

No one model is necessarily better or worse than another [6]. Every model has its own risks, challenges and issues in its nature. This study is not an assessment of Scrum as good or bad. Rather, the endeavor is to highlight the risks, challenges and issues of Scrum implementation within a COBIT environment as listed in the table below. As mentioned before, this study is free from any extensions and customizations of Scrum.

TABLE I.

LIST OF RISKS, CHALLENGES AND ISSUES

Process

Subject

Category

PO1

IT value management

Challenge

PO1

Business-IT alignment

Risk

PO4

Scrum teams' interaction with other parts of organizations Workload and resource capacity management

Risk

PO4 PO4

Challenge

PO4

External contractors and third-parties without Scrum capabilities Segregation of duties

Challenge Challenge

PO4

Process maturity model

Challenge

PO7

Building the culture

Challenge

PO7

People management activities

Challenge

PO7

Performance measurement

Challenge

PO7

Career path development

Issue

PO10

“How” side of project management

Challenge

PO10

Project time, scope and budget management

Challenge

PO10

Project resource competency management

Challenge

PO10

Integrated project plan

Challenge

PO10

Project scaling

Challenge

PO10

Restructuring project management office

Issue

PO10

Project risk management

Challenge

AI's

Finding CRACK customers

Challenge

AI's

Dependency on great product owners

Challenge

AI's

Identifying requirements effects

Challenge

AI's

Losing the big picture in design

Risk

AI's

Requirements elaboration and traceability

Challenge

AI's

Risk

AI's

Managing the first point of interaction with the customers Iterative and incremental development of software development documents, and their formal approvals Incremental and continuous testing

Challenge

AI's

Proving support documents of products

Challenge

AI's

Establishing agile IT infrastructures

Challenge

AI's

Challenge

The study hopefully provides a risk map to manage and a list of challenges and issues to tackle. In doing so, it is actually possible to tailor Scrum with customizations and extensions. On the other side, the question of how much COBIT (v.4.1) is suitable to support being agile may rise and if possible organizations may choose the option of tailoring COBIT in a more agile way. One way or another, the study reminds that while the opportunities and benefits of Scrum make it attractive, organizations should be circumspect in integrating it with COBIT practices. Although agility is necessary for organizational adaptation, organizations should remember that stability is necessary for organizational optimization, which results in higher assurances for delivering the value. Thus, systems development organizations need to strike a balance between the two conflicting interests: agility and stability [32].

For researchers, there are several avenues of the future work to reach a more comprehensive level of this study as below: • Developing extensions to Scrum framework to find possible solutions from the theory for the items which are addressed in this work, • Investigating issues in practice faced by organizations that adopt Scrum within COBIT environments (it also serves as a kind of justification of this study with practical examples) • Investigating issues in practice faced by organizations that adopt Scrum and matching the issues with COBIT practices (it also serves as a kind of justification of COBIT with practical examples) • Finding practical solutions for the issues coming from Scrum practices in COBIT environments and assessing their effectiveness, • Developing a COBIT maturity assessment of Scrum processes, • Doing the similar work of this study with the version 5 of COBIT.

References [1] [2] [3]

[4] [5] [6]

[7]

[8]

[9]

[10]

[11] [12] [13]

K. Beck et al., "Agile manifesto" http://agilemanifesto.org/, 2001. ISACA, "Cobit 4.1", Rolling Meadows, ISACA, 2007. ISACA, “COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT Governance, 2nd edn.”, Rolling Meadows, ISACA, 2007. ISACA ,”COBIT Global Regulatory and Legislative Recognition”, Rolling Meadows, ISACA, 2014. K. Schwaber, Agile Project Management with Scrum. Redmond: Microsoft Press, 2004. A. I. Khan, M. R. J. Qureshi, and U. A. Khan, “A Comprehensive Study of Commonly Practiced Heavy & Light Weight Software Methodologies,” International Journal of Computer Science and Issues, vol. 8, no. 4, pp. 441-450, June 2011 S. P. Ravi, B. Reddaiah, L. S. Movva, and R. Kilaparthi, "A Critical review and empirical study on success of risk management activity with respect to scrum," ESTIJ, vol. 2, no. 3, pp. 467-473, June 2012. R. Hoda, J. Noble and S. Marshall, ‘Documentation strategies on agile software development projects’ Int. J. Agile and Extreme Software Development, vol. 1, no. 1, 2012. T. Dingsøyr, S. Nerur, V. Balijepally, and N.B. Moe, "A decade of agile methodologies: Towards explaining agile software development", Journal of Systems and Software, vol. 85, no, 6, pp. 1213-1221, 2012. O. Ktata and G. Lévesque, 'Agile development: issues and avenues requiring a substantial enhancement of the business perspective in large projects', in 2nd Canadian Conference on Computer Science and Software Engineering, Montreal, Quebec, Canada, 2009. B.W. Boehm, "Making a Difference in the Software Century", Computer, IEEE Computer Society, March 2008, pp. 32-38. R. Bandler, Get the life you want. Deerfield Beach, Fla.: Health Communications, 2008. T. Dingsøyr and N. B. Moe, '"Towards Principles of Large-Scale Agile Development: A Summary of the workshop at XP2014 and a revised

[14]

[15] [16]

[17]

[18]

[19]

[20] [21] [22]

[23] [24]

[25]

[26] [27] [28] [29] [30] [31] [32]

[33] [34]

[35] [36]

research agenda', in Agile Methods: Large-Scale Development, Refactoring, Testing, and Estimation, vol. 199, T. Dingsøyr, N. B. Moe, R. Tonelli, S. Counsell, C. Gencel and K. Petersen, Ed. Springer Verlag, 2014. ISACA, “IS Standards, Guidelines and Procedures for Auditing and Control Professionals, Information Systems Audit and Control Association”, Rolling Meadows, ISACA, 2008. R. Charette, “Why software fails?” IEEE spectrum, vol: 42, 2005 P. J. Denning , C. Gunderson, and R. Hayes-Roth, ‘The profession of IT Evolutionary system development’, Communications of the ACM, v.51 n.12, December 2008 K. Schwaber and J. Sutherland, "The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game," http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf, July 2013, last access: 2015-06-18. E. Hossain, M.A. Babar, and H. Paik, Using Scrum in Global Software Development: A Systematic Literatur Review. In: Proc. of the 4th International Conference on Global Software Engineering, 2009. K. Judy, ‘Great Scrums Need Great Product Owners: Unbounded Collaboration and Collective Product Ownership ', in the 41st Hawaii International Conference on system sciences, 2008. M. Blom, 'Is Scrum and XP suitable for CSE Development?', Procedia Computer Science, vol. 1, no. 1, pp. 1511-1517, 2010. Z. Zhiying, 'CMM in uncertain environments', Commun. ACM, vol. 46, no. 8, pp. 115-119, 2003. K. Schwaber, 'Scrum development process', in OOPSLA’95 Workshop on Business Object Design and Implementation, Austin, Texas, United States, 1995. H. Kniberg, Scrum and XP from the Trenches, C4Media, Stockholm, 2007. R. Akif and H. Majeed "Issues and Challenges in Scrum Implementation", International Journal of Scientific & Engineering Research, vol. 3, no. 8, pp. 1-4, 2012. N. Zabkar and V. Mahnic, "Using COBIT indicators for measuring Scrum-based software development", WSEAS Transactions on Computers, vol. 7, no. 10, pp. 1605-1617, 2008. S. Gupta, 'SOX Compliant Agile Processes', in AGILE’08, 2008, pp. 140-143. A. Cockburn and J. Highsmith "Agile Software Development, The People Factor", Computer, vol. 34, no. 11, pp. 131 -133, 2001 S. Nerur, R. Mahapatra and G. Mangalaraj, 'Challenges of migrating to agile methodologies', Commun. ACM, vol. 48, no. 5, pp. 72-78, 2005. J. Highsmith, 'Cutter Consortium Reports: Agile Project Management: Principles and Tools', Cutter Consortium, Arlington, MA, 2003. B. Boehm and R. Turner, Balancing agility and discipline. Boston: Addison-Wesley, 2004. B. Boehm "Get Ready for Agile Methods, with Care", Computer, vol. 35, no. 1, pp.64 -69 2002 V. Vinekar, C. Slinkman and S. Nerur, 'Can Agile and Traditional Systems Development Approaches Coexist? An Ambidextrous View', Information Systems Management, vol. 23, no. 3, pp. 31-42, 2006. C. Schwaber and R. Fichera, 'Corporate IT leads the second wave of agile adoption', Forrester Research Inc, 2005. N. Zabkar and V. Mahnic, 'Assessing Scrum-based Software Development Process Measurement from COBIT Perspective', in 12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, 2008. R. Martin, Agile software development. Upper Saddle River, N.J.: Prentice Hall, 2003. J. Cho, ‘Issues and Challenges of agile software development with SCRUM’, Issues in Information Systems, vol. 9, no. 2, pp. 188-195, 2008.