The art of implementing Agile in SAP projects
After more than 20 years of practical experience in SAP projects, I see that a change in generations of employees and their way of work is also noticeable in the SAP ecosystem. We live in a VUCA world in which changes in society, economy, technology and entire business models are coming to all of us in faster cycles then ever. This challenge can also be observed in the SAP environment with a slight delay. In a nutshell, it is about mastering the “balancing act between stability and agility”.
In this blog post I would like to take a closer look at this change, the challenges and possible solutions. In addition I like to share some of my thoughts with the community.
The VUCA model
The VUCA model fits this situation very well. VUCA stands for the terms Volatility, Uncertainty, Complexity and Ambiguity (in German: Volatilität, Unsicherheit, Komplexität und Mehrdeutigkeit).
Within these four areas of tension, all employees are required to make assumptions and readjust them again and again. Much can no longer be planned far in advance, although the answer “we don’t know it exactly” seems to be the correct answer.
Source: HBR, Nathan Bennett and G. James Lemoine
Challenge 1: The Complexity
In my opinion, the complexity in SAP projects is probably the greatest challenge. The far-reaching dependencies between the various SAP modules, customizing, development and, last but not least, the entire technical complexity that represent the lower part of the iceberg is an enormous challenge. Each of these areas requires in-depth and long-term expert knowledge. Such an area can only be managed with a lot of practical experience.
Advice and wisdom 1 about complexity
The Via Negativa: The Greeks, Romans and medieval thinkers had a name for the reduction of complexity “The negative way”, “the way of renouncing”, “omitting”, “reducing”.
So the advice is clear: leave things out, think in terms of releases and stages. Rome wasn’t built in a day either.
Source: Via Negativa, from www.ausflugsziele.ch
Incidentally, the picture comes from a wonderful excursion destination: Roman road: The historic path of the Montecenerino Link
Challenge 2: The project approach
According to evolutionary theory, we all tend to do things the way we have always done. That gives us security, familiarity and we don’t have to leave our comfort zone and try something new and uncertain. But the world has changed. We live in a VUCA world. Forget about writing monstrous, ultra-large blueprint documents that nobody reads or understands except the author himself. Forget to think through and specify everything from the beginning. By the time it will be implemented, the world, and the technology, had changed in such a way that the initial situation and the assumptions from the monstrous, ultra-large blueprint had become obsolete. It is much better to write what we now know in small user stories that can be easily adapted and changed. Perhaps it also helps to ask who will be the future generation of users and how this generation wants to work with the newly designed system, solution or service. Also what are their requirements for a project of an average of 2 years. It definitely seems better to me than blindly doing it the way it has worked for the last 20 years. That is no guarantee for the future.
Here it takes the courage to say “why not”. In the waterfall, too, a project was the first one time and through experience and application in practice, the waterfall model has developed further. Why not carry out the next project now using an agile project approach such as Scrum or SAFe. Simply switch the “default value” for the project procedure model to Agile. By the way, the default value influences our decisions a lot more than we think. The modern economy and marketing used the default value principle for a long time. More about the default value at https://de.wikipedia.org/wiki/Default-Effekt
And there is one more uncertainty that I can defuse: in 2021, if you take an agile approach, you will no longer be among the “early adopters”. There is enough experience, training and know-how on this approach.
Advice and wisdom 2 on how to proceed
- Don’t worry, fear is a bad companion
- Change the default value to Agile
- Learn and improve
Source: Own illustration
Challenge 3: Divide the work into small pieces
Another thing, an inborncharacteristic is not to divide developments and customizing into manageable, small bites, to separate them and to make them testable more quickly. Keyword “early feedback”. Packing everything into the largest possible transport request is another cause. These are only imported into the QAS system shortly before the test phase. And often this is where the trouble starts: import problems (yes, there are also dependencies to other modules, down to the deepest development object, sequence and transport overtaking, downgrade conflicts) all of this only occurs in the QAS system. Now, however, the time is already running out to clean everything up quickly. Fulfilled test entry criterias – often a wish and not a fact.
Advice and wisdom 3 for work granularity
- Build a backlog of requirements
- Attention to a uniform granularity of the work for all involved
- Structuring customizing and development cleanly, recognizing dependencies, cutting, etc.
- Use techniques such as prototyping, minimum viable product MVP
- Structure work based on the INVEST criteria – more on this in the following blog post: Requirements Engineering for SAP Solutions
Source: Own illustration
Challenge 4: team, team spirit and next Generation
Probably the most important topic in any project, in sport or wherever. The human factor, the team, both essential to achieve goals.
So many aspects are important here, I will only go into one aspect, the different generations of employees in more detail.
Let’s take a look at the preferences of the different generations in the following overview. Here, too, there are many differences in terms of goals, working methods, value system and communication, to name just a few.
Roles, both in private and in the professional environment, have been clearly regulated since the Stone Age and often are still the same. Sometimes with a new name, but basically not new and with still the same tasks, competencies and responsibilities.
Why not tap into the knowledge of the different generations of employees and merge the different points of view profitably. Of course, a first step is needed here, someone has to jump over his shadow, accept new things, none of this is easy and does not happen overnight.
It is worth striving for the new product, the system to be developed or the service to be built in such a way that it offers the highest value to future employees and users.
I like to draw on the analogy of a pirate ship the Black Pearl. On a ship there is not just one captain, but always a team that works hand in hand. Everyone on the ship has their tasks and together the crew has a goal that needs to be achieved.
Advice and wisdom 4 for team, team spirit and next Generation
- Analysis of the generations of employees involved in the project, plan or operation and use this enormous potential.
- Ask yourself what future employees and users expect from the product, system and service
- Why not define new roles that may not have existed before, but can definitely make sense and contribute to the project
- Shared experiences – bring more team spirit and solidarity on all levels
- Always question the status quo, what still makes sense, what no longer makes sense
- Establish an open feedback and error culture
- Less “Yes, but …” More “Yes, why not …”
Source: HWZ – University of Applied Sciences Zurich
If you are faced with the task of implementing Agile in SAP projects, then think cleary about these topics, have an open mindset, be a Leader, have an ambition and strong vision and remember, once is always the first time!
To summarize I have drawn the following illustration with the main topics of this blog post.
Source: Own illustration
I hope I was able to gave some inspiration with this blog post and motivate everyone to think about it in the next project.
I would like to close with the following quote:
“The best way to predict the future is to create it.”