Scrum at Scale in a COBIT Compliant Environment: The Case of Turkiye Finans IT

Turkiye Finans IT in 2014 managed to be the first in Middle East and East Europe in terms of the size of the change by transforming all production and project teams and related processes to agile models from waterfall. The transformation included nearly 50 teams touching more than 200 people, and had to take place in a highly regulated environment driven by COBIT (Control Objectives for Information and Related Technology) regulations. Melting COBIT and Scrum in an organization is new and challenging (especially when a full compliance is required as in this case). Despite the prominent challenges, the charm of being agile pushed the Bank to go for the transformation. It has yielded the first coexistence of these two in practice. During the transformation, we have witnessed some issues coming from the core of Scrum and COBIT and scaling Scrum while staying conformant to COBIT and maintaining the essence of Scrum. This paper aims to discuss such challenges and provide solutions for them from the practice.

1. INTRODUCTION

Türkiye Finans has around 300 branches within the country and abroad and provides product and services to more than 3 million customers with about 4500 employees. In 2014 the Bank’s IT started and finished transformation covering nearly 50 teams with more than 200 people. Thus, the Bank managed to be the first in Middle East and East Europe in terms of the size of this change by transforming all production and project teams and related processes to agile models from waterfall.

Until the transformation, the projects were being developed by the classical Waterfall method, and the organizational structure has been formed according to this way. This situation was limiting the collaboration, transparency and communication, making the manageability difficult and decreasing efficiency (Akdağ, Kombak and Yılmaz, 2014). Suffering from such and well-known issues of waterfall-based models, the vision of the agile transformation was determined as:

• Improving the IT organization’s responsiveness and adaptation ability,
• Managing companywide demand and prioritization,
• Concentrating on master projects (>100 m/d) with Agile Scrum teams,
• Delivering product and services on time with quality,
• Optimize ROI with Business Product Owners,
• Creating a bottom to top mind to increase value orientation,
• Ensuring a transparent environment.

The transformation had also to take place in a highly regulated environment driven by COBIT (Control Objectives for Information and Related Technology) regulations. Melting COBIT and Scrum in an organization is new and challenging (especially when a full compliance is required as in this case). There are contrasting natures between them due to the following reasons:

• As a result of co-occurrence and similarities of COBIT with rationalized, engineering-based approaches, COBIT has a potential to make Scrum’s each sprint to resemble mini-waterfall in flow.
• While agile methods discourage heavy documentation, 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 teams are characterized by self-organization and Scrum trusts them to do their jobs well yet COBIT precludes this freedom inside the teams by the principle of segregation of duties.
• While COBIT is process-centric and designed to standardize people to the processes, Scrum relies on people and their creativity rather than processes.
• Conformance to plan is important in COBIT but Scrum concentrates on responding to change rather than on creating a plan and then blindly following it.
• Planning and control accomplished by a command and control style of management are practices of COBIT, but agile teams are encouraged to be self-organized.
• Instead of managing risks with high assurance in COBIT, agile development confronts risks to tackle them empirically.

Despite these prominent challenges, the charm of being agile pushed the Bank to go for the transformation. Besides, it has yielded the first coexistence of these two in practice, to the best of our knowledge (i.e. based on what the literature review showed us) (Ozkan, 2015). During the transformation, we have witnessed some issues coming from the core of Scrum and scaling Scrum while staying conformant to COBIT and maintaining the essence of Scrum. Thus, based on our experience, this paper aims to provide answers to four questions:

Q1: What are the challenges arising from the core of Scrum?

Q2: What are the challenges arising from scaling of Scrum?

Q3: What are the challenges for organizations that want to adopt Scrum and must fully comply with COBIT?

Q4: To what extent can the rules of the Scrum Guide can be maintained by the adopted Scrum model?

To name the issues witnessed during this journey arising from the aforementioned sources (i.e., core of Scrum, scaling Scrum, and COBIT), the paper will provide discussions under the subjects shown in the table below.

Table 1. Subjects by category

 

To link a subject to the related COBIT objective or practices, 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.

2. INTRODUCTION TO COBIT

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. Many countries facilitate COBIT for their public sector, governmental agencies and regulatory bodies. Specifically speaking for Turkey, in May 2006 the Banking Regulation and Supervision Agency of Turkey (BRSA) mandated that all banks operating in Turkey must adopt COBIT’s best practices when managing IT-related processes.

3. HISTORY OF AGILE TRANSFORMATION

With the transformation, instead of directorates of waterfall structures, a leaner organizational structure was established with agile teams at the centre containing qualifications from every profiles within itself. Besides, hierarchical manager layer was removed. By the transformation, the changed COBIT processes are as following while the rest of the processes maintain the version before the transformation:

• Define a Strategic IT Plan (Portfolio Management in relevant)
• Manage Projects
• Identify Automated Solutions
• Acquire and Maintain Application Software
• Enable Operation and Use
• Install and Accredit Solutions and Changes

From the organizational point of view, by the change, the development teams were reorganized, trained, got PSM I certificate. The training process was also conducted for all C-levels, relevant business unites and outsource resources. The teams by default are the domain Service Scrum Teams that deal with small projects (less than 100 m/d) and problem records. For these teams the product owners are from IT side and Scrum Masters are from the development teams. When a project is to be initiated, project members from these domain teams are selected by department managers and a dedicated project-specific project team is thus created. These created Project Scrum Teams work on master plan projects (>100 m/d), the Product Owner role is taken on by the business units and Scrum Masters are from PMO (Project Management Office). While this type of Scrum Masters are the former project managers working in the Project Management Office for the Project Scrum Teams, they have Scrum Master skills and qualifications.

4. CHALLENGES AND SOLUTIONS

This part is the description of challenges faced, solutions that are already taken and on the road map. Among the challenges, we have overcome some and some of them still remain to work on.

4.1 Managing IT Human Resources

Line managers, who have primary responsibilities over people have disappear after the transformation. However, there were still works in areas of administration and outside the product development. Thus, still there existed to take accountabilities and responsibilities of functions of teams related to personnel recruitment, retention, termination, competencies management, adhering to codes of ethics, performance evaluation and administrative operations, that were managed by line managers in the previous time. Also, a central decision point for workload and resource capacity management not inside but among the Scrum teams to response adequately to very dynamic business needs was an absolute need.

Solution: Apart from the department managers, we have distributed the most of those activities to other parts of the organization and development teams as much as possible in order tı avoid a narrow throat. Additionally, we have supported the managers by providing inputs for their decisions from outputs of the evaluation of the teams and parties around the teams.

4.2 Segregation of duties

In Scrum the roles of the team members are interchangeable, and this level of role description means that the roles for analyst, tester, coder, and so on disappears for inside and especially 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 an example, COBIT AI7.6.1 clearly states that “”ensure that the testing is designed and conducted by a test group independent from the development team.”

Solution: Considered such clear distinction between Scrum and COBIT we had to follow COBIT regulations with no options. Now, a coder is not allowed to make functional test for his/her code.

4.3 Building the culture

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. And, we are aware of that it may take enormous effort, time, and patience to build a culture of trust and respect among the employees.

Solution: In order to ensure the cultural transformation and persistence, the Agile Transformation Management Team including the IT senior management, and the Agile Studio Team were set-up by the support of the PMO. The Agile Studio ensures that the transparency is not deteriorated, the information is disseminated from bottom to top, and the new teams to be formed are cross-functional and self-organized. The Agile Studio, besides fulfilling these responsibilities, continues to explain the IT Organization’s new way of doing business to all business units within the corporation, and continues to teach them how to work with the IT Organization.

4.4 Performance Measurement

In Scrum, performance measurement and reward systems approach is different from traditional methods, and therefore, should be redesigned accordingly. Here are some reasons of the difference we know:

• Scrum’s approach makes it difficult to progress according to a plan, except planning for a sprint. Thus, one of the target references required for measurement is lost.
• Scrum’s success relies on motivated individuals. Organizations need to provide the environment and support that they need, and be confident that they will succeed. This confidence must also be shown in the context of producing their own data that reflect their own performance situation of the team. And this requires for high a maturity level of the teams. Otherwise, it may damage the teams’ transparency for the sake of personal favours.
• In the Scrum structure, which takes people to the centre, the level of measurement has mainly shifted from the information to knowledge (to the human side) in the pyramid, which is more difficult to measure.
• Scrum development relies on teamwork, as opposed to individual role assignment however common performance measurement is still at individual level of granularity.
• Scrum metrics are in general designed from product point of view, and a special attention should be paid when reducing the measurement point to personal performance assessment.

Solution: Although the measurement is possible in four different levels (IT, department, team and individual) in our case, the final results are expected to be delivered in personal level to human resource department systems of the bank. Among these four levels, at person level measurement was not preferred because it was against the team structure of Scrum. For the team level performance measurement, we have preferred not doing it as the results of the following points:

• Team structure for performance measurement expected by human resources does not overlap with Scrum teams’ structure in practice
• Teams are not isolated fully in doing their works, there are inter-team boundaries and it is hard to identify and separate the lines between them.
• There is a risk of using metrics for performance measurement purpose that teams use to improve themselves.
• In team based measurement, it is not visible to identify low and high level performance of individuals inside a team

At the end, among the four levels we decided to use department and IT level metrics. In doing so, we have planned to set performance metrics that can lead us at the basic level, focusing on methodology independency, main outputs, product and customer point of view. They are such as service availability and performance ratio, on time and on budget of project ratio, compliance with resolution targets of incident and problem records. After a while, we will go back and evaluate the measurements on team basis and adding new metrics to our list specific to Scrum. In doing so, we will try to balance the point at which the team spirit will be maintained and the point at which individual measurement will be visible.

4.5 Career path development

We have witnessed that it is a challenge in Scrum to adapt its unique career path development approach compatible with the organization’s human resources process and policies. Specifically speaking, Scrum provides a flat structure of organization rather than a hierarchy including steps to managerial positions.

Solution: In the new structure, we have added a position layer at same the level of former line manager position, yet which is not a hierarchical and can be promoted by evaluating the knowledge, experience, skills and contribution to results.

4.6 Re-definition of project for scalability

It is a fact that core Scrum focuses on product and its continuous delivery. On the other side, project is a notion that survives in reality. Not in a product but in a project dominated environment, like ours, this approach feeds the project scalability issues. Scrum regards a sprint as a project and a project as a sprint. In Scrum Guide project planning cannot find a proper place and the horizon in this manner does not go beyond sprint and release planning borders. From this point of view, Scrum regards the iron triangle differently, fixing time and budget of the project during a sprint and allowing changes of the requirements during this time of period, provided that the project goal is maintained. Thus, at some degree it neglects the (scalable) project space and this differs from project definition of the customer who describes it from a holistic and a wider (and scalable) perspective.

As a solution to that, Scrum authorities and practitioners have led to some solutions, listed in “agilescaling.org”, which claim to support scalable Scrum applications. These scaling solutions mainly shape around the fundamental Scrum concepts and result in enlarging genes of non-scalable core Scrum, except Disciplined Agile Delivery (DAD) which is the closest solution we apply.

Solution: We believe the project definition provided by PMBOK (Project Management Institute, 2008) is more suitable for the customer’s perspective that is basically free from the applied methodology. In the case of Scrum, according to this general definition, a project is finalized when all the work items related to the project is completed or the cost of the next iteration (sprint) is more than the value of the iteration. However, this definition stresses and calls for a steady, consistent and fair evaluation method in project selection phase that maximizes business value and serves for a common understanding of business valuation of project requests. Despite these difficulties in managing the value, we have intended to apply the abovementioned iron triangle definition for a project to our situation. We apply time-bound management of projects meaning extra resources can be loaded to finish a project on time, when a high priority project arrives resources are re-organized or project scope may be shortened as another high priority project calls for it.

Altogether, we see the different benefits of using such a project notion in practice:

• Vertical corridor, that descents from customer to the team in Scrum’s modular and granular structure will cause formation of vertical silos and one way or another silos at the end. The project play a uniting role by crossing this vertical silos in the horizontal.
• For the sake of management of multiple projects running simultaneously and keeping the same core team members during a project, we unify people around dedicated project teams from probably different domains.
• We highlight the contributions of a project spring from the abstraction and ability of connecting of it over the physical facts of Scrum (face to face communication, daily stand-ups, physical connection of teams and meetings etc.) that may force the flexibility. The project may experience a uniting influence as a virtual layer over this physical dependence.
• Scrum teams that are in a self-sufficient structure and thus prone to become estranged to outer world and diverged from central designs, structures and formations in time. Project will reduce this side effect.
• It is possible to reach a scalable project management blended with traditional structures by this way.
• A well-established project management is a necessity for the possibilities of scalable program and portfolio management.

We remind that organizations, like us, gravitated by the charm of being agile should consider it is still one of the hot topics of agile software development that is originally designed for relatively small teams to apply to it scalable sizes (Yvette, 2015). There are some limitations with respect to the nature of Scrum in the case of occurrence of corporate or organization size distributed area, subcontracting, developing large and complex systems (Akif and Majeed, 2012). As Scrum world continues to work on scalability in this manner, we have chosen to extend the core Scrum for the sake of enterprise wide project management.

4.7 Repositioning Project Manager

While one opinion argues that there is no need for project manager role in Scrum and this role’s responsibilities are apportioned among developer team, product owner, and Scrum Master, another opinion argues that project manager role can be in Scrum and it must be when the circumstances call for it (Ozkan and Kucuk, 2016). When only one team works on a project, what Scrum offers is almost ideal. Thus, it is possible to say that project management responsibilities in relatively small projects can be shared among Scrum’s defined roles; but a separate project manager role might be beneficial even necessary in practice when it comes to larger projects.

Additionally, being of product owner product value oriented and his/her position nearer to customer edge, Scrum Master’s perspective narrowed to team level and Scrum processes lead to a conclusion that, it is hard to manage, at least for big size projects, to the fullest extent by solely Scrum Master and/or product owner roles.

Solution: We aimed to establish project management structures including project manager role that keep up with agile culture and even support this culture. Therefore, we set project manager role unified with the Scrum master role. We have witnessed that project manager which works in conformity with agile culture:

• Functions as a bridge for Scrum world to open to the world where Scrum does not exist and for the rest of organization’s classical structures. Thus, it opens doors for communication between Scrum teams and other organs of the companies who somewhat behaves and have to behave plan-oriented.
• Facilitates and makes smooth the interim transition phases in the organizations that have long-established traditional work culture.
• Plays a unifying role freely from methodology when Scrum is not applied throughout all IT.
• When third party partners want to keep their own methodology, plays a unifying role above these two parts, Scrum and not Scrum, freely from both.

 

4.8 Program and Portfolio Management

It is important to remind that program comprises projects while portfolio comprises project, program (multiple projects) or works not included in the project. Portfolio more comprehensively includes all work requirements in any scale and a core process that any organisation probably has. Thus, program is more optional by design yet portfolio management is not and is the main focus here, in this title. In our case, there is only one program example which is managed as a bunch of projects.

Function of capacity management and planning in agile structures is narrowed to sprint level. Nevertheless, for agile structures that are aligned with dynamic work requirements and objectives, proper prioritization methods, capacity management processes and project selection methods are still needed. This can be possible with a systematic portfolio management with virtual and flexible structures that can be used to enable more movement space. However, current and common designs of Scrum for portfolio management are on the basis of elaboration methods of requirements using epic, feature, etc. definitions and not scalable on the basis of projects. And, portfolio and program management are basically described and positioned via project notion. In accordance with this purpose, before proceeding with portfolio and program, the project nation and project manager roles shall be addressed extensively in order to ensure a scalable model for program and portfolio management. However, in Scrum world, as seen, arguments over definition and management of project and the role and responsibilities of project manager still continue

Solution: For the reasons above, our solution for scaled portfolio and program management has been adopted over project notion. This is why we apply company-wide-portfolio management and still comply with COBIT PO01 and PO10 processes. However, when a project starts, a product owner and Scrum master are assigned to the project and loops of Scrum come in. Thus we mainly use Scrum inside a project, at work breakdown structure level, and run Scrum rituals with Scrum roles inside this cycle.

There is a committee in place in which business and IT participate determines the prioritization of IT projects in line with business needs. While COBIT does not identify who constitutes such a committee and who directs them how, yet in our case product owners are not a member of these committees, for the same reason.

IT project roadmap for the year has begun to be planned on a quarterly basis, instead of yearly in as in the past. During the prioritizing phase of projects they are classified according to their area of specialization and high-level effort estimation is performed by the relevant expert teams (T-Shirt sizing). In terms of the coverage, we apply the portfolio management to master projects (>100 m/d), excluding requirements out of projects. While this situation is aligned with the before-mentioned objective of “concentrating on Master Projects with Agile Scrum teams”, it has the risk of causing small project requests to fall behind the master project proposals.

4.9 Iterative and incremental development of software development documents, and their formal approvals

A rationalized, engineering-based approach has dominated software development almost since its inception and has a co-occurrence and similarities with COBIT. By this effect, in COBIT processes related to SDLC, certain document contents must be produced in a certain order and must be approved by related parties. Consider that iterative and incremental development of Scrum also means iterative and incremental development of such software development documents for many times including requirement specifications (AI2.9), high level design (AI2.1), detailed design (AI2.2) and test plans. It requires also formal approval cycles of these iteratively and incrementally developed documents by related business process owners and IT stakeholders (AI2.9.3), (AI2.1.5), (AI2.2.11) and (AI7.2.8).

Solution: We had a large number of SDLC documents prepared according to the waterfall structure, resulting from the walls in communication and planning for long-terms. With the re-arrangement for the new structure, the number of SDLC documents was reduced from 12 to 5, the number of titles in them from 175 to 38. Addition to this improvement, here are some points that are useful to express:

• We had to comply with COBIT and as a result, we did so substantially. This resulted in keeping documents fresher and updating more frequently compared to the past. On the other hand, the nice side is that the employees are fresher and more up-to-date in terms of document preparation knowledge and awareness.
• We have placed Sprint Zero step to identify and remove possible uncertainties around project scope, cost, schedule, and technical strategy. There, adequate grooming is conducted that is required for launching Sprint 1. Besides these benefits, this step has fortunately reduced the documentation overhead at a level.
• It is helpful to distinguish document requirements and their frequency according to project, release and sprint base. We prepare one high level design document per project, functional and technical design documents on sprint based and production related ones on released based.
• It is possible to approach differently to the risk on the creation of the value and the risk on disrupting the current production environment. In this respect, the approval of design documents given by the business and IT can be taken to the end of the sprint. Because, the lost value can maximum be as much as a sprint length. From this point of view we have moved and take the approvals of design documents at end of the sprint.
• Based on these, the following picture provides the point from COBIT and our solution and aims to depict the situation (B: Business, T: IT, PO: product owner, DA: domain architect, EA: enterprise architect, DT: development team):

Figure 2. Document requirements of the bank and COBIT

 

It is not easy to find the middle way between the documentary behaviors of Scrum’s fragmented, scaled down, and dynamic characteristic and the need for COBIT’s holistic, static and massive documentation approach. In a human-focused agile approach like Scrum, mitigating burdens on people, coming from COBIT documentation needs, is necessary. The use of tools can be helpful to facilitate this burden for the benefit of people. In this way, there will be time and effort to show the people’s true productivity. This is the main reason for the Bank’s short term plans in the drifting of the TFS Agile Center into widespread use in this context.

4.10 Losing the big picture in design

Scrum may present 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 analyse dependencies, constraints, assumptions, issues and second and sometimes third level effects across the requirement. Architecture in Scrum designed for current requirements may exhibit some degree of issues because not all requirements are gathered 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 and creating key alternative courses of actions of solutions in the feasibility study.

Solution: We deal with this challenge by setting a mandatory sprint zero step for all projects and stipulate formal approvals of design documents by SA, DA, and EA in sprints.

4.11 Organic growth of the system

Challenge: Incremental design means organic growth of the system being developed (Nerur et al., 2005). Organic growth of the system 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.

Solution: This is exactly what we do now for the sake of the nature of work as any promotion to the production calls for it. Different from the development documents, these are organized with release frequency that must be done only in corresponding sprints before the transition rather than each sprint.

Challenge: Organic growth of the system also requires continuous integration. For all types of development, each team checks in their newly constructed part of the system within the entire system in the integration environment which is the closest copy of the production and all tests must pass for the changes to be progressed.

Solution: In this equation, without a right balance between automated scripted tests and interactive user testing this iterative, incremental and continuous testing can be hard, time consuming and risky. This is why the need of test automation that is in the Bank’s short term plans manifests for the regression tests of increments that are part of large and interdependent applications.

Challenge: In the promotion to the production, sprint deployment is one of the major concerns for teams. Establishment of secure and sanitized test environments as a representative of the future operating landscape with the deployment frequency, which Scrum anticipates, can be challenging with cumbersome and non-agile infrastructures.

Solution: For this reason, we have increased the frequency of updating the test environments and have made improvements with more frequently updated data. And, for the time being, we have started work on “devops” to fasten and smooth the process.

5. SUMMARY AND DISCUSSION

In a use of these two frameworks (i.e. Scrum and COBIT), we know organizations need to strike a balance between the two conflicting interests: agility and stability. Because of the need for full implementation of COBIT by the rule of the government in our case, in the search of this balance, we have to find somewhere between them. For the time being, our case is a reminder that while the opportunities and benefits of Scrum make it attractive, organizations should be circumspect in integrating it with COBIT practices. Apart from this, relying on our experience on enterprise wide implementation of Scrum, organization should revisit some rules of the Scrum Guide below:

• In each sprint, useable, and potentially releasable product increment is (not) created in scaled sized projects. Organizations may re-identify the definition of a product in this sense that can be a document, system prototype etc.
• “The Product Owner may represent the desires of a committee in the Product Backlog.” may not be applicable in a company-wide-portfolio management.

The room for flexibility in such an adaptation has been in tailoring Scrum with customizations and extensions such as Sprint Zero and managing risks in a Scrum way-of-doing work. In doing so, it is useful to distinguish between the risk of losing potential value and the risk of disrupting the production environment. We believe that Scrum is good in the first one and risky in the second one. Meanwhile, we continue to be in touch with the government regulatory body to apply COBIT in a more flexible way.

Our study provides experience and suggestions based on a single case in Turkiye Finans IT that operates in finance domain, and therefore has some limitations. Although its construct validity and internal validity are high due to conforming well-defined requirements offered by Scrum Guide and COBIT, its external validity and reliability is low since the suggestions are specific to our case and the path we followed is not validated in a broader sense. Yet,we hope that practitioners will benefit from the challenges, issues witnessed, solutions created during our transformation experience, and that our findings will highlight the need for the co-existence of agile and disciplined approaches and be another input into efforts to do so.

REFERENCES

Akdağ, A., Kombak, T. and Yılmaz, C. 2014. Türkiye Finans Goes For Higher Benefits From Change. Scrum.org.

Nerur, S., Mahapatra, R. and Mangalaraj, G. Challenges of migrating to agile methodologies. Communications of the ACM, Vol. 48, No.5, 2005

Ozkan, N. 2015. Risks, Challenges and Issues in a Possible Scrum and COBIT Marriage. In Proceedings of the 22nd Asia-Pacific Software Engineering Conference, APSEC (New Delhi, India, December 01-03-2015)

Yvette, F. Is the Agile Manifesto dead? Not by a long shot. TechBeacon. Online. http://techbeacon.com/agile-manifesto-dead-not-long-shot.

Akif R. and Majeed H. 2012. Issues and Challenges in Scrum Implementation. International Journal of Scientific & Engineering Research, Vol. 3, No. 8, 2012, pp. 1-4

Project Management Institute. 2008. PMBOK Guide. New Town Square, Pennsylvania.

ASK Matrix: Online, http://www.agilescaling.org/ask-matrix.html. Online: 2016- 07- 26.

Ozkan N. and Kucuk C., A Systematic Approach to Project Related Concepts of Scrum, the Review of International Comparative Management, Vol. 17, No. 4, December 2016.