Scrum hielt als Vorgehensmodell für das Projektmanagement in den letzten Jahren in vielen Unternehmen Einzug. Ganz so toll, wie von vielen propagiert, läuft es aber nicht immer damit. Das motivierte Bernhard Löwenstein dazu, fünf Thesen zu formulieren, die in Folge von fünf Scrum-Experten auf Herz und Nieren geprüft werden.

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.

Konstantin Diener: Auf jeden Fall! Ich unterscheide gerne zwischen Unternehmen, die „agil machen“ und denen, die „agil sind“. Damit ein Team oder eine Organisation wirklich die Erträge agiler Entwicklung bekommt, muss man die zugrunde liegenden Konzepte verstehen. Zum Verständnis ist es nützlich, sich am Anfang an die Elemente des Scrum-Frameworks zu halten und nichts wegzulassen. Wenn die Konzepte und Beweggründe in Fleisch und Blut übergegangen sind, ist es vollkommen in Ordnung zu experimentieren, z. B. „Wir machen eine kurze Retro bei jedem Produktionsfehler, dafür aber nicht mehr unbedingt nach jedem Sprint“.

Ich unterscheide gerne zwischen Unternehmen, die „agil machen“

und denen, die „agil sind“.

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.

Konstantin Diener: Um auf diese These zu antworten, würde ich zunächst gerne beim Hausbaubeispiel bleiben. Wenn ich exakt weiß, wie das Haus aussehen soll und es sich über die Zeit daran nichts ändern wird, sollte ich gar keinen agilen Entwicklungsansatz wählen. Tatsächlich ist es aber in Softwareprojekten meist so, dass ich das nicht unbedingt so genau weiß. Da es Sommer ist, reicht es mir vielleicht zunächst, die Duschen (wegen der Privatsphäre) zu bauen und auf ihre Praxistauglichkeit zu untersuchen – essen und schlafen kann ich im Freien 😉 Mit den Erkenntnissen aus dieser ersten Baustufe kann ich das übrige Haus bauen.

Mit klassischen Modellen baue ich auch zwei Häuser. Ich merke aber erst nach der Fertigstellung, dass das erste Haus nicht sinnvoll nutzbar ist und muss dann noch einmal genauso lange auf die Fertigstellung warten. Und außerdem kann ich das „agile Haus“ schon teilweise benutzen.

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.

Konstantin Diener: Die Frage ist immer, was eleganter bedeutet. Nicht ohne Grund gibt es den Spruch über Informatiker: „Gib ihnen ein Problem und sie entwickeln eine Programmiersprache bzw. ein Framework, mit dem solche Probleme perfekt gelöst werden können.“ Ich will damit sagen, dass wir uns in der Softwareentwicklung auch gern „verkünsteln“. Deswegen arbeitet man in agilen Teams in der Regel ja mit „Good enough for now“-Lösungen. Dieses Konzept ist aber nur richtig angewendet, wenn das Team kontinuierlich Refactoring betreibt (in der Summe ein ganzes Haus wieder einreißt). Außerdem habe ich mit detaillierten Spezifikationen die Erfahrung gemacht, dass die meisten der dort getroffenen Abstraktionen sich als falsch herausstellen.

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.

Konstantin Diener: Das agile Manifest sagt nichts über den Umfang der Dokumentation, sondern nur, dass lauffähige Software wichtiger ist. Ich weiß, dass dieser Satz oft als „schreibt gar keine oder nur ganz wenig Dokumentation“ verstanden wird. Ich verstehe ihn als Anlass, über den richtigen Umfang von Dokumentation nachzudenken. In klassischen Projekten wird nämlich in der Regel viel zu viel sinnlose Dokumentation mit großem Aufwand erzeugt. Das geht zum Teil so weit, dass Klassen oder Methoden lausige Namen bekommen, weil man ja eh noch Javadoc dranschreiben muss. Oder dass Schnittstellendokumentationen in ein Write-only-Wiki geschrieben werden, anstatt sie in einem Format zu beschreiben, das sich gleichzeitig für automatisierte Tests eignet.

Scrum hat für mich nicht direkt etwas mit Technik zu tun, sondern ist ein Mittel zur Produktentwicklung, Arbeitsorganisation und kontinuierlichen Verbesserung.

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.

Konstantin Diener: Scrum hat für mich nicht direkt etwas mit Technik zu tun, sondern ist ein Mittel zur Produktentwicklung, Arbeitsorganisation und kontinuierlichen Verbesserung. Auch ohne die heutigen CI-Server und Testframeworks lässt sich mit Scrum immer noch einfacher auf Veränderungen reagieren und es lassen sich benutzbare Inkremente schneller ausliefern – noch dazu in einem sich verändernden Umfeld. Die Tools helfen uns in der Regel dabei, effizient zu sein. Scrum hilft uns dabei, effektiv zu sein. Kurz gesagt, bringen mir alle CI-Server, Testframeworks etc. keinen Mehrwert, wenn ich erst nach zwei Jahren feststelle, dass ich das falsche Produkt baue.