BLOG / COMPANY

S eit Mitte vorigen Jahres sind wir bestrebt, Scrum als agile Entwicklungs­methodik einzusetzen. Unsere Entscheidung basiert auf der Einsicht, dass unser bisher verfolgter Ansatz bei der Software-Entwicklung den anspruchs­vollen Erfor­dernissen eines sich schnell verändernden Marktes immer weniger gerecht wurde.

SCRUM-ENTWICKLER-TEAM: EINFÜHRUNG

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

Bisher hatten wir vorherige Analysen und Aufwands­schätzungen (in Zeitein­heiten) vorgenommen, um die Umsetzung von Kunden­anfragen einzuplanen und anschließend bearbeiten zu können. Diese Herangehens­weise ist im Scientific Management¹, das sich in der ersten Hälfte des vorigen Jahrhun­derts etabliert hat, durchaus üblich und für viele wirtschaft­liche Prozesse auch gut geeignet – dabei sind jedoch Planung und Umsetzung oft prozessual, personell und zeitlich entkoppelt, was unmittel­bares Reagieren auf Änderungen der Anfor­derungen stark erschwert.

Weiter werden dadurch grund­sätzliche Unwägbar­keiten komplexer Systeme (etwa umfang­reiche Software oder IT-Land­schaften) eher schlecht adressiert. Abhilfe kann hier der Einsatz von Scrum schaffen, wobei unser Ziel eine konsequente Orien­tierung am Scrum Guide² ist.

1. INTERDISZIPLINA­RI­TÄT NACH SCRUM GUIDE

Angestrebt nach Scrum Guide ist ein interdiszi­plinär aufgestelltes Team. Das Scrum-Entwickler-Team soll befähigt werden, in jedem Sprint einen wert­schöpfenden Beitrag zum Produkt erbringen zu können. Dazu ist es nötig, eine aus­reichende thematische Breite im Team vertreten zu haben, damit die umzu­setzenden Aufgaben möglichst unab­hängig von den anderen Teams bear­beitet werden können.

Deswegen wird also auf eine weitge­hen­de informa­tionelle Autonomie der Entwick­lungsteams abgezielt. Dennoch muss das Team klein genug sein, um eng zusammen­arbeiten zu können, ohne dass ein zu großer Koordi­nations­aufwand entsteht. Die Verpflich­tung auf ein Sprint-Ziel soll sicher­stellen, dass wert­schöpfende Arbeit im Sinne aller Stakeholder hochprio­risiert verfolgt wird; die Interessen aller Stakeholder sollen in einem Scrum-Team vert­reten sein, um von diesem gewahrt werden zu können.

2. INTERDISZIPLINA­RI­TÄT IM SCRUM-ENT­WICK­LER-TEAM BEI FLS

Zur Schaffung der Teams haben wir unsere bishe­rigen Ent­wick­lungsteams, die komponenten­orientiert zusammen­gestellt waren, neu aufge­teilt. Zur Maxi­mierung der Inter­diszi­plina­rität haben wir die Auf­teilung dabei so vorge­nommen, dass in jedem Scrum-Entwickler-Team eine möglichst große Breite an tech­nischen Fähig­keiten und komponen­tenspezi­fischer Erfahrung in der Entwick­lung des Produkts vorhanden ist.

Insbesondere haben wir dafür gesorgt, dass in jedem Team genug Wissen über unsere mobilen Anwen­dungen, Web-Anwen­dungen, Server-Kompo­nenten sowie unsere PowerOpt-Techno­logie vorhanden ist. Die Interessen der Kund*innen sind insofern im Team vertre­ten, als die Product Owner*innen das Produkt in deren Sinne voran­treiben.

3. VERANTWORTLICHKEIT NACH SCRUM GUIDE

Im Scrum Guide wird zwischen zwei Arten der Verant­wort­lich­keit unter­schieden, die relativ klar von­einander abgegrenzt sind.

• Responsibility – dies ist die Verant­wortung für die Durch­führung aller produkt­bezogenen Aktivi­täten (u. A. Entwicklung, Qualitäts­sicherung, Wartung, Betrieb und Forschung). Diese Verantwort­lichkeit bezieht sich also auf die Durchfüh­rung³ bestimmter, nötiger und vorher identifizier­barer Tätig­keiten.

• Accountability – dies ist die Verant­wor­tung für ziel­führendes Handeln, damit in jedem Sprint ein echter Wert für das Produkt geschaf­fen wird. Diese Verant­wortung bezieht sich also auf das Verfolgen (und Erreichen⁴) bestimmter Ziele. Um beide wahrnehmen zu können, soll das Team in seinem Handeln selbst­bestimmt sein.

4. VERANTWORTLICHKEIT IN DEN SCRUM-ENT­WICK­LER-TEAMS BEI FLS

Die Scrum-Entwickler-Teams sind so aufge­stellt, dass grund­sätz­lich beide oben genannten Verant­wortlich­keiten wahrge­nommen werden. Um die Aufgaben innerhalb der Responsi­bility wahrzu­nehmen, sind in den Scrum-Teams Software-Entwick­ler*innen sowohl für unmittel­bare Implemen­tierungs­aufgaben als auch explizit für die Quali­täts­sicherung und automati­sierte Tests vertreten.

Dieses Fachwissen wird durch Ex­pert*innen für Quali­tätssiche­rung ergänzt. Die Verant­wortung für den Betrieb der Software und die Durch­führung der zuge­hörigen Aufgaben liegt bisher nicht bei den Scrum-Teams; stattdessen werden sie von einem separaten DevOps-Team⁵ wahrge­nommen. Mittel­fristig wird aber angestrebt, auch diese Verant­wortung durch die Teams wahrnehmen zu lassen.

5. ÜBERGANG VON BISHE­RI­GER ENT­WICK­LUNGS­ME­THO­DIK ZU SCRUM

Wie eingangs erwähnt, haben wir zunächst struk­turelle Probleme innerhalb des Entwicklungs­prozesses ausfindig gemacht. Unsere bisherigen Aufwands­schätzungen waren oft unzuver­lässig. Der Grund dafür waren Änderungen der Anfor­derungen während der Entwick­lung, ferner Fehl­urteile über die tech­nischen Risiken.

Dies wurde durch kontinuier­liche Weiter­entwicklung unserer Code-Basis noch ungünstig verstärkt, da die während der Planung vorhan­denen Voraus­setzungen bei der erst etwas später stattfin­denden Umsetzung gelegentlich gar nicht mehr gegeben waren. Dadurch wurde insgesamt das Risiko, das unmittel­bare Verständnis für den Bedarf der Kund*innen zu verlieren, immer größer, was wir schon in der Einlei­tung kurz angerissen haben.

6. EIN KOMPLETTER STRUKTURWANDEL

Bei der Einführung von Scrum wurden wir von der codecentric AG beraten und bei der Umsetzung unter­stützt. Wir haben durch einen kompletten (zuerst nur entwick­lungs­internen) Struktur­wandel cross-funktionale⁶ Teams gebildet und eine konsequente und ständige Priori­sierung des Backlogs durch die Product-Owner*innen sicher­gestellt. Dazu wurden mit signifi­kantem Aufwand die bisherigen, teilweise nur relativ unsyste­matisch erfassten Anfor­derungen revidiert.

Danach wurden diese analysiert und in ein für die agile Entwicklung geeig­netes Format gebracht, das unter anderem explizite Akzeptanz­kriterien enthält.