Agile und Scrum: Geschichte, Urheber und Grundideen
Agile und Scrum bezeichnen unterschiedliche Dinge
Agile bezeichnet Werte und Prinzipien für Softwareentwicklung, bei der Menschen aus Erfahrung lernen und auf Veränderungen reagieren. Scrum ist ein Rahmenwerk, das einem Team eine bestimmte Struktur für komplexe Arbeit gibt. Der Zusammenhang ist eng, doch die Begriffe sind nicht austauschbar. Ein Team kann agil arbeiten, ohne Scrum zu verwenden. Allein das Ansetzen von Scrum-Besprechungen garantiert weder Anpassungsfähigkeit noch nützliche Ergebnisse.
Eine praktische Frage verdeutlicht den Unterschied: Was soll geschehen, wenn ein Team merkt, dass sein ursprünglicher Plan nicht mehr zum Problem passt? Ein agiler Ansatz nimmt neue Informationen zum Anlass, den Plan zu überdenken. Scrum schafft regelmäßige Gelegenheiten, Arbeit zu überprüfen und anzupassen. Beides ersetzt weder ein Ziel noch fachliches Urteilsvermögen oder Aufmerksamkeit für Qualität.
Warum ein anderer Ansatz nötig war
Softwareprojekte beginnen häufig mit unvollständigem Wissen. Nutzer können einen Bedarf oft erst klar beschreiben, nachdem sie eine mögliche Lösung gesehen haben. Entwickler entdecken technische Grenzen manchmal erst bei einem Umsetzungsversuch. Werden sämtliche Anforderungen anfangs als endgültig festgelegt behandelt, kann ein Team einen Plan gewissenhaft erfüllen, der nicht mehr zum nützlichsten Produkt führt. Eine spät entdeckte Abweichung macht Korrekturen teurer und störender.
Die Antwort bestand nicht darin, Planung aufzugeben. Vielmehr sollte die Zeit zwischen einer Entscheidung und der Erkenntnis über ihre Wirkung kürzer werden. Statt auf eine große Schlusslieferung zu warten, konnten Teams kleinere verwendbare Ergebnisse schaffen, Rückmeldungen einholen und Prioritäten ändern. Diese Überlegungen entwickelten sich in mehreren Ansätzen, bevor Agile zur gemeinsamen Bezeichnung wurde. Sie entstanden nicht an einem einzigen Tag als vollständige Erfindung einer Person.
Scrums Wurzeln liegen vor dem Agilen Manifest
Ein wichtiger Hintergrund ist der Artikel The New New Product Development Game von Hirotaka Takeuchi und Ikujiro Nonaka aus dem Jahr 1986. Seine Rugby-Metapher half, Produktentwicklung als abgestimmte Teambewegung statt als einfache Folge von Übergaben zu verstehen. Der Artikel behandelte Produktentwicklung allgemein. Er darf nicht mit dem später vollständig definierten Software-Rahmenwerk gleichgesetzt werden.
Ken Schwaber und Jeff Sutherland entwickelten Scrum Anfang der 1990er Jahre und stellten es 1995 gemeinsam auf der OOPSLA-Konferenz vor. Sie gelten als seine Mitbegründer; auch andere Praktiker trugen zur Entwicklung bei. Der erste Scrum Guide erschien 2010. Die Reihenfolge ist wichtig: Scrum existierte vor dem Agilen Manifest und wurde später eines der bekanntesten Rahmenwerke agiler Entwicklung.
Das Treffen von 2001 gab Agile eine gemeinsame Identität
Vom 11. bis 13. Februar 2001 trafen sich siebzehn Softwarepraktiker in Snowbird im US-Bundesstaat Utah. Sie vertraten unterschiedliche Ansätze, darunter Extreme Programming, Scrum und Crystal. Nach dem offiziellen Bericht über das Treffen wollten sie unter anderem Gemeinsamkeiten jenseits schwerfälliger, dokumentzentrierter Entwicklungsprozesse finden. Daraus entstand das Manifest für Agile Softwareentwicklung, meist Agiles Manifest genannt.
Die siebzehn Unterzeichner waren Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland und Dave Thomas. Agile hat somit eine gemeinschaftliche Urheberschaft. Scrums beide Mitbegründer gehörten dazu, doch die größere Bewegung lässt sich nicht ihnen allein zuschreiben.
Vier Werte mit einer wichtigen Einschränkung
Das Manifest gewichtet menschliche Zusammenarbeit stärker als starres Vertrauen auf Verfahren, funktionierende Software stärker als lückenlose Beschreibungen, eine fortlaufende Kundenbeziehung stärker als vertragliches Feilschen und Anpassung bei neuen Umständen stärker als mechanisches Festhalten an einem alten Plan. Diese Prioritäten helfen bei Spannungen, die Teams in wirklichen Projekten erleben. Sie verbieten weder Werkzeuge noch Verträge, Dokumentation oder Planung.
Diese Einschränkung ist wesentlich. Ein reguliertes Produkt kann umfangreiche Dokumentation verlangen; ein verteiltes Team kann stark auf Werkzeuge angewiesen sein. Entscheidend ist, ob sie der Arbeit und den Menschen dienen, die ihre Ergebnisse brauchen. Die zwölf ergänzenden Prinzipien behandeln unter anderem häufige Lieferung, nachhaltiges Arbeiten, technische Sorgfalt und regelmäßige Reflexion. Agile verlangt die Prüfung der Arbeitsweise, nicht bloß einen modischen Wortschatz.
Was Scrum diesen Ideen hinzufügt
Scrum organisiert Arbeit um ein kleines Team, eine gemeinsame Produktrichtung und wiederkehrende Zeitabschnitte, die Sprints. Ein Sprint dauert höchstens einen Monat. In dieser Zeit verfolgt das Team ein Sprint-Ziel und schafft eine verwendbare Ergänzung des Produkts. Kürzere Zyklen begrenzen, wie lange Annahmen ungeprüft bleiben, sofern das Team Ergebnisse tatsächlich untersucht und nicht nur Tätigkeiten meldet.
Der Scrum Guide beschreibt drei Verantwortlichkeiten. Der Product Owner verantwortet die Maximierung des Produktwerts und die Verwaltung des geordneten Product Backlogs. Developers schaffen das verwendbare Ergebnis und organisieren ihre Arbeit. Der Scrum Master unterstützt die Einführung von Scrum und die Wirksamkeit des Teams. Er ist nicht als Vorgesetzter definiert, der täglich Aufgaben verteilt. Der Product Owner ist eine Person und kein Entscheidungsgremium.
Ein Arbeitszyklus statt eines bloßen Besprechungskalenders
Im Sprint Planning wird geklärt, weshalb der kommende Sprint wichtig ist, was das Team übernehmen kann und wie es vorgehen will. Im Sprint nutzen Developers das fünfzehnminütige Daily Scrum, um den Fortschritt zum Ziel zu prüfen und den Plan anzupassen. Das Sprint Review untersucht das Ergebnis mit Stakeholdern und beeinflusst die weitere Arbeit. Die Sprint Retrospective dient der Verbesserung der Zusammenarbeit.
Diese Ereignisse haben unterschiedliche Zwecke. Das Review ist nicht einfach eine Freigabeschranke, und die Retrospektive ist kein Anlass, jemanden für eine schwierige Woche verantwortlich zu machen. Auch eine tägliche Besprechung wird nicht allein dadurch wirksam, dass alle stehen. Die Verbindung von Beobachtung und Handeln zählt mehr als die äußere Form: Werden ein Hindernis oder eine falsche Annahme sichtbar, braucht das Team eine realistische Reaktionsmöglichkeit.
Wie der Ansatz bei einem gewöhnlichen Produkt aussieht
Stellen wir uns ein Team vor, das eine Lernwebsite entwickelt. Statt vor jeder Vorführung eine vollständige Kursplattform zu bauen, könnte es zunächst eine kleine, verwendbare Lerneinheit liefern. Lernende können eine Lektion öffnen, ihren Inhalt lesen und sie als abgeschlossen markieren. Ihre Rückmeldungen könnten zeigen, dass eine verständliche Fortschrittsanzeige wichtiger ist als das aufwendige Dashboard, das ursprünglich zuerst vorgesehen war. Diese Erkenntnis kann die Reihenfolge der nächsten Arbeiten verändern.
Das ist ein Beispiel und kein historisches Projekt. Es zeigt zwei ergänzende Ideen: Inkrementelle Entwicklung fügt verwendbare Fähigkeiten hinzu; iterative Entwicklung greift Erkenntnisse oder bereits Gebautes auf und verbessert sie. Ein Prototyp zur Untersuchung einer Idee kann wertvoll sein, ist aber nicht automatisch eine fertige Produktergänzung. In Scrum muss Arbeit die Definition of Done des Teams erfüllen, bevor sie zu einem abgeschlossenen Increment gehört.
Wie andere Praktiken und Personen dazugehören
Agile reicht über Scrum hinaus. Extreme Programming betont besonders technische Praktiken der Softwareentwicklung; Kanban konzentriert sich auf den Arbeitsfluss und die Begrenzung gleichzeitig laufender Arbeit. Teams können außerdem User Storys, Schätzverfahren oder visuelle Tafeln einsetzen. Solche Techniken unterstützen die Arbeit, doch Scrum schreibt weder User Storys noch Story Points oder Planning Poker vor. Häufige Empfehlungen mit offiziellen Regeln zu verwechseln lässt das Rahmenwerk komplizierter erscheinen, als es ist.
Spätere Vermittler und Autoren verbreiteten diese Ideen. Mike Cohn etwa lieferte einflussreiche Erklärungen zu User Storys und agiler Planung, gehörte jedoch nicht zu den Unterzeichnern des Manifests. CI/CD liegt auf der technischen Seite: Häufige Integration, automatisierte Prüfungen und verlässliche Freigabeprozesse unterstützen kurze Rückkopplungszyklen. Es ist weder eine andere Bezeichnung für Agile noch ein verpflichtender Bestandteil von Scrum.
Was Erfolg tatsächlich bedeuten sollte
Agile und Scrum versprechen nicht, dass jedes Projekt leicht oder jeder Termin richtig eingeschätzt sein wird. Sie machen Unsicherheit zu etwas, das durch sichtbare Arbeit, Rückmeldung und Anpassung bearbeitet werden kann. Dafür braucht es Bedingungen außerhalb des Besprechungsraums: Zugang zu Nutzern, klare Prioritäten, Entscheidungsbefugnisse und einen nachhaltigen Umgang mit Qualität. Neue Stellenbezeichnungen ohne veränderte Bedingungen können die ursprünglichen Probleme unangetastet lassen.
Die hilfreiche Prüfung ist deshalb konkret: Entdeckt das Team Missverständnisse früher, reagiert es auf Erkenntnisse und schafft es etwas Verwendbares? Ein voller Kalender und eine gefüllte Aufgabentafel beantworten das nicht. Die Geschichte hilft, den Zweck im Blick zu behalten: Agile formulierte gemeinsame Prioritäten, während Scrum einen Rahmen bot, um Lernen und abgestimmte Lieferung in einen wiederholbaren Rhythmus zu bringen.
