Scrum und Hyperproduktivität Teil 2 – oder: Scrum für Fortgeschrittene

Die Idee hinter Scrum war nicht nur, Projekte erfolgreich abzuschließen, d.h. Zeit, Qualität und Budget einzuhalten ( obwohl das für sich alleine natürlich schon ein hehres Ziel wäre).

Es sollte darüber hinaus auch die Produktivität im Vergleich zur bisher eingesetzten Projektmanagementmethode auf einen neuen Level gehoben werden.

Eine Möglichkeit dazu wurde von Jeff Sutherland auf der Konferenz „Agile 2005“ beschrieben (nachzulesen hier). Sein Ansatz basiert im wesentlichen auf einer Arbeit von Nonaka und Takeuchi, die 1984 im „Harvard Business Review“ erschienen ist (siehe hier).

Darin beschreiben die beiden Autoren die Art und Weise, wie verschiedene japanische Firmen im Vergleich zu amerikanischen Firmen ihre Produkte entwickeln.

Dabei unterscheiden sie 3 prinzipiell verschiedene Arten der Produktentwicklung:

• Typ A: Ein rein sequentieller Ansatz, bei dem die Phasen strikt aufeinander folgen und eine neue Phase erst beginnt, wenn die vorherige Phase abgeschlossen wurde. Sie nannten diesen Ansatz auch „NASA-type phased program planning (PPP)“. Er wird von ihnen als veraltet angesehen.
• Typ B: Hier folgen die Phasen nicht strikt nacheinander, sondern aufeinanderfolgende Phasen können sich überlappen. Die nächste Phase kann also (ohne Zeitverzögerung) bereits beginnen, bevor die vorherige Phase abgeschlossen ist.
• Typ C: Hier können sich nicht nur aufeinanderfolgende Phasen überlappen (wie bei Typ B), sondern prinzipiell alle möglichen Phasen. Dieser Typ ermöglicht theoretisch die höchste Produktivität, ist aber sehr viel schwerer durchzuführen als die anderen beiden Arten.

Analog dieser Klassifizierung beschreibt auch Jeff Sutherland 3 verschiedene Arten von Scrum:

• Typ A: Sprint folgen immer sequentiell aufeinander. Ein neuer Sprint beginnt erst, wenn der vorherige Sprint abgeschlossen wurde. Die Zeit zwischen zwei Sprints wird für Organisation und Planung genutzt. Diese Zeit zwischen 2 Sprints bedeutet natürlich einen Verlust an Produktivität, bietet dem Team jedoch genügend Zeit zur Eingewöhnung und Anpassung. Aus diesem Grund dies oft bei neuen und noch unerfahrenen Teams eingesetzt: Zumindest in der Anfangsphase kann nämlich das so erhöhte Training die schlechtere Produktivität ausgleichen. Nach einiger Zeit sollte sich ein Team aber auf Typ B umstellen.
• Typ B: Zusätzlich zur vorherigen Variante werden hier in einen Sprint bereits Tasks eingebracht, die den nächsten Sprint vorbereiten. Dazu gehört z.B. die minimale Spezifikation einer User Story. Dies kann nämlich üblicherweise schon erledigt werden, bevor der nächste Sprint losgeht. Auf diese Weise ist das Product Backlog immer auf einem Stand, in dem der nächste Sprint so gut wie ohne Zeitverzögerung gestartet werden kann. Das ist vor allem auch dann wichtig, wenn tatsächlich mal der Fall eintritt, daß ein Sprint vorzeitig abgebrochen wird (was Scrum explizit erlaubt) und direkt ein neuer gestartet werden muß. Zudem ermöglicht erst diese Art von Scrum dem Team, in einen konstanten Rhythmus zu kommen. Diesen Rhythmus kann man auch als den „Herzschlag“ eines Projekts sehen. Ähnlich wie bei Lebewesen, so ist es auch hier nicht gut, wenn er stottert oder aussetzt. Fehlt ein solcher Rhythmus, so wird das auf Dauer die Moral beeinträchtigen, was sich natürlich auch auf die Produktivität niederschlägt. So konnte Abdel-Hamid z.B. zeigen, daß eine ständige volle Auslastung des Teams ohne konstanten Rhythmus und niedriger Moral die Produktivität halbieren kann (siehe hier)! Dagegen kann ein Team, das diese Art von Scrum beherrscht und richtig ausübt, seine Produktivtät im Vergleich zu Typ A um bis zu 100% erhöhen.
• Typ C: In diesem Typ von Scrum können sich verschiedene Sprints überlappen. Dies bedeutet, das Scrum-Team arbeitet zeitgleich an mehreren Sprints (und damit auch an mehreren Releases) in unterschiedlichen Stadien. Das benötigt natürlich zum Einen natürlich ein äußerst erfahrenes Scrum-Team (sprich: ein Team, das schon einige Zeit erfolgreich nach Typ B gearbeitet hat). Zum Anderen ist dies auch nicht mehr von einem Team alleine durchzuführen, sondern auf die Unterstützung durch die Organisation angewiesen, da Anpassungen etwa bei Versionskontrolle, Qualitätssicherung, Regressionstests und Releaseplanung gemacht werden müssen, um so viel wie möglich zu automatisieren (der manuelle Aufwand wäre ansonsten zu hoch und dadurch unrentabel). Macht man es jedoch richtig, so kann man auf diese Art Dutzende von Releases pro Jahr ausrollen. Als Beispiel führt Sutherland hier die Firma PatientKeeper an, die im Jahre 2005 auf diese Weise 45 Releases erfolgreich in Produktion gab und die Durchlaufzeit für neue Anforderungen (vom Antrag bis zur Produktivgehung) von 6 Monaten auf 1 Monat senken konnte.

Ein weiteres Kennzeichen eines nach Typ C arbeitenden Unternehmens ist totale Transparenz. Bei PatientKeeper z.B. waren alle Daten des Unternehmens für alle Angestellten zu jedem Zeitpunkt sichtbar. Zudem bekam jede Person täglich eine EMail mit allen Burndown-Charts und Impediments. So konnte man Probleme schon weit früher als bisher erkennen, und wenn nötig das ganze Unternehmen auf die Lösung eines Problems ansetzen.

Dank der oben angesprochenen weitestgehenden Automatisierung kostet das alles noch nicht einmal sonderlich viel Zeit: Die Vorgabe bei PatientKeeper war z.B. eine Dauer von 1 Minute pro Tag bei Teammitgliedern, und 10 Minuten pro Tag bei Projektmanagern.

Diese Vorgabe wurde auch erreicht:

Da man in 60 Sekunden natürlich nicht sonderlich viel ausrichten kann (langsame Anwendungen brauchen z.T. ja schon fast so lange um überhaupt zu starten) wurde es in das Tool integriert, das alle Entwickler sowieso ständig benutzen: Das Bugtracking-System. Dazu wurden die Tasks um genau 3 Felder erweitert:

• Initiale Schätzung
• Investierte Tage
• Fertigstellungsgrad in %

Auf diese Weise, so erläutert Sutherland, lässt sich sogar der „Heilige Gral der Buchführung“ erreichen: Microcosting jedes einzelnen Tasks, ohne den Entwicklern etwas anderes als ein sehr genaues Burndown-Chart zu zeigen.

Neuere Untersuchungen legen sogar nahe, daß sich Hyperproduktivität nicht nur für lokale, sondern auch für verteilte Teams erreichen lässt. Hier kommt u.a. zum Tragen, daß dank Breitband-Internetverbindungen Kommunikation und Zusammenarbeit heutzutage deutlich weniger ortsabhängig ist als früher, und dank moderner IDEs Entwickler sogar über Kontinente hinweg simultan am selben Quellcode arbeiten können.

Natürlich ist das Erreichen von Hyperproduktivität kein Selbstläufer. Verschiedene Techniken aus dem Extreme Programming scheinen sich jedoch sehr vorteilhaft auszuwirken. Scott Downey, Berater bei MySpace, hat zudem ein Verfahren entwickelt, mit dessen Hilfe er schon mehr als 40 Teams zu Hyperproduktivität verholfen hat.

Dies alles soll jedoch Thema des nächsten Artikels werden…

BFI