Vom Sport können wir viel für die Entwicklung von Software lernen. So können wir vom Segelsport etwas über den sinnvollen Einsatz vom Bordcomputer für die Steuerung einer Yacht in einer Segelregatta abschauen. So wie der wohl bekannteste Segelwettbewerb, der Americas Cup, in einzelnen Rennetappen (Match Races) stattfindet, so werden bei der agilen Softwareentwicklung fest definierte Zeitetappen von etwa 30 Tagen gesetzt. Bei Scrum heißen diese Etappen Sprints.
Eine der wichtigsten Rollen an Bord der Segelyachten ist der Navigator. Dieser hat zwei simple und doch schwierige Aufgaben: Sicherzustellen, dass das Boot anhand der Gegebenheiten wie Wind, Strömung etc. schnell fährt und dass es in die richtige Richtung fährt. Er überprüft mithilfe seines Bordcomputers, ob das Geschwindigkeitspotential den Wetterbedingungen entsprechend ausgenutzt wird. Bei Scrum hat der ScrumMaster die Funktion eines Navigators. Er überwacht, dass alle Prinzipien eingehalten werden und dass das Scrum-Team somit möglichst effektiv ans Ziel kommt.
Der Steuermann auf den Yachten führt das Ruder und gibt damit die Richtung an, in die das Schiff steuert. In Scrum entspricht dies der Rolle des Product Owner, der die Sicht des Kunden vertritt und bestimmt, was mit höchster Priorität umgesetzt wird.
So wie der Bordcomputer Informationen zur Position der Yacht in der Regatta liefert, so schaffen Scrum-Tools Transparenz bezüglich des Projektstandes. Sie sind nützlich für die Verwaltung der zu erledigenden Aufgaben und der Planung. Das einfachste und sehr oft verwendete Tool ist hierbei eine Pinnwand mit Kärtchen und ggf. ein Excel-Sheet. Damit sollte jedes Team das anfängt sich mit Scrum zu organisieren, beginnen. So ist es möglich, im zuerst kleinen Kreis, den Umgang mit den für Scrum typischen Arbeitsabläufen zu erproben. Gemeinsam wird ein Taskboard gepflegt und bereits erledigte Aufgaben werden z.B. am Ende des Arbeitstages markiert.
Teams und Projekte wachsen mit der Zeit und ein unübersichtlicher Aufgabendschungel entsteht. Die Teams werden an verschiedene Standorte verteilt. Manche Teams arbeiten sogar über mehrere Zeitzonen. Der Einsatz von Hilfsmitteln für die Verwaltung wird dann unerlässlich.
Ein Kernkonzept in Scrum ist die Selbstorganisation des Teams. Dies ist ein radikal anderes Konzept als im klassischen Projektmanagement. Hier gibt es niemanden der vergleicht ob und wie schnell einzelne Teammitglieder Arbeitsschritte durchgeführt haben. Wie auf einer Segelyacht bringt jeder die Leistungen, die erforderlich sind, um die Etappe zu gewinnen. Da in einem cross-funktionalen Team prinzipiell jeder an allen Aufgaben mitarbeiten kann, interessiert hier nur das gemeinsam geleistete Ergebnis und dass, was noch gemeinsam zu erledigen ist. In einem sich selbst organisierenden Team ist jedes Mitglied selbst-verantwortlich und proaktiv. Das ist ein sehr hoher Anspruch an alle Beteiligten. Kooperation, Kommunikation und Offenheit sind erforderlich. Jedes Teammitglied sollte zu jedem Zeitpunkt auf alle Informationen eines Projektes zugreifen können.
Scrum bezieht seine Effektivität aus der Fähigkeit der Beteiligten ihr Potential zusammen zu schließen, sodass das Ganze mehr wird als die Summe aller Teile. Sobald ein Konkurrenzverhalten der Teammitglieder untereinander gefördert wird, ist das Miteinander geschwächt. Metriken für die Verwaltung von Aufgaben sollten also immer nur das Gesamtsystem darstellen und nicht die geleistete Arbeit von Einzelpersonen. Der wirkliche Beitrag einer Einzelperson zum System ist nur in einer Fließbandproduktion in Arbeitseinheiten quantifizierbar, nicht aber in einem Entwicklungs- und Lernprozess.
Die Komponenten von Scrum
Auf den ersten Blick bietet Scrum einen Rahmen aus Zeitabläufen und verschiedenen Meetings, die zu bestimmten, festen Zeitpunkten abgehalten werden. Es gibt Iterationen von 30 Tagen, Sprints genannt, die fest eingehalten werden. Zu jedem Sprint werden Meetings fest eingeplant. Dies sind der tägliche Scrum, die Sprint Planungsmeetings am Anfang, sowie Produkt-Review und Pozess-Retrospektive am Ende. Des weiteren gibt es ein Product-Backlog, in dem alle zu erledigenden Anforderungen geführt werden. Für jeden Sprint werden Backlog-Einträge ausgewählt und abgearbeitet.
Auf den zweiten Blick wird dieser Rahmen gefüllt mit menschlichen Beziehungen und Bewusstsein, Kooperation und Selbstorganisation, sowie Kreativität, Mut und Vertrauen. Dieses sind alles formlose Faktoren, die nur subjektiv erfassbar sind. Verständigung zwischen den Menschen in einer Organisation kann nicht erzwungen werden. Machtspiele und verdeckter Boykott lassen sich nicht verbieten. Vertrauen kann nicht gefordert werden. Die einzige Möglichkeit die wir haben, um auf die formlosen Faktoren in der menschlichen Zusammenarbeit einzuwirken, ist indirekt. Dazu sind die richtigen Rahmenbedingungen erforderlich. Es ist vergleichbar mit den Spielregeln die für ein gutes Gesellschaftsspiel, wie Skat, gelten. Trotz gleicher Regeln ist jede Skatrunde eine eigene Welt.
Scrum bietet viele Hilfsinstrumente, um die Spielregeln einzuhalten.
Time-Boxing
Iterationen, die auf einen festen Zeitrahmen von z.B. 30 Tagen fixiert sind, profitieren von Vorteilen die daraus folgen:
Ein Projekt, bei dem in der laufenden Iteration, mit festem Zeitfenster, nur die Features mit der augenblicklich höchsten Priorität implementiert werden, haben kein Zeitproblem mehr. Damit fällt der größte menschliche Stressfaktor weg.
Wenn der Zeitrahmen bis zur nächsten Produktauslieferung fixiert ist, dann gibt es nur noch Schwierigkeiten bei dem setzen von Prioritäten und der Bereitstellung von Programmierkapazität.
Wenn nur die Features mit der höchsten Priorität umgesetzt werden, dann ist das Resultat automatisch der größte mögliche Wertzuwachs.Wenn jede Iteration das bestmögliche Produkt für den Kunden liefert und das Produkt „fertig“, also auslieferbar, ist, dann liegt das Projekt immer in der Zeit. Es wären dann andere Faktoren als Zeit zu diskutieren. Dies sind dann Qualifikation der Entwickler um mehr Features in einer Iteration zu verwirklichen. Die Optimierung der Kommunikation wäre ein Diskussionspunkt. Höhere Investitionen früher in der Zeit könnten Thema sein. Eventuell das Thema Motivation. Zeitplanung, als solches, ist aber kein Thema mehr.
Backlog Priorisieren
Prioritäten festlegen ist die Aufgabe des Kunden. Ein gut priorisierter Product-Backlog ist die Basis für die Planung.
Relative Schätzung
Da Software ein Entwicklungsprozess ist und keine Reproduktion am Fließband, ist es bei einem durchschnittlichen Projekt nicht möglich abzuschätzen, wie viele Stunden die Implementierung eines Features dauert. Es ist sehr wohl möglich zu schätzen, wie groß der Brocken ist, den ein Feature relativ zu einem anderen darstellt. Dazu wird ein Feature als Referenz festgelegt. Es ist so möglich abzuschätzen, ob ein anderes Feature größer, kleiner, doppelt so groß oder zehn mal so groß erscheint. Zu große Einheiten sollten in überschaubare aufgeteilt werden.
Planungspoker
Die relative Größe von Features lässt sich gut gemeinsam im Team schätzen. Diese Gruppenaufgabe hat verbindenden Charakter. Wenn jeder dabei ist, dann ist das gleichzeitig ein Committment für das Projekt. Wenn der Schätzvorgang als Planungspoker durchgeführt wird, dann wird es zu einem spielerischen Vergnügen. Diese Form von Poker funktioniert folgendermaßen:
jeder Teilnehmer bekommt einen Satz Pokerkarten mit den Ziffern 1, 2, 3, 5,10, 13, 20
Die Ziffern stehen für die relative Größe von Features zueinander. Eine mittelgroßer Brocken hat die Einheit 5.
Zuerst wird eine Referenzaufgabe festgelegt, relativ zu der weitere geschätzt werden.
Jedes Feature aus der Anforderungsliste (Product-Backlog) wird der Reihe nach bearbeitet, indem jeder, wie beim Pokerspiel, gleichzeitig seine Karte mit der Schätzzahl auf den Tisch legt.
Die geschätzte Größe ergibt sich aus dem Durchschnittswert.
Es zeigt sich hierbei, bei welchen Anforderungen Verständigung darüber notwendig ist, was hier gemeint ist.
Die relative Größe sagt nichts über die Zeit aus, die notwendig ist um das Feature zu Implementieren. Damit ist dieser Schätzvorgang unpolitisch.
Von der relativen Grösse zur Sprintplanung
Bei der Planung für den nächsten Sprint muss das Team abschätzen, wie viele Aufgaben aus dem Product-Backlog in der nächsten Iteration von 30 Tagen umsetzbar sind. Dazu ist es notwendig zu wissen, wie viel Zeit eine mittlere oder kleine Aufgabe in Anspruch nimmt. Daraus lassen sich dann Zeiten für größere Aufgaben errechnen. Ein neu gebildetes Team braucht mindestens drei Sprints, bis ihm genaue statistische Werte zur Verfügung stehen. Vorher kann es nur grobe Schätzungen abgeben.
Review und Retrospektive
In Scrum gibt es 2 verschiedene Ebenen des Beobachtens und Lernens:
a) Das aktuelle Produktergebnis wird zusammen mit dem Kunden inspiziert. Ist das Ergebnis so, wie der Kunde sich das vorstellt? Was lernen wir aus dem Prototyp für den nächsten Sprint?
b) In der Retrospektive wird der Teamprozess untersucht. Was lief gut, was lief schlecht? Wie können wir unseren Prozess verbessern? Die kontinuierliche Gestaltung der Prozesse wird so zu einem Führungsinstrument, mit dem jeder am Projekt Beteiligte einbezogen wird. Dies ergibt eine Rückkopplung mit der der Effizienzgrad im Team ständig erhöht wird. Damit hat jedes Team seine eigenen Spielregeln und somit sein eigenes Scrum.
Fazit
Scrum ist mehr als nur ein neuer Hype oder ein neues Produkt. Ähnlich wie in einem Match Race fordert es das gesamte Potential eines Softwareentwicklungsteams. Ein Team ist mehr als die Ansammlung von Personen. Wenn die Intelligenz, Kreativität und das menschliche Potential von Entwicklern zusammengeschlossen wird, dann ist das Ergebnis etwas völlig anderes, als die Summe aller Teile. Scrum bietet uns ein Konzept, mit dem wir es schaffen diese Ressourcen zu nutzen. Es hilft uns nicht nur die logisch-rationalen Fähigkeiten zu nutzen, sondern auch unsere zutiefst menschlichen wie Intuition, Bauchgefühl, Empathie und Vertrauen.
