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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Keep in mind one principle of the agile manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.”
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
16 | |
11 | |
8 | |
8 | |
6 | |
6 | |
6 | |
5 | |
5 | |
5 |