Scrum für die Softwareentwicklung.
1.1.3Von den ersten Artikeln bis zum Scrum Guide
Im Jahr 1997 veröffentlichte Ken Schwaber ein Paper mit dem Titel »SCRUM Development Process« auf der OOPSLA (siehe [Schwaber1997]). Dieser Artikel war die erste veröffentlichte Beschreibung von Scrum für die Softwareentwicklung. Im Jahre 1999 veröffentlichten Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber und Jeff Sutherland auf der PLOP-Konferenz einen Artikel mit dem Titel »SCRUM: A Pattern Language for Hyperproductive Software Development« (siehe [Beedle et al. 1999]).
2000 veröffentlichte Kent Beck sein Buch »Extreme Programming Explained – Embrace Change« (siehe [Beck2000]) und begleitete die Markteinführung des Buches durch eine Reihe von Konferenzvorträgen. eXtreme Programming (XP) nahm Grundgedanken von Scrum auf und ergänzte sie um Programmiertechniken, wie die testgetriebene Entwicklung und das Pair Programming. XP war für die damalige Zeit radikal und polarisierte: Der Großteil der Softwareentwicklungsbranche fand XP absurd oder utopisch. Eine kleine, aber sehr leidenschaftliche Gemeinschaft von Entwickler:innen sah darin jedoch einen notwendigen Paradigmenwechsel. Immer mehr Teams setzten XP erfolgreich ein, und das Interesse stieg immer weiter an. In diesem Zuge erlangte auch Scrum eine größere Bekanntheit. Die Community war sehr wissbegierig und experimentierfreudig und suchte stets nach neuen Inspirationen. So wurden weitere Ansätze mit ähnlichen Denkmodellen entdeckt oder entwickelt, wie z.B. Crystal (siehe [Cockburn2004]) und Feature Driven Development (siehe [PalmerFelsing2002]).
Diese Ansätze wurden zunächst unter dem Sammelbegriff »leichtgewichtig« zusammengefasst. Im Jahre 2001 trafen sich einflussreiche Vertreter:innen dieser »leichtgewichtigen« Ansätze (inkl. Ken Schwaber und Jeff Sutherland) in Snowbird und definierten das Agile Manifest, das gemeinsame Werte und Prinzipien festlegte (siehe [AgileManifesto2001]). Für die Werte wählten die Autor:innen Gegensatzpaare:
»Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.«
Seitdem nennen wir die genannten Ansätze nicht mehr »leichtgewichtig«, sondern agil.
Bei der Umsetzung in die Praxis erreichte Scrum die mit Abstand größte Verbreitung. Ken Schwaber und Mike Beedle veröffentlichten 2002 das erste Scrum-Buch (siehe [SchwaberBeedle2002]). Viele Scrum-Teams integrierten Entwicklungspraktiken aus XP (siehe dazu auch Kap. 4). Die anderen Ansätze sind in der Praxis fast bedeutungslos. Vor einigen Jahren brachte David Anderson mit Kanban frischen Wind in die Szene (siehe [Anderson2010]). Während es zunächst zwischen der Scrum- und der Kanban-Community starke Abgrenzungstendenzen gab, versteht man sich heute gegenseitig besser, und in der Praxis werden sowohl Scrum wie auch Kanban eingesetzt – mitunter sogar im selben Projekt.
Zuletzt veröffentlichten Ken Schwaber und Jeff Sutherland ihr erstes gemeinsames Scrum-Buch mit dem Titel »Software in 30 days«. Das Buch führt Manager in die Scrum-Denkweise ein und beleuchtet auch die Frage, wie Transitionen hin zu Scrum gestaltet werden können (siehe [SchwaberSutherland2012]).
Im Jahre 2010 veröffentlichten Ken Schwaber und Jeff Sutherland den ersten Scrum Guide, die offizielle Scrum-Definition (siehe [SchwaberSutherland2020]). Der Scrum Guide wird kontinuierlich weiterentwickelt; die aktuelle Version findet sich auf http://scrumguides.org. Dort existieren auch Übersetzungen in viele Sprachen, unter anderem ins Deutsche.
1.1.4Verbreitung von Scrum
Scrum ist in der agilen Softwareentwicklung der De-facto-Standard. In unserer Wahrnehmung schwankt die Durchdringung mit agilen Ansätzen stark zwischen Branchen. Wo die entwickelte Software direkte Bedeutung für den Unternehmenserfolg hat und hoher Marktdruck herrscht, ist agile Entwicklung der Standardfall und sequenzielle Verfahren sind die Ausnahme. Das Paradebeispiel ist das E-Business.
Weniger stark verbreitet ist agile Entwicklung dort, wo z.B. Inhouse-Anwendungen für die Sachbearbeitung in Konzernen entwickelt werden. Ob die Entwicklung einer neuen Buchhaltungssoftware in einer Bank oder Versicherung dieses oder nächstes Jahr kommt, macht sich in den Bilanzen kaum bemerkbar. In diesen Kontexten ist der Veränderungsdruck nicht so groß, und daher sind dort agile Verfahren weniger üblich. Allerdings gibt es so gut wie kein größeres Unternehmen, das nicht mindestens agile Pilotprojekte durchgeführt hat.
Mit der zunehmenden Verbreitung agiler Verfahren hat man inzwischen herausgefunden, dass diese auch in den Bereichen einsetzbar sind, die gemeinhin als schwierig gelten: große Entwicklungen mit über 100 Beteiligten, verteilte Teams, regulierte Umfelder (z.B. Medizinbereich), Automotive, Business Intelligence, Entwicklung von Hardware etc.
In den letzten Jahren haben Scrum und andere agile Ansätze auch außerhalb der Softwareentwicklung immer weitere Verbreitung gefunden: bei der Entwicklung von Hardware (siehe [wikispeed]), für generelles Management und Unternehmensorganisation (siehe [Denning2010], [Laloux2014]), für Unternehmenstransitionen (siehe Kap. 7), Entwicklung und Erbringen von Services sowie für Marketing und Vertrieb (siehe [Lammers2015], [Reppin2015], [vanSolingen et al. 2011]).
1.2Vorteile von Scrum
Scrum kann viele Vorteile mit sich bringen. Relevante Vorteile werden durch das Arbeiten in kleinen Einheiten (Batches) erzeugt: kürzere Time-to-Market, höhere Qualität und größere Effizienz. In Anlehnung an Don Reinertsen (siehe [Reinertsen2009]) erklärt Abbildung 1–4 diese Vorteile.
Abb. 1–4Scrum-Vorteile
Neben den kleinen Arbeitseinheiten wirken das cross-funktionale Team und die parallelen Phasen positiv auf die folgenden Aspekte:
Die parallelen Phasen verkürzen die Time-to-Market.
Die parallelen Phasen führen dazu, dass Probleme, Missverständnisse und Fehler früher entdeckt werden. Das führt zu kürzerer Time-to-Market sowie zu höherer Qualität.
Das cross-funktionale Team führt zu einer höheren Diversität bei der Arbeit, und die Wahrscheinlichkeit von Innovation steigt.
Durch die Arbeit im cross-funktionalen Team in parallelen Phasen sieht jedes Teammitglied seinen Beitrag zum ganzen Produkt und findet Sinn in seiner Arbeit. Das führt zu größerer Zufriedenheit und Motivation.
Wir beschäftigen uns in den folgenden Abschnitten genauer mit diesen positiven Effekten.
1.2.1Kürzere Time-to-Market
Die Time-to-Market verkürzt sich mit Scrum aufgrund zweier Ursachen. Zunächst führt Little’s Law (siehe [Little1961]) ganz mechanisch zu kürzeren Durchlaufzeiten: Die durchschnittliche Durchlaufzeit in der Entwicklung berechnet sich aus dem durchschnittlichen Work in Progress dividiert durch den durchschnittlichen