Abstract: The blog post “Waterfall or Agile, or both: Hybrid?” discusses the advantages and disadvantages of Waterfall and Agile methods and how companies can benefit from a combination of both, i.e. a hybrid method. It is recommended that companies adapt their way of working to their individual needs and remain flexible in order to be successful.
It amazes me that I am currently receiving many inquiries for S/4HANA projects asking whether I “can” do SAP Activate. From my point of view, this is the completely wrong question to ask. The correct question would be whether I have sufficient methodological knowledge to efficiently and safely implement S/4HANA in a specific situation in a project and according to the specifications of the company management.
Methods and tools
The background here is that early in my career as an SAP consultant, I was lucky enough to witness both the wrong and the right application of methods and tools in my first projects. The learning from this was: The unreflective strict application of a certain method in all situations is inefficient and usually leads to no good results, but many frustrations. Instead, it is more correct to determine the right mix for the specific project task from the construction kit of different methods and tools, to establish clear rules and to ensure that everything is understood, supported and followed by the project team because everyone has understood the respective meaning. This requires, on the one hand, a broad knowledge and experience with the different methods and tools available on the part of the project management responsible for it and, on the other hand, also the courage – sometimes justified – to go new ways.
For example, when I was told during the S/4HANA implementation that I was in charge of that it was the wish of those responsible in the company to focus on agile working in the project because this form of working method should be cultivated more broadly in the company in the future, we in the project management were happy to comply with this. In this context, I looked at the content of SAP Activate available at the time and found that although this was launched by SAP as an “agile approach” for the implementation of S/4HANA, it was ultimately essentially “old wine in new bottles” with an agile coating. However, the overall documentation did not seem complete to me, nor was there a clear consistent agile approach as described, for example, in SCRUM – probably the most widespread agile methodology. Nevertheless, we complied with the request for an agile approach, made the key project players fit in in-house training sessions and carried out the project following SCRUM in the essential phases. In the essential phases, because we found that agile was not the most sensible approach in all phases and areas of responsibility in order to get the project safely off the ground. So in the end, a hybrid approach seems to make the most sense.
In my experience, the agile approach – and I am using the SCRUM and SAFe rules as a basis here – has clear advantages in the scoping and prototyping phase, and these are in particular that:
- the business clearly gets into the driver seat by taking over the product-owner and business-owner roles and has clearly defined tasks and responsibilities for the specification and acceptance of artifacts and increments
- in the user stories it is not only documented which functions the business needs, but it must also be stated what they want to achieve with it (this is for me especially in Greenfield as well as in Bluefield projects a good argument and procedure to critically question and thus clean up historically grown functions and processes; in addition, based on the intended effect it can also be checked whether this can be achieved with other means than the obvious ones in the SAP standard)
- the use of resources in the autonomous SCRUM teams can be made much more effective in these more creative phases
- it is the responsibility of the business to prioritize the individual user stories and thus also to decide what may have to be postponed to a subsequent project due to time or resource restrictions
- last but not least, the project management is significantly relieved, since the SCRUM teams organize and manage themselves under the leadership of the SCRUM masters (including vacation planning, etc.).
What are the challenges and how can they be addressed?
- There must be a clear understanding of the roles and procedures among all players -> for this I recommend an in-house training of several days, as offered by many SCRUM trainers; furthermore, the first SCRUM review sessions should be accompanied and coached by the SCRUM trainer.
- You need dedicated, empathic and structured SCRUM Masters in all SCRUM teams -> for this you can either train and certify your own employees as SCRUM Masters or hire external SCRUM Masters on a transitional basis.
- Due to the usually very large range of functions in SAP projects, you will usually need several SCRUM teams with their own product and business owners, Scrum masters and delivery teams; since integration is a core topic in SAP, these must be managed in an overarching manner -> for this purpose, it is advisable to use an agile method, e.g. Scaled Agile Framework, or SAFe for short, and thus to schedule the contents of the individual sprints in a comprehensive manner, taking into account the integrative dependencies; it can be helpful here if the user stories belonging to a topic are bound together in chapters (e.g. EPICS, even if these are not exactly intended for this purpose according to SCRUM) and these are addressed in the sprint planning in the context of program increment planning meetings with all SCRUM teams. A good alternative to using SAFe in environments where the project team already has solid SCRUM experience can be the use of NEXUS, an approach in which there are dedicated integration roles.
- It is often not clear to the product and business owners which implementation and coordination efforts can be hidden behind which user stories. For example, some seemingly complex points in the SAP configuration can be completed with a mouse click, while supposed trifles can result in a great deal of effort -> In this context, it is important, In this context, it is important to consistently hold backlog definition meetings with sufficient time and to consistently evaluate the user stories with story points in order to determine the velocity of the individual sprints and to get a realistic view of what is feasible in the team. (see also S. Burkart: “Why small is not always right, as an introduction to his YouTube channel: https://youtu.be/BYd7ZuZ_W8c )
- Another problem is the completeness of the requirements, because due to the high degree of integration it is not obvious for the business for which topics user stories have to be created in order to draw a complete picture -> here a procedure according to SCRUM 3.0 (by Boris Gloger) can help, according to which it is permissible that the entire development team also participates in the creation of the user stories and thus closes the existing gaps.
- We have made the experience that the sole documentation of the requirements and solutions in the product and sprint backlog does not lead to a view of the future solution that is understandable for all -> Here, the creation of a business blueprint, in which the essential framework (org. units, core processes, as well as the use of essential master data and functions) are recorded at the beginning and then updated and completed during the sprints, can be used at the end of the scoping and prototyping phase for the overall acceptance of the tested prototype.
- The DOR (Definition of Ready) and DOD (Definiton of Done) must take into account the specifics of an SAP implementation -> here is a project example:
Definition of Ready (DoR)
Definition of Ready for product backlog entries, so that are can be scheduled into a sprint
- User Story is completely formulated (Representing function X, I need functionality Y in order to achieve benefit Z)
- The stakeholder of the backlog entry is clear
- There is at least one Acceptance criterion
- All Acceptance criteria are formulated sharply and as measurably as possible and understood by the development team
- The development team has no more questions about the functionality to be delivered
- Integrative questions with other teams are identified and coordinated
- The development team is able to appreciate the story points for the PBL entry
Definition of Done (DoD)
Definition of the elements that must be completed/checked for a product backlog entry to be set to status “Completed” by the Product Owner
- Process run-through based upon real data sample without error in the Unit-Test-System and completely documented in Test-Script (refer also to BLOG 19); stored in the central folder
- Process run-through accepted by the Product Owner & Stakeholders
- Missing functions are captured in new Product Backlog entries
- All Bus. Blueprint deliverables created:
- Processes, functions & roles are specified the BPM (i.e. based upon SAP BP BPMN2 uploads), if an e2e process has been completed or a sub-process flow is affected
- Necessary data-exchange with non S/4HANA systems is identified and documented
- Systems connection and information flow (object level) between the systems is documented
- Functional specification (information exchange (content and event or time) is defined for inbound and outbound interfaces and stored in SAP PO (previous PI)
- Field content of all required master data fields necessary within this process is identified, confirmed by MDM-Team and documented in accordance with rules defined by Master Data Management
- Functional specification is created for the development of forms and stored in the central folder and linked to Change No in SolMan-CHarM
- Functional specification is created for the development of enhancements and Add-Ons and stored in the central folder and linked to Change No in SolMan-CHarM
- All involved process steps executed in S/4HANA (each line in the test-script) are recorded in the authoring system (see also BLOG 25) and are referring to the related process in the BPM
- All required organizational changes are identified and logged in the Organizational Change Management-Log
- All configuration executed is completely documented in accordance with the guidelines in the IMG of the development system
- All decisions taken by the SCRUM Team during the sprint are noted in the meeting minutes (see also https://sapxp.ch/meeting-minutes-xlsm/?lang=en )
- All gaps that can’t be resolved within the SAP Standard are logged in the Hold-Basket and assigned to SAP responsible
- MIND: If the missing DoD deliverables are completely captured in new Product Backlog entries, the executed one can be set to “Completed”
In a brownfield S/4HANA migration, I would not use agile in the scoping/prototyping phase. In my opinion, agile cannot be applied there in a meaningful way, but would rather tempt people to deviate from the prescribed approach, because creativity is encouraged in an agile approach. Also, the SCRUM framework cannot be applied consistently to a 1:1 transfer of today’s processes and functions, or only with difficulty.
Also, I can’t really imagine an agile approach being applied in a meaningful way in the project preparation, realization and implementation phases; in the realization and implementation phases, it is a matter of completing and finalizing the requirements created in the agile scoping/prototyping phase. Here, the classic waterfall approach, as we know it from Accelerated SAP (ASAP), seems to me to make much more sense – flowcharts for the corresponding phases can be found, for example, at our download site https://sapxp.ch/asap-ms-project-plans-zip-digistore24/?lang=en .
For an overview of the differences between the various methods, I recommend: https://www.theprojectgroup.com/blog/en/agile-project-management-methods/#prettyPhoto .
Conclusion
In summary, based on my experience so far, I would only use an agile approach in the scoping/prototyping phase of greenfield and bluefield S/4HANA implementations, but I would also create a business blueprint and otherwise work in a waterfall-based manner, i.e. apply a so-called hybrid approach.
In a brownfield S/4HANA migration, I would only use a waterfall-based approach.