Running an SAP project and/or maintenance endeavor is a challenging thing. This is very specific for ERP projects as ERP covers all the business processes and involves all of the business.
However, the main problem is not any general vision on how to do it, but the level of solid delivery of every single deliverable through all project teams and stages. This level of delivery—shall we say, a tactical one—makes a difference between an excellent and mediocre result!
Enter Scrum. This is a powerful, but mostly unsung component of SAP Activate, especially for teams working remotely. In this blog post I am going to show you how Scrum fits very well for SAP projects and how it can help to drive solid delivery from all project teams. I am going to show how Scrum may foster teams to deliver every piece of the project, starting from specification through setup to test and cutover.
This post will be beneficial for all SAP project stakeholders, especially project managers, team leaders, and team members such as consultants, developers, and business representatives.
ERP is Still a Challenging Area
ERP in the broad sense, invented by SAP more than 30 years ago, is still a vital and crucial technology for business. Despite its many years of life, it is still a challenging technology in terms of implementation and maintenance.
The general concept of ERP is still the same as it was back then, but the implementation process has changed significantly; it is now much more demanding. It’s not just about automation anymore; there is the need of real digital transformation.
SAP S/4HANA brings new possibilities to make an ERP solution great for every organization. And despite the target of digital transformation, a weak point often is how to turn that vision into reality. It often seems that IT technology and implementation have changed, but the way of implementation tends to be still the old school command & control way. This way has not worked properly for a long time.
SAP Activate’s official implementation method gives a very good material prescription and also a very good organizational framework for teams to follow. In practice, however, deployment and delivery can still cause trouble. This is because, while the technical part of a project is clear and predictable, the human part (organization and individuals) creates a galaxy of challenges. The old way of forcing people to change just doesn’t work.
Scrum Is a Peer of ERP
Did you know that Scrum is also about 30 years old?
Let’s explore how much in common Scrum has with SAP projects. Scrum gives many benefits to an SAP project, but for some reasons the use of it is still quite limited.
The poor state of using Scrum for ERP projects is mainly due to the misconception of what Scrum is (and what it isn’t) and also to prejudices caused by these misconceptions. It seems there is a resentment arising against Scrum and agile delivery, with a tendency to circle back to old implementation methods.
I dare to say that completing digital transformation with old-school methods sounds strange. In practice, this quite often brings mediocre results as people are not keen on working in this kind of environment.
Of course, the same thing can happen in cases of wrongly implemented Scrum—it means any kind of mess called Scrum. That is why, instead turning back to the past, it is worth reading the Scrum Guide and implementing Scrum the right way.
Scrum as a Delivery Engine Fits Well with SAP Activate
Scrum may work as part of SAP Activate and/or any other methodology. Scrum itself is not any complete project methodology—this is done on purpose, as stated in the Scrum Guide.
A New Definition of Scrum
A new version of the Scrum Guide was released in 2020 (I’ll refer to it as “SG2020” going forward).
The new Scrum Guide is deeply revamped when comparing it with the previous 2017 version. I find it interesting that while the “old” version from 2017 (“SG2017”) contains 19 pages the new one has only 14. This includes the title page and one page for the table of contents—so this means the guide is really succinct. Wow! Could you imagine something simpler? How is it possible that there are so many misconceptions about Scrum while the Scrum Guide is a short document and written in prompt and plain language?
The positioning of Scrum has changed in recent years, and we see that it fits very well with implementing and maintaining SAP:
“Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.” (SG2020, emphasis mine)
It is a bit of a pity that in the new definition the world “delivery” is missing. Scrum is a very friendly teamwork and communication framework created for the sake of delivery. Yes, delivery, and not just development as many people think. Let’s have a look at the previous definition:
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” (SG2017)
Taking the above into account, it becomes clear that Scrum is—shall we say—natively tailored to work for SAP projects to deliver the best result. I can confirm this from my own experience.
Scrum Comes Into the “Tactical” Layer Project Organization
Now let’s take a glance at how Scrum may work within SAP Activate in bringing the organizational framework to team collaboration.
Note that the Scrum Guide defines Scrum as team work organization. All that is above the team layer—meaning the work of many teams for the sake of the common project—needs what we call “scaled Scrum.” This may be similar to Scrum, but for bigger projects there is a need for a more formal approach. For SAP projects, SAP Activate takes the idea of Scrum and scales it for you. This is one of the misconceptions, that people think Scrum is everything, even for huge projects.
Scrum gives a work model for the level of every team and for the communication between the team and all the project stakeholders. You can see three layers of a project in the figure below:
- The waterfall frame of the prepare, explore, realize, and deploy phases (a kind of a masterplan) is a strategic layer.
- Underneath is a kind of “operational” layer with workstreams broken down by deliverables. This is a very important component of SAP Activate, indicating what to do and when to do it—a prescription of sorts.
- Scrum comes as the lowest layer—all teams work in synchronized cycles, executing tasks assigned to workstreams. This is an iterative way. Every cycle starts with planning and ends with a review and retrospective.
It is worth mentioning that standards like PRINCE2 and PMI also leave this layer for individual settlements. Filling it with Scrum makes it easy to grant conformity to these standards.
We can say that Scrum is a very good tactic. I love comparing Scrum to the organization of the ancient Roman army, focused on the smallest unit with a standard tactic for the entire legion—the maniple.
If Not Scrum, Then What?
Let’s have a look at this aspect from a different angle: if not Scrum, then what? After talking with my peers and reading publications criticizing Scrum, I found that the alternative was old command & control style.
It is interesting that people criticizing Scrum are not very keen on providing a proposal of an alternative solution. That may be because implementing the newest IT technology with a more than 30-year-old method, which has a bad reputation, could be found unsettling.
It seems that now we are turning back from newer, very good methods like Scrum to old ones long disgraced by bad results. Shall it be just because of misunderstanding and misconception? Would you take a car with an old, suboptimal and toxic engine instead of a new, effective, and environmentally friendly one?
Command & control may be close to toxic micromanagement, making people work as though they were machines without a right sense of ownership and contribution. This brings mediocre results on projects and leads to issues like business disruption. The old way is not making people responsible. The old way is making many people sick.
Yes, command & control has worked so far and, of course, will work, but it is like an old engine in any old car. Many things have changed over the years and people are not keen on working in an environment that feels 30 years old.
This is specifically valid for SAP projects as each consultant and developer are carriers of solid knowledge regarding business and best practices. Doing SAP projects in the “old-school” way may kill all the creativity, morale, and engagement.
Scrum comes with a very intuitive, inclusive, and human-friendly organizational framework that can work very well in the SAP Activate “waterfall,” bringing many benefits like:
- The right control and inspection for stakeholders, especially for a customer.
- Excluding micromanagement and high and toxic overhead for work spent on reporting project status.
- The right feelings of contribution and ownership, a kind of brotherhood within the team for the sake of the best possible delivery.
And best of all, it works! I have used Scrum in the way of teams and work organization, taking over troubled projects and bringing a fast turnaround. The only difficulty was using Scrum wisely and in the right way!
In another post I will present four powers of Scrum that give:
- Standard and universal work organization for all teams working in sync in a huge project.
- Ways to bring all people contributing and engaged together for the sake of delivery.
- A "shield" for the unit during project delivery, similar to the tortoise formation.
- A clear and effective way of reporting, making delivery transparent.