Warum Scrum ohne Extreme Programming (XP) in der Softwareentwicklung definitiv keine gute Idee ist.

Wir haben als Scrum Master, Agile Coaches und Developer über Jahre hinweg viele Teams auf ihrer agilen Reise begleiten dürfen und dabei unterschiedliche Vorgehensweisen gesehen und zusammen ausprobiert. Der Vergleich der verschiedenen existierenden agilen Frameworks und die Adaption im jeweiligen Kontext beschäftigt uns tagtäglich und somit die Frage, wie wir unsere Teams bestmöglich dabei unterstützen können, ein wirklich gutes und erfolgreiches Produkt zu entwickeln.

Hier möchten wir speziell auf zwei Vorgehensmodelle eingehen: Scrum und Extreme Programming (XP) und unsere Beobachtungen mit euch teilen. 

Wir stellen in der Praxis häufig fest, dass mit Scrum gearbeitet wird, aber bei der Einführung des Frameworks die Anwendung von technischen Praktiken zur Softwareentwicklung dabei kaum eine Rolle spielt.

Wie entscheidend dieser Punkt aber für den Erfolg der Umsetzung und für die Zufriedenheit von Entwicklungsteams und Kunden ist, zeigen wir euch am Beispiel von zwei Teams.

Fall 1: Ein typischer Sprint in einem Scrum-Team

Das ganze Team trifft sich und wir arbeiten zusammen daran, was das nächste, kleine und für unsere Kunden wertstiftende Ziel sein könnte — im Review haben uns die Kunden dazu hilfreichen Input gegeben. Wir überlegen, wie wir dieses Ziel erreichen können und was dafür zu tun ist. Motiviert starten wir den Sprint. Wir treffen uns im Daily und besprechen, was wir heute erreichen wollen und wie wir unserem Vorhaben einen Schritt näher kommen können.

“Motiviert starten wir in den Sprint. Am Nachmittag erhalten wir die Info, dass es Probleme mit der Anwendung gibt.”

Am Nachmittag erhalten wir die Info, dass es Probleme mit unserer Anwendung gibt. Wir kommen als Team zusammen und besprechen, wer seine Arbeit unterbrechen kann, um dem Problem auf den Grund zu gehen. Eine Entwicklerin meldet sich für diese Aufgabe und beginnt sofort mit der Fehleranalyse. 

Die erste Rückmeldung erfolgt schnell: Eines der neuen Features, welches wir im letzten Sprint auf Produktion deployt haben, hat einen negativen Seiteneffekt auf ein bereits älteres Feature, wodurch die Nutzung unserer App erheblich beeinträchtigt ist. 

Die Ursache ist zum Glück schnell identifiziert und die Fehlerbehebung kann beginnen. Wenige Stunden später vermeldet die Entwicklerin, dass sie weitere Hilfe benötigt, da sie Teile des betroffenen Codes nicht nachvollziehen kann, da dieser schon älter ist und vor ihrer Zeit im Team entstanden ist. Ein Teammitglied eilt ihr zu Hilfe und bald darauf haben sie eine erste Idee, was helfen könnte. 

Im nächsten Daily besprechen wir die Fertigstellung des Bugfixes und planen die Weiterarbeit am Sprintziel. Gegen Mittag kommt die erhoffte Erfolgsmeldung: Der Fehler wurde behoben. Nun kann das Produktions-Release in die Wege geleitet werden. Die Entwicklerin legt ein neues Ticket im Product Backlog an, um den alten Legacy Code endlich mal ‘ordentlich’ zu refactoren. Ein anderes Teammitglied kümmert sich um die Koordination mit dem IT-Betrieb und übernimmt die Regressionstests. Alle Aufgaben für das Release sind abends abgeschlossen und das Deployment wurde für die kommende Nacht terminiert. 

“Am Tag vor dem Review planen wir, was wir realistisch von den angebrochenen Stories noch fertig bekommen können, damit unsere Kunden morgen etwas zu sehen bekommen.” 

Die restlichen Tage im Sprint verlaufen ohne Unterbrechungen und am Tag vor dem Review planen wir, was wir realistisch von den angebrochenen Stories noch fertig bekommen können, damit unsere Kunden morgen etwas zu sehen bekommen. 

Im Review besprechen wir mit den Kunden den aktuellen Zustand unseres Produktes. Die Kunden sind immer noch über die Produktionsprobleme verärgert und bemängeln, dass sich solche Ausfälle in letzter Zeit häufen. Zudem sind sie enttäuscht, dass wir erneut das besprochene Ziel nicht erreicht haben. 

Mit gemischten Gefühlen gehen wir in die Retro. Wir grübeln, wie wir es schaffen können, eine Balance zwischen dem Abbau der technischen Schulden und der Weiterentwicklung des Produktes zu finden.

Fall 2: Eine typische Iteration in einem Extreme-Programming-Team

Wie jeden Montag treffen wir uns und überprüfen den bisherigen Fortschritt unserer Arbeit, einschließlich der Frage, wie der tatsächliche mit dem erwarteten Fortschritt der vergangenen Woche übereinstimmt.

Danach stellt uns unsere Kundin vor, welche Stories für diese Woche wichtig sind. Im Anschluss daran zerlegen wir die Stories in kleinere Aufgaben und beginnen mit dem Schreiben von automatischen Tests für die ersten User Stories. 

Um die Qualität des Codes so hoch wie möglich zu halten, setzen wir mit Test Driven Development (TDD) auf eine Test- und Designstrategie. Dabei schreiben wir zu Beginn einen Test, der fehlschlägt. Wir entwickeln dann den Produktivcode genau so weit, bis der Test unseren Code positiv (Test ist grün) bestätigt. 

“Fast die gesamte Zeit arbeiten wir im Pair-Programming-Modus.”

Wir arbeiten an jeder Story mit mindestens zwei Personen und fast die gesamte Zeit arbeiten wir im Pair-Programming-Modus. Auch wenn das teilweise sehr anstrengend ist, da wir uns intensiv auf unsere Partner einlassen müssen und dabei sehr fokussiert arbeiten, sind wir mit den Ergebnissen, die wir gemeinsam schaffen, sehr zufrieden.  Um das Wissen über das Softwaresystem so breit wie möglich zu streuen, wechseln wir von Zeit zu Zeit die Pair-Programming-Paare.

Da wir von Beginn an über eine sehr hohe Testabdeckung verfügen, ist kontinuierliches Refactoring einfach möglich, was unseren Code sehr stabil, einfach wartbar und leicht verständlich macht. Die sehr hohe Testabdeckung bewirkt, dass wir großes Vertrauen in unseren eigenen Code haben, was zu einer schnellen Reaktionsfähigkeit bei Problemen oder Fehlern führt.

“Wir sind in der Lage, nach der Fertigstellung einer Story unmittelbar ‚live‘ zu gehen und unseren Kunden dadurch auch mehrmals pro Woche neue Funktionalität zur Verfügung zu stellen.”

Wir haben schon zu Beginn unserer Arbeit nach dem Prinzip “Was automatisiert werden kann, wird automatisiert” gearbeitet, wodurch der gesamte Code automatisch und nach jedem Einchecken gebaut, getestet und deployt werden kann. So sind wir in der Lage, nach der Fertigstellung einer Story unmittelbar ‘live’ zu gehen und unseren Kunden dadurch auch mehrmals pro Woche neue Funktionalität zur Verfügung zu stellen.
   
Weil wir eine Kundin als festes Teammitglied haben, bekommen wir täglich Feedback zu unserer Entwicklung und können dementsprechend sehr schnell auf Kundenwünsche reagieren.

Am Donnerstagmorgen erwähnt die Kundenvertreterin spontan, dass eine kleine Anpassung am Produktivsystem für eine Marketing-Kampagne sehr hilfreich wäre. Durch die stets eingeplante Slack-Time und unsere schnelle Lieferfähigkeit können wir diesem Wunsch nachgehen, ohne unsere Ziele für die Woche zu gefährden. Am Freitag Mittag steht die Anpassung im Produktivsystem bereit und wir haben unsere Wochenziele erreicht.

Am Freitag endet unsere Iteration und wir gehen zufrieden ins Wochenende. 

XP als Ergänzung zu Scrum

Der Unterschied zwischen XP und Scrum

Der wesentliche Unterschied zwischen Scrum und XP ist das Anwendungsfeld:
Scrum ist für jede Form von Produktentwicklung in unterschiedlichen Bereichen gedacht, wohingegen XP explizit die Problemstellungen in der Softwareentwicklung adressiert.

Kent Beck empfiehlt 22 Praktiken, die Software-Entwicklungsteams dabei helfen sollen, hochqualitative Software zu entwickeln. Welche der Praktiken angewendet werden, ist kontextspezifisch und wird von den jeweiligen Teams entschieden.

Wie sich der Verzicht auf XP-Praktiken bei der Softwareentwicklung konkret auswirkt

Basierend auf unseren Erfahrungen der letzten Jahre mit vielen verschiedenen Kunden, sind die Auswirkungen von Scrum ohne den Einsatz von XP-Praktiken auf Dauer weitreichend und gefährden mit steigender Komplexität des Produktes zusehends das Ziel von Scrum: ein “done”-Increment zu erstellen, um Kundenfeedback zu ermöglichen.

Diese Szenarien in Nicht-XP-Teams beobachten wir häufiger:

• Viele wiederkehrende manuelle Tests aufgrund fehlender Testautomatisierung, die mit zunehmender Komplexität an Zuverlässigkeit verlieren und Kapazitäten binden
• Schlecht wartbarer und unverständlicher Code durch fehlende Refactorings und seltenere Design-Diskussionen z.B. im Rahmen des Pair-Programmings
• Lange Integrationsphasen verbunden mit vielen Konflikten durch seltene Integration und langlebige Branches
• Seltene, teure und riskante Produktionsreleases aufgrund unausgereifter Automatisierung der Releaseprozesse 
• Eine Bugwelle an Fehlern durch fehlende Testautomatisierung
• Wissenssilos und Abhängigkeiten zu einzelnen Teammitgliedern durch fehlenden Wissenstransfer z.B. mittels Pair-Programming

Fazit und Empfehlung: Scrum ohne XP ist keine gute Idee!

Keiner Organisation ist damit geholfen, wenn ihre Software-Entwicklungsteams ausgelaugt und demotiviert sind, weil sie trotz vieler Überstunden mit einem Berg von technischer Schuld zu kämpfen haben und ein viel zu kleiner Anteil ihrer Zeit in die Entwicklung neuer Funktionalität investiert werden kann.   

Der Einsatz von Scrum für die Entwicklung digitaler Produkte ist grundsätzlich eine gute Idee. Wir plädieren allerdings dafür, im Kontext der Softwareentwicklung den Fokus auf die Kernpraktiken von XP zu legen: Pair-Programming, testgetriebene Entwicklung (TDD) und Continuous Integration tragen dazu bei, die Qualität des Produktes und den Softwareentwicklungsprozess zu verbessern. Verzichtet ihr darauf, werden mit an Sicherheit grenzender Wahrscheinlichkeit viele der oben aufgelisteten Probleme sehr zeitnah zu Tage treten – und zwar unabhängig davon, ob ihr Scrum, Kanban oder eine andere agile Arbeitsweise verwendet.  

Scrum in Kombination mit XP wird euch dabei helfen, erfolgreicher und effizienter Produkte zu entwickeln.

Von Kristian Bergmann, Michael Brandt & Alexandra Untch