Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 

Introduction


Today, no one doubts that agile projects are more successful than those that work with the old waterfall model.  This can also be proven empirically: The Standish Group Chaos Study from 2020 shows that Agile Projects are 3X more likely to succeed than Waterfall projects.


This is also true for S/4HANA implementation projects, but there are significant differences to normal software development projects. But wait: You don't have to reinvent the wheel again. With Focused Build, there is a solution for agile S/4HANA implementations that has been successfully used in hundreds of projects and has been continuously developed for years.


Focused Build is an add-on for SAP Solution Manager that comes with a tool-based, requirements-to-deploy process as well as functional enhancements. It essentially contains the accumulated experience for a successful S/4HANA implementation project in one solution. The usage rights of SAP Solution Manager include SAP Focused Build at no additional costs.


However, there are some things that you should be aware of. These 10 tips will help you to successfully survive your agile S/4HANA project.



1. Check the organization readiness for agile projects


A true agile transformation is defined as the process of transforming an organization’s culture to one of agility. Transformation is about a fundamental change in the way people think and act. This transformation process touches every facet of an organization, including people, strategy, processes, and technology. It is a long-term goal with significant organizational changes.


Fortunately, this is not a mandatory requirement for a successful agile project. The focus during an agile adoption is on process change, such as waterfall to SCRUM or SAFe.


Keep in mind that it can be very difficult for employees who are used to a waterfall process to think and work in sprints and waves. Make sure to schedule onboarding events, training sessions, and discussion groups to help employees get a feel for agile processes. SCRUM trainings are also a good starting point.


You can find many online resources about this topic. Try the IDC Agility Assessment (sponsored by SAP) to find out more about how agile your organization is.



2. Ensure management commitment


Without a true management commitment, it will be difficult to overcome internal opposition and problems. This starts with the COO, affects all involved unit managers and, of course, the project managers.


It is best to create a project charter that defines the commitment to an agile approach and is signed by all persons involved. Address potential objections and challenges before the project begins.


It is very helpful to have a customer internal ambassador – some call it a technical or agile evangelist - for all agile related topics. This ambassador is appointed by and reports directly to C-Level management.



3. Do not force an agile approach against significant resistance


However, it will sometimes happen that employees or an organization are not (yet) ready for an agile approach. Don't fight against windmills if you don’t get the management commitment or if the project members are absolutely unwilling to work in an agile way.


In this case it is wiser to stay with the old waterfall model (it was introduced in 1970). Perhaps you can establish an incremental development with some minor releases to reduce the risk of a big bang deployment.


Another strategy is to start the first agile project with a team that has an open mindset. Afterwards, you can promote the project as a successful Proof-of-Concept and the team members can support other projects as agile ambassadors.



4. Get an experienced Focused Build Coach


For a successful Focused Build project, it is essential to get the support of an experienced Focused Build coach. For large and complex projects, two coaches are also not a bad idea.


How to recognize a good coach?




  • He is proactive, has a holistic project perspective and can integrate all different layers (methodology, processes, and data).

  • Has at least one Focused Build certification, for example the openSAP Agile Project Delivery with Focused Build for SAP Solution Manager.

  • Should also be a certified Professional Scrum master.

  • Is familiar with the Scaled Agile Framework (SAFe). SAFe is an agile framework developed for larger teams and agile enterprises. The requirements-to-deploy process enabled by the Focused Build solution is based on SAFe.

  • Is an expert regarding all SAP Solution Manager functions and scenarios.

  • Many technical problems occur in the area of transport management and change request management. It can’t hurt if a coach has also deep technical knowledge in this area.


Even if you have many certifications - there is a clear difference between theory and practice. An experienced Focused Build coach will help you to setup the project, plan releases, waves, and sprints. All Focused Build related trainings are done by the coach and establish him as the contact person for the project team.



5. Don’t try to change the Focused Build methodology



  • “We do agile development in a different way”

  • “We use Focused Build, but with a waterfall approach”

  • “Focused Build is fine, but we need additional functions to fulfil internal requirements”


When I hear statements like that, all my alarm bells ring. Focused Build and the methodology are deeply integrated with each other. The possibilities to modify the tool or the methodology are very limited. In return, you get a well-proven, ready-to-use solution that you don't have to configure first.


I recommend every project and customer to use Focused Build exactly as it is designed to be used. If you need another approach or a different methodology, then you are maybe better off with an individual SAP Solution Manager setup. The Focused Build Coach can tell you exactly which modifications are possible, and which are not.



6. Don’t underestimate the effort for an agile project


Doing a project in an agile way does not mean that the effort is necessarily decreased. At least for the first agile project - things usually look better for the second one when you can work with an experienced team.


In agile projects, you get constantly customer feedback, errors are detected earlier, and costs are saved as a result. On the other hand, there are additional costs for a Focused Build Coach and trainings. It also takes some time for employees to understand the agile methodology and operate Focused Build without support.


Depending on the size of the project, a coach (in complex projects even two) is needed full-time at the beginning. As the project progresses, the amount of work is usually reduced and finally a coach is only called when problems arise.



7. Communication


Communication is an important part of any project, but it is essential when using agile methods. According to an article published by the Project Management Institute, 50% of project failures can be directly attributed to lack of communication.


There are several well-known techniques for agile team communication, such as daily scrum, task boards, sprint reviews, retrospective, and more. I would like to highlight two of them.




  • Align all teams – Agile teams tend to be small. In SAP implementation projects you will often be working with multiple teams. The backlog should not simply be processed item by item. Therefore, all teams should align before each wave (sometimes also before each sprint) to ensure they work towards a common goal.

  • Retrospective - Remember that in most projects, people are just learning how to work in an agile way. A retrospective after each wave helps to identify what worked well and where the process needs to be adjusted. Even though Focused Build brings a clearly structured methodology, every project is different and within certain limitations you must adapt the agile processes for each project.


8. Set up a proper system landscape


A two-tier landscape for SAP Solution Manager is a prerequisite. Focused Build is the backbone of your project. A failure can significantly delay the project or result in high expenses. Updates, Service Packs or other changes should always be tested first in the DEV Solution Manager system before they are transported into the productive system. In a validated GxP Environments, I even recommend a 3-tier Solution Manager landscape.


For your on-premise S/4HANA system, at least a 4-tier system landscape is standard (DEV, QUA, PRE, and PRD).


The functional integration tests, regression tests, and performance tests require a clean and stable test environment. They are done in the preproduction system (PRE). This ensures that no transports can disrupt the test phase and that the test environment only contains functional changes of the current release.


In agile projects, development and tests run in parallel. This would not be possible with a 3-system landscape.



9. Build work packages correctly


A work package is always related to a transaction, describes a function, and it must be testable. Looked at the other way around: a single functional test is related to a work package or a process step. But what is the right size for a work package?


Well, it depends. A work package should be implementable in one wave and a work item in one sprint. You need as many work items as there are developers or skills. In the end, the team decides how many items are in a package.




  • In a work package there should be as many items as necessary and as few as possible.

  • If you have found a suitable size for work packages, make all the others similar in size.


Keep in mind one principle of the agile manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.”



10. Bookmark Focused Build online resources


There are tons of online documentation, training materials and other resources that will help you to be successful with Focused Build. Unfortunately, they are not always easy to find.




Conclusion


Focused Build is the best way to implement agile S/4HANA projects. The unique combination of methodology, best practices, and functional extension guides you through your project, is immediately available and gives you at any time complete transparency on the current project status.


These 10 tips may help you to make your next project even more successful. Do you have any other tips? Let me know in the comments.


Special thanks to Petra Heidler, Jannis Mücke, and Stefan Doktor who supported me with ideas and proofreading.

4 Comments