Category Archives: Programmierung

Scrum baut keine Häuser

Obwohl ich fast nie formal nach agilen Prozessmodellen wie z. B. SCRUM gearbeitet habe, bin ich ein Befürworter agiler Vorgehensweisen (Manche werden sagen: gerade deshalb). Sie dienen in erster Linie dazu, Prozesse möglichst schlank zu gestalten, Anpassungen im gesamten Projektverlauf so leicht wie möglich zu machen und sollen die Zusammenarbeit der Entwickler fördern. Der Kerngedanke liegt darin, Interaktion zwischen den Projektbeteiligten zu fördern und die Identifikation mit dem Projektziel zu maximieren.

„People and interactions are more important than processes and tools.“ Das ist der Kerngedanke des berühmten (berüchtigten) agilen Manifests. Das sollte man nicht aus den Augen velieren. Dem liegt zu Grunde, dass ein Team besonders effektiv und motiviert arbeitet, wenn sich jeder einzelne dem gemeinsamen Ziel des Teams verpflichtet fühlt und mit Begeisterung auch eigene Ideen einbringt.

Um diese Zusammenarbeit zu fördern wurde SCRUM als Vorgehensmodell für die Umsetzung von Softwareprojekten entwickelt. Kernkonzepte sind:

  1. Das Team trifft sich täglich um sich über die anstehenden Aufgaben auszutauschen und festzulegen, wer welchen Teil der Arbeit übernimmt. (Daily Scrum)
  2. Die Arbeit wird in mehrere Blöcke zerlegt, die in einem definierten Zeitraum zum Abschluss gebracht werden müssen („Sprint“). Was in einem solchen Block erarbeitet werden soll, wird erst unmittelbar vor Beginn dieses Blocks (Sprints) vom Team gemeinsam mit dem Product Owner (vergleichbar dem Produktmanager in klassischen Modellen) festgelegt.
  3. Die Komplexität der einzelnen Arbeitsschritte (innerhalb eines Sprints) wird vom Entwicklungsteam (gemeinsam) abgeschätzt – es erfolgt keine unmittelbare Zeitschätzung.
  4. In jedem Sprint wird ein Produktteil in solcher Qualität erstellt, dass er veröffentlicht werden kann.
  5. Es gibt einen sog. SCRUM Master, der die Einhaltung des SCRUM-Prozesses überwacht und dafür sorgt, die Arbeitsbedingungen des Teams zu optimieren (z. B. indem er dafür sorgt, dass das Team ungestört auf das aktuelle Sprintziel hinarbeiten und keine zusätzlichen Anforderungen direkt in das Team hineingetragen werden.
  6. Nach jedem Sprint folgt eine sog. Retrospektive, die dazu dient, die eigene Arbeitsweise und deren Ergebnisse zu analysieren mit dem Ziel der kontinuierlichen Verbesserung.

Der Unterschied zu klassischen Projekten liegt im wesentlichen darin, dass die Inhalte von Sprints erst unmittelbar vor der Umsetzung detailliert festgelegt werden und dadurch Änderungen an den Anforderungen problemlos im Projektverlauf möglich sind.

Gerne wird in diesem Zusammenhang das Beispiel des Hausbaus verwendet, z. B. hier:

Scrum baut keine Fertighäuser

oder auch mehr oder weniger ironisch, ungefähr so:

Kunde: Familie mit zwei Kindern

Kundenanforderung:

Als Familie möchten wir ein kleines Einfamilienhaus mit einem großen Wohnzimmer, zwei Kinderzimmern, einem Schlafzimmer und dann noch eine Garage für das Auto.

Mit diesem unvollständigen Satz an Anforderungen legt das Projektteam bereits los. Es wird zunächst das Wohnzimmer gebaut und nach und nach ggf. die restlichen Zimmer. Plötzlich entscheidet der Kunde, dass er auch noch einen Hobbykeller möchte – was nun?

Hier muss man sich eines klar machen: Der Vergleich des Hausbaus mit einem Softwareprojekt hinkt auf diese Art ganz gewaltig. Das was beim Hausbau der konkrete Zusammenbau eines Hauses durch die Handwerker ist, ist nicht mit dem Inhalt eines Sprints nach SCRUM vergleichbar. Denn der Zusammenbau von Software-Komponenten – der Build-Prozess (!!) ist in der Softwareentwicklung zum Glück viel weniger aufwendig. Genau dadurch wird Agilität ermöglicht.

Vergleichbar ist viel eher die Planung eines einzelnen Raumes (z. B. des Wohnzimmers) mit einem Sprintziel. Dann werden eine ganze Reihe von Parallelen sichtbar: Der Architekt macht einen ersten Entwurf für ein Zimmer (es ist egal, mit welchem er anfängt, es sind beliebige Änderungen möglich. Der Kunde muss zunächst keine konkrete Vorstellung von der Größe der einzelnen Räumen und deren Anordnung haben sondern kann sich in vielen Iterationen daran annähern und natürlich wird der Architekt versuchen, den Kunden so früh und so regelmäßig wie möglich über seine Fortschritte zu informieren. Dann erst wird das Haus gebaut – aber das ist nicht mehr SCRUM, das ist der Nightly Build oder ein Klick in Visual Studio.

Also: Scrum baut keine Häuser. Scrum entwirft Baupläne.

Fragen, Kommentare und Anregungen sind ausdrücklich erwünscht.