Scrum – verstehen und erfolgreich einsetzen. Henning Wolf

       Abb. 1–5Weniger Work in Progress reduziert Durchlaufzeiten.

      Man kann sich das gut an einem Fahrgeschäft in einem Vergnügungspark verdeutlichen. Der Work in Progress ist die Menge der Menschen in der Schlange und im Fahrgeschäft. Der Durchsatz ist die Menge an Menschen, die das Fahrgeschäft in einer bestimmten Zeiteinheit absolvieren können. Nehmen wir an, in der Achterbahn können 100 Menschen mitfahren. Eine Fahrt dauert 5 Minuten. Das Ein- und Aussteigen dauert zusammen noch einmal 5 Minuten. Dann beträgt der Durchsatz 100 Menschen/10 Minuten, also durchschnittlich 10 Menschen/Minute. Steigen gerade 100 Leute in die Achterbahn ein und stehen weitere 900 in der Schlange, wartet der nächste Gast, der sich an die Schlange anstellt, ca. 100 Minuten. Stehen nur 100 Menschen in der Schlange, muss er nur ca. 20 Minuten warten. Vergnügungsparks machen von dieser Erkenntnis Gebrauch und zeigen mit Schildern im Wartebereich an, wie lange man noch warten muss, wenn man das Schild erreicht hat.

      Der Durchsatz in der Softwareentwicklung ist die Menge an Funktionen, die ein Team in einer Zeiteinheit (z.B. Sprint) entwickeln kann. Der Durchsatz sollte sich über die kontinuierliche Verbesserung in Scrum langfristig erhöhen. Er wird sich aber häufig nicht sprunghaft verbessern. Im Gegensatz dazu ist der Work in Progress – also die Menge der begonnenen, aber nicht abgeschlossenen Arbeit – leicht änderbar. In Scrum erreichen wir dies durch das Sprint-Konzept. Es wird nur ein kleiner Teil der für das Produkt notwendigen Funktionen für den nächsten Sprint ausgewählt und damit der Work in Progress auf diesen Anteil beschränkt.

Eine zweite wichtige Ursache für die kürzere Time-to-Market findet sich in Untersuchungen über die Verwendung von klassisch entwickelter Software. Verschiedene Analysen kommen übereinstimmend zu dem Schluss, dass der Wertbeitrag der Funktionen in Software extrem unterschiedlich ist. So präsentierte Jim Johnson auf der XP-Konferenz 2002 eine Untersuchung an vier Softwareprojekten, die ergab, dass 64% der Funktionen selten oder nie genutzt wurden (siehe Abb. 1–6, [Johnson2002]).

       Abb. 1–6Ein Großteil der Funktionen in Softwaresystemen wird selten oder nie genutzt.

      Natürlich gibt es Funktionen, die selten benutzt werden und auf die man doch nicht verzichten kann (z.B. der Jahresabschluss in einer Finanzbuchhaltung). Allerdings kann man damit nicht den hohen Anteil (64%) am Gesamtumfang rechtfertigen.

      Arnold und Yüce berichten in [ArnoldYüce2013], dass bei einem Projekt bei Maersk Line die wertvollsten 25% der Features 90% der Wertschöpfung ausmachten.

      Wir können also häufig die Time-to-Market allein dadurch deutlich reduzieren, dass wir nur die wirklich wertvollen Funktionen implementieren. Scrum stellt dies sicher, indem der Product Owner die Funktionen priorisiert.

       1.2.2Höhere Qualität

      Zunächst mag die höhere Qualität überraschen, die mit Scrum einhergeht. Qualität steht bei Scrum aber kontinuierlich im Fokus der Betrachtung und wird nicht ans Projektende verschoben. Die Qualitätssicherung einer Funktionalität findet direkt nach ihrer Entwicklung statt. So werden Fehler bereits wenige Stunden oder Tage, nachdem sie produziert wurden, entdeckt. Dadurch sind sie um Größenordnungen leichter zu lokalisieren und zu beheben, als hätte man sie erst nach Wochen oder Monaten entdeckt. Insgesamt erhöht sich dadurch auch das Qualitätsbewusstsein bei allen Beteiligten.

      Außerdem führt Scrum zu gebrauchstauglicherer Software, weil Kund:innen und Anwender:innen regelmäßig Feedback zum Produkt geben.

       1.2.3Größere Effizienz

      In klassischen sequenziellen Prozessen (z.B. Wasserfall) arbeiten wir mit großen Batches. Es werden erst alle Anforderungen definiert, dann wird die Architektur des ganzen Systems festgelegt, dann werden alle Funktionen programmiert und schließlich alle Funktionen getestet. Diese großen Batches bringen sehr großen Verwaltungsaufwand mit sich, der allerdings meist nicht explizit sichtbar wird: Es müssen sehr große Zeiträume überplant werden. In diesen großen Zeiträumen kumulieren sich die Unwägbarkeiten, sodass man sehr viel Aufwand in Schätzungen, Puffer und Risikomanagement stecken muss.

      In Scrum planen wir nur sehr kleine Zeiträume detailliert und können daher sehr leichtgewichtig arbeiten. An vieles kann man sich einfach so erinnern, für den Rest reichen oft Haftnotizen oder Karteikarten aus.

      Außerdem sind Korrekturen in Scrum ungleich billiger, wenn sie sich auf vorangegangene Aktivitäten beziehen. Stellt sich beim Vorgehen nach dem Wasserfallmodell während des Testens heraus, dass grundsätzliche Festlegungen zur Systemarchitektur ungünstig waren, entstehen erhebliche Kosten. In Scrum würde man diese Art von Problemen viel früher entdecken und kann sie deshalb kostengünstiger beseitigen.

       1.2.4Mehr Innovation

      Wenn man mehrere Leute mit derselben Ausbildung und demselben Hintergrund in einen Raum steckt und sie bittet, kreativ zu sein, kommt meist nicht viel dabei heraus. Innovation entsteht aus Diversität und braucht Zusammenarbeit (siehe [Sawyer2008]).

      Das cross-funktionale Team in Scrum bietet daher gute Voraussetzungen für die Entwicklung innovativer Produkte.

       1.2.5Größere Arbeitszufriedenheit

      Nach Dan Pink ist extrinsische Motivation (also Belohnungen als Anreize) hochgradig schädlich für Wissensarbeit (siehe [Pink2011]). Stattdessen benötigt man intrinsisch motivierte Menschen, und man kann die Wahrscheinlichkeit für intrinsische Motivation erhöhen, wenn drei Dinge gegeben sind:

       PurposeIch muss den Zweck meiner Arbeit verstehen und sinnvoll finden.

       MasteryIch muss an der Aufgabe wachsen können, darf aber nicht maßlos überfordert sein.

       AutonomyIch kann das Wie der Aufgabenerledigung weitestgehend selbst bestimmen.

      Diese drei Forderungen erfüllt Scrum sehr gut. Das Team kennt die Produktziele, entwickelt Features, die direkt Nutzen für die Kund:innen stiften, und hat Kontakt zu den Kund:innen im Sprint-Review. Dadurch wird der Forderung nach Purpose Genüge getan. Autonomie ist für die Entwickler:innen bezüglich des Wie der Arbeit gegeben, und der Scrum Master stellt sicher, dass diese Autonomie von außen nicht verletzt wird. Durch die selbstorganisierte Teamarbeit besteht außerdem die Chance, immer wieder Aufgaben zu finden, an denen die Teammitglieder wachsen können.

      In der Konsequenz führt Scrum zu motivierteren, zufriedeneren Teammitgliedern. Natürlich gibt es vereinzelt Menschen, die mit Teamarbeit nicht gut zurechtkommen. Es werden also nicht unbedingt alle glücklich mit Scrum. Für den Großteil sollte das aber schon gelten. Ist das nicht der Fall, stimmt vermutlich irgendetwas mit der Art und Weise nicht, wie Scrum praktiziert wird.

       1.3Eignung

      Scrum eignet sich für die Entwicklung, wenn nennenswerte Probleme zu lösen sind. Für repetitive Tätigkeiten (z.B. Produktion oder Erbringen eines standardisierten Service) ist Scrum nur bedingt verwendbar und häufig zumindest ineffizient. Das verwundert auch nicht weiter, wenn man sich vergegenwärtigt, dass für das operative Erbringen einer Leistung andere Dinge wichtig sind als für die Entwicklung von Produkten oder Dienstleistungen.