Wenn man Scrum auf einen einzigen Begriff reduzieren müsste, welcher wäre das?
Diese Frage stellen wir gerne in unseren Trainings. Die Antworten sind unterschiedlich. Hier eine kleine Auswahl:
- Agile Softwareentwicklung
- Teamarbeit
- Spaß an der Arbeit
- Schnellere Ergebnisse
- Sprints
Die Antwort, die wir eigentlich im Sinn haben, ist für viele überraschend:
Das Done Product Increment
Warum ist das wichtig?
Ohne ein Produkt, welches wir entwickeln wollen, ist Scrum unnötig. Wir brauchen kein Team, keine Regeln, keine Zusammenarbeit. Dieses Produkt ist aber nicht das große endgültige Ziel, sondern es wird schrittweise in Sprints von maximal 4 Wochen Länge entwickelt. Am Ende eines jeden Sprints erwarten wir ein Inkrement des Produkts, welches einen Mehrwert darstellt und produktiv eingesetzt werden kann – es muss also „Done“ sein.
Leider legen unserer Erfahrung nach zu wenige Scrum Teams wirklich wert auf diese Idee von Done. Häufig wird das Product Increment am Ende eines Sprints nicht ausgeliefert und das Entwicklungsteam hat deshalb keine echte Motivation, ein Done Increment zu liefern. Das Resultat sind qualitativ nicht ausreichende Ergebnisse, an denen für den Produktivbetrieb noch einiges nachgearbeitet werden muss. Das schränkt den Product Owner in seiner Entscheidungsfähigkeit ein. Er kann oft nicht beurteilen, was tatsächlich noch zu tun ist, um ein Release der Software wirklich durchzuführen.
Der Weg zu Done
Ein Done Increment entwickelt sich nicht einfach so. Es gehören einige Dinge dazu, die es einem Entwicklungsteam in Scrum erleichtern, Systeme und Anwendungen zu entwickeln, die wirklich „releasable“ sind. Wir zeigen einen möglichen Weg auf, bei dem ein Entwicklungsteam dem Done Increment Stück für Stück näherkommt.
Selbstverantwortung übernehmen
Der erste Schritt ist, die Verantwortung für das Done Increment nicht bei Anderen zu suchen, sondern sie selbst zu übernehmen. Unsere Anwender, Kunden und die Organisation, in der wir arbeiten, bieten uns keine perfekte Umgebung. Wir müssen unter den bestehenden Rahmenbedingungen dafür sorgen, auslieferbare Software zu entwickeln. Dafür erarbeiten wir Kriterien, die diese Auslieferbarkeit gewährleisten: die Definition of Done.
Ein cross-funktionales Team sein
Eine grundlegende Anforderung an ein Scrum Entwicklungsteam ist: es soll cross-funktional sein. Das heißt, das Entwicklungsteam muss in der Lage sein, ein Done Increment herzustellen. Das funktioniert oft in drei Schritten:
- Daran glauben, dass Cross-Funktionalität möglich ist
- Strategien entwickeln, um Wissen im Team zu verteilen
- Echte Zusammenarbeit als Team
Scrum lernen und verstehen
Dieser Punkt klingt zunächst trivial. Die 11 Regeln, die Scrum ausmachen, sind einfach und wirken offensichtlich. Wichtig ist aber, hinter diesen Regeln die Prinzipien zu entdecken. Scrum basiert auf der empirischen Prozesssteuerung: Transparenz, Überprüfung und Anpassung. Dabei werden konkrete Erfahrungen genutzt, um das eigene Vorgehen konsequent und kontinuierlich zu verbessern. Alle Regeln in Scrum sind danach ausgerichtet.
Daneben sind die Werte Offenheit, Respekt, Fokus, Commitment und Mut nötig, um nachhaltig mit Scrum erfolgreich sein zu können.
Done definieren
Ein Entwicklungsteam muss nicht nur wissen, welche Qualitätskriterien für sein Produkt erfüllt sein müssen, es muss auch in der Lage sein, diese Kriterien zu erreichen. Die Maßnahmen dafür beschreibt das Team in einer Definition of Done.
Die Definition of Done ist abhängig vom Produkt und vom Kontext der Produktentwicklung. Eine App fürs Online Banking hat andere Qualitätsanforderungen als ein medizinisches Gerät und braucht deshalb andere Maßnahmen, um diese Qualität herzustellen.
Als Team zusammenwachsen
Es geht in Scrum nicht darum, als Einzelner möglichst tolle Leistungen zu erbringen. Viel wichtiger ist es, als echtes Team zusammen zu arbeiten. Die Gesamtleistung eines gut funktionierenden Teams übertrifft dabei die Leistungsfähigkeit der einzelnen Mitglieder bei weitem. Dabei arbeitet das Team als Ganzes am gemeinsamen Ziel, z.B. dem Sprintziel.
Quality first!
In Scrum ist Qualität nicht verhandelbar. Sie wird nicht zu Gunsten einer kurzfristig schnelleren Entwicklung ignoriert. Teams, die mit Scrum wirklich erfolgreich sein wollen, dürfen deshalb nicht der Versuchung erliegen, Abkürzungen in Bezug auf die Qualität zu akzeptieren, um noch eine weitere Funktionalität liefern zu können.
Geeignete Architekturen einsetzen
Da sich Anforderungen in Scrum laufend ändern können, muss die Software flexibel und erweiterbar sein. Die Softwarearchitektur entwickelt sich zusammen mit der Software. Gute Prinzipien der Softwareentwicklung wie lose Kopplung / starke Kohäsion, Self-contained Systems oder konsequentes Refactoring helfen dem Team dabei.
Automatisierung einsetzen
Werkzeuge allein machen kein gutes Team. Aber die richtigen Werkzeuge können ein gutes Team dabei unterstützen, noch besser zu werden und auf die vielfältigen Anforderungen in der Softwareentwicklung zu reagieren.
Entwicklungsteams sollten nach technischer Exzellenz streben und Werkzeuge gezielt einsetzen, wo diese sie bei der Softwareentwicklung, -verteilung und -betrieb unterstützen. Prinzipien wie Testgetriebene Softwareentwicklung oder DevOps können hilfreiche und sinnvolle Praktiken für Scrum Entwicklungsteams sein.
Unfertige Features isolieren
Scrum Teams müssen spätestens am Ende eines Sprints ein auslieferbares Product Increment liefern. Häufig stehen Teams vor der Herausforderung, dass zu diesem Zeitpunkt noch unfertige Funktionalität in der Codebasis vorhanden ist, die nicht auslieferbar ist.
Entwicklungsteams sollten Strategien entwickeln, um diese unfertigen Teile der Software isolieren zu können, damit trotzdem ein Done Increment präsentiert werden kann.
Kurzlebige Branches im Versionskontrollsystem können dabei helfen, sind jedoch oft ein Risiko, weil es beim Merge zu Konflikten und Fehlern kommen kann. Eine Entwicklungsstrategie mit nur einem Master Branch und die Verwendung von Feature Toggles können dieses Problem beheben.
Sind wir jetzt Done?
Diese Frage ist spannend. Scrum Teams liefern mit jedem Sprint ein Done Increment, also müssen sie irgendwann mal „Done“ sein. Auf der anderen Seite lernen sie jeden Sprint etwas Neues dazu und verbessern sich und ihre Arbeitsweise. Sie sind dadurch in der Lage, ihr Verständnis von Done zu verfeinern und die Maßnahmen hin zum Done Increment zu verbessern.
Diese vom Team übernommene Verantwortung führt häufig zu einer Erweiterung des Denkens. Entwicklungsteams kümmern sich nicht mehr nur um die reine Softwareentwicklung, sondern übernehmen mehr und mehr Verantwortung für den gesamten Lebenszyklus des Systems. Diese Geisteshaltung von DevOps ist die Basis vieler sehr guter Scrum Teams.
Ein Scrum Team hat also nicht irgendwann eine Definition of Done, mit der es ab dann auslieferbare Product Increments liefert. Vielmehr schließt sich hier der Kreis zur Legende vom Heiligen Gral: dieser kann auch nicht gefunden werden, sondern der Weg hin zum Gral und die Vervollkommnung der Person ist das Ziel.
Jeder im Scrum Team, insbesondere im Entwicklungsteam, ist verantwortlich dafür, diesen Weg mit zu gehen und die kontinuierliche Verbesserung bei sich selbst und im Team voran zu bringen.
Autoren: Peter Götz & Thomas Schissler