Nebenwirkungen der agilen Software-Entwicklung
Das ist ein Erfahrungsbericht aus der Praxis – ich berichte aus meiner Arbeit in einem Projekt für ein Neues Mobilitätskonzept, und zwar konkret über die Auswirkungen auf die Qualität und die Kosten die wir nach der Umstellung auf Scrum beobachten konnten.
Es geht in diesem Artikel nicht um das Projekt an sich und auch nicht um Scrum – obwohl ich darüber auch sehr gerne schreibe und auch rede. Wenn Sie also möchten, dann nehmen Sie gern Kontakt zu mir auf oder nutzen Sie die Kommentarfunktion am Ende des Artikels.
Der Artikel gliedert sich in drei Teile:
In der Einleitung stelle ich das Projekt kurz vor und beschreibe die Ausgangslage, die dazu geführt hat, dass wir in diesem Projekt Scrum zum ersten Mal einsetzen.
Das soll quasi die Bühne für den Hauptteil bereiten, in dem ich beleuchten möchte, was sich durch die Umstellung auf Scrum geändert hat und auch zu beantworten versuche, warum das erst mit Scrum passiert ist.
Am Ende ziehe ich ein kleines Fazit und wage einen Ausblick was die Übertragbarkeit der Ergebnisse auf andere Projekte angeht.
Ausgangslage
Ich arbeite für eine IT-Tochtergesellschaft eines großen deutschen Konzerns, die sich unter anderem durch eine eigene Softwareentwicklung vom Rest des Konzerns abhebt, der ansonsten die Entwicklung von Software primär an Fremdfirmen auslagert.
In meiner bisherigen Laufbahn durfte ich schon einige Vorgehensweisen zur Entwicklung von Software kennenlernen. Von komplettem Chaos über das Wasserfallmodell und das V-Modell hin zum Rational Unified Process – aber ich fühle mich am wohlsten in einem kleinen aber stetig wachsenden Teil der sich „Agil“ nennt.
Auf den ersten Blick sieht das für den Außenstehenden mitunter nach Chaos aus und man hat den Eindruck alle laufen wild und unkoordiniert durcheinander.
Aber bei genauerem Hinsehen erkennt man dass hier sehr diszipliniert gearbeitet wird, dass jeder seine Aufgabe hat und alle mit Hingabe auf ein gemeinsames Ziel zusteuern.
Das Projekt ist ein innovatives Mobilitätsprojekt, das von einer anderen Tochtergesellschaft unseres Mutterkonzerns betrieben wird, die ebenso eine 100%ige Tochter ist.
Das Projekt reklamiert für sich nicht weniger als die Neuerfindung der Mobilität – das will ich mal dahingestellt sein lassen, aber eins ist klar:
Als Innovationsprojekt besitzt es einige spezielle Eigenschaften, die es von einem Standard-Softwareprojekt im Konzern abheben:
- Hoher Grad an Wirksamkeit in der Öffentlichkeit
- Hohes Medieninteresse
- Hohe Anforderungen an Flexibilität, was neue und geänderte Geschäftsanforderungen betrifft
- Hohe Anforderungen an Time-To-Market: Nur der Erste ist das Original, alle anderen sind nur Me-Too
Mit dieser Art von Anforderungen hatten wir bei uns im Unternehmen keine Erfahrungen, als wir von der Schwester beauftragt wurden, die Software für das Backend des Projekts zu entwickeln.
Wir haben trotzdem den Zuschlag bekommen weil wir als interner IT-Dienstleister eine besondere Vertraulichkeit von Informationen bieten können.
Also haben wir im Frühjahr 2008 mit der Entwicklung eines Prototypen für den anvisierten Pilotstandort begonnen, der sich zufälligerweise genau in der Stadt befindet, in der wir unseren Hauptsitz haben.
Zunächst waren wir nur beauftragt, die Backend Komponenten „Portal“ und „Back Office“ zu entwickeln.
Die Hardware im Fahrzeug sowie die Software-Komponenten, die die Kommunikation der Fahrzeuge mit der Zentrale steuern („Fahrzeugserver“), wurden dagegen zunächst extern zugekauft.
Das Standard-Vorgehen im Konzern ist eine ausgefeilte Version der Wasserfallmethode. Also hatten wir oben an der Quelle den Kunden (violett), anschließend etwas weiter stromabwärts einige Requirements Engineers (gelb), die die Spezifikation erstellen sollten.
Noch ein Stück weiter unten kamen dann die Entwickler (rot) und am Ende der Kaskaden schließlich die Tester (grün), bevor das Produkt dann ausgeliefert werden sollte.
Zwischendrin gab es auch noch Leute mit Sonderrollen (türkis) für Architektur, Qualität, Sicherheit, Produktmanagement und noch einige mehr.
Bis in die erste Jahreshälfte 2009 war das Projekt ziemlich stark angewachsen. Bei einem Schnappschuss im Frühsommer 2009 sah die Organisation in etwa so aus:
Der rechte Zweig war ein neues Teilprojekt, welches aus der Entscheidung entstanden war, die Fahrzeugsoftware und die Fahrzeugkommunikation im Backend künftig selbst zu entwickeln
Das Projekt bestand zu diesem Zeitpunkt aus 2 Kundenvertretern, 10 Leuten mit Fokus auf Requirements Engineering, 19 Personen in der Entwicklung, 4 die mit Test beschäftigt waren und 9 mit Querschnittsfunktionen.
Insgesamt beschäftigte das Projekt im Sommer 2009 also 44 Personen, wobei es in Spitzenzeiten bis zu 50 waren, die meisten in Vollzeit.
Wie man an dem Organigramm sehen kann, war also alles ordentlich aufgesetzt und organisiert. Leider hat diese Organisation nicht gut funktioniert – zumindest aus Sicht des Kunden.
Auf Seiten unseres Managements herrschte zunächst Unverständnis über diese Unzufriedenheit – schließlich hatte man alles so gemacht wie es den Vorgaben des Mutterkonzerns entsprach.
Konkret monierte die Kundenseite:
- Zu geringe Interaktionsmöglichkeiten mit der Entwicklung
- Große Aufwände bei Änderungswünschen (Change Control Board)
- Lange Reaktionszeiten bei Änderungen
- Stark angewachsene Projektteamgröße (Kosten) – bei gleichzeitigem
- Rückgang des Output (es vergingen Monate der Spezifikation, ohne dass es Fortschritte in der Software gab)
Zur Erinnerung: Wir haben es hier mit einem Innovationsprojekt zu tun – was der Kunde dringend brauchte war:
- Eine hohe Entwicklungsgeschwindigkeit
- Kurze Releasezyklen
- Schnellen Fortschritt
Was er von uns bekam war für ihn quälend langsam:
Die Spezifikation dauerte zu lange, obwohl im Laufe der Monate immer mehr und immer mehr Requirements Engineers in das Projekt genommen wurden – oder gerade deswegen?
Es wurden zwar Teilspezifikationen gemacht und an die Entwicklung und den Test gegeben, aber die waren nicht in der Reihenfolge wie sie die Entwicklung gebraucht hätte – und mussten deshalb immer wieder geändert werden.
Das war das zweite Problem:
Selbst die Anforderungen, die bereits bekannt waren (es gab und gibt noch viele unbekannte), waren nicht fix, sondern mussten häufig geändert werden. Das betraf auch die Teile der Software, die bereits in Betrieb waren. Das führte dazu dass auch deren Spezifikation immer wieder überarbeitet werden musste, was wiederum Kapazität zum Festhalten neuer Anforderungen band.
Letztlich wurde versucht, die Änderungen mit Hilfe eines Change Control Boards in den Griff zu bekommen. Das machte die notwendigen Kursänderungen in der Software zwar wirklich kontrollierbar, aber eben auch ziemlich langwierig und aufwendig.
Insgesamt war die gesamte Situation ziemlich verfahren: Die Kommunikationswege zu starr, die Entwicklung zu langsam, die Flexibilität zu gering, schlichtweg: Die Lösung war vielleicht nicht schlecht, passte aber definitiv nicht zum Problem.
Im Sommer 2009 wurde der Druck des Kunden so groß, dass eine Sache klar wurde: So konnte es nicht weitergehen. Auf meinen Vorschlag hin und in Absprache mit dem Kunden wurde daher beschlossen, in einem der Teilprojekte ein neues Vorgehensmodell zu testen: Scrum.
Scrum an sich ist nicht gerade neu, aber für unser Unternehmen war und ist ein solches Vorgehen doch ziemliches Neuland, und auch bei der Mutter gehen die Bestrebungen momentan gerade eher in die andere Richtung.
Was hat sich mit Scrum geändert?
Jedenfalls haben wir im September 2009 das erste Scrum Team gebildet, das sich zunächst um die Entwicklung der Fahrzeugsoftware und der dazugehörigen Serverkomponente kümmern sollte.
Alle Verbesserungen, die damit erreicht werden sollten, wurden auch erreicht:
- Der Kunde in seiner neuen Position als Product Owner kann jederzeit mit allen Teammitgliedern reden – und andersherum genauso. Vorher durfte er nur mit den Requirements Engineers kommunizieren.
- Die Entwicklung in kleinen dreiwöchigen Zyklen gibt dem PO die Möglichkeit, sehr schnell neue Features in den Markt zu bringen. Vorher vergingen Monate ohne eine neue produktive Version.
- Der PO kann jederzeit seine Meinung ändern und dem Team – in dreiwöchigem Abstand – neue Ziele und eine neue Richtung geben. Vorher gab es nur den aufwendigen und langwierigen Weg über das Change Control Board, dessen Zweck eher das Verhindern von Änderungen war.
- Die Zusammenarbeit im Projekt wurde stark verbessert – es gibt jetzt ein echtes Teamgefühl und kein „Wir gegen die“ mehr. Vorher hatten sich Entwickler, Tester und Requirements Engineers bei Problemen gegenseitig den Schwarzen Peter zugeschoben
Insgesamt ist das ganze Projekt schneller und flexibler geworden – und effizienter. Aber ich wollte ja eigentlich über die Nebenwirkungen sprechen, die nicht unbedingt im Hauptfokus der Umstellung standen.
Erste Nebenwirkung
Wir sehen eine deutlich verbesserte Qualität der Software – woran erkennen wir das?
Am offensichtlichsten für alle Beteiligten ist sicher die Ruhe und die Gelassenheit, die mittlerweile ins Team eingekehrt ist.
Neue Releases sorgten im letzten Jahr noch dafür, dass wochenlang das blanke Chaos im Projekt herrschte und alle wild durcheinanderliefen wie kopflose Hühner.
Heute passieren die Deployments für neue Releases fast unbemerkt. Zwei Teammitglieder erledigen die Aufgabe an einem Nachmittag, während das Team im nächsten Sprint schon an der Weiterentwicklung arbeitet.
Eine andere Metrik an der man – wie ich finde – sehr schön sehen kann, wie die Qualität der Software sich verbessert hat, ist die Anzahl der Bugfix Releases nach einem regulären Release:
Wenn ich zurückdenke an das letzte Release im Jahr 2009, dann folgtem diesen innerhalb eines Monats insgesamt sieben Bugfixes, zum Teil im Abstand von nur einem Tag (oberer Zeitstrahl).
Wenn man weiß, was es für ein Aufwand ist, im Rechenzentrum des Mutterkonzerns ein Deployment hinzubekommen, dann wird umso klarer, wie verzweifelt das Projekt gewesen sein muss, diesen Aufwand fast täglich auf sich zu nehmen.
Erst einen guten Monat nach dem Go-Live hatte sich die Lage wieder einigermaßen beruhigt.
Betrachtet man dagegen das erste Release nach der Einführung von Scrum, dann sieht man sehr deutlich dass hier weitaus größere Ruhe geherrscht haben muss (unterer Zeitstrahl).
Zwar hatte dieses Release einen etwas geringeren Funktionsumfang, beinhaltete dafür aber die komplette Umgestaltung der Webanwendung und damit der Präsentationsschicht.
Zudem waren zwei der drei Bugfix Releases zum größeren Teil von kleineren (vom Kunden gewünschten) Modifikationen getrieben als von wirklichen Bugfixes.
Insgesamt wurden in diesem Release sechs als „hoch“ eingestufte Bugs gefunden, davon waren zwei jedoch schon in der Vorgängerversion vorhanden.
Was sind nun die Hauptzutaten für diese Qualitätssteigerung? Die erste und aus meiner Sicht wichtigste ist die weitestgehende Automatisierung von Tests.
Früher war die eine Hauptzutat für unsere Tests eine kleine Armee von etwa 40 Studenten. Die zweite war eine Menge Zeit: Rund zwei Monate waren als extra Testphase vor jedem Release notwendig.
Heute läuft vieles von dem, was wir früher aufwendig und zeitraubend in mehreren Iterationen manuell getestet haben, mindestens einmal pro Nacht automatisch ab.
Das ist nicht nur eine enorme Zeitersparnis, sondern gibt uns auch die Sicherheit, dass nach einer Änderung alles noch so funktioniert wie vorher. Außerdem ist es wesentlich einfacher, auftretende Fehler zu beseitigen – einfach weil sie viel schneller entdeckt werden.
Unit Test Ergebnisse von Mitte Dezember 2010:
- Code Coverage für den Fahrzeugserver: nahe 100% (mehr als 1.150 Tests)
- Code Coverage fürs Backend: 52% auf Klassenebene (ca. 450 Tests)
- Automatisierte Funktionaltests (GUI Tests mit Selenium): ca. 350 Tests
Um das Thema Testen abzuschließen kann ich feststellen, dass wir heute in allen vier Agilen Test Quadranten unterwegs sind:
Das hat sicher der Qualität einen enormen Schub gegeben.
Ich weiß, was Sie denken: „Was hat das mit Scrum zu tun? Das hätte ich alles auch ohne Scrum haben können! Tests und Testautomatisierung gab es auch vorher schon!“
Und Sie haben Recht: Scrum hat nicht das Testen neu erfunden. Und auch sonst nicht die Softwareeentwicklung. Scrum ist kein Wundermittel und auch keine Silberkugel.
Aber: Richtig angewendet schafft Scrum die notwendigen Voraussetzungen unter anderem für Qualität:
In Scrum habe ich ein Team, das zusammen die Software erstellt. Von Anfang bis Ende. Fertig. Es gibt keinen extra Qualitätsbeauftragten, der von außen in das Team hineinregiert. Und es gibt keine nachgeordnete Instanz, die später die Qualität in das Produkt hineinzutesten versucht.
Das Team, das die Software baut, ist auch dafür verantwortlich, dass die Software das Richtige tut und dass sie das Richtige auch richtig tut. Sprich: Das Team selbst ist ganz allein für die Qualität verantwortlich.
Um diese Verantwortung wahrnehmen zu können, muss das Team auch die dazu notwendigen Entscheidungen treffen können.
In Scrum heißt das: Ermächtigtes Team – und das ist das Hauptverdienst von Scrum: Das Team so aufzusetzen dass es die Kompetenzen und auch die Befugnisse hat, die richtigen Entscheidungen zu treffen.
Macht man das, dann wird das Team sehr schnell erkennen, dass es besser ist, Qualität von vornherein einzubauen anstatt sie später hineinzutesten.
Die Aufgabe des Scrum Masters ist es, dafür zu sorgen, dass das Team diese Freiräume bekommt – und auch nutzt.
So haben wir Anfang des Jahres die gesamte GUI mit automatisierten Tests versehen – auf Kosten einer zunächst reduzierten Entwicklungsgeschwindigkeit und gegen den anfänglichen Widerstand des Product Owners.
Wir haben das Versionsverwaltungstool gewechselt – gegen massiven Widerstand aus dem Unternehmen. Für das Unternehmen war dieses Tool nicht nur für die Versionsverwaltung da, sondern die zentrale Instanz, auf deren Features der gesamte Wasserfallprozess aufgebaut war. Damit war es eine Heilige Kuh und selbstverständlich für alle Arten von Softwareentwicklung vorgeschrieben.
Leider hat uns diese Kuh behindert, denn sie benötigte einen speziellen Fat Client, der nicht für unser Vorgehen geeignet war und uns durch häufiges Einfrieren und Abstürzen mehr Arbeit gekostet als gespart hat.
Also haben wir ein Sakrileg begangen und sind eigenmächtig auf Subversion umgestiegen. Das hat innerhalb der Organisation für Turbulenzen gesorgt, aber unserer Entwicklungsgeschwindigkeit einen großen Schub gegeben.
Seither weiß ich, warum es heißt, dass ein guter Scrum Master immer genau einen halben Schritt davon entfernt ist, gekündigt zu werden…
Anschließend haben wir auch noch den Buildprozess vereinfacht und ein neues CI System (Hudson) eingeführt.
Zweite Nebenwirkung
Kommen wir zu den Kosten – wieder eine einfache Metrik:
Vorher: ca. 44 Mitarbeiter im Projekt
Heute: ca. 30 Mitarbeiter im Projekt
Dadurch sanken die Kosten um mehr als 30%
Dagegen stieg der Output – wir liefern alle drei Wochen ein neues Produktinkrement, das potentiell releasefähig ist. In der Regel wird dieses Inkrement nach jedem zweiten Sprint auch tatsächlich ausgeliefert, also alle sechs Wochen.
Für die Scrum-Leute: Das Backend-Team hat im Jahr 2010 in 19 Sprints insgesamt 117 User Stories umgesetzt.
Die Effizienz ist also deutlich gestiegen – das merkt man auch an der Kundenzufriedenheit, die Mitte 2009 im Keller war. Heute ist der Kunde zwar immer noch nicht extrem begeistert, aber zumindest deutlich entspannter.
Die Einführung von Scrum im Neuen Mobilitätskonzept ist eine spannende Entwicklung. Was hat sich sonst noch geändert durch Scrum?
Weitere Nebenwirkungen
Wir machen heute keine überflüssigen Prozessschritte und Dokumentationen mehr – und damit meine ich die Art von Dokumentation die mehr Kopfzerbrechen bereitet als dass sie hilfreich ist und die für die Mülltonne produziert wird. Diese Art von Geldverschwendung haben wir eliminiert.
Vielen denken ja, in agilen Projekten wird generell nichts mehr dokumentiert, aber das ist falsch! Wenn Ihnen jemand so etwas erzählt, dann disqualifiziert er sich damit selbst.
In agilen Projekten, die dieses Etikett auch verdienen, wird sehr wohl dokumentiert – nur eben auf einem sinnvollen Level.
Wir haben dafür eine einfache Leitlinie – wann immer es mehr Nutzen stiftet, etwas zu dokumentieren als das Dokumentieren kostet, dann wird dokumentiert.
Darüber hinaus wird natürlich alles dokumentiert, was vorgeschrieben ist oder was zum Betrieb benötigt wird – oder was der Product Owner im Rahmen einer User Story explizit anfordert und damit ja auch bezahlt.
Die Kommunikation hat sich verändert, sie ist direkter und weniger formal geworden.
Wenn wir ein Problem zu lösen haben und ein bestimmtes Werkzeug vorgegeben ist, das offensichtlich nicht passt, dann tun wir alles, um es durch ein passenderes zu ersetzen.
Das mag trivial klingen, ist aber in einem großen streng reglementierten Konzern mitunter eine spannende Aufgabe!
Wir arbeiten jetzt mehr als Team zusammen. Früher hieß es oft: „Klar, wir sitzen alle im selben Boot. Aber das Loch ist auf eurer Seite!“ Heute spielt es auch in den Köpfen der Leute keine Rolle mehr, auf welcher Seite des Bootes das Loch ist.
Das Team hat eine höhere Verantwortlichkeit. Das führt insgesamt zu einer höheren Motivation, weil die Tätigkeiten interessanter und breiter angelegt sind als vorher.
Rollen wie z.B. Quality Manager, die primär der Überwachung und Kontrolle dienen, werden dadurch obsolet
Die Rolle des Managements ändert sich durch Scrum ebenfalls: Sie geht weg von einer Befehls-Kontroll-Sequenz hin zu einer mehr unterstützenden Rolle – dem Team dabei zu helfen, erfolgreich zu sein.
Fazit
Damit wird es Zeit für ein Fazit…wo stehen wir heute?
Unser Kunde wollte eine hohe Entwicklungsgeschwindigkeit – Wir sind auf jeden Fall schneller geworden, auch wenn sicher noch weiteres Potential besteht.
Unser Kunde wollte maximale Flexibilität und Wendigkeit – Wir sind auf jeden Fall flexibler geworden, auch wenn es Hindernisse gibt, die wir (noch) nicht überwunden haben.
Wir haben unsere automatisierte Testbasis signifikant ausgeweitet und damit die Qualität gesteigert. Das hat uns Luft und Zeit zum Entwickeln verschafft. Wir haben es schließlich mit einer Legacy-Anwendung zu tun, die nicht von vornherein auf automatisierte Testbarkeit hin entwickelt worden war.
Möglich ist das alles auch ohne Scrum – aber die Scrum Spielregeln machen es deutlich einfacher. Scrum ist damit ein gutes Vehikel, es schafft Transparenz und schafft die Möglichkeit zur Veränderung und damit zur Verbesserung.
Die Veränderung umsetzen mussten wir zwar immer noch selber, denn Scrum an sich löst keine Probleme, sondern macht sie nur sichtbar.
Dennoch: Wir haben von dem Umstieg profitiert und können Scrum auf jeden Fall für Innovationsprojekte empfehlen.
Ein Wort der Warnung am Schluss: Tun Sie es nur, wenn Sie es ernst meinen – ein bisschen Scrum funktioniert genausowenig wie ein bisschen schwanger.
Und – es ist nicht einfach. Aber es lohnt sich.
Update 2020: Dieser Artikel ist eine überarbeitete Version eines Vortrags, den ich im Januar 2011 auf den Software Quality Days in Wien gehalten habe.
