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.

Oliver Kraeft: Da stimme ich zu. Oft habe ich die Variante erlebt, dass nur das Daily Scrum stattfindet oder einzelne Teile des Scrum-Prozesses nicht vorkommen. Bei der Scrum-Master-Zertifizierung lernt man, dass man zwar etwas aus dem Prozess weglassen kann, es dann aber kein Scrum mehr ist. Aber auch die Variante, dass zwar Scrum verwendet wird, es aber nicht so genannt wird, habe ich kennengelernt.

Den Scrum-Prozess zu verwenden, ist eine große Umstellung für das Team. Die eigenen Tätigkeiten sind für alle sichtbar und sie ändern sich mitunter gegenüber dem klassischen Vorgehen. Das ist nicht jedermanns Sache.

Durch die Retrospektive verbessert sich der Prozess mit jedem Sprint.                                                                                                                                                                                    .

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.

Oliver Kraeft: Ich denke, die Softwareentwicklung hat sich im Laufe der Jahre stark verändert, beispielsweise durch Bücher wie „Design Patterns“, „Clean Code“ oder „Refactoring“ und auch durch die testgetriebene Softwareentwicklung. Dadurch hat sich der Fokus in Richtung bessere Codequalität bzw. laufende Codeverbesserung bewegt. Heute ist Refactoring Stand der Dinge, zumindest wenn es eine gute Testabdeckung gibt. Die gängigen IDEs unterstützen einen dabei. Durch das iterative Vorgehen kommt es zwangsläufig dazu, dass schon vorhandener Code verändert werden muss und deswegen Wert auf die Wart- und Veränderbarkeit gelegt wird.

Der Agile & Culture Track auf der W-JAX 2018

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.

Oliver Kraeft: Das kann zwar passieren, hat meiner Meinung aber nichts mit Scrum zu tun. Wenn es in einem Scrum-Prozess passiert, würde es auch ohne Scrum passieren. Man kann durchaus mehrere Sprints für Architekturüberlegungen und Prototypen verwenden. Um zu erreichen, dass die Codequalität hoch genug ist, benötigt man Codereviews, das sollte zur Definition of Done gehören. Es sei denn, alle Entwickler sind so brillant, dass das nicht nötig ist. Das ist aber meist nicht der Fall. Ich halte Codereviews jedenfalls für sehr wichtig.

Bei der Scrum-Master-Zertifizierung lernt man, dass man zwar etwas aus dem Prozess weglassen kann, es dann aber kein Scrum mehr 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.

Oliver Kraeft: Dieser These stimme ich nicht zu. Ob das Dokumentieren Teil der Arbeiten eines Softwareentwicklers ist, hat nichts mit Scrum zu tun. Die Dokumentation muss gewünscht sein, und dann ist sie ein Teil des Sprint Backlogs. Dokumentation muss ebenfalls Bestandteil der Definition of Done sein. In meinem aktuellen Projekt erfolgt ein Teil der Dokumentation durch die Tests, wodurch diese automatisch immer aktuell ist.

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.

Oliver Kraeft: Aus meiner Sicht ist Scrum den klassischen Vorgehensmodellen aus drei Gründen überlegen:

• Scrum beachtet eine der wichtigen Eigenschaften der Softwareentwicklung, nämlich dass sie ein iterativer (sich in kleinen Schritten wiederholender) Prozess ist.
• In regelmäßigen Abständen erhält der Kunde eine lauffähige Software, sodass Fehlentwicklungen schnell erkannt werden.
• Durch die Retrospektive verbessert sich der Prozess mit jedem Sprint.