Die Kurzfassung für Eilige:
Scrum ist der mit großem Abstand beliebteste Ansatz zur Umsetzung agiler Projekte. Scrum basiert auf dem Scrum Guide und stellt als Framework eine Reihe von Accountabilities, Events, Artefakten und Regeln zur Verfügung, die vom Team mit den eigenen Methoden ausgestaltet werden können. Scrum ist besonders in der Software-Branche weit verbreitet, kann aber in verschiedensten Branchen eingesetzt werden.

Du hast schon oft von Scrum gehört, aber keine Idee, was es damit wirklich auf sich hat? Keine Sorge, in diesem Überblick erhältst du die grundlegenden Informationen zum Scrum-Framework – auch für Nicht-Software-Entwickler. Der Ansatz ist einfach und komplex zugleich: Im ersten Moment kann das Regelwerk abschreckend wirken. Wurden die verschiedenen Regeln jedoch einmal verinnerlicht und sind Aufgaben, Befugnisse und Abläufe klar, dann ergibt sich ein rundes Bild, in dem ein agiles Projekt abgewickelt werden kann.

Was ist Scrum – und was nicht?

Scrum ist eine recht junge Methodik aus dem Bereich des agilen Projektmanagements: Erst 1995 wurde es von den US-Amerikanern Ken Schwaber und Jeff Sutherland vorgestellt. Die Basis bildet der offizielle Scrum-Guide, der folgende Definiton parat hat:

… ein Rahmenwerk (Framework), mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen und sowohl produktiv als auch kreativ Produkte in höchster Qualität ausliefern können.

Was wie ein Marketingtext klingt, besteht aus einigen wichtigen Komponenten:

1. Ein Framework: Also ein Rahmen aus Regeln. Dieses Regelwerk besteht aus Scrum-Teams und ihren Verantwortlichkeiten (Accountabilities), Ereignissen (Events), Artefakten (Artifacts) und den eigentlichen Regeln (Rules).
2. Für komplexe adaptive Aufgabenstellungen: Scrum ist immer dann gut geeignet, wenn das Ergebnis des Projekt oder der Weg dahin noch unklar ist. Ein Standard-Fertigteilhaus mit Scrum bauen? Wenig sinnvoll. Eine innovative App entwickeln? Das funktioniert gut!
3. Produkte in höchster Qualität: Das Framework bietet eine Reihe von Mechanismen, um eine hohe Qualität des Ergebnisses sicherzustellen.

Du merkst hier schon, wie sehr sich Scrum seine eigene Sprache bzw. Begrifflichkeiten geschaffen hat, um sich selbst zu beschreiben. Das ist für Einsteiger sicher anfangs verwirrend. Doch keine Sorge: Wenn du dich darauf einlässt, dann werden die Begriffe schnell zu einer Selbstverständlichkeit und stehen dir nicht mehr im Weg.

Um Scrum sauber von anderen Ansätzen abzugrenzen, hilft die Frage: Was ist Scrum nicht? Es ist

• Kein Prozess zur Software-Entwicklung.
• Keine Technik oder Methode.
• Kein Produktentwicklungsprozess.
• Keine Sammlung von Best Practices.

Im Unterschied zu Prozessen oder Methoden stellt Scrum keinen klaren Plan vor, wie ein Produkt zu entwickeln ist. Stattdessen stellt Scrum einen Rahmen zur Verfügung, der abhängig von Unternehmen, Branche und Vorlieben durch konkrete Techniken mit Leben gefüllt werden kann.

Die 3 Säulen von Scrum

Scrum basiert auf der Theorie empirischer Prozesssteuerung (kurz „Empirie“). Die Grundidee: Statt alles von vornherein zu planen, wird ein Projekt in wiederkehrenden Iterationen (Sprints) abgewickelt. In jeder dieser Iterationen werden Erkenntnisse gewonnen und im nächsten Zyklus verwertet.

Drei Säulen bilden die Grundlagen und sollten von allen Beteiligten verinnerlicht werden:

• Transparenz (transparency): Alle Informationen über das Projekt und Ergebnisse müssen für alle Beteiligten sichtbar sein. Allgemeine Standards helfen dabei, dass Informationen gleich interpretiert und Missverständnisse verhindert werden.
• Überprüfung (inspection): Dokumente, Arbeitsfortschritte und Prozesse werden regelmäßig kontrolliert, um frühes Feedback zu erhalten und unerwünschte Abweichungen zu erkennen.
• Anpassung (adaption): Basierend auf regelmäßiger Überprüfung werden Kurskorrekturen vorgenommen, um weitere Abweichungen zu verhindern oder die Arbeitsergebnisse oder Prozesse zu verbessern.

Wo wird Scrum eingesetzt?

Je nach Statistik werden 80-90% aller agilen Projekte mit Scrum oder Scrum-Hybriden abgewickelt. Scrum ist mit Abstand am weitesten in der Software-Branche verbreitet.
Es kann jedoch in verschiedensten Branchen für komplexe Probleme eingesetzt werden und wird (teilweise in angepasster Form) immer häufiger in folgenden Bereichen genutzt:

• In der Produktentwicklung physischer Produkte
• In Marketing– und Designprojekten
• In der Verwaltung
• In der Versicherungs– und Finanzbranche
• An Universitäten
• Im Personalbereich (Human Resources)

Die Vorteile von Scrum

Scrum ist ein Framework aus dem agilen Projektmanagement. Alle Vorteile aus diesem iterativen Ansatz gelten also auch für Scrum. Eine Reihe von Vorteilen findest du im Überblicksartikel für agiles Projektmanagement.

Weiterlesen: Agiles Projektmanagement: Der ultimative Überblick

Die Scrum-Werte

Der Scrum-Guide propagiert fünf Werte, die die Basis für die Zusammenarbeit eines Scrum-Teams bilden:

• Selbstverpflichtung (commitment): Alle Beteiligten verpflichten sich dazu, die Ziele des Teams zu erreichen.
• Offenheit (openness): Offenheit statt Verbergen, Transparenz statt „unter den Tisch fallen lassen“: Das Scrum-Team und Stakeholder tauschen sich offen über Ergebnisse und Probleme aus.
• Mut (courage): Probleme werden als Herausforderungen angesehen und mit geeigneten Werkzeugen gelöst. Allen ist klar, dass die Zukunft nicht vorausgesagt werden kann und Anpassungen nötig sein können.
• Respekt (respect): Alle Beteiligten behandeln sich mit gegenseitigem Respekt, um eine vertrauensvolle Umgebung zum Lernen und Wissensaustausch zu schaffen.
• Fokus (focus): Alle Beteiligten konzentrieren sich auf die Arbeit im jeweiligen Sprint und vermeiden Aufgaben, die nicht dem Sprint-Ziel dienen.

Zugegeben: All diese Aussagen klingen für dich vermutlich selbstverständlich. Sollten wir nicht alle so miteinander umgehen? Natürlich sollten wir das. Doch vermutlich hast du auch schon erlebt, dass Werte wie Respekt und Offenheit ab und zu verlorengehen, wenn es im Projekt haarig zugeht. Aufgrund solcher Erfahrungen wurden diese Werte explizit in das Scrum-Framework übernommen, um immer wieder daran zu erinnern, wie wichtig sie sind – für Scrum-Teams, aber eben nicht nur für diese. Auch nicht genannte Werte wie Ehrlichkeit, Vertrauen und Verantwortungsbewusstsein sollten im Scrum ebenso selbstverständlich sein wie in anderen Projekten.

Das Scrum-Framework im Überblick

Was zeichnet ein Framework aus? Es bietet ein Rahmenwerk, ohne auf die Inhalte und das konkrete Vorgehen einzugehen. Meist besteht es aus einer Definition von Verantwortlichkeiten und Regeln, wie diese Verantwortlichkeiten zusammenarbeiten. Genauso ist es auch im Scrum. Die folgende Grafik zeigt einen Überblick über das gesamte Framework:

Das Scrum-Framework besteht aus Scrum-Teams und ihren Verantwortlichkeiten (Accountabilities), Ereignissen (Events), Artefakten (Artifacts) und Regeln (Rules).

In Kurzform läuft ein Scrum-Projekt wie folgt ab:

1. Der Product Owner erstellt eine nach Prioritäten geordnete Liste von Aufgaben bzw. Features, das sogenannte Product Backlog.
2. Während der Sprint-Planung werden die am höchsten priorisierten Aufgaben von den Developern in die Aufgabenliste des nächsten Sprints übertragen, das sogenannte Sprint Backlog. Das Team entscheidet auch, wie die Aufgaben konkret umgesetzt werden sollen.
3. Der Sprint umfasst eine bestimmte Zeitspanne, meist 2-4 Wochen. Während des Sprints werden die Aufgaben des Sprint Backlogs abgearbeitet. Es findet ein tägliches Meeting statt, um die Fortschritte zu bewerten, das sogenannte Daily Scrum.
4. Der Scrum Master sorgt während der ganzen Zeit dafür, dass die Prozesse eingehalten, Unklarheiten und Hindernisse beseitig werden und das Team fokussiert auf sein Ziel hinarbeitet.
5. Am Ende des Sprints muss immer ein auslieferungsfähiges Ergebnis entstanden sein, das Inkrement: ein neues Feature, ein Produkt oder ein anderes Zwischenergebnis, das ein Stakeholder begutachten kann.
6. Zum Abschluss des Sprints werden weitere Meetings durchgeführt: ein Sprint Review, in dem das Ergebnis des Sprints von Stakeholdern eingeschätzt wird und die Retrospektive, in der das Team die eigenen Prozesse bewertet.

Der Prozess wird so lange zyklisch durchlaufen, bis entweder das Produkt fertiggestellt wurde (das Product Backlog leer ist), oder aufgrund von Einschränkungen durch Termine und Budgets von einem weiteren Sprint abgesehen wird.

Was bedeutet „fertig“? (Definition of Done)

Wann ist ein Produkt „fertig“? Und wann ist eine Funktion so implementiert, dass sie fertig ist? Liegen keine festen Kriterien vor, können die Meinungen über ein „fertiges“ Produkt weit auseinander gehen.

Scrum sieht daher eine feste Definition vor – die „Definition of Done“:

• Alle Beteiligten müssen wissen, wann ein Element aus dem Product Backlog als „Fertig“ (Done) bezeichnet werden kann.
• Jedes Element aus dem Product Backlog sollte über Abnahmekriterien verfügen, um über das „Fertig“ entscheiden zu können.
• Ist ein Inkrement „Done“, zeichnet es sich durch hohe Qualität aus und ist bereit für die Auslieferung.
• Verfügt das Unternehmen über allgemeine Standards oder Konventionen für Inkremente, muss das Inkrement des Scrum-Teams diesen Anforderungen entsprechen.

Inkremente stehen nicht für sich allein, sondern müssen auch mit vorherigen Inkrementen kompatibel sein. Ein Inkrement kann nur dann „Done“ sein, wenn es sorgfältig getestet wurde und mit früheren Versionen harmoniert.

Rollen im Scrum-Framework (Roles)

Ein Scrum-Team besteht aus drei Rollen:

• Product Owner: Er ist der Verantwortliche für den Projektinhalt. Was soll in welcher Reihenfolge erschaffen werden? Der Product Owner hat eine Vision des Produktes und behält den betriebswirtschaftlichen Überblick.
• Scrum Master: Der Verantwortliche für die Einhaltung des Scrum-Prozesses. Er fungiert als Coach, Mentor, Moderator und beseitigt Hindernissen.
• Developer: Die Verantwortlichen für die Umsetzung der Projektinhalte. Die Teams sollten mit mehreren Funktionen (cross-functional) besetzt sein (z. B. Designer, Java-Programmierer, Tester), um komplette Aufgabenblöcke eigenverantwortlich lösen zu können.

In den folgenden Abschnitten betrachten wir die einzelnen Rollen näher:

Der Product Owner

Der Product Owner fungiert als „Wertemaximierer“: Er ist dafür verantwortlich, den Wert eines Produkts und die Leistung der Developer zu maximieren. Er spielt eine zentrale Rolle im Team und ist Ansprechpartner für alle Belange der Produktentwicklung. Er muss dafür sorgen, dass die verfügbaren Ressourcen auf wirtschaftlich vernünftige Weise eingesetzt werden. Der Product Owner vermittelt zwischen den Bedürfnissen der Stakeholder und der Organisation und den Developern:

Weiterlesen: Scrum-Rollen: Scrum Master, Product Owner, Entwicklungsteam im Überblick

Der Scrum Master

Der Scrum Master ist der Wächter über Scrum und dienende Führungskraft des Scrum-Teams („Servant Leader“).

Der Scrum Master fördert Scrum im Sinne es Scrum Guides und hilft allen Beteiligten, die Scrum-Theorie, -Werte und -Regeln zu verstehen und praktisch anzuwenden. Er fungiert als Coach, Berater, Moderator, Trainer und Problemlöser.

Ein Scrum Master kann keine inhaltliche Kontrolle über das Team ausüben. Er sorgt nicht dafür, dass Arbeit erledigt wird, sondern dafür, dass das Team produktiv arbeiten kann und die Scrum-Prozesse einhält.

Ein Scrum Master kontrolliert nicht und gibt keine Anweisungen, sondern stellt sich mit seiner Arbeit in den Dienst des Teams. Er räumt Hindernisse aus, schützt vor Einflüssen von außen und sorgt mit seiner Arbeit dafür, dass die Arbeit des Teams maximiert wird. Ein guter Scrum Master stellt sich täglich die Frage:

„Was kann ich tun, damit das Team gute Arbeit leisten kann?“

Weiterlesen: Scrum-Rollen: Scrum Master, Product Owner, Entwicklungsteam im Überblick

Die Developer

Die Developer erledigen die Entwicklungsarbeit und erstellen ein potenziell auslieferbares Produktinkrement am Ende eines jeden Sprints, das der „Definition of Done“ entspricht.

Es besteht aus 3-9 Mitgliedern, die Vollzeit für ein Scrum-Team arbeiten. Das Team sollte klein genug sein, um Kommunikationsaufwände zu reduzieren und groß genug, um alle nötigen Qualifikationen abzudecken. Der Product Owner und der Scrum Master gehören nicht zu den 3-9 Mitgliedern.

Weiterlesen: Scrum-Rollen: Scrum Master, Product Owner, Entwicklungsteam im Überblick

Ereignisse im Scrum-Framework (Events)

Im agilen Projektmanagement gibt es keine vorher festgelegten Projektphasen, sondern zyklisch ablaufende Iterationen, im Scrum „Sprints“ genannt.

Sprints sind das Herzstück von Scrum und eine Art Mini-Projekt. Jedes Scrum-Projekt besteht aus mehreren Sprints, die maximal einen Monat lang sind und in denen ein definiertes Ziel erreicht werden soll. In jedem Sprint finden die vier folgenden Events statt, die alle mit einer maximalen Dauer (Timebox) versehen sind:

• Der Sprint als Container für die anderen Ereignisse
• Sprint-Planung zum Beginn eines Sprints
• Daily Scrum als tägliches Meeting während der Sprint-Ausführung
• Sprint Review zur Präsentation und Analyse des Sprint-Ergebnisses
• Sprint-Retrospektive zur Analyse des Prozesses und der Zusammenarbeit

Alle Ereignisse dienen dazu, die Transparenz in einem Scrum-Projekt zu erhöhen und allen Beteiligten die Möglichkeit für regelmäßigen Austausch zu geben.

Ein wichtiges Grundprinzip im Scrum ist das „Überprüfen und Anpassen“ (Inspect & Adapt). Bis auf den Sprint selbst bieten alle Ereignisse die Möglichkeit, die aktuelle Arbeit kritisch zu begutachten und wenn nötig den Kurs zu korrigieren. Die kurzen Zeiträume stellen regelmäßiges Feedback sicher und helfen so dabei, das Produkt nicht am Markt und den Zielstellungen vorbei zu entwickeln.

Weiterlesen: Die Scrum-Events im Überblick

Sprint-Planung

Die Sprint-Planung stellt die Weichen für den gesamten Sprint und gibt allen Beteiligten ein klares Bild von dem, was während des Sprints erreicht werden soll. Dieses Ereignis dauert maximal 8 Stunden für einen einmonatigen Sprint, bei kürzeren Sprints entsprechend kürzer.

Während der Sprint-Planung werden drei wichtige Fragen beantwortet:

1. Was ist das Sprint-Ziel?
2. Was kann während dieses Sprints erledigt werden?
3. Wie wird die ausgewählte Arbeit erledigt?

Daily Scrum

Der Name ist Programm: Im Daily Scrum treffen sich die Developer täglich, um den aktuellen Stand zu kommunizieren und nächste Schritte abzuleiten.

Der Scrum-Guide schreibt keinen festen Ablauf für das Daily Scrum vor. Trotzdem haben sich in der Praxis drei Fragen etabliert, die von jedem Team-Mitglied beantwortet werden:

1. Was habe ich gestern getan, damit die Developer ihr Sprint-Ziel erreichen?
2. Was tue ich heute, damit die Developer ihr Sprint-Ziel erreichen?
3. Welche Probleme und Hindernisse stören meine Arbeit?

Das Daily Scrum-Meeting wird oft auch als Daily Standup bezeichnet, da es üblicherweise im Stehen abgehalten wird. Laut Scrum-Guide dauert es 15 Minuten, unabhängig von Sprintlänge oder Teamgröße. Um Gewohnheiten zu etablieren und Logistik und Planung zu vereinfachen, sollte das Daily Scrum jeden Tag zur gleichen Zeit und am gleichen Ort stattfinden.

Sprint Review

Am Ende eines jeden Sprints wird ein Sprint Review durchgeführt, um das fertiggestellte Produktinkrement zu präsentieren und Feedback einzuholen. Basierend auf den Erkenntnissen des Sprints, dem Feedback und möglicher Änderungen des Marktes wird das Product Backlog überarbeitet.

Das Sprint Review ist ein wichtiges Ereignis für die Zusammenarbeit und Kommunikation zwischen Developern und Stakeholdern: Hier erhält das Team direkt Feedback über die Ergebnisse und kann das weitere Vorgehen ableiten.

Auch ein Blick über den Tellerrand hinaus wird gewagt: Markterwartungen und Umfeld, Zeitpläne und Budgets werden ebenso diskutiert wie konkrete Funktionen/Features.

Sprint-Retrospektive

Gemäß des Ansatzes des „Überprüfens und Anpassens“ (Inspect & Adapt) erhält das Scrum-Team am Ende eines jeden Sprints die Möglichkeit, die eigenen Prozesse zu prüfen und zu verbessern.

• Wie lief die Zusammenarbeit im Team?
• Wie gut haben wir die Prozesse eingehalten und die vorhandenen Werkzeuge eingesetzt?
• Was hat besonders gut funktioniert?
• Was möchten wir verbessern?

Weiterlesen: 9 Retrospektive-Methoden, die jeder Projektmanager kennen sollte

Artefakte im Scrum-Framework (Artifacts)

Neben Rollen und Ereignisse spielen Artefakte eine wichtige Rolle. Der für Einsteiger oft wenig greifbare Begriff beschreibt nichts anderes als eine bestimmte Form von Dokumenten oder Teile eines Produkts. Folgende Artefakte sind im Framework definiert:

• Product Backlog: Ein Container (bzw. „ein Behälter“) für alle Funktionen, die das zukünftige Produkt enthalten soll bzw. aller Aufgaben, die im Projekt erledigt werden sollen. Der Product Owner pflegt und priorisiert die Inhalte. Im einfachsten Fall handelt es sich um eine simple Liste, in der alle Features einer Software aufgelistet sind.
• Sprint Backlog: Eine Teilmenge des Product Backlogs, und zwar genau die Funktionen, die während der Sprint-Planung als Ziel für den aktuellen Sprint gewählt werden.
• Inkrement: Das Ergebnis eines Sprints und ein potenziell auslieferbares Produkt oder Teil eines Produkts. Das Inkrement muss festgelegten Kriterien entsprechen (Definition of Done). Wann ist ein Produkt „fertig“? Und wann ist eine Funktion so implementiert, das sie fertig ist? Liegen keine festen Kriterien vor, können die Meinungen über ein „fertiges“ Produkt weit auseinander gehen – deshalb wird eine „Definition of Done“ zuvor explizit festgelegt.

Weiterlesen: Die Scrum-Artefakte im Überblick

Product Backlog

Das Product Backlog ist eine sortierte Liste aller Funktionen, die das zukünftige Produkt enthalten soll. Elemente weit oben im Product Backlog haben eine höhere Priorität und werden früher in Sprints aufgenommen als Elemente, die weiter unten angeordnet sind.

Ein Product Backlog kann folgende Elemente enthalten:

• Funktionen bzw. Eigenschaften des zu entwickelnden Produkts
• Änderungen und Anpassungen
• Fehlerbehebungen/Defekte

Im Gegensatz zu einem Anforderungskatalog im traditionellen Projektmanagement handelt es sich um eine Liste, die ständigen Veränderungen ausgesetzt ist. Neue Anforderungen, Erkenntnisse aus Sprints oder ein sich änderndes Umfeld führen zu neuen oder veränderten Einträgen im Product Backlog.

Sprint Backlog

Das Sprint Backlog besteht aus Elementen des Product Backlogs, die für den aktuellen Sprint ausgewählt wurden und die zur Erreichung des Sprint-Ziels nötig sind.

Ergänzt werden die Elemente durch einen Plan, wie die Funktionen umgesetzt werden sollen. Hierfür werden die Elemente in Teilaufgaben zerlegt.

Inkrement

Das Inkrement ist die Summe aller erledigten Product Backlog-Einträge während des Sprints plus der Inkremente der vorherigen Sprints. Jedes Produktinkrement muss „Fertig“ sein, also der „Definition of Done“ entsprechen, die zu Beginn des Sprints vom Scrum-Team festgelegt wurde.

Egal, ob ein Inkrement tatsächlich produktiv eingesetzt wird: Es sollte in jedem Fall nutzbar und potenziell auslieferbar sein.

Scrum skalieren

Ein Scrum-Projekt klingt im ersten Moment übersichtlich: Team von üblicherweise 10 Personen, das an einem Backlog arbeitet und in iterativen Zyklen ein Produkt entwickelt. Doch was, wenn das Produkt zu groß für ein einzelnes Team ist? Oder wenn sich der agile Ansatz in allen Unternehmensbereichen durchsetzt und die Prozesse der Teams ineinandergreifen müssen? Dann wird es Zeit, den Scrum-Prozess an größere Herausforderungen anzupassen, sprich: zu skalieren.

Bei der Skalierung steht ein Unternehmen vor folgenden Herausforderungen:

• Wie werden mehrere Teams koordiniert?
• Wie greifen die Prozesse für Tests und Integration der verschiedenen Inkremente ineinander?
• Wie werden mehrere Backlogs verwaltet?
• Wie werden alle Projekte und Teams so ausgerichtet, dass die Ergebnisse zur übergreifenden Unternehmensstrategie passen?

Grundsätzlich ändert die Skalierung nichts am Kern des Scrum-Frameworks: Es gibt weiterhin die bekannten Rollen, Events, Artefakte und Prinzipien. Um mehrere Teams oder sogar ein ganzes Unternehmen zu koordinieren, werden allerdings mehr Schnittstellen, Hierarchien und Kommunikation benötigt. An dieser Stelle gehen wir nicht in die Tiefe, sondern listen lediglich einige der bekanntesten Ansätze zur Skalierung von Scrum auf:

• LeSS: Ein minimalistischer Ansatz, der sich eng am ursprünglichen Scrum orientiert und gut für kleine und mittelgroße Skalierung.
• Scrum@Scale: Sinnvoll, wenn Scrum für das gesamte Unternehmen eingesetzt werden soll und passend für Skalierung im großen Stil.
• Scrum of Scrums (SoS): Einfache Option, bei der mehrere Teams an einem Produkt arbeiten und sich in Scrum-of-Scrum-Meetings koordinieren.
• Nexus: Orientiert sich auch eng am Standard-Scrum, fügt aber einige zusätzliche Rollen, Events und Artefakte hinzu, was den Ansatz weniger minimalistisch macht.
• Spotify Modell bzw. Spotify Engineering Culture: Eignet sich gut für Teams, die an Komponenten eines Produkts oder Services arbeiten.
• SAFe: SAFe setzt auf einen Top-Down-Ansatz mit mehreren Ebenen, daraus resultierenden zusätzlichen Rollen, Events und Artefakten.

Fazit

Beenden wir diesen Übersichtsartikel mit einem passenden Zitat:

“Scrum is kind of like poker; you can learn the rules in 10 minutes, but it takes a long time to get great at it.”
“Scrum ist ein wenig wie Pokern: Die Regeln lernst du in 10 Minuten, aber es dauert lange, bis du richtig gut darin bist.“

Scrum Master David Matthew

Für unsere Scrum-Grafiken orientieren wir uns übrigens an der hervorragenden Bibliothek des AGILExicon®. Reinschauen lohnt sich!