THESE 1

Bernhard Löwenstein: Die meisten Unternehmen machen nicht Scrum, sondern verwenden lediglich einen Scrum-ähnlichen Prozess. So werden beispielsweise immer wieder die Daily Stand-ups oder die Retrospektiven nicht gemacht. Dadurch geht aber manch großer Vorteil verloren, dessen sich die Unternehmen aber gar nicht bewusst sind.

Thomas Much: Es geht nicht nur mancher Vorteil verloren, sondern es entsteht auch häufig Frust, weil die Beteiligten merken, dass das Vorgehen nicht stimmig ist. Häufig fühlt sich Scrum dann „kaputt“ an und Agilität wird künftig abgelehnt. Es ist ein nicht zu unterschätzender Aufwand, vernünftige Daily Stand-ups und hilfreiche Retrospektiven durchzuführen. Denn offene Kommunikation, stolz sein auf Stärken und das Lernen aus Fehlern müssen viele Teams – und deren Leiter – oft erst noch lernen! Ein Unternehmen sollte sich daher immer zuerst die Frage stellen, warum es agil werden bzw. Scrum machen will. Möchte man die Teams befähigen, autonomer zu handeln, um dadurch mehr Flexibilität zu erreichen? Dann kann man die Mühe des Lernens auf sich nehmen, was letztendlich das ganze Unternehmen verändern wird. Oder möchte man sich nur möglichst schnell „agil“ auf die Fahnen schreiben können und verpackt daher den bisherigen (starren oder nicht vorhandenen) Prozess in einem Buzzword? Das ist in aller Regel kontraproduktiv.

THESE 2

Bernhard Löwenstein: Bei den früher klassischen Vorgehensmodellen gab es immer einen großen Aufschrei der Entwickler, wenn Codeteile im Nachhinein geändert werden mussten. Bei Scrum sind in den meisten Projekten die zwischendurch durchgeführten Codeadaptierungen noch wesentlich umfangreicher, allerdings wird dies nicht bewusst wahrgenommen. Um es mit einer Metapher auszudrücken: Am Ende steht zwar ein fertiges Haus, aber auf dem Weg dahin hat man oft in Summe auch ein ganzes Haus wieder eingerissen.

Thomas Much: In der Tat, weil Refactoring fester Bestandteil agiler Softwareentwicklung ist. Es ist durchaus üblich, 20 Prozent der Entwicklungszeit für Refactorings zu verwenden. Dabei kann es passieren, dass letztendlich der gesamte Code umgeschrieben wird, manche Codestellen sogar mehrfach. Wenn neue Anforderungen entstehen oder das Team neue Erkenntnisse gewinnt, sollte der betroffene Code zeitnah umgebaut werden. Wenn man das auf irgendwann später verschiebt, passiert das nie und der Code verrottet. Oder man hat mühsam ein komplettes Hochhaus gebaut, merkt nun aber, dass man nur ein Reihenhaus benötigt. Einen solchen Umbau nach Projektende durchzuführen, ist unglaublich aufwendig und stößt zurecht auf Widerstand. Dann doch lieber in kleinen Schritten während der Entwicklung.

Die Refactorings werden sehr wohl bewusst wahrgenommen, weil nicht nur der Code geändert, sondern auch die betroffenen Tests angepasst werden müssen. Ein agiles Team begreift die regelmäßigen Änderungen aber als Chance, die Codebasis wartbar und möglichst klein zu halten.

Die besten Werkzeuge für Scrum sind ein möglichst großes Whiteboard, Post-its und Stifte.

Der Agile & Culture Track auf der JAX 2019

THESE 3

Bernhard Löwenstein: Es wird bei Scrum vorab kaum mehr etwas spezifiziert, sondern die Produktivität wird vorrangig daran gemessen, wie schnell die Entwickler loslegen und etwas Herzeigbares liefern. Das endet oftmals in Code, der deutlich eleganter geschrieben hätte werden können, oder in Architekturen, die sich später als suboptimal herausstellen.

Thomas Much: Das beschreibt weder Scrum noch irgendein agiles Vorgehen, sondern ungeplantes Programmieren auf Zuruf. Das mag unglaublich agil klingen, endet aber oft im Chaos. Leider ist das noch zu oft die Projektrealität. Agilität beschreibt dagegen ein sehr planvolles Vorgehen – nur, dass nicht mehr alles im Vorfeld durchplant wird. Je näher die Umsetzung einer Aufgabe rückt, desto genauer wird sie geplant. Weiter entfernte Aufgaben werden nur grob geplant. Wenn sich Anforderungen ändern oder neu ergeben, wird neu priorisiert und geplant. Und erst nach der Detailplanung einer Aufgabe wird mit deren Umsetzung begonnen.

Damit das funktioniert, brauchen wir bei agilem Vorgehen mehr denn je ein klares, sinnvolles Ziel, da der Weg dahin noch nicht exakt beschrieben ist. Ein Hilfsmittel zur Visualisierung des Ziels und der Reise dorthin kann beispielsweise User Story Mapping sein. Und egal, wie gut wir planen – agil oder nicht agil – Code und Architektur werden sich im Laufe der Zeit immer als suboptimal herausstellen. Agilität akzeptiert dies als inhärentes Problem der Softwareentwicklung und plant solche notwendigen Änderungen regelmäßig ein (siehe These 2).

Bei agilem Vorgehen brauchen wir mehr denn je ein klares, sinnvolles Ziel, da der Weg dahin noch nicht exakt beschrieben ist.

THESE 4

Bernhard Löwenstein: Entwickler lieben Scrum vor allem deshalb, da die lästige Arbeit des Dokumentierens auf ein Minimum reduziert wird und das Programmieren im Vordergrund steht. Das erzeugt den Eindruck, dass man stets produktiv ist, auch wenn dies gesamtheitlich betrachtet nicht so der Fall ist.

Thomas Much: Wenn durch das Weglassen überflüssiger Dokumentation die Gesamtproduktivität sinkt, ist irgendetwas anderes im agilen Vorgehen nicht in Ordnung, beispielsweise die Planung (siehe These 3). Denn solange das Team das sinnvolle Minimum an Dokumentation schreibt, ist dagegen nichts einzuwenden. Scrum bzw. Agilität darf nur kein Freibrief dafür sein, dass man gar keine Dokumentation mehr erstellt.

Sinnvolle Dokumentation ist beispielsweise ein Überblick über die fachlichen und technischen Zusammenhänge oder die Pflege des Betriebshandbuchs. Das kann ein Standardtask am Ende jeder Story als Teil der Definition of Done sein. Die übrige Dokumentation inklusive der meisten Codekommentare lässt sich durch eleganten Code ersetzen: ordentlich benannte Variablen, Methoden und Klassen sowie verständliche Unit-Tests. Solche Art von Dokumentation ist für ein gut funktionierendes, crossfunktionales agiles Team essenziell. Wer darauf verzichten möchte, nimmt Scrum vermutlich nur als Vorwand, um alleine vor sich hin hacken zu können.

Ein agiles Team begreift die regelmäßigen Änderungen aber als Chance, die Codebasis wartbar und möglichst klein zu halten.

THESE 5

Bernhard Löwenstein: Wer Scrum mit den früher klassischen Vorgehensmodellen vergleicht, macht oft den Fehler, dass er Scrum inklusive der heute bereitstehenden Werkzeuge und Techniken mit dem früher klassischen Prozess exklusive dieser Werkzeuge und Techniken vergleicht (da es diese eben damals noch nicht gab). Klarerweise scheint Scrum dann den „alten“ Vorgehensmodellen deutlich überlegen zu sein.

Thomas Much: Die besten Werkzeuge für Scrum sind ein möglichst großes Whiteboard, Post-its und Stifte. Die gab es auch früher schon. Und eigentlich sind die Techniken für die klassischen Prozessmodelle viel ausgefeilter als die von Scrum, auch weil sie über einen viel längeren Zeitraum entstanden sind und eingesetzt wurden. Und dennoch haben sich die klassischen Techniken für viele Projekte als ungeeignet erwiesen. Scrum bzw. agiles Vorgehen ist dann besser geeignet, wenn die Detailanforderungen sich erst im Projektverlauf klären oder ändern, weil Scrum das Risiko von Änderungen akzeptiert und ein Vorgehen dafür beschreibt, wie damit geordnet umgegangen wird.

Projekte, deren Anforderungen im Vorfeld exakt feststehen (müssen), sind mit einem anderen klassischen Vorgehensmodell vermutlich besser beraten. Aber die vielen Projekte, bei denen das Management die Augen davor verschließt, dass die Anforderungen beim Projektstart eben nicht exakt feststehen – für die ist ein agiles Vorgehen tatsächlich „überlegen“, weil das klassische Vorgehen in diesem Fall schlicht ungeeignet ist.