In the last 20 years, most SAP projects used a sequential IT delivery model (especially the V-model). In current SAP projects we see the shift towards a Demand/Supply Model where parts of the Agile way of working are implemented in SAP projects.
In this section we first describe how to transition from a sequential to a hybrid IT delivery model. Next, we describe good practices of the Agile mindset that can be implemented in SAP projects.
Working towards a hybrid model
Many organizations with SAP projects that want to benefit from the Agile way of working will actually need to implement a hybrid IT delivery model. When an SAP project wants to move from a V-model approach towards a hybrid model (especially the Demand/Supply model) it is advisable to start small. SAP projects are usually major in size and impact and consist of multiple teams working on the same solution. For this change in way of working, start with a minimum viable product (MVP), for example for the Finance Module, and after this approach has been proven successful, expand to the core value chain.
Begin a transition towards a hybrid model by adding smaller custom functionality to a sprint and start expanding from there. It is important to consider that if a team is working on an object in a sprint that another team cannot work on the same object. Coordinating which team is working on a specific SAP object and managing the integration of these objects is crucial when multiple teams are working in a hybrid model. The system integration test (SIT) to verify the quality of the integration of multiple deliverables is a good method to guarantee the quality of these releases.
Demand/Supply model
The Business is the Demand side è the business demands new changes, requirements, legislation etc. This is the non-agile part of the hybrid model. Then the business needs are translated in requirements / Epics / Feature / User Stories and handed over to the Development team(s).
The IT delivery team is the Supply side è the development team(s) will transform the demands into useful (business) processes using design / coding / Unit Test(UT) and System Test(ST) in an agile way of working. After successful UT / ST (teams focused UT and ST testing) the solution is handed over back to the business for final integration, acceptance and regression test before it can be deployed to production.
Agile good practices in SAP
An overview of the Agile good practices that are commonly implemented in SAP projects:
Delivering functionality in sprints;
(Non-)functional requirements for SAP products can be delivered in smaller iteration than the waterfall release schedule. By using sprints for each Solution Train, the project becomes more manageable. Testing these sprints will require regression testing preferably by using Test Automation each sprint to guarantee the quality of each sprint. During each sprint the scope of the (automated) regression test set can be expanded.
Create user stories;
Splitting up (non)-functional requirements into user stories is required for the use of sprints in the project. This helps in making the project scope more manageable. Consider to focus the user stories within the Solution Train on the (non-)functional requirements within that Solution Train and have a separate set of user stories to focus on the end-to-end solution covering multiple Solution Trains.
Create a backlog for user stories;
Having a backlog for the user stories allows the team to combine related functionalities in the same sprint. A project can link specific user stories to each Solution Train. The user stories that cover multiple Solution Trains can be marked as end-to-end user stories. For example, in the Hire to Retire process the team can split up this process into specific epics and user stories for: Setting up different parts of master data, setting up organizational structure, recruitment, onboarding etc.
Set up planning sessions;
Planning sessions are required when using sprints in the project. Planning sessions allow the team to set up the scope of each sprint. Planning sessions should also include the check for dependencies with other teams, stakeholders and solution trains.
Set up daily stand-up sessions;
A daily stand-up with the team to discuss what each team member did yesterday, what they are planning for today and to check for impediments.
Set up retrospective sessions;
A retroactive session after each sprint will help to optimize the performance of the team.
Set up refinement sessions;
During the refinement sessions the team can check the impact of a user story within the team and/or with other teams and departments and set up end-to-end testing.
Set up demo sessions;
Having the developers demo new functionality to the end users is a good way to keep the business involved in the SAP project.
Assign the role of Product Owner;
The role of Product Owner is very useful in an SAP project. The Product Owner is the linking pin between developers and business.
Assign the role of Scrum Master;
The Scrum Master of a team sets up the planning sessions, retrospectives and daily stand-up sessions and helps team members solve impediments.
Definition of Done, Definition of Ready;
To ensure the definition and verification of quality goals it is critical to define when a specific work item is completed. For two very important states – “ready” and “done” the Definition of Ready (DoR) and the Definition of Done (DoD) have to be defined and agreed upon between the relevant stakeholders.