Using Agile Scrum in SAP projects

There is perhaps no more popular topic of discussion than the use of Agile in SAP projects. Despite the fact that the principles of agile development were formulated back in 2001 [1], their use is now becoming more in demand than ever. This is primarily due to the fact that the last decade has been marked by the massive use of information technologies (hereinafter referred to as IT) in everyday life: government service portals, online stores, e-government and much more. The above requires both competent software development (hereinafter referred to as software) and no less skillful implementation.

Rice. 1. Agile Values ​​and Principles

Agile is a methodology for the implementation and implementation of software based on an iterative model and includes a set of methods, which include FDD (Feature Driven Development), XP (eXtreme Programming), Kanban, Crystal, etc. The essence of the methodology is to use the 4 core values ​​and 12 principles (Fig. 1) declared in the Agile manifesto [2], adherence to which is intended to significantly facilitate the implementation of information systems (hereinafter referred to as IS). One of the striking examples of the use of Agile principles is the Scrum method. Considered as a counterweight to the classic waterfall model of IS implementation, the Scrum method provides a clear picture of the implementation process and describes the implementation of the basic components of the manifesto. To be fair, it should be noted that Scrum is partially used in the waterfall model, for example, to clarify requirements during the analysis phase through prototyping.

Let us recall that the iterative approach to software implementation consists of dividing the implementation process into stages called iterations, within which the implemented part of the solution is developed and demonstrated to the customer. [3]. At the same time, there may be no requirements at all, the number of upcoming iterations is not known, and the scope of the project can be changed with fixed deadlines and budget. Following the Scrum method, iterations are called sprints, the list of requirements is called a backlog, the progress of the project is monitored on the board with sticky notes, and the team is viewed as self-organizing [4]. A conceptual picture of running an implementation project according to Scrum is given below in Fig. 2.

Rice. 2. Project implementation process according to Scrum

Despite the difference between the cascade and iterative models of IS implementation, in both approaches the functionality of the developed system is confirmed by successfully passing acceptance testing (User Acceptance Test – UAT) [3]. However, Scrum differs significantly from both models due to the lack of UAT and solution documentation. The project for implementing corporate information systems (hereinafter referred to as CIS) using Scrum consists of the following steps:

• identification and analysis of requirements for CIS, prioritization of found requirements and formation of a product backlog;

• determining the number and duration of CIS development sprints; creating a backlog of sprints and distributing them among iterations;

• implementation of the CIS according to the sprint backlog, functional and integration testing, demonstration of the resulting product to the product owner and customer, sprint retrospective and updating of backlogs, as well as productive operation of the implemented solution (for all sprints) [4].

Moreover, unlike waterfall and iterative models, the measure of Scrum project delivery is the sprint (part of the product), not the product. Thus, in Scrum, the result of each sprint is subject to industrial use, even if the final sprint, which marks the implementation of the entire product, has not yet been implemented.

The Agile methodology was initially focused on development, but not on software customization, which is why a Scrum team is understood to be a team of 5-7 developers. Customization is an IS customization that does not require software modification of the solution. Software configuration is carried out by functional consultants, while solution implementation is carried out by software developers. It should be noted that the number of variations in system settings to suit customer needs is very limited. IS customization ensures standardization, unification, and transparency of the solution: it is much easier for a beginner to understand the settings due to their determinism than with software developments.

Let's say that customization is carried out by developers. Modern corporate information systems, for example, from SAP AG: ERP, SRM, SRM and others, operate and undergo changes due to:

and the project for their implementation is characterized by functional:

• a large amount of master and variable data for migration purposes and subsequent use in SAP;

• a single integrated organizational structure of the enterprise in SAP;

• a specified number of business processes to be reflected in SAP;

• a large array of transport requests and tasks for transfer to SAP

and organizational features:

• integration of SAP with external systems;

• a large number of project team members (depending on the project – 1-5 people within one functional area, the project can have from 1 to 7 areas).

The implementation of such systems is carried out mainly on the basis of a cascade model due to the high cost, volume, complexity and duration of the project. Let's do the following exercise: we will highlight the methods of implementing CIS, as well as the types of projects, then for the “method-type” pair we will try to assess the feasibility of using Agile Scrum (Table 1). As an assessment, we will choose a scale from 1 to 3, where 1 – use is unlikely, 2 – use is possible, but a significant transformation of the team is required, 3 – it is recommended to use Scrum.

Table 1. Feasibility of using Agile Scrum in SAP projects

Using Agile Scrum to refine the SAP system during its development can achieve a positive effect. It is worth noting that the development affects only limited functionality of the SAP system, comparable in scope to the module, for example, procurement, sales, inventories, etc. The use of Scrum dictates special requirements for the organization and composition of the team: now architectural decisions must be made confidentially and collectively; development is carried out based on requirements, design solutions, development specifications and other documentation are missing; everyone reports daily on the results of the work done. To use flexible methodology, a transformation of the project team is necessary, the first attempt of which may end in failure. The benefits of Scrum will only be felt if the team is continuously working on projects using the flexible methodology of Agile, and not ad hoc: using Scrum requires overcoming the inertia of the waterfall model. The same requirement can be simultaneously incorrectly interpreted and incorrectly implemented; continuous demonstration of the developed solution to the product owner and end users allows you to get exactly the product that the user expects and wants to see. This is the advantage of the iterative model, which includes Agile. Thus, the feasibility of using Agile Scrum in projects for the development of SAP systems due to their refinement seems justified, but requires significant changes in thinking, organization and understanding of the new rules of the game of the entire project team (Table 1, feasibility assessment 2-3).

Let us turn to the case of customizing the SAP system in the process of its development. The simplest example is the implementation of a previously unused module, for example, SAP ERP WM (Warehouse Management). Such activities do not require excessive work of a functional consultant. Let's figure out how the positive effect of using Scrum in the process of finalizing SAP is achieved. The program can be organized and programmed in a huge number of ways, the flexible development model allows you to choose only the one that satisfies the end user. In the case of customizing an SAP system, the situation is completely different: customization of the solution is very limited, and the customization options are either singular in nature or very similar. Demonstration of an intermediate product to the user cannot fundamentally change the chosen solution due to its determinism. As a result, the end user can influence little, and the Scrum method itself provides only quick delivery of a solution without any significant feedback (Table 1, feasibility rating 1-2).

And finally, full-scale implementation of SAP. A significant part of the projects, both replication and implementation of SAP “from scratch,” require modification: customization for the most part cannot cover all business requirements. Let's start with organizational difficulties: an SAP implementation project requires the involvement of a large number of both developers and consultants. Depending on the project, the number of team members can vary from 5 to 37, which clearly violates the requirements of Scrum (according to the agile methodology, a team should consist of 5-7 developers). Almost every SAP project includes integration with external systems. Regardless of the content and quality of sprint implementation by the SAP project team, there is a high dependence on external resources. Ignoring the SAP project plan, delaying testing and release of the product, not informing about changes made and other actions of the external party critically affect the execution of the sprint and cannot be eliminated within Scrum…

Literary source

Stepanov D.Yu., Velsovsky A.V. Application of Agile Scrum in SAP projects // Corporate information systems. – 2018. – No. 1. – pp. 9-17. – URL: http://corpinfosys.ru/archive/issue-1/46-2018-1-scrum.