Die vier Varianten der agilen Hardware-Produktentwicklung

Bild: Wikimedia Commons / Jonathan Juursema - CC BY-SA 3.0

Das Thema der Agilität im Hardware-Bereich hat leicht mythische Züge. Obwohl es sich um die älteste Variante der agilen Produktentwicklung handelt (dazu gleich mehr) gibt es in der von Softwareentwicklung und Organisationsentwicklung geprägten Community kaum jemanden der schon einmal daran beteiligt gewesen wäre. Die Folge ist die erwähnte Mythologisierung: irgendwie geht es, irgendwo findet es bereits statt, irgendwie ist es aber unklar wie es gehen soll. Die Wahrheit ist dabei viel profaner - ganz im Sinn der alten Erkenntnis, dass Agilität einfach zu verstehen aber schwer umzusetzen ist, sind die wesentlichen Erscheinungsformen der agilen Hardware-Herstellung einfach zu beschreiben - und schon oft beschrieben worden.

Prototyping

Die gerade erwähnte älteste Erscheinungsform agiler Produktentwicklung überhaupt. Bereits 1986 beschrieben Hirotaka Takeuchi und Ikujiro Nonaka in ihrem bahnbrechenden Artikel The New New Product Development Game wie crossfunktionale, selbstorganisierte, End to End-verantwortliche Teams bei Canon, NEC, Xerox und Honda in kurzen Zyklen neue Produkte entwickelten - Foto-Apparate, Computer, Kopierer und Autos. Wichtig ist in diesem Fall, dass es sich noch nicht um Serienfertigung handelte sondern um die Erstellung von Prototypen oder Vorserien-Modellen, deren Neuartigkeit und geringe Stückzahl den relativ hohen Handarbeits- und Abstimmungsaufwand nötig (und vertretbar) machte. Vergleichbare Vorgehensweisen gibt es in frühen Produktentwicklungsphasen bis heute.

Computer-aided Design

Ein anderer Ansatz um möglichst früh zu benutzbaren Ergebnissen zu kommen. Basierend auf den Erfahrungen der Vergangenheit werden neue Ideen durch eine IT-gestützte Machbarkeitsanalyse geschickt. Das ersetzt natürlich nicht die menschliche Kreativität (und das soll es auch nicht), es ermöglicht aber ein "fail fast, learn fast, try again" in sehr kurzen Zyklen. Wenn die Berechnungen z.B. zeigen, dass das Material eines Bauteils einer angedachten Belastung nicht standhalten würde, dann kann man direkt mit der Entwicklung einer verbesserten zweiten Version beginnen ohne von der ersten auch nur einen Prototypen erstellt zu haben. Beeindruckend ist auch die Spannbreite der möglichen Einsätze, sie reicht vom Hausbau bis zum Turnschuh.

3D-Druck

Ein erster Ansatz um auch die serielle Fertigung flexibler und anpassungsfähiger zu machen. Obwohl der 3D-Druck zunächst wie eine blosse Fertigungs-Art wirkt (z.B. im Bild oben) ist das wesentliche Element auch hier die Verbindung mit der IT. Moderne 3D-Drucker können mit einer einzigen Fertigungsanlage praktisch jede statisch mögliche Form erstellen ohne dafür umgebaut werden zu müssen, nötig ist dafür nur noch das Einspielen einer neuen Bauvorlage. Auf diese Art können in kurzer Zeit alle nötigen Einzelteile selbst für komplizierte Maschinen gebaut werden, zum Beispiel für Flugzeuge. Und auch von denen kann dann jedes Einzelne nochmal individuell angepasst werden.

Modulare Montage

Ein anderer Ansatz für die serielle Fertigung, diesesmal einer der darauf aufbaut, dass die zusammenzubauenden Einzelteile zwar immer gleich sind, es aber möglich ist sie in unterschiedlichen zusammensetzungen zu kombinieren. Konkret geschieht das dadurch, dass die lineare Fertigungsstrasse abgelöst wird durch verschiedene automatisierte "Montage-Inseln", die von einem (das Fliessband ersetzenden) Montage-Roboter in unterschiedlicher Reihenfolge angefahren werden können. Auch hier ermöglicht eine IT-Steuerung schnelle individuelle Ergebnisse, ohne dass die Fertigungsanlage dafür umgebaut werden müsste.

Rocket Science

Wie oben gesagt, Hardware-Agilität ist einfach zu verstehen aber schwer umzusetzen, tatsächlich so schwer, dass man immer wieder hört, dass das Ganze nur in der Theorie möglich wäre. Das es sehr wohl geht zeigt ausgerechnet eine Firma deren Tätigkeit (die Raumfahrt) im Englischen sprichwörtlich für extrem schwierige Herausforderungen steht. SpaceX ist nicht das einzige, vermutlich aber das prominenteste Beispiel dafür, dass sogar alle vier Varianten der agilen Hardware-Produktentwicklung gleichzeitig einsetzbar sind. Und eine Schlusspointe wird auch möglich - wer Hardware-Agilität meistert kann nach den Sternen greifen.

Kommentierte Links (LXIII)

• Tendayi Viki: Do Entrepreneurs Really Create More Transformative Innovations Than Intrapreneurs?

Es gibt Zahlen die überraschen, und die die Tendayi Viki hier aus einer älteren Studie ausgegraben hat gehören dazu: es waren keine Startups in denen die meisten bahnbrechenden Innovationen zwischen 1980 und 2010 gemacht wurden sondern Konzerne (auch für die 10 Jahre danach lässt es sich feststellen - das Meiste was unsere Welt verändert hat kommt aus den "Big Companies" der amerikanischen Westküste und asiatischen Ostküste). Was sich daraus ergibt: anders als in der öffentlichen Wahrnehmung verankert ist es nicht der Entrepreneur, also der genialisch veranlagte Erfinder/Unternehmensgründer, der unsere Art zu Leben und zu Arbeiten verändert. Wichtiger ist stattdessen der Intrapreneur, der als Teil einer grossen Organisation für deren bestehende Kunden Neues erschafft und Bestehendes verbessert. Ein Grund mehr den eigenen Mitarbeitern Raum zur Selbstorganisation und Selbstentfaltung zu geben. (siehe auch Vikis zweiten Artikel zu dem Thema: Why Intrapreneurs Are Not Just Entrepreneurs Working Inside Large Companies)

• Yuri Malishenko: How visual thinking can make you a better agile coach

  Dass es hilfreich ist neue Informationen auch mit einfachen Bildern zu visualisieren um sie mit verschiedenen Sinnen aufnehmen zu können ist nichts was die "agile Bewegung" erfunden hätte, schon die Jahrtausende alten Höhlenmalereien beruhen auf diesem Prinzip. Mit dem Aufkommen von Flip-Charts und Post-Its auch im Büro-Kontext anwendbar geworden sind diese schnell erstellten Zeichnungen aber zu einem Erkennungszeichen agiler Teams und Coaches geworden und tragen zur Soft Power der Agilität bei. Yuri Malishenko gibt mit seinem Artikel einen interessanten Einblick in diese "Kleinkunst", sowohl in Bezug auf die verschiedenen möglichen Anwendungsgebiete als auch in Bezug auf die digitale Wieder- und Weiterverwendung. Gerade letzteres dürfte in einer Zeit zunehmender Remote-Arbeit immer wichtiger werden.
  

• Ellen Merryweather: The Difference: Prototype vs MVP

  Nicht nur im Startup-Umfeld, auch in mittleren und grossen Unternehmen gibt es den zunehmenden Trend Produktentwicklungen mit einem Prototypen oder MVP zu beginnen statt von Beginn an umfangreiche "fertige" Versionen zu entwickeln von denen sich dann beim Release herausstellt, dass kein Kunde sie so will. Das ist für sich genommen erstmal gut, das zu beobachtende Problem ist aber eine Verwirrung was denn mit diesen Begriffen genau gemeint sein soll. Ellen Merryweathers Differenzierungsversuch ist hier sehr hilfreich, vor allem weil sie sich nicht darauf konzentriert zu beschreiben was Prototyp und MVP sind sondern wofür sie ihrer Meinung nach gedacht sind: das eine für interne Machbarkeits-Analysen, das andere für das Einholen von frühem Feedback potentieller Benutzer.

• GeePaw Hill: An Intro to Spikes

  Passend zum letzten Thema: Michael Hill aka GeePaw Hill gehörte zu den ersten Extreme Programming-Coaches und dürfte daher wie kaum ein anderer geeignet sein die dazugehörigen Konzepte und Begriffe zu erklären. Der dessen er sich hier annimmt ist einer der etwas unbekannteren - der Spike. Pawhill definiert ihn hier als spezifische Anforderung eines Proof of Concept oder eines Prototypen. Ganz wichtig in seiner Definition: egal was das Ergebnis ist, es darf nicht in das Produkt eingebaut werden. Würde das doch passieren wäre das Risiko zu gross, dass das im Anschluss nötige Refactoring immer weiter nach hinten priorisiert wird und der (von Natur aus rudimentäre) PoC-Code in Live-Betrieb und Weiterentwicklung die Produktqualität, Architektur, Performance und andere wichtige Aspekte negativ beeinflusst.
  

• Mike Cohn: Can a Team Vote Someone Off the Team?

  Ein schönes Bespiel für eine Frage die scheinbar mit Ja oder Nein zu beantworten ist, dann aber ein grosses "Kommt darauf an" nach sich zieht. In diesem Fall: es kommt darauf welchen Grad an Autonomie dieses Team hat. Mike Cohn übernimmt dazu die Abstufung von Richard Hackmann, bestehend aus Manager-Led (fremdbestimmt), Self-Organizing (selbstorganisiert), Self-Designing (sich selbst zusammenstellend) und Self-Governing (den eigenen Zweck bestimmend). Naheliegenderweise ist das Entfernen eines Teammitglieds durch das Team ab Stufe drei möglich. Was Cohn ausserdem zu Recht betont: in der Realität findet man solche Teams sehr selten.
  

Paper Prototyping

Bild: Flickr / Rosenfeld Media - CC BY 2.0

In Ansätzen wie Lean Startup und Design Thinking stehen MVPs und Prototypen im Vordergrund, also frühe, mit möglichst wenig Aufwand erzeugte Arbeitsergebnisse, die aber trotzdem schon einen so guten Eindruck vom späteren Produkt geben, dass auf dessen Basis ein erstes Benutzerfeedback eingeholt werden kann. Diese Gleichzeitigkeit von möglichst wenig Aufwand und möglichst gutem Eindruck ist natürlich eine Herausforderung, die nur mit bestimmten Techniken gemeistert werden kann. Eine der bekanntesten unter ihnen ist das Paper Prototyping.

Die grundlegende Idee ist simpel - statt mit relativ viel Arbeit irgendetwas Vorzeigbares in digitalen Design-Tools zu entwerfen, es zu programmieren und es dann auf ein Vorführgerät oder eine Vorführumgebung zu bringen wird einfach ein Entwurf mit Stiften auf ein Papier gemalt und der dann der Zielgruppe vorgelegt. Die muss dann nur noch die Frage beantworten ob er ihr gut genug gefällt um mit mehr Aufwand in eine echte Umsetzung zu gehen. Wenn nicht kann man verbessern - oder abbrechen ohne Investitionen zu verlieren.

Für jemanden der einen solchen Papier-Prototypen noch nie gesehen hat (oder nur solche die dilettantisch erzeugt wurden) wird dieser Ansatz zuerst merkwürdig klingen. Ein bemaltes Papier soll ausreichend sein um verwertbares Nutzerfeedback zu erzeugen? Die Skepsis ist berechtigt, wie so oft gilt auch hier, dass man eine gelungene Anwendung gesehen haben muss bevor man sich etwas darunter vorstellen kann. Glücklicherweise gibt es im Internet genug gute Beispiele, wie etwa dieses Video (nur eine Minute lang):

Gut sichtbar sind hier einige Erfolgsfaktoren: die hier gezeigten Prototypen sind durch Color Coding und minimalistisches Design so übersichtlich gestaltet, dass eine Konzentration auf die zentralen Funktionen stattfindet, die aufeinanderfolgenden "Screens" simulieren einen Bedienungsablauf (was dann durch den "Vorführ-Rahmen" noch besser erfahrbar wird) und durch Elemente wie die Klappmeüs und die Post It-Schnipsel ist bereits eine echte Interaktion möglich.

Anhand dieses Beispiels kann man es sich schon besser vorstellen wie ein Paper Prototype zu Vorführzwecken verwandt wird. Auch von der dadurch möglichen Geschwindigkeit bekommt man eine Vorstellung - ein geübter Zeichner wird in der Lage sein das Feedback der Testgruppe innerhalb von Minuten in einen verbesserten und direkt wieder testbaren Prototypen einzuarbeiten, ein Tempo mit dem kein noch so guter digitaler Entwurf mithalten kann.

Natürlich gibt es bei diesem Vorgehen auch Risiken, von denen als wichtigstes die Illusion einer einfachen Umsetzbarkeit zu nennen ist (ich durfte einmal miterleben wie ein Team aus UX-Designern einen vom Kunden gefeierten Prototypen einer Website erstellte, nur um nachher zu erfahren, dass die Umsetzung die halbe IT ein Jahr lang beschäftigt halten würde). Durch eine frühe Einbindung der IT in den Prototyping-Prozess lässt sich die Wahrscheinlichkeit solcher Missverständnisse aber reduzieren.

Trotz dieses Risikos ist Paper Prototyping aufgrund der genannten Vorteile vor allem in den frühen Phasen einer Produktentwicklung wärmstens zu empfehlen, das schnelle Feedback und die Möglichkeit einer extrem frühen Verbesserung des Produkts wiegt die möglichen Nachteile klar auf. Und im schlimmsten Fall muss man nichts verwerfen ausser den ersten Blättern eines Papierblocks, bevor man mit den nächsten Blättern den nächsten Prototypen baut.

Das Problem mit Jira, Trello, Leankit & Co

Bild: Wikimedia Commons / Hunini - CC BY-SA 4.0

Wenn man Teil eines durchgängig aus dem Homeoffice arbeitenden agilen Projekts ist, ist es in den meisten Fällen nicht mehr die Frage ob man eines der zahlreichen digitalen Arbeitsmanagement-Tools benutzt, es geht nur noch darum welches - Jira, Trello, Leankit, Octane, den Teams Planner oder eines der eher unbekannten Nischen-Tools. Sie alle haben aber zwei Dinge gemeinsam: sie verändern die Art wie wir Arbeit (und Arbeits-Management) wahrnehmen und sie bringen eigene Prozessabläufe mit sich die man zwangsläufig zu den eigenen machen muss. Man sollte ihnen daher mit Vorsicht und bewusstem Herangehen begegnen, immer mit der klassischen Coaching-Frage im Hinterkopf - was macht das mit mir?.

Die offensichtlichste Folge ist, dass die Sichtbarkeit der Arbeit abnimmt. während man vorher auf einer Wand den Überblick über alle wichtigen Informationen haben konnte (Sprint-Board, Burndown, Impediments, Personas, etc.) sind diese zwar immer noch da, allerdings verstreut über verschiedene Websites. Um von einer zur anderen zu wechseln muss man sich durch Tabs klicken oder Seitenabschnitte durchscrollen. Das Big Picture geht verloren.

Was ausserdem häufig unterschätzt wird: das physische Board ist unübersehbar präsent und erinnert an To Dos und Missstände, das digitale Board wird in der Regel nur während der Meetings aufgerufen und ist sonst unsichtbar. Und selbst wenn man es auf grossen Wandbildschirmen präsentiert sind die meisten Tools so aufgebaut, dass wichtige Informationen innerhalb der Tickets gespeichert werden und erst sichtbar werden wenn man diese separat öffnet.

Ein ebenfalls erst auf den zweiten Blick sichtbarer Effekt ist der, dass digitale Tools oft zu einer starken Aufblähung des Informationsumfangs führen. Jedes Ticket enthält eine Vielzahl von potentiell nutzbaren Freitextfeldern, Labels, Attachements und Verlinkungen, die zum einen ein schlechtes Gefühl erzeugen können wenn man sie frei lässt (→ Horror Vacui), zum anderen aber auch keine Obergrenze setzen, so dass in Summe aller Tickets eine nicht mehr aktuell zu haltende Umfangsmenge entstehen kann.

Offensichtlicher als die zuvor genannten Punkte ist das Phänomen, dass die Tools ihren Nutzern Prozesse aufzwingen (bzw. bisherige Prozesse nicht abbilden können). Häufig genannt wird z.B., dass Tickets sich immer nur einer Person zuordnen lassen, was im Widerspruch zu der verbreiteten Praktik des Pairings steht. Auch die Aufteilung von Arbeit/Anforderungen in mehr als drei Hierarchie-Ebenen (Epic, Story, Subtask) ist in praktisch keinem Tool möglich, selbst wenn der eigene Planungsansatz es eigentlich erfordern würde.

Was zuletzt fast immer unterschätzt wird ist der mit digitalen Tools verbundene Administrationsaufwand. Dieser umfasst nicht nur die Einrichtung und Berechtigung der Accounts (wobei alleine das schon erstaunlich arbeitsintensiv sein kann) sondern auch das Anlegen und Verwalten von Projekten, Boards, Filtern, etc. Ein verbreitetes Phänomen ist die Wahrnehmung dieser Aufgaben durch die Scrum Master, was einerseits verständlich ist (die Teams werden entlastet) auf der anderen Seite aber dazu führt, dass für seine eigentlichen Aufgaben weniger Zeit bleibt.

Wie zu Beginn gesagt, ganz wird man im Rahmen verteilter Arbeit nicht um die Nutzung digitaler Arbeitsmanagement-Tools herumkommen. Aufgrund der genannten Phänomene sind Teams und Unternehmen aber gut beraten wenn sie sich reflektiert und regelmässig mit der Frage auseinandersetzen welche Auswirkungen das auf ihre Arbeitsweisen hat. Dadurch kann zwar nicht verhindert werden, dass diese durch die Tools beeinflusst werden, man kann aber versuchen das in Bahnen zu lenken die nicht gegenläufig zum grundlegenden Zusammenarbeitsmodell sind.

Endspurt, Design Sprint, Sprint

Bild: Flickr / A Healthier Michigan - CC BY-SA 2.0

Gerade dann wenn die Bedeutung eines Begriffs für alle Beteiligten scheinbar selbstverständlich ist lohnt sich ein näherer Blick. Das gilt natürlich auch für die Fachsprache die sich über die Jahrzehnte im Rahmen der agilen Arbeitsweisen entwickelt hat. Ein Fall an dem sich das aufzeigen lässt ist der Sprint. Je nach Kontext können sich hinter diesem Wort stark unterschiedliche Ausprägungen verbergen, derer man sich bewusst sein sollte wenn man es benutzt.

Die in der Realität am häufigsten anzutreffende Variante lässt sich am besten als "Endspurt" beschreiben. Nach längeren Anforderungserhebungs- und Planungsprozessen geht es hier nur noch darum das definierte Ergebnis in kurzen Schüben umzusetzen (häufig anzutreffen in SAFe). Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse relativ klar und stabil sind, die Umsetzung aber technisch oder organisatorisch anspruchsvoll ist. Der Inspect & Adapt-Zyklus dient dann nur noch der Überprüfung und Anpassung des Umsetzungsvorgehens. Das mit diesem Ansatz verbundene Risiko ist, dass er entgleisen kann wenn die Anforderungen sich ändern.

Auch der umgekehrte Fall existiert, es sind die so genannten "Design Sprints". In ihrer bekanntesten Variante enthalten sie nicht nur das blosse Anforderungsdesign sondern auch die Erstellung erster Prototypen oder Vorführ-Versionen und deren Validierung an einer echten Anwender-Zielgruppe. Sobald diese positiv reagiert erfolgt die Übergabe an die eigentliche Umsetzung. Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse noch unklar oder instabil sind. Der Inspect & Adapt-Zyklus dient vor allem dem Erstellen und Verwerfen von Bedarfs- oder Anwendungs-Hypothesen. Das mit diesem Ansatz verbundene Risiko ist, dass seine Ergebnisse sich als nur schwer umsetzbar herausstellen können.

Der dritte Typ entspricht den Sprints in Scrum oder den Iterationen in Extreme Programming. Der Anspruch dieses Ansatzes ist, auf der Basis einfach formulierter Anwender-Bedürfnisse sowohl das Design als auch die Umsetzung einer Funktionserweiterung in einem (!) Intervall umzusetzen. Sinn macht dieses Vorgehen wenn sowohl die Anforderungen und Nutzerbedürfnisse als auch die Bedingungen der Umsetzung sich ändern können. Der Inspect & Adapt-Zyklus sollte alle dieser Aspekte berücksichtigen. Das mit diesem Ansatz verbundene Risiko ist, dass er bei vielen Abhängigkeiten und hohem Abstimmungsbedarf unverhältnismässig viele Ressourcen für diese Themen verwendet.¹

Was anhand dieser verschiedenen Ausprägungen erkennbar ist: abhängig von Verständnis und Erfordernissen kann sich jeweils etwas Unterschiedliches hinter dem scheinbar klaren Begriffs des Sprints verbergen (dazu kämen noch Antipattern wie z.B. der Konzeptions-Sprint", der "Test-Sprint" oder der "Gewaltmarsch"), es macht also grossen Sinn sich zu vergewissern welches im eigenen Fall vorliegt.

¹Der übliche Lösungsansatz im agilen Vorgehen wäre die Vermeidung oder Auflösung von Abhängigkeiten, z.B. durch crossfunktionale Teams oder shared Code.

Ein Bild sagt mehr als 1000 Worte (XXVIII)

Super excited that you liked my last drawing. Here is a new one! 🤗 pic.twitter.com/vULVb0uoFo

— Vincent Déniel (@vincentdnl) April 21, 2020

Die Grundlagen-Dokumente von Scrum

Bild: Pxfuel - CC0 1.0

Scrum ist sich selbst in einer Hinsicht sehr treu: es findet ein kontinuierlicher Verbesserungsprozess statt, in dessen Rahmen seine Regeln ständig überarbeitet, ausdifferenziert aber zum Teil auch wieder verschlankt werden. Da dieser Prozess seit über 30 Jahren anhält ist es nicht immer einfach nachzuverfolgen was zu welchem Zeitpunkt hinzugefügt oder verändert wurde. Dem kann abgeholfen werden - hier sind die wichtigsten Grundlagenwerke auf denen das Scrum-Framework beruht und die es immer weiter entwickelt haben:

1986: The New New Product Development Game (Hirotaka Takeuchi, Ikujiro Nonaka)

Dieser von von den Wissenschaftlern Takeuchi und Nonaka verfasste Artikel über die Arbeit japanischer Fabrikteams ist das einzige Grundlagenwerk an dem die "Scrum-Väter" Jeff Sutherland und Ken Schwaber nicht beteiligt waren (statt Scrum wird auch noch vom "Rugby Approach" gesprochen). Aus heutiger Sicht beschreibt es noch nicht Scrum selbst sondern einige Prinzipien auf denen es beruht, u.a. crossfunktionale Teams und iterativ-incrementelles Arbeiten. Die 1990 erfolgte Übertragung des New New Product Development Game auf die IT durch DeGrace und Stahl war damit die Inspiration für die Entwicklung von Scrum in seinem heutigen Sinn, was Sutherland und Schwaber auch selbst betont haben.

1995: SCRUM Development Process (Jeff Sutherland, Ken Schwaber)

Nachdem Sutherland und Schwaber Scrum in den ersten Jahren nur im Rahmen ihrer eigenen Software-Projekte einsetzten führte der Wunsch es bekannter zu machen zur Vorstellung durch die beiden auf der OOPSLA-Konferenz im Jahr 1995. Das Konferenz-Paper gilt als Initialzündung der weltweiten Verbreitung von Scrum, enthält aber vieles noch nicht was heute zentral ist. Umgekehrt sind noch Elemente vom Wasserfall-Vorgehen enthalten, etwa die Phasen "Pregame", "Game" und "Postgame". Anderes, wie der Sprint, das Sprint-Ziel, das Sprint Planning, das Sprint Review oder der Product Owner (noch als Product Manager), existieren bereits. Scrum ist in dieser (und den nächsten) Versionen explizit ein Ansatz der Software-Entwicklung.

1998: SCRUM - An extension pattern language for hyperproductive software development (Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherland)

Dieses leicht despektierlich "Scrum-Plop" abgekürzte Gemeinschaftswerk einer ganzen Reihe verschiedener Autoren erwähnt zum ersten mal die Rolle des Scrum Masters, wenn auch noch als eine spezifische Form des Teamleiters, dem auch leitende und kontrollierende Funktionen zugeschrieben werden. Besonders interessant: zusätzlich zum Scrum Master wird auch ein (nicht genauer beschriebener) Coach erwähnt, der anscheinend zu dieser Zeit noch eine eigene Rolle war. Auch das 15-minütige Daily Scrum-Meeting taucht hier erstmals auf, genau wie das Commitment des Teams das Sprint-Ziel zu erreichen.

2001: Agile Software Development with Scrum (Ken Schwaber, Mike Beedle)

Das erste Buch über Scrum, gleichzeitig aber auch ein Werk das im Rückblick leicht wunderlich wirkt. Statt Scrum als eigenständigen Ansatz vorzustellen stellten Schwaber und Beedle in den Vordergrund, dass ein anderer methodischer Ansatz, Extreme Programming (XP), sich mit Hilfe von Scrum besonders gut umsetzen liesse. Hintergrund ist, dass XP um das Jahr 2000 herum populärer war als Scrum und die Verbindung dieser beiden Ansätze Scrum schneller bekannt machen konnte. Zusätzlich kannten und respektierten sich die Urheber von Scrum und XP (u.a. waren sie 2001 gemeinsam an der Enstehung des agilen Manifests beteiligt). Der halboffizielle Status einiger XP-Elemente in Scrum (User Stories, Story Points, Pair Programming) erklärt sich aus dieser Zeit.

2001: Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies (Jeff Sutherland)

In dieser Übersicht über die Scrum-Einführung in verschiedenen Unternehmen tauchen erstmals Skalierungs-Elemente auf. Zum Einen findet sich hier die Idee, dass auch Management-Teams nach Scrum arbeiten können, zum Anderen wird hier zum ersten mal das Scrum of Scrums vorgestellt, ein wöchentliches Scrum-Meeting in dem sich Vertreter verschiedener Teams treffen um sich untereinander abzustimmen und die Arbeit an übergreifenden Themen zu koordinieren. Aus diesen Ansätzen entstand später das Skalierungsframework Scrum@Scale (siehe unten).

2003: Scrum and the Perfect Storm (Ken Schwaber)

Im Vergleich zu den anderen Texten ein eher wenig wichtiger, es wird nicht wirklich etwas Neues hinzugefügt. Interessant ist aber, dass Ken Schwaber in ihm einen weiteren Aspekt aus dem Extreme Programming aufgreift: den Team-Raum (angelehnt an den Extreme Space, in dem alle Teammitglieder zusammensitzen). Mittlerweile aus dem offiziellen Teil von Scrum verschwunden ist er noch immer ein wichtiger Teil in vielen Umsetzungen.

2003: What is Scrum? (Ken Schwaber)

Ein weiterer Artikel von Ken Schwaber, der diesesmal aber grössere Änderungen beschreibt. Das Sprint Planning wird unterteilt in Planning I (was machen wir?) und Planning II (wie machen wir es?). Im Daily werden die drei Fragen gestellt was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind. Erstmals findet am Ende des Sprints eine Retrospektive statt, die mittlerweile der zentrale Antrieb für den kontinuierlichen Verbesserungsprozess geworden ist und als das Scrum Meeting schlechthin gilt. Auch die später zum zentralen Abnahme-Kriterium gewordene Definition of Done wird hier erstmals erwähnt, allerdings noch eher beiläufig an verschiedenen Stellen im Fliesstext. Diese zentralen Änderungen tauchen dann auch 2004 in Schwabers Buch Agile Project Management with Scrum auf.

2010: Erste Version des Scrum Guide (Jeff Sutherland, Ken Schwaber)

Ein Dokument das erst rückwirkend zum ersten Scrum Guide erklärt wurde, Sutherland und Schwaber veröffentlichten es zuerst unter dem schlichten Namen "Scrum". Es ist die letzte Version von Scrum in der sich Wasserfall-Elemente finden: zusätzlich zu den Sprint Plannings können langfristige "Release Plannings" durchgeführt werden und es gibt noch die Möglichkeit Integration und Testing in separate Sprints auszulagern. Auch die kontrovers benannten Rollen "Chicken" (Teammitglied) und "Pig" (Stakeholder) tauchen ein letztes mal auf. Positiv zu benennen ist, dass der Scrum Master als helfender und coachender "Servant Leader" beschrieben wird, was seitdem unverändert gilt. Mit der Festlegung, dass mehrere Teams ein gemeinsames Backlog haben können taucht ein weiterer Skalierungs-Aspekt auf.

2011 (Juli): Zweite Version des Scrum Guide (Jeff Sutherland, Ken Schwaber)

Die letzten Wasserfall-Elemente verschwinden aus dem Scrum Guide, ausserdem alle spezifischen Bezüge zur Softwareentwicklung, womit Scrum auch auf andere Bereiche anwendbar wird. Auch die Pig- und Chicken-Rollen verschwinden. Das Grooming wird dagegen zu einem festen Bestandteil und die Rollen werden ausführlicher beschrieben als vorher. Im Wesentlichen entspricht diese Version von Scrum der die bis heute gültig ist, die späteren Änderungen sind kleiner.

2011 (Oktober): Dritte Version des Scrum Guide (Jeff Sutherland, Ken Schwaber)

Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.

2013: Vierte Version des Scrum Guide (Jeff Sutherland, Ken Schwaber)

Es werden Neuerungen und Ergänzungen in verschiedenen Bereichen eingeführt: die Teammitglieder sollen sich in den Daily Scrums nicht mehr nur fragen was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind, sondern auch welchen Einfluss das auf das Erreichen des Sprint-Ziels haben wird. Das (in manchen Ländern anstössige) Wort Grooming wird durch Refinement ersetzt. In diesem Zusammenhang wird es auch möglich Backlog-Einträgen den Status Ready zu geben, woraus die inoffizielle Definition of Ready abgeleitet werden kann. Die Teilung des Sprint Plannings in Planning I und Planning II wird aufgehoben, das Was und das Wie können jetzt beliebig erarbeitet werden. Eine kleinere Ergänzung kommt bei den Skalierungs-Aspekten dazu: mehrere Teams können eine gemeinsame Definition of Done haben.

2015: Nexus Guide (Ken Schwaber)

Das erste offizielle Skalierungsframework von Scrum. Grundlage sind die beiden Skalierungs-Aspekte des Scrum Guide, die gemeinsame Definition of Done und das gemeinsame Backlog für Teams die an einem gemeinsamen Produkt arbeiten. Da gleichzeitig vorgegeben ist dass es nur einen Product Owner für ein Backlog geben darf wird daraus abgeleitet, dass der auch für alle derartigen Teams zuständig ist. Weitere Elemente sind die Aufteilung der Scrum-Meetings in jeweils einen übergreifenden und einen teamspezifischen Teil und die Möglichkeit ein Integration Team zu etablieren, dass den anderen Teams dabei hilft sich selbst zu koordinieren. Ein sehr ähnliches, halboffizielles Framework ist Large Scale Scrum (LeSS).

2016: Fünfte Version des Scrum Guide (Jeff Sutherland, Ken Schwaber)

Die "Scrum-Werte" Respekt, Commitment, Fokus, Offenheit und Mut werden in den Scrum Guide aufgenommen. Das ist keine vollständige Neuerung, da sie bereits 2001 im Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle enthalten waren. Ihre Wiedereinführung ist der bisher prominenteste Fall einer Scrum-Regeländerung die auf Wünsche aus der Anwender-Community zurückgeht.

2017: Sechste Version des Scrum Guide (Jeff Sutherland, Ken Schwaber)

Neben verschiedenen redaktionellen Änderungen gibt es drei grössere: die berühmten drei Fragen im Daily Scrum sind jetzt optional, der Scrum Master bewegt sich mehr Richtung Coach, da er nicht mehr für die Einhaltung der Scrum-Regeln sorgt sondern deren Verständnis fördert, und zuletzt muss in jeden Sprint mindestens eine Massnahme zur Verbesserung der eigenen Arbeitsweisen aufgenommen werden.

2018: Scrum@Scale Guide (Jeff Sutherland)

Eine vergleichsweise kontroverse Neuerung. Anders als der oben erwähnte Nexus-Ansatz geht Scrum@Scale davon aus, dass Scrum nur für einzelne Teams gedacht ist und nicht für grössere Organisationen. Skalierung funktioniert daher in diesem Modell nicht durch die Gruppierung von Teams um Backlogs und Product Owner sondern dadurch, dass es zwar übergeordnete Hierarchie-Ebenen gibt, diese sich aber auch in Form von Scrum Teams organisieren.

---

Honorable Mentions

Natürlich gibt es noch weitere Quellen die wertvoll für das Verständnis von Scrum sind, vor allem in Buchform. Von Schwaber und Sutherland sind das vor allem die ikonisch benannten Titel Software in 30 Days und The Art of Doing Twice The Work In Half the Time, es gibt Scrum and XP from the Trenches von Henrik Kniberg, Agile Product Management with Scrum von Roman Pichler, die Bücher von Mike Cohn, die Bücher von Craig Larman und Bas Vodde und viele mehr. Sie alle haben Scrum aber nicht verändert sondern beschreiben lediglich seine Anwendungsmöglichkeiten und vermitteln bewährte Techniken und Praktiken, weshalb sie keine Grundlagen-Dokumente im eigentlichen Sinn sind (lesenswert sind sie natürlich trotzdem).

Story Points in Kanban

Bild: Freegreatpicture / Max Pixel - CC0 1.0

Wenn es darum geht Aufwands- oder Komplexitätsschätzungen zu machen raten die meisten in agilen Vorgehensweisen erfahrenen Entwickler zu Story Points, unter anderem wegen der Vorteile relationaler Schätzungen, aber auch aus anderen Gründen. Was dabei fast alle gemeinsam haben ist aber eine Einschränkung auf nur ein oder zwei Frameworks, nämlich Scrum und Extreme Programming. Eine Anwendung im Rahmen von Kanban (des dritten grossen agilen Ansatzes) wird von den meisten nicht erwogen. Dabei wäre sie auch hier durchaus möglich.

Ähnlich wie im Fall der iterativen Ansätze Scrum und XP ist ein Story Point auch in Kanban eine neutrale (d.h. personenunabhängige) Schätzgrösse, die je nachdem wer an der Anforderung arbeitet eine etwas schnellere oder langsamere Umsetzungsdauer bedeuten kann, aber trotzdem eine gemeinsame Schätzung des Teams ermöglicht. Was im Vergleich zur klassischen Anwendung dagegen anders ist, ist die Art des Einsatzes zu Planungs-, Forecast- oder Prognosezwecken.

In Scrum und XP dienen die in der Vergangenheit gelieferten Story Points als Grundlage für die Velocity, also die durchschnittliche Menge an Arbeit die das Team bisher pro Sprint oder Iteration erledigen konnte¹. Diese ist dann wiederum ein Indikator dafür was voraussichtlich in zukünftigen Sprints fertiggestellt werden kann. Da in Kanban an die Stelle der festen Lieferzyklen eine beständige Lieferung tritt ist diese Art der Prognose hier nicht möglich, es wird anders vorgegangen.

Was stattdessen passiert ist eine Einteilung der Anforderungen in Äquivalenzklassen, deren durchschnittliche Lead- oder Cycle-Time gemessen wird. Wenn z.B. in der Vergangenheit Anforderungen mit 5 Punkten im Durchschnitt 4 Tage gebraucht haben, dann kann angenommen werden, dass das in Zukunft vergleichbar sein wird. Allerdings - ist das nicht doch wieder eine Schätzung in Zeiteinheiten? Ja, schon, wenn man es dabei belässt. Aber es steckt noch mehr dahinter.

Bedingt durch verschiedene Unsicherheitsfaktoren (Erfahrung des Bearbeiters, Neuartigkeit des Themas, etc.) kommt es normalerweise bei einem Teil der umgesetzten Anforderungen zu Abweichungen nach oben und unten, meistens in Form einer Gauss-Kurve. Das kann z.B. heissen, dass etwa 20 % der Fälle früher als gedacht fertig werden, etwa 60 % ungefähr rechtzeitig² und etwa 20 % später als gedacht. Diese Zahlen ermöglichen eine Ausdifferenzierung der Prognose.

Beim oben genannten Beispiel von 5 Punkten könnte dass etwa bedeuten³, dass man eine praktisch sichere Ablieferung nach 6 Tagen zusichern kann, eine sehr wahrscheinliche nach 4 Tagen und eine unwahrscheinliche aber theoretisch mögliche nach 2 Tagen. Für die abnehmende Einheit ergibt sich dadurch die Möglichkeit verschiedener Planungsvarianten um flexibel reagieren zu können, mit verbesserter Anpassungsfähigkeit über verschiedene Stationen der Lieferkette als Folge.

Man muss sich bewusst sein: diese Art der Business Agility erfordert Arbeit und Disziplin beim Erheben und Auswerten der Statistiken, man sollte sich also fragen welcher Mehrwert so entstehen soll und ob er in erträglicher Relation zu den Aufwänden steht. Wenn man das mit Ja beantworten kann steht dem Einsatz von Story Points in Kanban aber nichts mehr im Weg.

¹Nur zur Klarstellung: man kann in Scrum und XP Story Points benutzen, muss es aber nicht
²Auch hier gibt es noch kleinere Abweichung in einigen Fällen
³Abhängig vom Umfang der Abweichungen