Software Development At SAP: The Scrum/Agile Methodology

Software development is considered an industry and as such we have been developing applications the same way other goods are manufactured: creating a CAD drawing of the end product, splitting it into individual components, handing it over to manufacturing and the final assembly line.

In such a process, a lot of effort goes into the design. Every subsequent step considers the design a given. Even in ‘traditional’ manufacturing, this is not ideal. Concepts like Kaizen – continuous improvement cycles – are added to the mix, e.g. if somebody finds that the manufacturing costs can be reduced by moving the bolt, the process will be adapted accordingly. The CAD drawing is changed quickly; however, new molds must be created, and the assembly line must be reconfigured – those are the expensive follow-up costs of a later design change.

Software development is different as moving a UI control essentially costs nothing. This raises the question: Why define the details upfront? “No battle plan survives the first contact with the enemy,” as Graf Helmut von Moltke (Prussian field marshal) would have said.

Same can be said about project plans once they are confronted with reality. Consequently, instead of creating a project plan and the illusion of having everything under control, we rather say we will provide *something* that can be used, but we do not know how it will look like yet.

Actually, the entire setup is upside down. Instead of defining the deliverable and estimate the cost, in an Agile project we assume the costs are a given and deliver a product that works. We do not guarantee it will be as fancy as envisioned, but it will definitely be a product that can be used and delivers value. Not a bad starting point!

Interestingly enough, the actual outcome will be a more complete software in less time. I am going to explain why that is the case with a couple of real-life examples.

Starting a project à la Scrum

The first step is to write up a product vision. A short sentence what the product is about and guidelines to be followed. Example: “We need an alerting system based on S/4 Hana data to proactively inform end users about important states of the business immediately”.

This is not the time for assumptions about how this solution should be built technically. Generally speaking, the less constraints there are, the better. We want to facilitate the knowledge of the dev team and keep them engaged by utilizing their creativity in solving problems.

Work packages are derived from this vision and added to a list called the product backlog: “Somebody needs to check where the data comes from exactly”; “What are the options to capture changes in S/4 Hana with low latency?”; “How should the business user be informed? Through e-mail, maybe?”; “What is the complexity of the formulas for the alerts and who will define those?”

The product backlog is different from a project plan as it contains only those items that are important right now. In our example, these are all research items; later it will be mostly coding. The development team then assigns a timeframe to each item. The cost and the priority define the order of the backlog item list and every developer (or dev team) picks items they feel comfortable with.

This approach has multiple natural fail-safes: If development does not understand one item, it must be revisited. If an item will take months to complete, it is too big to estimate with confidence and needs to be broken up or reduced in scope. If no development team feels qualified to pick an item, there is obviously a problem in the available skillset. If different people estimate the costs differently, it carries an inherent risk.

Every iteration means a new product version

One area where complex development projects fail frequently is putting the individual parts together. I have seen horrible situations in the past: Software products that were impossible to install, UIs from hell, frontend and backend being incompatible. The solution is to release a working product in every iteration, e.g. every two weeks. The important part is to package the product into an installer and deploy it in the test system. Not only does that proof the components work together, but also will the developers know that their features will be demoed in the context of a fresh install, and consequently care about side effects from the beginning.

In our example, in the first iteration the team shows the various options how changes in the S/4 Hana system can be captured, all with the pros and cons and their preferred approach. They can demo how it will work in the test system.

Similarly, in a later stage the other team will show how the formulas for the alerts are entered. Initially just very specific kinds of formulas, but at least they can demo the UI, how the backend stores and executes the alerts. Over the next iterations it is just a matter of enabling more formulas – the bulk of the work.

Thanks to the progress in CI/CD (Continuous Integration/Continuous Delivery) automation, the product packaging is even faster and easier than it was before when we did all of that manually at the end of the development cycle half a year later.

Something interesting will happen

At first glance, the Scrum methodology looks as if the project plan is built on the fly rather than being created upfront, and there is not much difference between the two methods in terms of efficiency. The surprise comes when the final product is more complete than initially anticipated and finished in time. The reason for that is the work environment the Scrum method creates and its focus on “value”.

Example: We have ordered the product backlog together as a team, so it contains the aspect of priority and cost. By asking development to pick the items, they are matched with the available skillsets. Question: What happens when important items that can be completed in less time than others and we have the skills for are completed first? We get a bigger bang for the bucks. Sorry, I meant to say: We achieve a higher ROI in development. More gets done in a shorter amount of time. The unimportant tasks are the ones we might not have completed at the end of the project.

Beware typical pitfalls

Even if Scrum is implemented with good intentions, it can gradually turn into the opposite. Here are a few examples of good-Scrum-turned-bad in real-life projects and what to do about it.

• Motivation. In one project, the product backlog was created and then assigned to development teams. Note, the Scrum method insists the dev team picks backlog items themselves. The consequence of assigning the items was that people were not motivated. How would you feel if a coworker explains a task and asks you to be done by end of next week? You will do your job and occasionally ask for clarifications. But if you pick an item yourself, you feel much more engaged. Also, the person assigning the tasks will quickly be the bottleneck, as the dev team is waiting for their decisions. Neither can happen when you pick and choose yourself as soon as you are finished with an item.
• Scrum simulation. One way to look at Scrum/Agile is to remove all rules imposed on us by the project plan, by following the Scrum rules to the letter. For each iteration, there will be a Sprint planning meeting, an Estimation meeting, Sprint Review and a Retrospective before starting the next iteration. In one project, every round felt identical: “Are you done with the backlog item?” The answer: “No, I need 10 more days because other things were more important.” Follow-up question: “Were there any impediments blocking you?” Answer: “Yes, I was waiting for a decision from management.” And so on. At the surface, the project did follow the Scrum structure, but it failed on adopting the Scrum spirit. Needless to say what the outcome was.
• Blame game. The Sprint review meeting was led by the dev manager and everybody had to defend why they were not done with the item as planned. As consequence, the dev team was reluctant picking items and very conservative on the estimations. No motivation means little progress. Similar things happen when most team members are junior developers.
• Wrong project. When a project consists of linear tasks only – projects where the first item needs to be completed before the next can start – Scrum is not the most suitable method. It would mean to have a single backlog item in every iteration, wouldn’t it? For such projects, a classic waterfall project plan is the better choice.

What is Scrum?

Summarizing the key advantages, if used properly, Scrum is a fantastic method to engage and motivate the software development team. At their core, all Scrum processes center around maximizing ROI. It requires some getting used to, but once the team is up to speed, it increases its speed even further.

This process needs constant monitoring and adjustments by a person with knowledge and experience in the Scrum process – and empathy. Only then can the Scrum method make good on its promises by motivating team members and reducing waste. In short, hire a Scrum master with a proven track record to help with the project. That will be money well spent. (Note: I myself am not a Scrum Master. Would love to get certified but one day only has 24 hours, I’m afraid…)