Eines der Ziele bei der Entwicklung von Scrum war es, den Teams mit möglichst hoher Wahrscheinlichkeit dazu zu verhelfen, einen sogenannten „hyperproduktiven Zustand“ zu erreichen. Hierunter versteht man eine Projektsituation, in der die tatsächliche Produktivität um den Faktor 5 bis 10 über dem in der Industrie üblichen Durchschnitt liegt.
Hyperproduktivität ist schwierig zu beschreiben. Die meisten Personen, die man fragt, kommen nach einiger Überlegung zumeist nur zu der Aussage „wenn man es vor sich hat erkennt man es“. Fast jeder, der Teil eines solchen Teams war, fügt außerdem noch hinzu: „Ich habe nie zuvor härter gearbeitet als in diesem Projekt, hatte aber trotzdem mehr Spaß bei der Arbeit als jemals zuvor. Es war einer der Höhepunkte meiner Karriere“.
Manche Projekte haben sich sogar bis zu einem Punkt beschleunigt, an dem von außen bremsend eingewirkt werden musste.
Eine Erklärung dieses Umstands scheint zwar schwierig. Clinton Keith hat jedoch vier wesentliche Punkte für das Erreichen von Hyperproduktivität identifiziert:
- Unabhängigkeit und gefühltes Eigentum für das Projektergebnis: Das Team fühlt, daß es frei und kreativ arbeiten und trotzdem die Kontrolle über das Projekt behält
- Führung: Es gibt eine Person, die das Team und den Kunden auf eine gemeinsame Vision einschwören und das Team auf Kurs halten kann
- Kompetenz: Nicht jeder im Team muß ein Experte auf seinem Gebiet sein, jedoch war in hyperproduktiven Teams so gut wie immer ein Experte auf dem Kerngebiet des Projekts vorhanden. Er dient als Vorbild für das restliche Team.
- Zusammenarbeit: Hyperproduktive Teams arbeiten zumeist ohne Vorbehalte zusammen. Jeder fühlt sich dafür verantwortlich, dem anderen so gut zu helfen wie er kann.
Ein weiterer Punkt scheint auch die Anwendung verschiedener Techniken aus dem „Extreme Programming“ (XP) zu sein. Dies deckt sich sowohl mit unseren eigenen Erfahrungen, als auch mit der Literatur (siehe z.B. „Distributed Scrum: Agile Project Management with Outsourced Development Teams“ von Jeff Sutherland et al, oder auch „On the Productivity of Agile Software Practices: An Industrial Case Study“ von Maurer und Martel).
Als besonders produktivitätssteigernd haben sich vor allem diese Techniken und Prinzipien aus XP herausgestellt:
- (Verzicht auf) Dokumentation: Soll nur da erstellt werden, wo es auch sinnvoll ist. Ansonsten ist es besser, sich die Dokumentation aus dem Quellcode generieren zu lassen. Scrum und XP sind nicht dokumentengetrieben. Abnahmen o.ä. erfolgen immer anhand ausgelieferter Funktionalität, und nicht von Dokumenten. Es ist daher explizit möglich (und gewünscht), den Umfang der Dokumentation so weit wie möglich zu reduzieren.
- Continuous Integration: Darunter versteht man das Automatisieren des Neubildens und Testens der Anwendung. Sobald ein Entwickler etwas neues in die Versionsverwaltung eincheckt wird automatisch die Anwendung komplett neu gebaut und alle Tests ausgeführt. Geht hierbei irgendwas schief werden die Änderungen zurückgenommen und dem Entwickler nochmal zur Korrektur vorgelegt. Dies erhöht die Produktivität gleich in mehrfacher Hinsicht: Die sofortigen Unit-Tests erhöhen die Wahrscheinlichkeit, Fehler direkt beim Einchecken zu entdecken. Zudem hat man zu jedem Zeitpunkt einen lauffähigen Stand, etwa für Vorführ- oder Testzwecke. Continuous Integration erlaubt daher schnelleres Feedback als die traditionelle Methode und erhöht dabei auch noch die Qualität.
- Pair Programming: Beim Pair Programming arbeiten zwei Entwickler an einem Computer. Das mag zwar im ersten Moment etwas befremdlich klingen (nur 50% Produktivität?), ist aber genau das Gegenteil. Die Erfahrung hat gezeigt, daß zwei Entwickler an einem Computer schneller vorankommen als wenn sie jeweils an einem eigenen Rechner sitzen würden. Diese Methode fördert zudem den Wissenstransfer und beugt der Bildung von Wissensmonopolen vor. Die Wahrscheinlichkeit, daß ein kranker Entwickler das gesamte Projekt in Verzug bringt, kann somit reduziert werden. Viele moderne IDEs (wie Eclipse oder Netbeans) verfügen heute über ein „Collaboration“-Plugin (siehe z.B. hier für Netbeans), wodurch auch verteilte Teams die Vorteile von Pair Programming nutzen können.
- Testgetriebene Entwicklung: Zu diesem Thema habe ich schon zu einem früheren Zeitpunkt mal einen Artikel geschrieben (siehe hier), weswegen ich hier nicht nochmal alles wiederholen möchte. Die Kernaussage ist jedoch, daß sich damit das Risiko der sich stetig wechselnden Anforderungen in den Griff kriegen lässt. Zudem erzieht es die Programmierer dazu, sich früh mit dem Design des Codes zu befassen und nicht mehr zu schreiben, als unbedingt notwendig ist.
In dem oben verlinkten Paper greift Jeff Sutherland zudem noch eine interessante, aus der Biologie stammende Beobachtung aus dem ersten Scrum-Projekt auf, die auch einen Teil zur Erhöhung der Produktivität beiträgt: Punktualismus. Dies beschreibt eine Beobachtung in der Evolution, wonach eine Art über einen längeren Zeitraum stabil bleibt, und dann in einem (relativ) kürzeren Zeitraum einen plötzlichen evolutionären Sprung macht.
Dieses Phänomen lässt sich interessanterweise wohl auch auf Software-Systeme übertragen. Auch hier bleibt die Funktionalität des Systems über eine gewisse Zeit (d.h. eine gewisse Zahl von Änderungen) stabil. Später jedoch kann bereits eine einzige weitere Änderung einen größeren Sprung der Funktionalität der Anwendung verursachen. Als Resultat davon konnten etwa in dem zitieren Scrum-Projekt einige Funktionen bereits vor dem gedachten Termin ausgeliefert werden, da bereits vorhandener Code eines anderen Entwicklers den Aufwand für die Realisierung der neuen Funktion wesentlich reduziert hat.
Dieser Aspekt ist auch Teil des bei Toyota eingesetzten Prinzips des „Set-Based Concurrent Engineering“ (SBCE). Entwickler betrachten mögliche Lösungsvorschläge und engen diese nach und nach ein, sodass irgendwann ein einziger Lösungsweg übrig bleibt. Die Entscheidung, wann und wie diese Funktion implementiert wird, wird jedoch so lange wie möglich hinausgezögert. Erst ganz zum Schluss wird die am meisten fortgeschrittene Komponente als Ort für die Umsetzung ausgewählt, wodurch man weniger Entwicklungsaufwand hat und eine elegantere Architektur erhält.
Basierend auf den oben angesprochenen Punkten lässt sich auch relativ einfach ablesen, wie sich Hyperproduktivität zuverlässig verhindern lässt:
- Kein Feedback: Ein geschlossener Feedback-Zyklus ist ein wesentlicher Faktor für stetige Verbesserung (PDCA: Plan, Do, Check, Act). Ohne ihn wird das Team daran gehindert, aus seinen Fehlern zu lernen und die Produktivität zu verbessern. Das ist z.B. mit ein Grund, warum das Wasserfallmodell in der Regel nicht funktioniert.
- Unzureichender Informationsaustausch: Ein schlechter oder langsamer Informationsaustausch bremst das Projekt. Dies ist v.a. auch ein Problem bei großen und/oder verteilten Teams ein Problem. Man sollte deswegen alle Register ziehen (auch technischer Art), diesen Nachteil so gut wie möglich auszugleichen. Man könnte bspw. ein Wiki oder ein Diskussionsforum einrichten, aber auch EMail oder Instant Messaging nutzen.
- Keine Kooperation im Projektteam: Gründe für eine mangelhafte Kooperation könnten z.B. politische Spielchen, persönliche Abneigungen, oder auch eine abweichende Unternehmenskultur sein.
- Mangelnde Selbstorganisation: Straffe Hierarchien, Command-and-Control Management oder auch mangelnde Unabhängigkeit des Projektteams stehen der Selbstorganisation im Wege, die aber eine der wichtigsten Voraussetzungen für das Gelingen eines Scrum-Projekts ist.
Michael Dubakov hat in einem Blog-Eintrag ausführlich gezeigt, daß Softwareentwicklung ein komplexes adaptives System ist.
Wenn man sich dessen Definition auf Wikipedia mal durchliest, so fallen einem dabei Begriffe auf wie „Selbstorganisation“, „Kommunikation“, „Anpassung“ oder „Feedback“.
Schon mal gehört? Richtig: Diese Begriffe stehen auch im agilen Manifest.
Sind agile Modelle daher besser geeignet um Hyperproduktivität zu erreichen als traditionelle Vorgehensweisen? Eine genaue Antwort darauf versuche ich in einem der nächsten Artikel zu geben.
BFI
Wird geladen ...
Eine Antwort
Hallo und guten Tag,
es ist schön zu lesen, was andere unter dem Wort „Produktivität“ bzw „Hyperproduktivität“ verstehen!
Ich habe den Artikel gelesen und bin zu dem eindeutigen Entschluss gekommen, dass „Scrum“ nicht mehr ist, als ein guter, ausgearbeiteter Plan, der zur Realisierung von Produktentwicklungen sehr hilfreich ist.
Ich studiere BWL und zum theoretischen Teil gehört immer der Praxisbezug!
„Scrum“ ist für mich kein außergewöhnliches Vorgehensmodell, sondern der Normal-/Optimalfall zur Erreichung der Ziele!
Ich bedanke mich und verbleibe mit freundlichem Gruß!