What if I told you that the best method for a delivery of any SAP project is: “Be good for your team, hear their voice, and let them feel the joy of contribution.
"Protect them so they have the right environment to deliver, be their mate, and help them hustle by fostering good practices and removing obstacles. Provide visibility of the progress all around and then… you will get the project done.”
Does it sound a little bit too simple or even naïve? The above sentences are a very brief and plain description of how Scrum works.
In this post, I am going to show you a blend of four benefits of Scrum, turning the above statement into reality. I will write the ideas here in a way that is different from what is in the Scrum Guide and ACT 200 training about agility in SAP Activate. Note that Scrum is just a method—some pieces of advice—and it will work only if deployed in a wise way. It is like the magic wands from the Harry Potter series. If you know how to cast the spell, it will work!
Let’s name the four benefits. Two of them address the team, one of them applies to individuals in the team, and another one concerns all external stakeholders and overall project control:
- Benefit No. 1: A solid organizational framework for dynamic and remote teams
- Benefit No. 2: Scrum brings joy at work: it is fair, human-friendly, and inclusive
- Benefit No. 3: A protecting shield for the team
- Benefit No. 4: Good visibility among all stakeholders
Finally, I will wrap up: Scrum and SAP Activate fit into any other project management methodology.
Just one remark: Scrum usually comes along with many agile techniques and tools, but in this post I’m writing just about Scrum, meaning only about the stuff from the Scrum Guide. I will write about agile techniques and tools another time.
Solid Organizational and Communication Frameworks
This benefit provides a very good universal, intuitive, and well-known work concept for a team.
I am going to start presenting the benefits with something quite obvious: Scrum is quite well-known. Even if there are many misconceptions around it, this popularity is a value itself. It gives, shall we say, a common and universal language of team collaboration.
SAP projects are no longer as stable and simple as in the past: with just one vendor and just one customer. Usually there are much more complex organizations, for example: a headquarters and local sites, core team and some other teams, off-shore and near-shore, several outsourcing parties making some part of the business processes and some maintaining all or pieces of IT landscape, etc. Scrum is quite well known among all of these teams.
Of course, beside specific Scrum terminology we may use some other terms like “blueprint” or “specification.” This example will relate to the “backlog,” making the project easier for all, including ERP and SAP-agnostic people. This will work very well and your SAP project can be understood very quickly by people all around.
Now to the second aspect and the main benefit of this benefit: Scrum gives a very good organizational framework for a team. This means the right pace, defined in the form of regular cycles (called sprints) with a defined template of communication activities.
My favorite cycle is a weekly one as this fits well into the common weekly work/life balance and rhythm. This helps team members maintain a very good mood; even if they fail at some tasks they get a kind of absolution and reflection to improve during the next cycle.
The recommended cycle is usually two to three weeks but I have recently found that the Scrum founders say that a weekly pace is good, as it gives better control over job progress with a limited amount of interim documentation within the cycle.
While the framework is focused on the team, communication in Scrum is focused on material progress or delivery. Scrum is about the way of communication and collaboration: internally within the team, and externally as a tool of communication and collaboration with stakeholders.
As a bonus, I have found that Scrum is a very good framework for all remote work. This makes it particularly attractive during the work from home era that we’ve been living in the past year.
Bringing Joy to Work
This benefit gives a tool to gain the engagement of people and to ignite their passion to work better.
This is my favorite benefit: the organizational framework brought by Scrum is fair and inclusive. The main focus is on the team, and all team members have equal rights and the right and obligation, even, to speak up. This is done on purpose, as within the team all individuals are leveraged to be efficient and have space to contribute. Efficiency and delivery comes as a result. In Scrum this inclusion is by definition and this is maybe the main reason for many of the misconceptions of Scrum as this is, in fact, a turn from the classic “command & control” style.
It is obvious that within SAP projects this kind of approach is of great importance, as all consultants and developers bear a solid knowledge about business and best practices. Sharing good news about the best practices is a vital component of an implementation process. All people, including business representatives, who are engaged and passionate about their work, can really create the best business solution.
The way in which Scrum addresses this makes a very good environment, leveraging the idea that all people feel responsible and are motivated and challenged to deliver.
Taking it from a different angle, having all of these team members engaged, we get a strong remedy from discontent and alienation, which are common issues in IT. Note that Scrum gives it institutionally, but how we manage to use this benefit depends on us.
Scrum is democratic, making people decide to some extent about their areas and tasks. It’s worth noting, however, that considering large project scope, only the product owner is empowered to make any changes. In this way it leverages knowledge sharing for the sake of the best possible approach, but still keeps accountability clear.
While we are touching on personal management, it is necessary to mention here that Scrum gives “only” a framework to be used. This means that the charge of personal management techniques is obvious and necessary. These are not components of Scrum. These are activities such as:
- Forming the team and re-forming after every change of organization in dynamical environments
- Justifying the performance, awarding over-performance, and mentoring in case of underperformance.
As touched upon in benefit number one, the organization of work into regular sprints is very human friendly. If people fail during one sprint, this approach helps them deal with it in the right way. Those who fail get a retrospective view at the end of the cycle, and can break for the weekend (or longer, in the case of two- or three-week sprints) and regain energy and motivation before the next cycle.
Protecting the Team
This benefit provides a shield to protect the team against external interference during the cycle.
This is a kind of a hidden gem in Scrum and a lot of people miss it when reading the Scrum Guide. This is because the Scrum Guide is very succinct, counting just 14 pages in the most recent version, thus apparently making it a good ground for misconception.
Many of us treat methodologies as a prescription while Scrum only defines a way and mindset. This is one of the main mistakes that people make when disparaging Scrum: to say that if Scrum is open and provokes changes to the project scope, these may happen at any time. This is wrong—changes are welcome but are allowed only between cycles. This protection for the team’s sprint work is a clear consequence of the Scrum Guide. This encourages members to be responsible and deliver efficiently.
Today this protection is even more important than many years ago: chaotic and random requests towards the team and individual team members are popular distractors nowadays. Many people around the project feel empowered to dictate project priorities and request status reporting. This may have a devastating result on work efficiency and mood within the team, and eventually can badly impact the delivery. Together with micromanagement it may lead to even bigger trouble. And reading about loud, publicly known failures, we can see results of this bad behavior.
Any external interference into the work of the team within the cycle shall be avoided. This is the Scrum master’s duty. Scrum defines it clearly—planning and setting of priorities may happen only at the initiation of a cycle, and reporting of the status to external stakeholders (as a part of review) may happen only at the end. For projects with high demand on reporting, I would again advise the weekly cycle.
This protection does a very good job at insulating the team and each team member, creating a good mood and also giving the right environment for delivery.
A completely different story is how to organize the work of people who are assigned to the project only part-time. This is especially true for maintenance consultants working in competence centers and being requested for priority incidents. There are techniques for dealing with this that keep the protection working.
This benefit gives all the stakeholders around a project the right view of the project.
Every project needs visibility and the right status control. That is obvious and works for SAP projects as well. All known standards, like those defined by PMI, define regular and irregular monitoring and inspection activities. This is also an obvious practice demanded by the management and helps to keep the project on the right course with the right pace of delivery. In this sense, Scrum gives conformity to the PMI standard like SAP Activate does.
The thing is that we can see projects all around loaded with many status meetings. Moreover, often there are random, or even sudden and chaotic requests to the team or team members. We know from the previous point this may be detrimental. The protecting shield helps with this from the team’s perspective, but what about the other side—overall visibility?
Scrum defines it very clearly as “a must” - let me quote from the Scrum Guide (2020 version):
“The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.”
The point for control for external stakeholders is located at the end of the sprint in the form of the review.
The rhythm of sprints shall reflect the cadence of a project, giving the right control and allowing inspection in a way that protects it from damaging micromanagement and chaotic random queries. That should be fully sufficient, and if there was high demand of status reporting, the right pace may be weekly sprints.
The other thing is internal monitoring within the team and this happens every day in the form of daily stand-ups. The important thing is that it goes in a friendly and helpful way, fostering people to perform and removing impediments from their road.
It makes a lot of sense to know SAP Activate, as it is the optimal method for any SAP-based project. Additionally, Scrum and SAP Activate can fit into any other project management methodology, into any proprietary method. While writing about SAP Activate I am conscious that nowadays almost all organizations have their own project management methods. However, at least based on my observation, these are very similar to SAP Activate and its Scrum-based toolset.