SAP Masterclass: Agile Development in Practice

Workshop Overview

SAP Masterclass - Agile Development in Practice on Wednesday, May 28 from 13:45 until 18:00 at SAP Berlin

Presenters:

• Dr. Christoph Matthies (Senior Product Specialist, AI Core)
• Ralf Teusner (Senior Researcher)

Disclaimer: These notes represent my personal understanding from the workshop. Any misquotes are under my sole responsibility.

Key Insights

On Certifications and Experience

Yes, there are certifications for Scrum and Agile. Typically, they need to be renewed after a while. They are not totally mandatory, as far as I understand, but can be good to have at the beginning of your career. Also, it is good not to be overly reliant on certificates. Experience and on-the-job experience are, of course, more important, and our workshop leaders today have plenty of it.

Programming vs Software Engineering

Programming is NOT software engineering. Programming is what you might do at home or alone, writing some code and possibly coding an app, but product engineering is about creating a product within a team.

So, what is a developer's role? In a team, you not only code but also, for instance, suggest sensible refactoring, log bugs, and notify the product owner by opening issues. Fight for it. When you see a bug, if you don’t take care of logging and alerting, nobody else might. At least, you cannot count on it.

Developer's Role

• Evaluate and refine requirements
• Suggest sensible refactoring
• Log bugs and notify product owner
• Take ownership of issue tracking

Agile Development

The Agile Manifesto (2001)

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

The manifesto emphasizes "working software over comprehensive documentation." This isn't a dogma but rather guidance - the keyword is "over," not "either/or."

Agile focuses on smaller development iterations. Ideally, this actively involves stakeholders, but this has proven to be sometimes difficult to achieve in reality. Stakeholders mostly expect us to do our job and produce software and are not always happy or have the time to participate actively in the process. We work in small iterations, which allows for the early identification of production issues but needs a high degree of automation.

Scrum and Kanban are foundational ideas.

In Scrum, we have a product backlog, which can initially be unorganized – a bit like a pile of 'to-dos' to be sorted. From this, we create the sprint backlog, and we go into a development iteration, typically lasting one to two weeks, or a maximum of a month. We will have daily stand-ups (or daily scrums), but most importantly, at the end of an iteration, a review and retrospective. This cycle creates a product increment, a piece of working software, through empirical process control: iterating with continuous feedback.

The developer's role here is to evaluate and refine requirements. Product management will push for features, and sometimes developers need to push back if the requirements become unrealistic. Developers are not just "code monkeys" – something to remember, not just machines that turn coffee into code.

At the end of the iteration, we could deploy. This depends. In reality, deployment can be costly because stakeholders might need to get used to new features and designs and may eventually need training. We create a product that is ready to be deployed, but the actual deployment can wait. We do not have to deploy it every single time; frequent releases can be troubling for users.

Drawbacks and Considerations in Agile/Scrum

Some perceive Agile as having drawbacks, such as "no planning," making it difficult to predict when the software will be ready. We do not have a complete upfront design but rather user stories instead of extensive initial requirements. Also, it can sometimes come with a strong, almost dogmatic, ideology.

To be Agile, we need continuous integration and tests. The first person to merge might not have a problem, but what about the second? To help avoid merge conflicts, use draft Pull Requests (PRs); this way, you can see what other developers are working on. A requisite is automated tests, and also dedicated QA people for the user interface. It is helpful to have a human being go through the product and software.

What is the ideal size of a PR? The workshop suggested we don't care too much about the number of commits within it, as a diff ultimately shows what changed. However, it's better for PRs to be as small as possible.

How to check the quality of code? It's humorously suggested to measure it with the "WTF per minute" metric. A good test is to have both an expert and a newbie review it; if the newbie has a low WTF rate per minute, the code might be considered clear. Of course, an expert review is also needed.

Regarding automation and testing: most teams learn its importance "by pain" – they realize how crucial testing is after facing issues.

Team Work in Agile

If a team isn't working as it should because members don't want to work together, then it's often not just a development problem but potentially an HR problem. Agile frameworks don't typically delve into resolving these deep-seated conflicts.

However, it is true that people have different working styles. Ideally, we don't want to involve management for every issue the team faces; it should be a self-organizing team. We also presuppose that developers are eager to work. It is important to come to an agreement. Sometimes a written agreement can be beneficial, for instance, regarding working hours or a daily schedule. Agreeing on certain points is key.

Very important is the "Definition of Done." Team consensus on this is crucial. It's also better to write it down, especially for larger teams, to avoid lengthy discussions later. So, what constitutes "Done"? Deployed? Tested? Reviewed?

In cases of team disagreement, it's not always a democracy. There is often an architect or lead role, a decider, because some decisions can be very costly to change later, and the team cannot go through endless discussions.

Agile vs. Waterfall

Waterfall is often used as a contrast to sell Agile, like a "boogeyman" – if not Agile, then it must be Waterfall. But is this realistic? Did a purely Waterfall project ever truly exist? Usually, we can say Waterfall involves front-loaded processes, which start with some kind of design already in place. This approach is often necessary when building physical structures like ships, bridges, or buildings. Don't we usually start with a template or design derived from something made before? In this sense, it's quite different from much software development. Using Waterfall principles for such projects would certainly be beneficial; you don't build a bridge by iterating on the design and building simultaneously. That would probably be quite dangerous as well.

Core Concepts

• Focuses on smaller development iterations
• Emphasizes stakeholder involvement (though sometimes challenging in practice)
• Requires high degree of automation
• Values working software over extensive documentation
• Uses empirical process control through continuous feedback

Scrum Framework

• Product backlog (initially unorganized "to-dos")
• Sprint backlog for iterations (1-2 weeks, max 1 month)
• Daily stand-ups (scrums)
• Sprint review and retrospective
• Creates product increments through iteration

Kanban

• Suited for just-in-time production
• Focuses on cycle time optimization
• No prescribed iteration length
• Requires experienced team for bottleneck identification
• Promotes "swarm-like" collaboration

Kanban (meaning billboard or signboard in Japanese) is ideally suited for just-in-time production and cycle time optimization. There is no prescribed iteration length like in Scrum, nor are we constantly waiting for feedback in the same structured way. Flow can become constricted by bottlenecks.

Drawbacks of Kanban include requiring a certain level of experience to identify bottlenecks, so the team should ideally be experienced. There's a "swarm-like" behavior where everybody needs to collaborate when a bottleneck introduces a delay.

On Following a Process

When people sometimes say, "We don’t follow a process," it's actually not true. You always follow some process, even if it's informally called "anarchy" or "self-organization"; it's rarely completely given to chance.

Context is Key for Agile

Agile has two sides: the good and the bad. The choice of using Agile is highly context-dependent. For instance, regarding the planning horizon, with Agile, we inherently communicate uncertainty.

Not having a detailed design at the start works best if your developers know what they are doing. Sometimes, you need to refactor existing designs, and in this case, some Agile approaches might seem less suited if not handled carefully. Adopting architectural decisions can be painful because they are hard to change later.

So, Agile has drawbacks. A complete, upfront project plan often doesn't exist. Continuous refinement, while a strength, can also be a drawback if not managed. Regularly talking with your developers via meetings, like those at the end of each sprint (e.g., once a week), plus other meetings, can sometimes feel like a bit much.

Product Management and External Factors

Product management on a large scale is not explicitly part of Scrum or Agile frameworks but is, of course, required. Consider things like GDPR, sanctions (e.g., related to Russia, Iran), external contractors, or someone on leave. Management is needed and will typically take care of these aspects. Scrum aims to provide a protected space for the development team. Product management has its moment to ask questions and provide input, particularly during the sprint review.

Deployment Considerations

• Product should be deployment-ready after each iteration
• Actual deployment timing depends on stakeholder needs
• Consider training requirements
• Balance between readiness and frequency

Challenges and Solutions

• Merge conflict prevention through draft PRs
• Continuous integration and automated testing
• Code quality measurement ("WTF per minute" metric)
• Small, focused PRs preferred
• Balance between planning and flexibility

The Project Management Triangle

• Scope
• Cost
• Time
• Quality (inside the triangle)

A common concept is the project management triangle: Scope, Cost, Time, with Quality often considered constrained or affected by these three. Or, as the saying goes: "Good, Fast, Cheap – Choose Two."

Context and Implementation

Choosing the Right Approach

• Context-dependent decision making
• Consideration of planning horizon
• Team experience level
• Architectural decisions impact
• External factors (GDPR, contractors, etc.)

Team Dynamics

• Team consensus is crucial
• "Definition of Done" must be clearly documented
• Architectural decisions require clear leadership
• Teams should be self-organizing with minimal management intervention
• Written agreements help establish working norms (e.g., working hours, schedules)

Note: While team autonomy is important, significant interpersonal conflicts may require HR intervention as they fall outside the scope of Agile frameworks.

Roles and Responsibilities

The Product Owner owns the Product Backlog.
The Development Team owns the Sprint Backlog.
The Scrum Master coordinates and facilitates. During the sprint, their role is to remove impediments and help with process and people.

Questions and Reflections from the Workshop

A question for reflection: What is our experience working in a group? Scrum, Kanban, or a mix of the two (Scrumban)? If you do a mix, you could, for instance, manage the development iteration within a sprint using Kanban principles, while the rest follows Scrum. This hybrid approach can also work. For velocity-based planning, Agile (specifically Scrum) is often used. To optimize cycle time, Kanban is a strong candidate.

Onboarding Junior Developers

What is the expectation towards a junior developer? The workshop suggested: initially, perhaps "no expectation at all." A junior dev will typically be assigned a buddy and may do pair programming (though not always mandatory). They will usually be assigned tickets that are challenging enough to be interesting. Should they still take tickets from the top of the backlog? Yes, but adapted to their level.

Regarding the performance of individual team members, in Agile, statistics are generally for the team, not for the individual. The emphasis is on learning and improving together with team members. The philosophy is that teams are generally better than individuals working in isolation.

Work as a team. Do not focus on individual performance; otherwise, a measure can become a target (Goodhart's Law). Of course, it needs to be a functional team; if not everyone wants to be part of the team, it becomes an HR matter, which is outside the scope of Agile methodologies themselves. Story points are internal to the team. Managers are typically not privy to individual story points; the team is self-organizing. During dailies and retrospectives, the team can see if there is a problem or if someone consistently struggles with their workload.

From Vision to Tasks

A typical hierarchy for breaking down work can be:

• Vision
• Goals
• Epics (From here, Scrum is usually inserted)
• Features
• User Stories
• Tasks Other considerations include: Priority, Team Structure, and Threats.

A Good Interview Question Example

An example of a good interview question (from the workshop): "Can you tell me a story of how something went wrong in your team and how you (or the team) fixed it?"

Product Owner Exercise Summary

Vision: "We help students write their best code by providing food for brain"

• One-page app hosted on 42 school intranet
• Daily single recipe by dedicated cook
• Vegan/vegetarian options
• Uses saved food plus basic supplies
• Booking system for students
• Cost-covering pricing model with minimal margin
• Supports circular economy and upcycling

To conclude, we did a Product Owner exercise. It's important to understand the other side too: What is the Product Owner's role?

Imagine we have a donor able to spend money upfront to finance warm food on our campus, but long-term, a bit of profit wouldn't be bad. So, our group came up with an idea for an app: a single page hosted on the 42 school intranet. We would have one cook making one recipe a day – a minimal menu, perhaps vegan/vegetarian, using "saved food" (food surplus) plus some regular deliveries for basics. The app would allow logged-in students to book a meal, so we'd know when it's sold out. The price would be set just to cover costs plus a small extra margin.

The focus was on cheap meals. Our Vision: "We help students write their best code by providing food for the brain." We also aimed to support the circular economy and upcycling (acknowledging these are buzzwords).

We only had 10 minutes to discuss this idea, but we got a glimpse of what a Product Owner would do: liaising with stakeholders (like the donor), planning resources (like manpower), and creating a vision for a product.

Resources

http://agilemanifesto.org