BLOG / COMPANY

SCRUM@FLS – DEEP DIVE IN DAS SCRUM-ENTWICKLER-TEAM


KONTAKT ›
S eit Mitte letzten Jahres sind wir bestrebt, Scrum1 als agile Entwicklungsmethodik einzusetzen. Unsere Entscheidung basiert auf der Einsicht, dass unser bisher verfolgter Ansatz bei der Software-Entwicklung den anspruchsvollen Erfordernissen eines sich schnell verändernden Marktes immer weniger gerecht wurde.

EINFÜHRUNG

Dieser Blog-Artikel steht im Kontext früherer Beiträge, bei denen wir zunächst die Rolle der Product-Owner*innen2 und später die Rolle der Scrum-Master*innen3 beleuchtet haben. In diesem Artikel wollen wir die Rolle der Entwicklungs-Teams darstellen. Die Rolle der Entwickler*innen ist bei uns in der Produktentwicklung zahlenmäßig am stärksten vertreten und ihre Arbeit wirkt sich am unmittelbarsten auf die Produkte aus.

Bisher hatten wir vorherige Analysen und Aufwandsschätzungen (in Zeiteinheiten) vorgenommen, um die Umsetzung von Kundenanfragen einzuplanen und anschließend bearbeiten zu können. Diese Herangehensweise ist im Scientific Management4, das sich in der ersten Hälfte des vorigen Jahrhunderts etabliert hat, durchaus üblich und für viele wirtschaftliche Prozesse auch gut geeignet – dabei sind jedoch Planung und Umsetzung oft prozessual, personell und zeitlich entkoppelt, was unmittelbares Reagieren auf Änderungen der Anforderungen stark erschwert. Weiter werden dadurch grundsätzliche Unwägbarkeiten komplexer Systeme (etwa umfangreiche Software oder IT-Landschaften) eher schlecht adressiert. Abhilfe kann hier der Einsatz von Scrum schaffen, wobei unser Ziel eine konsequente Orientierung am Scrum Guide5 ist.

1. INTERDISZIPLINARITÄT NACH SCRUM GUIDE

Angestrebt nach Scrum Guide ist ein interdisziplinär aufgestelltes Team. Das Team soll befähigt werden, in jedem Sprint einen wertschöpfenden Beitrag zum Produkt erbringen zu können. Dazu ist es nötig, eine ausreichende thematische Breite im Team vertreten zu haben, damit die umzusetzenden Aufgaben möglichst unabhängig von den anderen Teams bearbeitet werden können. Deswegen wird also auf eine weitgehende informationelle Autonomie der Entwicklungsteams abgezielt. Dennoch muss das Team klein genug sein, um eng zusammenarbeiten zu können, ohne dass ein zu großer Koordinationsaufwand entsteht. Die Verpflichtung auf ein Sprint-Ziel soll sicherstellen, dass wertschöpfende Arbeit im Sinne aller Stakeholder hochpriorisiert verfolgt wird; die Interessen aller Stakeholder sollen in einem Scrum-Team vertreten sein, um von diesem gewahrt werden zu können.

2. INTERDISZIPLINARITÄT BEI FLS

Zur Schaffung der Teams haben wir unsere bisherigen Entwicklungsteams, die komponentenorientiert zusammengestellt waren, neu aufgeteilt. Zur Maximierung der Interdisziplinarität haben wir die Aufteilung dabei so vorgenommen, dass in jedem Scrum-Team eine möglichst große Breite an technischen Fähigkeiten und komponentenspezifischer Erfahrung in der Entwicklung des Produkts vorhanden ist. Insbesondere haben wir dafür gesorgt, dass in jedem Team genug Wissen über unsere mobilen Anwendungen, Web-Anwendungen, Server-Komponenten sowie unsere PowerOpt6-Technologie vorhanden ist. Die Interessen der Kund*innen sind insofern im Team vertreten, als die Product Owner*innen das Produkt in deren Sinne vorantreiben.

3. VERANTWORTLICHKEIT NACH SCRUM GUIDE

Im Scrum Guide wird zwischen zwei Arten der Verantwortlichkeit unterschieden, die relativ klar voneinander abgegrenzt sind.

Responsibility – dies ist die Verantwortung für die Durchführung aller produktbezogenen Aktivitäten (u. A. Entwicklung, Qualitätssicherung, Wartung, Betrieb und Forschung). Diese Verantwortlichkeit bezieht sich also auf die Durchführung7 bestimmter, nötiger und vorher identifizierbarer Tätigkeiten.

Accountability – dies ist die Verantwortung für zielführendes Handeln, damit in jedem Sprint ein echter Wert für das Produkt geschaffen wird. Diese Verantwortung bezieht sich also auf das Verfolgen (und Erreichen8) bestimmter Ziele. Um beide wahrnehmen zu können, soll das Team in seinem Handeln selbstbestimmt sein.

4. VERANTWORTLICHKEIT BEI FLS

Die Teams sind so aufgestellt, dass grundsätzlich beide oben genannten Verantwortlichkeiten wahrgenommen werden. Um die Aufgaben innerhalb der Responsibility wahrzunehmen, sind in den Scrum-Teams Software-Entwickler*innen sowohl für unmittelbare Implementierungsaufgaben als auch explizit für die Qualitätssicherung und automatisierte Tests vertreten. Dieses Fachwissen wird durch Expert*innen für Qualitätssicherung ergänzt. Die Verantwortung für den Betrieb der Software und die Durchführung der zugehörigen Aufgaben liegt bisher nicht bei den Scrum-Teams; stattdessen werden sie von einem separaten DevOps-Team9 wahrgenommen. Mittelfristig wird aber angestrebt, auch diese Verantwortung durch die Teams wahrnehmen zu lassen.

Scrum-Werte: Commitment, Fokus, Mut, Offenheit, Respekt

5. ÜBERGANG VON BISHERIGER ENTWICKLUNGSMETHODIK ZU SCRUM

Wie eingangs erwähnt, haben wir zunächst strukturelle Probleme innerhalb des Entwicklungsprozesses ausfindig gemacht. Unsere bisherigen Aufwandsschätzungen waren oft unzuverlässig. Der Grund dafür waren Änderungen der Anforderungen während der Entwicklung, ferner Fehlurteile über die technischen Risiken. Dies wurde durch kontinuierliche Weiterentwicklung unserer Code-Basis noch ungünstig verstärkt, da die während der Planung vorhandenen Voraussetzungen bei der erst etwas später stattfindenden Umsetzung gelegentlich gar nicht mehr gegeben waren. Dadurch wurde insgesamt das Risiko, das unmittelbare Verständnis für den Bedarf der Kund*innen zu verlieren, immer größer, was wir schon in der Einleitung kurz angerissen haben. Bei der Einführung von Scrum wurden wir von der codecentric AG10 beraten und bei der Umsetzung unterstützt. Wir haben durch einen kompletten (zuerst nur entwicklungsinternen) Strukturwandel cross-funktionale11 Teams gebildet und eine konsequente und ständige Priorisierung des Backlogs durch die Product-Owner*innen sichergestellt. Dazu wurden mit signifikantem Aufwand die bisherigen, teilweise nur relativ unsystematisch erfassten Anforderungen revidiert. Danach wurden diese analysiert und in ein für die agile Entwicklung geeignetes Format gebracht, das unter anderem explizite Akzeptanzkriterien enthält.



FAZIT

Natürlich kam die Entscheidung zur Änderung der Entwicklungsmethodik nicht über Nacht. Anspruchsvollere Kundenprojekte mit höherer Komplexität, sowie ein Wachstum des Unternehmens, waren ausschlaggebende Gründe, unseren Ansatz zu überdenken. Nach einer schrittweisen Einsicht, sind wir dazu übergegangen, konsequent Scrum einzusetzen, diesen Wandel dabei behutsam anzugehen und kontinuierlich zu reflektieren.

WEITERFÜHRENDE LINKS:

Lesen Sie hier Teil 1 der Serie "SCRUM@FLS".

Zur Vorstellung des Product Owners >

Zur Vorstellung des Scrum Masters >

Lust auf neue Herausforderungen? Zu unserem Karriere-Portal geht es hier entlang >.


1 Rolf Dräther et al., Scrum kurz & gut, O’Reilly, 2013

2 https://www.fastleansmart.com/blog/scrumfls-product-ownerin/

3 https://www.fastleansmart.com/blog/aufgaben-einer-scrum-masterin/

4 Frederick W. Taylor: The principles of scientific management, Harper & Brothers, 1911.

5 Ken Schwaber & Jeff Sutherland: Der Scrum Guide – Der gültige Leitfaden für Scrum: Die Spielregeln, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf

6 https://www.fastleansmart.com/technologien/poweropt/#poweropt

7 Im Scrum Guide wird dieser Begriff so erklärt, dass das Team umsetzungsverantwortlich ist.

8 Im Scrum Guide wird dieser Begriff so erklärt, dass das Team ergebnisverantwortlich ist.

9 https://azure.microsoft.com/de-de/overview/what-is-devops/

10 codecentric AG, Hochstraße 11, 42679 Solingen, https://www.codecentric.de/

11 https://www.techdivision.com/leistungen/change-und-organisationsentwicklung/agile-blog/was-ist-ein-cross-funktionales-team.html

DEMO BUCHEN