Scrum in der Softwareentwicklung: agil und strukturiert

Scrum ist ein agiles Framework für die Entwicklung komplexer Produkte. Es setzt auf Transparenz, regelmäßige Überprüfung, Anpassung und die Selbstorganisation des Scrum Teams. Für die Anwendung gibt es den offiziellen Scrum Guide, der Rollen beziehungsweise Verantwortlichkeiten, Ereignisse und Artefakte beschreibt.

Obwohl viele Personen Scrum als agile Entwicklungsmethode bezeichnen, handelt es sich eigentlich nicht um eine Methode, sondern um ein „Framework“. Das Scrum Framework wird vor allem in der Produktentwicklung eingesetzt, kann aber auch in anderen komplexen Arbeitsumfeldern genutzt werden. Die Entwicklung wird nach Scrum in Iterationen organisiert, den Sprints. Die Sprints geben dem Team durch ihre gleichmäßige Länge einen Rhythmus.

Nach dem Scrum Guide besteht ein Scrum Team aus drei Verantwortlichkeiten: 

Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren und das Product Backlog zu ordnen

Scrum Master unterstützt das Team dabei, Scrum wirksam anzuwenden, Hindernisse zu beseitigen und die Zusammenarbeit kontinuierlich zu verbessern

Developers setzen die Anforderungen um und erstellen in jedem Sprint ein nutzbares Increment

Bei Projektron haben wir diese Verantwortlichkeiten für unsere Multi-Team-Produktentwicklung erweitert. Heute arbeiten fünf Scrum Teams an BCS. Das Product Backlog Management wird durch mehrere Domain Product Owner unterstützt, die fachliche Produktbereiche verantworten und ihre Expertise aus der Organisation einbringen. Die Gesamtverantwortung für Produktstrategie, Priorisierung, Release-Ziele und zentrale Standards liegt beim Chief Product Owner.

Wichtig ist dabei: Die Domain Product Owner ersetzen den Chief Product Owner nicht. Sie übernehmen delegierte Verantwortung innerhalb definierter Leitplanken, zum Beispiel bei der Vorbereitung von Anforderungen, der fachlichen Priorisierung innerhalb ihrer Domäne und der Verwendung zugesagter Story-Point-Budgets pro Release.

Scrum Teams sollten klein genug sein, um handlungsfähig zu bleiben, und groß genug, um alle notwendigen Kompetenzen für die Produktentwicklung abzudecken. Zu große Teams erhöhen den Kommunikations- und Koordinationsaufwand. Bei Projektron war genau das ein Grund, die Entwicklung 2025 von drei auf fünf kleinere Scrum Teams aufzuteilen: Die Teams können sich dadurch leichter organisieren, Abstimmungen reduzieren und fokussierter an ihren Themen arbeiten.

Jede Person, die nach dem Framework nicht Mitglied des Scrum-Teams ist, aber ein Interesse an der Entwicklung des Produkts hat, wird als Stakeholder bezeichnet. Stakeholder nehmen am Scrum-Prozess in unterschiedlicher Weise Teil, sind aber nicht Teil des Scrum-Teams. Beispiele für Stakeholder sind Kunden, Benutzer oder das Management.

Es gibt wiederkehrende Aktivitäten, die als regelmäßige Termine angesetzt werden. Sie geben dem Team einen festen Rhythmus und schaffen Transparenz:

Der Sprint ist ein fest definiertes Zeitintervall von maximal einem Monat, in dem das Scrum Team an einem gemeinsamen Sprint-Ziel arbeitet. Bei Projektron arbeiten die Scrum Teams heute in dreiwöchigen Sprints. Früher waren unsere Sprints zwei Wochen lang; mit der Einführung des fünften Teams haben wir die Sprint-Dauer verlängert, um mehr Raum für zusammenhängende Entwicklungsarbeit, Abstimmung und Review-Zyklen zu schaffen.

Eine Besonderheit unseres Projektron-Scrums ist der rotierende Zwischensprint. Zu jedem Zeitpunkt übernimmt ein Team gebündelt operative und vorbereitende Aufgaben wie Support, Bugfixing, interne Verbesserungen und die Vorbereitung kommender Sprints. Die übrigen Teams können dadurch stabiler an ihren Sprint-Zielen arbeiten. Diese Rotation sorgt dafür, dass ungeplante Arbeit nicht alle Teams gleichzeitig unterbricht und die Verantwortung fair verteilt bleibt.

Jeder Sprint beginnt mit dem Sprint Planning. In diesem Termin klärt das Scrum Team, welches Sprint-Ziel erreicht werden soll und welche Product-Backlog-Einträge dafür ausgewählt werden. Die Developers besprechen außerdem, wie sie die Arbeit im Sprint umsetzen wollen.

Während des Sprints findet täglich der Daily Scrum statt. Dieses kurze Meeting dient dazu, den Fortschritt in Richtung Sprint-Ziel zu überprüfen, die nächsten Schritte abzustimmen und Hindernisse sichtbar zu machen.

Am Ende des Sprints findet das Sprint Review statt. Dort wird das entstandene Increment gemeinsam mit relevanten Stakeholdern betrachtet. Ziel ist nicht nur die Präsentation fertiger Arbeit, sondern auch Feedback, fachliche Einordnung und gegebenenfalls die Anpassung des Product Backlogs.

Anschließend folgt die Retrospektive. In ihr reflektiert das Scrum Team die Zusammenarbeit, die Prozesse und mögliche Verbesserungen für den nächsten Sprint. Während es im Sprint Review vor allem um das Produkt geht, steht in der Retrospektive die Arbeitsweise des Teams im Mittelpunkt.

Neben den Verantwortlichkeiten und Ereignissen gibt es in Scrum drei Artefakte, die Transparenz über Arbeit, Zielsetzung und Fortschritt schaffen:

Das Product Backlog ist die Gesamtliste aller User Storys, Anforderungen, Verbesserungen und Aufgaben, die für das Produkt realisiert werden sollen. Die Liste wird ständig weiterentwickelt und enthält nach Priorität geordnet alle Aufgaben, an denen das Scrum Team arbeiten wird.

Das Sprint Backlog enthält das Sprint-Ziel, die für den Sprint ausgewählten Product-Backlog-Einträge und den Plan der Developers zur Umsetzung.

Das Inkrement (englisch: Increment) ist ein potenziell auslieferbares Teilergebnis oder Produkt, das die Definition of Done erfüllt. Die Entscheidung darüber, ob das Inkrement ausgeliefert wird oder nicht, liegt im Ermessen des Product Owner.

Basis für die Abnahme der User Storys am Ende des Sprints in der Demo ist die Definition of Done (DoD). Es müssen alle Punkte der Definition of Done erfüllt sein, damit eine User Story fertig ist, also vollständig und releasefähig implementiert. Zur Sprint Demo ist es nur erlaubt, fertige User Storys zu präsentieren.

Bei Projektron wurde die Qualitätssicherung im Laufe der Zeit deutlich stärker standardisiert. Früher wurden User Storys und Tickets nicht immer einheitlich bearbeitet, getestet oder abgenommen. Dadurch konnten Anforderungen über mehrere Releases hinweg verschoben werden, und nicht immer war klar, ob eine zugesagte Umsetzung tatsächlich rechtzeitig und vollständig abgeschlossen wurde. Heute sorgen klarere Standards, definierte Abnahmeprozesse, ein Nacharbeitenprozess sowie eine verbindlichere Release-Planung dafür, dass Anforderungen nachvollziehbarer durch den Entwicklungsprozess laufen.

Wir fassten den Entschluss, Scrum einzuführen, um die Zufriedenheit in der Entwicklung zu erhöhen und unsere Produktentwicklung verlässlicher zu strukturieren. Im Dezember 2009 etablierten wir Scrum in der Softwareentwicklung bei Projektron. Im Gegensatz zu vielen Unternehmen, die Scrum vor allem einführen, um agiler zu werden, stand bei uns von Anfang an ein anderer Aspekt im Vordergrund: Wir wollten strukturierter, planbarer und transparenter arbeiten.

Die Notwendigkeit dazu ergab sich aus der zuvor herrschenden unstrukturierten Vorgehensweise: Die Kundenbetreuer ersuchten Entwickler ihrer Wahl wann immer es ihnen beliebte und baten sie, Anforderungen ihrer Kunden und Supporttickets schnell umzusetzen. Vertriebsmitarbeiter versprachen im Kundengespräch vor Ort Anpassungen an der Software, die Entwickler nun schnell ins nächste Release bringen mussten. Kundenbeschwerden wurden überhastet in Anpassungswünsche übersetzt.

Auf diese Weise war oft nicht klar,

• was das nächste Release enthalten sollte,
• ob kurzfristig noch weitere Umsetzungswünsche eintrudelten,
• wie lange es noch dauern würde, bis das Release erfolgen konnte,
• welche weiteren Anforderungen (außer der des konkreten Kunden) die Erweiterung auch zu erfüllen hat und
• wie die Anpassung oder Erweiterung getestet werden soll

Es existierte zum Zeitpunkt der Einführung von Scrum noch kein Prozess, der sicher gestellt hätte, dass sämtliche neue Softwareerweiterungen in die Dokumentation aufgenommen werden und der Kunde davon erfährt.

Auch später, als wir bereits mit drei Scrum-Teams arbeiteten, zeigte sich: Scrum allein löst nicht automatisch alle Strukturprobleme. Bis einschließlich 2024 gab es weiterhin Bereiche, in denen unsere Prozesse zu wenig verbindlich waren. Domain Product Owner waren nicht immer ausreichend eingearbeitet, dokumentierte Standards fehlten teilweise, und User Storys oder Tickets wurden nicht durchgängig einheitlich bearbeitet, getestet und abgenommen.

Dadurch entstanden wiederkehrende Probleme in der Release-Planung:

• Zugesagte Umsetzungen konnten nicht immer zuverlässig eingehalten werden.
• Releases erschienen teilweise später als geplant .
• der inhaltliche Zuschnitt einzelner Releases war nicht immer rund.
• Anforderungen wurden von Release zu Release verschoben, teilweise über längere Zeiträume.
• Domain Product Owner wussten nicht immer, wann ihre User Storys umgesetzt würden.
• Manche Tickets wurden geschätzt, aber anschließend nicht konsequent weiterverfolgt.
• Andere Anforderungen wurden formuliert, aber nicht umgesetzt, sodass Aufwand entstand, ohne dass daraus zuverlässig Produktwert wurde.

Diese Erfahrungen waren ein wesentlicher Auslöser für die Weiterentwicklung unseres heutigen Scrum-Modells. Der Grundgedanke, strukturierter, planbarer und transparenter arbeiten zu wollen, prägt unser Scrum-Modell bis heute. Mit wachsendem Produktumfang, steigender Kundenzahl und inzwischen fünf Scrum-Teams wurde Scrum bei Projektron kontinuierlich weiterentwickelt. Ziel war dabei nie, Scrum zu ersetzen, sondern seine Prinzipien so anzuwenden, dass sie zu unserer Produktentwicklung, unserer Release-Planung und unserer Organisation passen. Wir brauchten klarere Standards, verbindlichere Prozesse, eine bessere Release-Steuerung und mehr Transparenz darüber, wann welche Anforderungen umgesetzt werden.

Heute arbeiten bei Projektron fünf Scrum-Teams an der Weiterentwicklung von BCS. Diese Struktur wurde 2025 eingeführt, nachdem wir zuvor mit drei Teams gearbeitet hatten. Ziel der Aufteilung war es, kleinere Teams zu schaffen, die sich leichter selbst organisieren, Abstimmungen reduzieren und fokussierter an ihren Themen arbeiten können.

Jedes Team besteht aus ca. sechs Personen und arbeitet in dreiwöchigen Sprints. Mit der Einführung des fünften Teams wurde die Sprint-Dauer bewusst von zwei auf drei Wochen verlängert. Die längeren Sprints geben den Teams mehr Raum für zusammenhängende Entwicklungsarbeit, Abstimmung und Review. Gleichzeitig reduzieren sie den relativen Aufwand, der durch häufige Sprintwechsel entsteht. Zudem sorgen die längeren Sprints für eine bessere Qualitätssicherungsphase innerhalb des Sprints, wenn weitere Testkapazitäten verfügbar sind.

Die Teams arbeiten weiterhin zeitlich versetzt. Dadurch entstehen weniger Lastspitzen bei Sprint Planning, Sprint Review, Abstimmungen und weiteren gemeinsamen Terminen. Wichtige Rollen wie Scrum Master, Domain Product Owner und der Chief Product Owner können so besser über mehrere Teams hinweg eingebunden werden.

Eine Besonderheit unseres Modells ist der rotierende Zwischensprint. Zu jedem Zeitpunkt übernimmt ein Team gebündelt operative und vorbereitende Aufgaben wie Support, Bugfixing, interne Verbesserungen und die Vorbereitung kommender Sprints. Die übrigen Teams können dadurch stabiler an ihren Sprint-Zielen arbeiten. Die Rotation sorgt dafür, dass diese Verantwortung fair verteilt bleibt.

Seit der Einführung von Scrum im Dezember 2009 haben wir unser Vorgehen kontinuierlich weiterentwickelt. Projektron Scrum ist heute kein einmalig eingeführter Prozess mehr, sondern ein gewachsenes Modell für die Produktentwicklung mit mehreren Teams. Dabei übernehmen wir Scrum nicht nach einer starren Schablone, sondern passen seine Anwendung dort an, wo unser Produkt, unsere Organisation und unsere Release-Struktur zusätzliche Klarheit erfordern.

Wichtige Anpassungen unseres heutigen Scrum-Modells sind:

Diese Anpassungen bedeuten nicht, dass wir Scrum ersetzen. Sie schaffen vielmehr Rahmenbedingungen, unter denen Scrum-Prinzipien wie Transparenz, Fokus, Überprüfung und Anpassung auch in einer Produktentwicklung mit mehreren Teams wirksam bleiben. 

Nicht jede unserer früheren Anpassungen hat sich dauerhaft bewährt. Einige frühere Experimente haben wir wieder abgeschafft, weil sie für unsere Anforderungen nicht praxistauglich genug waren. Diese regelmäßige Überprüfung gehört für uns zum Scrum-Verständnis: Auch der eigene Prozess muss inspiziert und angepasst werden. Unser Vorgehen basiert weiterhin auf empirischer Steuerung: Wir machen Arbeit, Fortschritt und Probleme transparent, überprüfen regelmäßig, ob unsere Prozesse wirksam sind, und passen sie an, wenn sie nicht mehr zu unserem Kontext passen.

Herausforderungen unseres Scrum-Modells

Unser Scrum-Modell schafft mehr Struktur, bringt aber auch zusätzliche Anforderungen mit sich. Insbesondere in einem Multi-Team-Setup müssen unterschiedliche Arbeitsmodi aktiv zusammengeführt werden: reguläre Feature-Teams, rotierender Zwischensprint, spezialisiertes Team sowie mehrere Domain Product Owner folgen nicht alle denselben Routinen.

Ein zentraler Trade-off besteht in der Balance zwischen Autonomie und Gesamtsteuerung. Domain Product Owner benötigen ausreichend Entscheidungsspielraum, um ihre fachliche Expertise wirksam einzubringen. Gleichzeitig muss sichergestellt werden, dass ihre Prioritäten zur übergreifenden Produktstrategie, zu Release-Zielen und zu verfügbaren Kapazitäten passen.

Auch die Prozessdisziplin wird wichtiger. Klare Standards, ein definierter DPO-Prozess sowie verbindliche Regeln für User Storys, Abnahmen und Nacharbeiten schaffen Verlässlichkeit, müssen aber regelmäßig überprüft werden, um nicht zu unnötiger Bürokratie zu führen.

Die zusätzliche Komplexität verschwindet nicht, sondern sie wird bewusst sichtbar gemacht und gesteuert. BCS unterstützt uns dabei, Anforderungen, Budgets, Zuständigkeiten und Prozesse transparent abzubilden und so die Koordination beherrschbar zu halten.

Wann eignet sich unser Scrum-Modell?

Unser Ansatz ist besonders geeignet für Organisationen, in denen mehrere Teams an einem gemeinsamen, fachlich breiten Produkt arbeiten und sowohl geplante Produktentwicklung als auch ungeplante operative Arbeit kontinuierlich bewältigt werden müssen.

Weniger geeignet ist dieses Modell für kleinere Organisationen oder Produkte mit geringer Komplexität. Wenn ein einzelnes Scrum Team mit einem Product Owner ausreicht, würde unser Ansatz unnötige Struktur und Koordinationsaufwand erzeugen.

Wie bei Scrum generell gilt: Der Kontext entscheidet.

Ein wichtiger Bestandteil ist die Abbildung unserer Standards und Prozesse. Der DPO-Prozess ist in BPMN modelliert und beschreibt, wann welche Schritte notwendig sind, welche Entscheidungen getroffen werden müssen und welche Beteiligten einzubinden sind. Einzelne Prozessschritte wurden inzwischen automatisiert.

So entsteht eine besondere Rückkopplung: Wir nutzen BCS zur Koordination unserer eigenen Produktentwicklung. Gleichzeitig fließen die Erfahrungen aus unserer Scrum-Praxis wieder in die Weiterentwicklung von BCS ein. Unsere Software wird dadurch nicht nur für Scrum genutzt, sondern entwickelt sich mit unserem Scrum-Modell weiter.

Insgesamt erweist sich Scrum in unserer Softwareentwicklung als flexibles und wirksames Framework, um ein hochwertiges Softwareprodukt wie BCS kontinuierlich weiterzuentwickeln. Für uns liegt der größte Nutzen jedoch nicht allein in Agilität, sondern in der Verbindung von Anpassungsfähigkeit und Struktur.

Heute liegt unser Fokus nicht mehr darauf, Scrum einfach auf weitere Teams auszuweiten. Stattdessen entwickeln wir unser Scrum-Modell gezielt weiter: mit klareren Standards, verbindlicherer Release-Planung, besserer Unterstützung der Domain Product Owner und einer stärkeren Abbildung unserer Prozesse in BCS.

Unsere eigene Arbeitsweise wirkt damit direkt auf unser Produkt zurück. Was wir in der skalierten Scrum-Praxis benötigen, fließt in die Weiterentwicklung von BCS ein. So entwickeln sich Produkt und Vorgehensweise gemeinsam weiter.