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

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.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?