Was ist Scrum?

Scrum ist ein Framework für die Entwicklung, Bereitstellung und nachhaltige Pflege komplexer Produkte durch effektive Teamzusammenarbeit. Es bietet einen schlanken Prozess, um kollaborative, teambasierte Aktivitäten zu fokussieren und zu koordinieren, während das Scrum-Team komplizierte adaptive Probleme angeht und ein Produkt von optimalem Wert schrittweise und nach einem vorhersagbaren Zeitplan liefert.

Ursprünglich von den Professoren Hirotaka Takeuchi und Ikujiro Nonaka konzipiert und 1986 als "The New Product Development Game" in der Harvard Business Review veröffentlicht, wurde Scrum in den 1990er Jahren von Jeff Sutherland und Ken Schwaber angepasst und popularisiert. Es ist zu einer immer beliebteren Arbeitsweise geworden und hat sich von der Softwareentwicklung auf viele Bereiche der Produktentwicklung ausgedehnt, die von einem iterativen und inkrementellen Ansatz profitieren können. Es gelingt oder scheitert an der technischen Kompetenz und den gemeinsamen Anstrengungen des Teams.

Aus prozessualer Sicht bietet Scrum einen einfachen und äußerst effektiven agilen Ansatz für die Produktbereitstellung. Wie später gezeigt wird, ist Scrum nicht dazu gedacht und beschreibt auch keinen agilen Ansatz für Projektmanagement.  

Das Framework umfasst drei verschiedene Rollen, die ein Scrum Team bilden, jeweils mit klar definierten Verantwortlichkeiten, fünf Events und drei Artefakte. Die Regeln, die im Scrum Guide beschrieben sind, verbinden die Rollen, Events und Artefakte miteinander und leiten ihre Beziehungen und Interaktionen.

• Die 5 Events: Der Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
• Die 3 Artefakte: Product Backlog, Sprint Backlog, Product Increment
• Die 3 Rollen: Product Owner, Developer, Scrum Master.

1. Der Sprint ist eine Zeitbox, die eine beliebige Dauer haben kann, aber typischerweise 2 bis 4 Wochen beträgt, während der ein oder mehrere „Done" (d.h. verwendbare und zumindest potenziell auslieferbare) Produktinkremente erstellt werden. Der Sprint enthält alle anderen Ereignisse.
2. Sprint Planning ist die Planung der Arbeit, die im nächsten Sprint von den Entwicklern durchgeführt werden soll. Sie handeln ein realistisches Sprint-Ziel mit dem Product Owner aus, wählen geeignete Elemente aus dem Product Backlog aus, die zu diesem Ziel beitragen, und planen die Arbeit zur Erreichung desselben.
3. Das Daily Scrum ist ein 15-minütiges Meeting, das von den Entwicklern im Scrum-Team abgehalten wird. Es findet jeden Tag des Sprints statt und die Entwickler nutzen es, um ihr Engagement zur Erreichung des Sprint-Ziels zu bekräftigen und ihre Pläne entsprechend anzupassen.
4. Das Sprint Review findet am Ende des Sprints statt. Sein Zweck ist es, den Stakeholdern sichtbar zu machen, was im Sprint geliefert wurde, damit sie es formal inspizieren und Anpassungen am Product Backlog vorschlagen können, um die laufende Entwicklung zu lenken.
5. Die Sprint Retrospektive ist eine Gelegenheit für das Scrum-Team, über die Wirksamkeit ihrer Arbeitsweise zu reflektieren und einen Plan für Verbesserungen zu erstellen, die während der nächsten oder nachfolgenden Sprints umgesetzt werden sollen.

Scrums drei Artefakte sind darauf ausgelegt, den Fokus auf den zu liefernden Wert aufrechtzuerhalten. Sie sind transparent – das heißt bewusst sichtbar – für jeden, der sich dafür interessiert, was das Scrum Team tut und wie es an seine Arbeit herangeht. Jedes Artefakt beinhaltet eine Verpflichtung.

Das Product Backlog ist eine geordnete Liste von allem, was getan werden muss, um das Product Goal zu erreichen. Es ist die einzige Arbeitsquelle für das Scrum Team. Obwohl es mehr als ein Product Goal geben kann, zum Beispiel zur Beschreibung einer Produkt-Roadmap, wird nur ein Ziel zur Zeit bearbeitet. Das Product Goal ist das Ziel, die Verpflichtung, die das Product Backlog zu erreichen bestimmt ist.

Das Sprint Backlog umfasst die Menge der Product Backlog Items, die für einen Sprint ausgewählt wurden, und alle Arbeiten, die nötig sind, um das Sprint Goal zu erreichen. Während ein oder mehrere Product Increments während des Sprints geliefert werden können, gibt es nur ein Sprint Goal. Das Sprint Goal ist die Verpflichtung für das Sprint Backlog und das, was die Entwickler zu erreichen streben.

Das Product Increment ist das, was die Entwickler erstellen, um den Bedarf zu erfüllen, der durch ein oder mehrere Product Backlog Items beschrieben wird. Es ist ein greifbarer Schritt zur Erreichung des Sprint Goals. Wenn mehr als eines in einem Sprint geliefert wird, schließt jedes Product Increment das vorherige mit ein. Die Verpflichtung besteht darin, die „Definition of Done" für das Product Increment zu erreichen. Diese „Definition of Done" ist eine formale Beschreibung der notwendigen Qualitätsstandards, die das Produkt erfüllen muss.

Wir wissen aus dem Agile-Manifest , dass Praktiker der Agilität Individuen und Interaktionen über Prozesse und Werkzeuge stellen – das bedeutet, dass es zwar einen Platz für Prozesse und Werkzeuge gibt – und seien wir ganz klar, Scrum beinhaltet ein bedeutendes Prozesselement – wir aber Menschen und die Art, wie sie zusammenarbeiten, höher bewerten. Die Rollen und Verantwortlichkeiten, die mit diesen Rollen verbunden sind, sowie die kollaborativen Interaktionen zwischen den Personen, die diese Rollen innehaben, sind grundlegend für den effektiven Einsatz von Scrum.

Ein Scrum Team besteht aus einem Product Owner, einem Scrum Master und typischerweise zwischen 5 und 9 Entwicklern. Das Team muss funktionsübergreifend sein – gemeinsam über alle Kompetenzen verfügen, die zur Lieferung des gewünschten Produkts benötigt werden, und in der Lage sein, zusammenzuarbeiten, um dieses Ziel zu erreichen. Das Team ist selbstorganisierend – es erkennt keine hierarchische Struktur an und ermöglicht es, dass Führung für spezifische Arbeiten angemessen entsteht.

Product Owner

Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren, das aus der Arbeit des Scrum Teams resultiert. Der Product Owner ist eine Einzelperson, kein Komitee, und vertritt typischerweise die Bedürfnisse vieler Stakeholder, einschließlich der Kunden, für die der Wert geschaffen wird. Bei seinem Beitrag zur Arbeit des Scrum Teams ist er für ein effektives Product Backlog Management verantwortlich, was Folgendes umfasst:

• Entwicklung und explizite Kommunikation des Product Goals.
• Erstellung und klare Kommunikation von Product Backlog Items.
• Priorisierung von Product Backlog Items.
• Sicherstellung, dass das Product Backlog transparent, sichtbar und verstanden wird.

Jeder Stakeholder, der das Product Backlog ändern möchte, kann dies nur über den Product Owner tun.

Entwickler

Die Entwicklerrolle im Scrum Team gilt für jeden, der aktiv mit anderen im Team zusammenarbeitet, um das Produkt zu entwickeln – sogar jemand, der auch eine der anderen Rollen innehat, kann ein Entwickler sein. Die von einem Entwickler benötigten Fähigkeiten variieren je nach Art der ausgeführten Arbeit und dem, was produziert wird. Entwickler, die in einem Scrum Team arbeiten, um einen Garten zu gestalten, benötigen völlig andere Fähigkeiten als diejenigen, die eine aufwendige Dinnerparty vorbereiten oder ein neues Spiel für ein Smartphone entwickeln. Scrum kann in all diesen Entwicklungsumgebungen angewendet werden.

In Scrum sind Entwickler immer verantwortlich für:

• Erstellung eines Plans für den Sprint, des Sprint Backlogs;
• Gewährleistung von Qualität durch Einhaltung einer Definition of Done;
• Anpassung ihres Plans jeden Tag in Richtung des Sprint Goals; und
• gegenseitige Verantwortlichkeit als Fachkräfte.

Scrum Master

Der Scrum Master ist dafür verantwortlich, Scrum so zu etablieren, wie es im Scrum Guide definiert ist. Er tut dies, indem er allen dabei hilft, die Scrum-Theorie und -Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.

Oft als dienende Führungskraft bezeichnet, besitzt der Scrum Master keine Befehlsgewalt – er sagt den Leuten nicht, was sie tun und wie sie sich verhalten sollen, sondern hilft ihnen zu verstehen, wie Scrum funktionieren sollte, und tut, was er kann, um dessen Einführung zu erleichtern. Er bietet einen Service für:

• Das Scrum Team – Coaching ihrer Scrum-Einführung, Unterstützung beim Finden von Wegen zur kontinuierlichen Verbesserung der Art, wie sie Wert liefern, und Beseitigung alles dessen, was dem im Wege steht.
• Den Product Owner – Unterstützung beim Product Backlog Management und Hilfe dabei sicherzustellen, dass Product Goals und Product Backlog Items richtig geformt, ausgedrückt und verstanden werden.
• Die breitere Organisation, in der das Scrum Team existiert – Unterstützung beim Verständnis der Scrum-Arbeitsweise und wie sie arbeiten und sich verhalten müssen, um Scrum Teams optimal effektiv sein zu lassen.

Das Scrum-Framework basiert auf der Theorie der empirischen Prozesskontrolle oder dem Empirismus, der besagt, dass Wissen aus Erfahrung entsteht und Entscheidungsfindung auf dem beruht, was beobachtet werden kann. Die Säulen der empirischen Prozesskontrolle sind Transparenz von Prozess und Fortschritt, Inspektion von Prozess und Fortschritt sowie Anpassung sowohl des entstehenden Produkts (es mit jeder Iteration und jedem Inkrement zu verbessern) als auch der Arbeitsweise (kontinuierliche Verbesserung der Teameffektivität und -leistung).

Es ist wichtig zu verstehen, wie der empirische Prozess effektiv gestaltet wird. Transparenz ermöglicht Inspektion, Inspektion ermöglicht Anpassung und Anpassungen müssen transparent sein. Inspektion ohne Transparenz ist irreführend und verschwenderisch, Inspektion ohne die Absicht zur Anpassung ist sinnlos und Anpassung ohne Transparenz zur Inspektion ihrer Auswirkungen macht Anpassung riskant.

Effektive Scrum-Teams leben und atmen eine Reihe von fünf Werten. Diese Werte sind nicht einzigartig für ein Scrum-Team, aber indem sie explizit gemacht werden, fördern sie effektive, kollaborative teambasierte Arbeitsweise. Die Werte sind Verpflichtung, Fokus, Offenheit, Respekt und Mut.

• Verpflichtung: Scrum-Team-Mitglieder sind verpflichtet, Sprint-Ziele zu erreichen und hochwertige Arbeit durch iterative Entwicklung und inkrementelle Lieferung zu erbringen. Dies fördert Verantwortung und Rechenschaftspflicht unter den Teammitgliedern.
• Mut: Scrum-Team-Mitglieder haben den Mut, Herausforderungen und Hindernisse offen anzugehen. Sie sind bereit, Risiken einzugehen und sich zu Problemen zu äußern, die den Erfolg des Teams beeinträchtigen könnten.
• Offenheit: Scrum-Team-Mitglieder teilen Informationen, Fortschritte und Bedenken untereinander, wodurch Vertrauen und Zusammenarbeit innerhalb des Teams gefördert werden.
• Fokus: Scrum-Team-Mitglieder behalten einen kollektiven Fokus auf Produkt- und Sprint-Ziele bei und priorisieren ihre Arbeit, um ihre Wertschöpfung zu optimieren.
• Respekt: Scrum-Team-Mitglieder respektieren sich gegenseitig als Fachkräfte und erkennen die Fähigkeiten, Perspektiven und Beiträge der anderen an, während sie das Produkt liefern. Dies schafft ein positives Arbeitsumfeld und verbessert die Zusammenarbeit zwischen den Teammitgliedern.

Diese Werte können und sollten angewendet werden, um jede agile Arbeitsweise effektiv zu gestalten.

Die Scrum-Werte tragen gemeinsam zur Fähigkeit des Scrum-Teams bei:

• Sich an Veränderungen anzupassen: Scrum reagiert sehr flexibel auf sich ändernde Anforderungen. Es berücksichtigt sich entwickelnde Kundenbedürfnisse, indem es Anpassungen am Ende jedes Sprints ermöglicht und so Flexibilität und höhere Kundenzufriedenheit fördert.
• Gemeinsam Entscheidungen zu treffen: Die selbstorganisierende Natur des Scrum-Teams und die empirische Grundlage der Scrum-Arbeitsweise fördern die Zusammenarbeit. Das Leben der Scrum-Werte bringt kollaboratives Arbeiten zum Leben.  
• Kontinuierlich zu verbessern: Scrum beinhaltet regelmäßige Retrospektiven – deren Zweck es ist, dem Scrum-Team regelmäßige Gelegenheiten zu bieten, die Wirksamkeit ihrer Arbeitsweise zu überprüfen und Verbesserungsbereiche zu identifizieren. Das ist kontinuierliche Verbesserung in der Praxis.
• Einen kundenorientierten Ansatz zu verfolgen: Scrum legt großen Wert darauf, dem Kunden Nutzen zu liefern. Der Product Owner, der die Kundeninteressen vertritt, priorisiert Features und stellt sicher, dass das Produkt während seiner gesamten Entwicklung mit den Kundenbedürfnissen und -erwartungen übereinstimmt.

Scrum bietet zahlreiche Vorteile für die Produktentwicklung und verbessert Effizienz, Zusammenarbeit und Anpassungsfähigkeit:

• Flexibilität
• Schnellere Markteinführung
• Verbesserte Zusammenarbeit
• Höhere Produktqualität
• Gesteigerte Kundenzufriedenheit
• Erhöhte Produktivität
• Besseres Risikomanagement
• Transparenz
• Gestärkte Teams
• Kontinuierliche Verbesserung.

Entdecken Sie mehr über die 10 wichtigsten Vorteile der Verwendung von Scrum, die in diesem Blog näher erläutert werden.

Scrum kann verschiedene Herausforderungen und Nachteile mit sich bringen. Bei der Einführung von Scrum kann es, wie bei allen neuen Arbeitsweisen, zu Widerstand gegen Veränderungen kommen. Teams können Schwierigkeiten mit dem Maß an Zusammenarbeit und Kommunikation haben, das für eine effektive Funktionsweise von Scrum erforderlich ist. Rollen wie der Scrum Master haben auch spezifische Verantwortlichkeiten, die sich von traditionellen Rollen unterscheiden, und das Missverständnis dieser Rollen kann zu Verwirrung und Ineffizienz führen. Sobald Scrum implementiert ist, bleiben noch Herausforderungen zu bewältigen. Häufige Risiken oder Nachteile sind:

1. Unzureichende Unterstützung durch das Management: Wie bei jeder Veränderungsinitiative ohne starke Unterstützung durch das Management innerhalb der Organisation wird die Einführung von Scrum auf Widerstand stoßen oder Schwierigkeiten bei der Überwindung organisatorischer Barrieren haben. Mangelndes Verständnis für den notwendigen kulturellen Wandel und schwache Verpflichtung dazu auf höheren Ebenen können den Wert, den Scrum als Arbeitsweise liefern kann, erheblich einschränken.
2. Lernkurve: Anfängliche Störungen und Anpassungen können die Produktivität beeinträchtigen, da sich Teammitglieder an die neuen Rollen, Ereignisse und kollaborativen Prozesse anpassen, die Scrum einführt. Das Sprichwort, dass sich die Dinge verschlechtern können, bevor sie besser werden, trifft oft zu. Der Schlüssel liegt darin, Zeit zum Lernen einzuräumen und Personen zu identifizieren, die bereits nachweislich anderswo damit erfolgreich waren und helfen können.
3. Selbstüberschätzung: Teams können das Risiko eingehen, sich während der Sprint-Planung zu viel Arbeit vorzunehmen, was zu Burnout oder Qualitätseinbußen bei den Liefergegenständen führt. Es ist entscheidend, das Verlangen nach schnellem Fortschritt mit realistischer Zielsetzung zu balancieren, um nachhaltige Entwicklungspraktiken aufrechtzuerhalten. Es ist wichtig, ein nachhaltiges Tempo zu etablieren – rechnen Sie mit dem Verfehlen von Sprint-Zielen, während das Team herausfindet, was erreicht werden kann.
4. Übermäßiger Fokus auf kurzfristige Ziele: Der Fokus auf kurze, zeitlich festgelegte Sprints in Scrum kann manchmal zu einer kurzsichtigen Sichtweise führen, bei der Teams unmittelbare Ziele über langfristige strategische Ziele stellen. In einer reinen Produktumgebung sollte ein guter Product Owner in der Lage sein, einen angemessenen langfristigen Fokus zu kommunizieren und aufrechtzuerhalten. Wenn die Komplexität herausfordernd wird, kann etwas mehr benötigt werden...
5. Probleme bei der Integration der Arbeit mehrerer Teams für größere, komplexere Vorhaben: Scrum ist stark, wenn es auf einzelne Teams angewendet wird, aber extrem schwach, wenn die zu erledigende Arbeit die Kapazität der "10 oder weniger" Personen im Team übersteigt, um sie zu bewältigen. In diesem Fall wird ein breiteres Framework empfohlen, um mit Umfang und/oder Komplexität umzugehen.

Für extreme Größenordnungen in einem Produktkontext – wo Hunderte von Entwicklern benötigt werden – kann ein skaliertes Framework wie SAFe ratsam sein. Für kleinere Größenordnungen – zum Beispiel bis zu 100 Entwickler – und/oder wo die Komplexität der gesamten Geschäftslösung mehrere Produkte, Dienstleistungen und andere Aktivitäten umfasst, wird ein agiles Projektframework wie AgilePM den Bedarf decken.

Aufbauend auf dem oben erwähnten Skalierungsproblem beantworten in dieser Folge von APMG's 'Level Up'-Serie Experten für agiles Projektmanagement Fragen zu agilem Projektmanagement und Scrum. Eine der wichtigsten behandelten Fragen ist der Unterschied zwischen diesen Ansätzen.  Themen wie Sprint-Planung, die ideale Länge eines Sprints und der Wert von täglichen Stand-ups werden diskutiert.

Das Agile Business Consortium hat seinen weltweit führenden Agile Project Management-Ansatz (AgilePM) weiterentwickelt, um eine Version anzubieten, die speziell für die Zusammenarbeit mit Scrum konzipiert wurde. AgilePM for Scrum bietet ein einheitliches Framework für die Bereitstellung vollständiger Geschäftslösungen. Es behandelt explizit Lösungen, die mehrere Produkte oder Dienstleistungen umfassen und die gemeinsamen Entwicklungsanstrengungen mehrerer Scrum-Teams oder eine Kombination aus Scrum- und Nicht-Scrum-Teams erfordern. Mit Techniken für agile teamübergreifende Planung und Koordination, Führung aus den Perspektiven der Geschäftsvision, Lösungsarchitektur und Projektmanagement, Governance, Risikomanagement und mehr ist dies eine Überlegung wert für komplexere Projektsituationen.

In diesem Video diskutieren Richard Pharro, CEO von APMG International, und ich über „AgilePM for Scrum". Dieses neue Framework vereint die Stärken zweier führender Agile-Frameworks. Richard stellt wichtige Fragen mit dem Ziel, Einblicke in das Framework zu geben, einschließlich seines Umfangs, der Gründe für seine Entwicklung und wer am meisten von dem Framework profitieren kann. Zusätzlich erkunden wir das akkreditierte Schulungs- und Zertifizierungsprogramm, das dieses Framework unterstützt.

Scrum hat einen bedeutenden Weg für Agilität in der Softwareproduktentwicklung geebnet und ist aus gutem Grund ein sehr beliebter und vielseitiger Ansatz, der perfekt dazu geeignet ist, Produkte zu liefern, die Kunden begeistern, auch angesichts komplexer und sich entwickelnder Anforderungen. Es nutzt die Vorteile funktionsübergreifender, kollaborativer Teams, um Werte schneller und effizienter zu liefern als ihre weniger agilen Pendants.

Es ist jedoch nicht ohne Herausforderungen... Ken Schwaber und Jeff Sutherland stellen in ihrem Scrum Guide 2020 fest, dass „Das Scrum Framework, wie hierin beschrieben, ist unveränderlich. Obwohl es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis kein Scrum. Scrum existiert nur in seiner Gesamtheit..."

Scrum ist ein einfaches, elegantes, effektives agiles Framework für die Produktlieferung. Dies wurde immer wieder auf der ganzen Welt in vielen verschiedenen Anwendungen in vielen verschiedenen Branchen bewiesen, aber nur wenn es in seiner Gesamtheit verwendet wird. Wenn Sie irgendein Element von Scrum weglassen, wird es einfach nicht richtig funktionieren. Scrum funktioniert, ScrumBut birgt die Gefahr des Scheiterns. ScrumBut beschreibt eine Situation, in der „wir verwenden Scrum, aber wir machen das nicht".  Für „wir machen das nicht" setzen Sie ein, was Sie möchten... „Wir machen kein tägliches Scrum", „wir arbeiten nicht zusammen", „wir haben keinen Scrum Master, wir haben einen Manager", „wir haben kein Product Backlog, wir haben eine Spezifikation", „wir definieren kein Sprint-Ziel" usw. Schwaber und Sutherland haben Scrum entwickelt, haben seine schrittweise und sorgfältige Evolution seit Mitte der 1990er Jahre überwacht – akzeptieren Sie ihre Weisheit und machen Sie es richtig.  

Wenn Ihr Gebiet die Produktentwicklung ist, dann ist es leicht zu sehen, wie die Einbringung von Agilität in dieses Gebiet durch die Anwendung und kontinuierliche Verbesserung der Anwendung von Scrum enormen Nutzen bringen könnte. Aber wenn Ihr Anliegen weiter reicht als reine Produktentwicklung, dann könnte sich Scrum allein als unzureichend erweisen.

Schulung, Bildung und kontinuierliche Ermutigung und Unterstützung von Scrum Teams ist erforderlich, um den Erfolg von Scrum zu nutzen. APMG bietet die folgenden Zertifizierungen für die Schlüsselrollen an.

Dieser Kurs lehrt Sie, als Scrum Master zu brillieren und die Produkt- und Lösungsentwicklung mit Scrum zu verbessern. Zu den wichtigsten Lerninhalten gehören ein umfassendes Verständnis des Scrum Frameworks, der Scrum-Prinzipien und der Rolle des Scrum Masters. Sie lernen auch, wie Sie effektive Entwicklungsteams aufbauen, als dienende Führungskraft agieren, Scrum-Events moderieren, Product Owner bei der Backlog-Verwaltung unterstützen und die Einführung von Scrum vorantreiben.

In diesem Kurs lernen Sie, wie Sie den Wert von Produkten maximieren, die von Scrum Teams geliefert werden. Gewinnen Sie ein tiefes Verständnis des Scrum Frameworks und der Rolle des Scrum Product Owners. Meistern Sie die Scrum Prinzipien und lernen Sie, wie Sie ein wertorientiertes Product Backlog erstellen und priorisieren, indem Sie Epics und Themes in umsetzbare User Stories aufteilen.

Der erste Tag sowohl des Scrum Master als auch des Product Owner Kurses ist identisch – sprechen Sie mit Ihrem APMG Schulungsanbieter über die Durchführung dieses Tages als eigenständigen Kurs, ideal für Teammitglieder und Stakeholder. Er deckt alles im Scrum Guide ab – und sie müssen alles wissen.   

AgilePM for Scrum kombiniert Scrum mit dem weltweit führenden agilen Projektmanagement-Ansatz (AgilePM) und bietet ein einheitliches Framework für die Bereitstellung vollständiger Geschäftslösungen, bei denen iterative und inkrementelle Entwicklung erforderlich ist. Diese Zertifizierung vermittelt Ihnen die Fähigkeiten, Scrum mit Agile Project Management zu integrieren. Die Kurse behandeln die Prinzipien und Theorien, die dem Scrum-Framework zugrunde liegen – angeboten von APMG- und Agile Business Consortium-akkreditierten Anbietern.

Das Bild des 'Scrum Framework' wurde vom Agile Business Consortium erstellt. Copyright © 2024, Agile Business Consortium. Alle Rechte vorbehalten.