Direkt zum Hauptbereich

Wie liest man sich in Scrum und Agilität ein?

Nehmen wir an, Sie hätten keine Ahnung von Scrum und Agilität. Aber Sie spüren bei Ihren (Beratungs-) Kunden immer wieder, dass sie diese Themen bewegen. Wer sind die Player, welche Bücher sind wichtig? In diesem Artikel versuche ich einen Überblick zu geben.

Was ist Scrum?

There is a version in English language to this article: How do you familiarize yourself with Scrum and agility?, published 03-DEC-2023, accessible at https://www.teamworkblog.de/2023/12/how-do-you-familiarize-yourself-with.html 

Scrum ist ein Arbeitsrahmen, um komplexe Probleme zu lösen. Das Entwickeln von Software ist ein Beispiel für ein komplexes Problem. Bei komplexen Problemen gibt es keine linearen Zusammenhänge und das Gesamtsystem ist ständig in Veränderung.

Der Scrum Guide ist das offizielle Dokument von Ken Schwaber und Jeff Sutherland, den Erfindern von Scrum. Dort werden Werte, der theoretische Hintergrund, die Verantwortlichkeiten, Ereignisse und die Scrum Artefakte erklärt.
  • Werte: Wichtig ist, wie wir miteinander umgehen. Im Scrum Guide werden Werte wie Respekt, Aufgeschlossenheit, Mut, Fokus und Hingabe zum Team propagiert.
  • Empirisches Arbeiten: Scrum Teams machen ihre Arbeit transparent. Sie überprüfen ständig etwas und passen daraufhin irgendetwas an.
  • Verantwortlichkeiten: 
    • Der Product Owner ist so etwas wie ein Chefkonstrukteur für das Produkt. Diese Person muss sich am Erfolg des Produktes messen lassen. Der Product Owner kümmert sich um die Stakeholder. Die wichtigsten Stakeholder sind die (künfitgen) Anwender.
    • Der Scrum Master ist dafür zuständig, dass das Scrum-Team produktiv arbeitet. 
    • Die Developer sind die eigentlichen Experten, die sich gegenseitig helfen und gemeinsam für das Liefern verantwortlich sind.
  • Ereignisse: Scrum Teams geben sich bewusst einen Takt. So zwingen sie sich selbst, ihre Planung immer wieder an die Realität anzupassen. 
    • Jeder Sprint beginnt mit einer Planung und endet mit einem Review der Ergebnisse. 
    • Nach dem Review nimmt sich das Scrum Team Zeit, um an der Lieferfähigkeit zu arbeiten. Dafür ist die Sprint Retrospektive da.
    • Jeden Tag treffen sich die Developer im Daily Scrum, um sich erneut auf das Sprintziel einzuschwören.
  • Artefakte: 
    • Es gibt bei Scrum eine Liste, in der alle Ideen gesammelt, sortiert und verfeinert werden, die wir im Endergebnis haben wollen. Das ist das Product Backlog. Zum Produkt gibt es ein klar formuliertes Produktziel.
    • Im Sprint Planning erstellt das Scrum Team einen konkreten Arbeitsplan für einen Sprint. Das ist das Sprint Backlog. Mit jedem Sprint wird ein Sprintziel vereinbart. Das Erreichen dieses Ziels ist noch wichtiger als die Umsetzung der einzelen, ausgewählten Einträge aus dem Product Backlog.
    • In jedem Sprint - auch im ersten - wird ein Produkt erstellt. Es wächst von Sprint zu Sprint. Dieses Inkrement wird im Sprint Review gemeinsam begutachtet, um den weiteren Verlauf der Arbeit zu organisieren.

Die wichtigsten Organisationen sind die Agile Alliance, die Scrum Alliance, die Scrum Inc. und die scrum.org. Da Scrum freigegeben wurde, darf jeder Scrum zertifizieren.

Warum machen wir Scrum?

In Scrum sind viele Ideen eingeflossen. Beispiele:

  • Weil fragmentiertes Arbeiten das Liefern von Ergebnissen stark verzögert, fordert Scrum einen Teamansatz, bei dem alle Beteiligten möglichst viel Zeit für die gemeinsame Arbeit einbringen können.
  • Weil Teams, die sich täglich synchronisieren, schneller Probleme beheben, gibt es ein Daily Scrum.
  • Weil Kunden gute Produkte lieben und dafür einen fairen Preis zahlen, haben wir die Idee des Chefkonstrukteurs aus den Anfängen des Maschinen- und Flugzeugbaus in die PO-Rolle übernommen.
  • Weil die Lieferprozess am Anfang selten rund laufen, haben wir das Konzept der kontinuierlichen Verbesserung in die Rolle des Scrum Masters und des Daily Scrums übernommen. Die Konzepte stammen aus dem Scientific Management, Industrial Engineering und der Arbeit bei Toyota.
  • Weil wir am Anfang nicht wissen, was ein gutes Produkt und was gute Abläufe sind, spielt das Dazu-Lernen eine große Rolle in Scrum.

Scrum ist also nicht eine weitere Projekt- oder Produktmanagementmethode. Bei Scrum arbeiten wir kontinuierlich an den Hindernissen, die Organisationen davon abhalten, Ergebnisse zu liefern.

Wie ist Scrum entstanden?

Das erste Scrum-Team wurde 1993 zusamengestellt. Im Jahr 1995 wurde Scrum auf der OOPSLA-Konferenz in Austin vorgestellt (Link zum Konferenzpaper).

Jeff Sutherland hat die Entstehung von Scrum in einem Buch zusammengefasst: Scrum : The Art of Doing Twice the Work in Half the Time.https://www.scruminc.com/new-scrum-the-book/ (Ausgabe in deutscher Sprache: Sutherland, Jeff: Die Scrum-Revolution : Management mit der bahnbrechenden Methode der erfolgreichsten Unternehmen. Frankfurt am Main: Campus Verlag, 2015. https://www.campus.de/buecher-campus-verlag/business/management-unternehmensfuehrung/die_scrum_revolution-8485.html).

Ken Schwaber hat etwas über die Gründung der scrum.org geschrieben: The Genesis of the scrum.org 

Jeff Sutherland hat etwas über die Ursprünge im Scrum-Inc-Blog geschrieben:

Der Artikel von Takeuchi und Nonaka "The New New Product Development Game" ist ebenfalls eine wichtige Grundlage. (Die Konzepte, wie Organisationen lernen, sind später im Buch "The Knowledge-creating Company" genauer beschrieben worden.) In diesem Artikel gibt es die Überschrift "Moving the Scrum downfield". Daher kommt der Name dieser Arbeitsweise. (Scrum ist englisch und bedeutet Gedränge.)

Die Grundlagen für die Ideen in Scrum und zum agilen Arbeiten wurden bereits Ende des 19. Jahrhunderts gelegt. Es gibt dazu eine interessante Ideengeschichte.

Was bedeutet Agilität?

Die Erfinder von Scrum und andere Praktiker aus dem Bereich von IT-Projekten in großen Unternehmen haben sich im Jahr 2001 getroffen, um eine Handreichung für IT-Projekte zu entwickeln. Da alle aus unterschiedlichen Domänen kamen, konnten sie sich nicht auf ein gemeinsames Vorgehen einigen. Allerdings fiel es ihnen leicht, Anforderungen an eine gute Zusammenarbeit zu formulieren. Daraus wurde das Agile Manifest (für Softwareentwicklung) mit seinen 12 Prinzipien

Die Beteiligten hatten sich für den Begriff Agilität entschieden, weil sie das Buch "Agile Competitors and Virtual Organizations" kannten.

Welche Strömungen gibt es bei Agilität und Scrum?

Der Report "State of Agile" von Version One (nun digital.ai) listet auf, welche agilen Arbeitsweisen die Industrie nutzt. In der 15. Ausgabe nutzen die befragten Firmen zu zwei Dritteln Scrum, weitere 15% eine Kombination von Scrum mit Kanban oder etwas anderem. 6% nutzen Kanban.

In Googles Ngram Viewer kann man suchen, wie oft bestimmte Begriffe in deutsch- oder englischsprachigen Büchern auftauchen.

Ich habe in der englischsprachigen Literatur nach den Begriffen Scrum, Agility, Kanban, Project Management und Lean Production gesucht. In den deutschen Büchern habe ich nach Scrum, Agilität, Kanban, Projektmanagement und schlanke Produktion gesucht (siehe Abb. 1).

Abb. 1: Auswertung in verschiedenen Bücherbeständen nach agilen Begriffen im Ngram Viewer von Google (oben Englisch, unten Deutsch)

Ich sehe bei den Praktiker:innen folgende Gruppen:

  • Viele Scrum-Anwender:innen kommen aus der Softwareentwicklung und IT. Dazu kommt eine aktive Community die Kanban bevorzugt. Vor allem große US-amerikanische Unternehmen wie Google, Apple, Microsoft und Amazon waren durch Scrum sehr erfolgreich.
  • Dann gibt es Leute, die über das Projektmanagement Bezug zu Scrum gefunden haben. Zu PRINCE2 gibt es eine agile Variante und das PMI fördert Disciplined Agile Delivery als agile Arbeitsweise.
  • Es gibt zudem Berater:innen und Coaches, die ihr Coaching um das Angebot Agile Coaching erweitert haben. Beim Agile Coaching hat sich Lyssa Adkins einen Namen gemacht.
  • Agiles Arbeiten verändert auch die Organisationen und ihre Strukturen. Hier gibt es Organisationsberater:innen, die Themen wie New Work, Teal Organisations, Management 3.0 oder Liberated Companies vertreten.

Die Lean-Leute machen ebenfalls gute Arbeit. Aber die Lean und die Agile Community haben noch nicht so richtig zusammengefunden, obwohl wir gemeinsame Wurzeln haben. (Aber wir arbeiten daran.)

Was ist Kanban?

Kanban wird oft nach Scrum als weitere agile Arbeitsweise genannt. Kanban wurde ursprünglich bei Toyota entwickelt, um die Produktion und den Teilefluss in der Fabrik zu steuern. David J. Anderson hat dieses Konzept auf Dienstleistungen und IT-Services übertragen.

Scrum bietet mit eigenen Rollen und Ereignissen einen Rahmen, um komplexe Probleme zu zerlegen und um kleine Schritte zu machen. Bei Kanban ist eigentlich ganz klar, was die Arbeit ist. Deswegen gibt es auch keine besonderen Rollen oder Ereignisse. Kanban legt Wert darauf, die Arbeit sichtbar zu machen (in Form einer Kanbantafel) und sich Regeln zu geben, mit denen die Menge der Arbeit bewusst begrenzt wird.

Inzwischen gehen die Konzepte ineinander über. Die scrum.org bietet einen Guide an, um Kanban in die Softwareentwicklung zu integrieren, um den Fluss der Arbeit besser zu steuern (Professional Scrum with Kanban).

Welche Themen sollte ein:e Scrum Master:in kennen?

Jeff Sutherland betont regelmäßig, dass sich Scrum-Leute mit 4 Themenbereichen auskennen sollten, um ihre Organisationen bei gutem Scrum zu unterstützen:

  • Kenntnis des Scrum Guides
  • Kenntnis der Scrum Patterns
  • Kenntnis von Lean Thinking für die kontinuierliche Verbesserung und für die Produktentwicklung
  • Kenntnis über skaliertes Scrum, d. h. wie koordinieren mehrere agile Teams ihre Arbeit.

Es gibt eine direkte Verbindung zwischen Lean Thinking und Scrum. 

  • Ein Scrum Master ist für die kontinuierliche Verbesserung der Arbeit des Teams verantwortlich. Hier haben erfahren Scrum Master Ideen aus der Lean Production übernommen (z. B. Prozesseffizienz, Flow, A3-Report, Toyota Kata).
  • Ein Product Owner nutzt die Konzepte von Lean Product Development. Dazu gibt es wichtige Literatur von Allen C. Ward, Durward K. Sobek, James M. Morgan und Donald Reinertsen.

Für die Lean Community gibt es das Lean Enterprise Institute in den USA. Ein wichtiger Autor in der Lean-Welt ist für mich Bob Emiliani. In Deutschland gibt es die Leanbase.

Zur Skalierung von Scrum gibt es mehrere Konzepte:

  • Für die Koordination von mehreren agilen Teams, die am gleichen Produkt arbeiten, wird Scaled Professional Scrum mit dem Nexus Guide der scrum.org empfohlen.
  • Für eine agile Organisation mit mehreren Einheiten und mehreren Produkten ist der Scrum @ Scale Guide sehr interessant.

Weitere Alternativen sind LeSS und Disciplined Agile® Delivery (DAD). Das Scaled Agile Framework ist in großen Unternehmen sehr bekannt. Aber es steht bei Agilisten sehr in der Kritik und wird nicht empfohlen. Ganz neu ist Unfix von Jurgen Appelo.

Welche Themengebiete werden häufig im Zusammenhang mit Agilität genannt?

In der IT-Welt ist das Thema Automatisierung von Changes sehr wichtig. Daraus ist eine ganze Bewegung, DevOps entstanden.

Im Bereich der Produktentwicklung nutzen agile Teams auch gern der Werkzeuge und Abläufe aus Design Thinking.

Für die Koordination von großen Gruppen wird häufig Open Space Technology, World Café und Lean Coffee eingesetzt. In jüngster Zeit sind Liberating Structures sehr beliebt.

Organisationen sind soziale, komplex-adaptive Systeme, die sich nicht dirigistisch verändern lassen. Hier wird häufig auf die Arbeit von Dave Snowden verwiesen, der sich um die Formulierung von Cynefin und Estuarine Mapping kümmert. Jeff Sutherland verweist gern auf Punktualismus für die Veränderung von komplexen Systemen.

Über kurz oder lang kommt auch die Frage auf, wie sich Organisationen Ziele setzen. Im Moment sind OKRs sehr in Mode. Andere Techniken sind Balanced Scorecard und Hoshin Kanri.

Man muss auch wissen, dass sich viele frühe Agilisten Gedanken gemacht haben. Sie entwickeln Konzepte weiter und kommen mit neuen Ideen. Da sind z. B. Heart of Agile oder Modern Agile entstanden.

Soweit ein ganz grober Überblick. Wer vergleichbare Überblicke kennt, kann diese gern als Kommentar hinzufügen.

Ihr wollt mehr über Scrum wissen? Wir haben eine Übersichtsseite zu Scrum, über die man sich in die wichtigsten Artikel in diesem Blog einlesen kann.

Vielen Dank an das "meine Selbsthilfegruppe", dem Lean Coffee Frankfurt/Karlsruhe für Feedback zur ersten Version. Jede:r, der/die sich einliest, wird schnell sehen, dass es an vielen Orten und virtuell, agile Anwendergruppen, Scrum-Tische gibt, die zum Austausch und Lernen einladen.


Kommentare

Beliebte Posts aus diesem Blog

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Teamleitungen gesucht

Was macht Teams erfolgreich? Kann man das lernen? Ab Herbst starten unsere Kurse für aktuelle und künftige Teamleitungen. Jetzt gibt es die Gelegenheit, den Kurs zu testen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Nachschau zum Lean Coffee-Spezial "Agil einfach machen" (Interaktive Buchvorstellung)

Bei unserem Lean Coffee-Spezial Ende Mai waren wir von Lean Coffee Karlsruhe/Frankfurt Zeugen einer Buchvorstellung, doch nicht nur das – natürlich gab es auch einen nicht unbeträchtlichen Anteil an eigener Aktion, denn bei unseren Spezialterminen ist traditionell „Teilgabe“ angesagt. Das Autorenduo Christian Baron und Janick Oswald zeigte uns, was es mit „Agil einfach machen“ auf sich hat.  

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Kleine Organisationsveränderungen, die direktes Feedback erzeugen

Große Veränderungen sind in einer Organisation schwer zu messen. Oft liegt zwischen Ursache und Wirkung ein langer Zeitraum, sodass die Umsetzer:innen nicht wissen, was genau gewirkt hat. Hier ist eine Liste mit kleinen Maßnahmen, die schnell etwas zurückmelden.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Agil sein heißt nicht, unternehmerisch zu denken

 Die Diskussion, ob Agilität ein „Hype“ war, der nun vorüber ist. Ob wir schon im „Post-agilen Zeitalter“ leben. Und wenn ja, wer dafür verantwortlich ist: diese Diskussion nehme ich jetzt schon seit etwa anderthalb Jahren wahr, und sie geht auch aktuell weiter. In meiner Branche wird Agilität weiter gebraucht Ich bin in der speziellen Situation, dass ich beruflich aus dem öffentlichen Dienst komme und auch seit meinem Ausscheiden vor 15 Jahren weiterhin vor allem Kunden im öffentlichen Bereich berate. Also auf einem Parkett, das normalerweise nicht mit den Anliegen des Agilen Manifests verbunden wird: der Produktion von Software für gewerbliche Kunden in einem unsicheren Umfeld. Auf diesem scheinbar „exotischen“ Feld hat sich in den vergangenen sechs bis acht Jahren bei vielen Verwaltungen die Erkenntnis verbreitet, dass agile Vorgehensweisen bei den anstehenden Transformationen für sie sinnvoll sein können. Denn auch Projekte z.B. die „Digitalisierung der Verwaltung“ (ein völlig ...