SAP is often referred to as standard software. In other words, software that is created for an application area for the anonymous market – and must be adapted to the specific user requirements or even aligned with the entire operational process organization by means of “customizing”.
But how flexible and adaptable is SAP as standard software? Are there restrictions that limit, for example, the creation of “potentially deliverable increments” at the end of a sprint? Is conceptual design necessary on a traditional scale or can it be done iteratively? In short, how agile does SAP go?
Agilon conducted a survey in 2019 on agile ways of working in SAP projects and noted the following three findings:
- Agile approaches are now leading in SAP projects (55%)
- Agile potential is still not exploited, however.
- Main obstacles to this: hybridization of agile and waterfall, and non-compliance with “agile rules of the game”
There is even SAP’s own agile methodology “SAP Activate”, which was used in twelve percent of cases (2nd place behind Scrum).
At the same time, there is still ignorance regarding flexibility and adaptability in companies using SAP. As a long-standing IT service provider, we would like to share our experience from numerous SAP projects with you.
From individual development to customizing – customer requirements lead the way
.
Development services in an SAP project usually include enhancements to the standard software and custom developments. In many use cases, however, development is not necessarily required, because customizing is actually “just” configuring the existing software so that it works as desired in the project.
SAP Netweaver can also be used as a pure development platform.
Different approaches lead to the goal
.
As in all projects, SAP projects or their approaches are not always the same: the context and scope at SAP is a bit larger, so smaller increments are sometimes less useful. Furthermore, only smaller elements are testable and more complex tests are difficult to automate so far.
In the case of customer-specific SAP developments, on the other hand, packages are even artificially cut somewhat smaller. The development process here is similar to that for custom software. However, several developers cannot work on the same source code at the same time. In the future, ABAP in the Cloud will provide a remedy here, but not all individual developments can be transferred functionally one-to-one to the cloud. The adaptability of the software is limited in the ABAP Cloud.
There are also projects where increments go live combined into releases. Until the sprint review, the features are imported and tested on the integration environment. The number of sprints to release varies from a minimum of three sprints to four months.
What is special about SAP is that not a complete software is versioned, but only parts of it. Thus, parts can be delivered even if something is adapted in adjacent parts. Large SAP releases with function updates entail many adjustments and rework. In theSAP S/4HANA Cloud, a new release is delivered every three months, which keeps individual developments to a minimum. Automated tests are therefore all the more necessary and could be carried out via SAP iRPA, for example.
There are SAP projects that are iterative in development, but organized overall according to waterfall. For example, when replacing a legacy system, which requires data migration and further development. For data migration, there is a long planning phase in which the project is discussed iteratively with the customer.
In such cases, targeted test migrations are performed before the development scopes are set live. Through these migrations, the team can iteratively find out what already works or what does not after the data migration from the legacy system to the new system and incorporate findings from this into future custom development. In the last step, the Go Live is also simulated here. If a form of key user feedback flows in addition, a safe and also rudimentary agile methodology results here.
Naturally, there are very many interfaces in SAP, which must also be documented. For this, audit-proof and approved business and IT concepts are essential. Missing or lengthy releases are not infrequently a blocker in SAP projects.
It is sometimes helpful in the product backlog to distinguish between several types of stories: development deliverables, conceptual stories, and support deliverables (e.g., tests). The conceptual stories are used for continuous expansion of the Product Backlog.
This means that a conceptual story then becomes a developer story. This approach enables an iterative technical detailing and thus an earlier value creation than in classical approaches.
Specific system and business knowledge indispensable
.
The agile team should always have all the knowledge it needs to implement the contents of the product backlog. In the case of SAP, these are specific system and business process knowledge.
In larger projects, the consulting share is often high, so that sometimes several business analysts are in the team. Although Scrum does not provide for roles and specialists, there are specialists in SAP projects, but they should ideally have cross-functional knowledge – and act as consulting developers or developing consultants.
Due to the complexity of an SAP ERP system, customers almost exclusively purchase consulting services to support the role of the product owner. Sometimes these services are complemented by support, which is increasingly integrated into a DevOps model.
Conclusion: SAP and Agile – it works!
One of the biggest challenges is that, compared to other systems, SAP ERP system runs like a thread through the entire company and therefore continuous availability of the system with its functionalities must also be ensured. The consequence of this is that releases, if necessary, can somewhat curb progress.
Approaches such as iterative procedures, test migrations, key user feedback, sprint-based conceptions and DevOps models show that there is always an agile way – no matter what the requirement is. This is also confirmed by the above-mentioned study and thus disproves the dusty prejudice of the waterfall must-have.
The majority of SAP projects feature a hybridization of the agile and classic approaches. Whether this is the best or rather the “cautious” way towards “agilization” of SAP projects remains to be seen.
Learn more about our innovative services in the SAP area – in the SAP Success Story.
Would you like to learn more about agile methods?
Our team of experts will be happy to advise you.
