Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03172.jsonl.gz/1793

Event 1
SASM
Advanced Scrum Master Zertifizierung (SASM)
Es ist soweit - SAFe 6.0 ist da! Wir aktualisieren gerade unsere Inhalte. Besuch unser SAFe-Board für Updates.
Seit den 1970er-Jahren wurden aufgrund von Problemen traditioneller Methoden unterschiedliche Ansätze entwickelt. Ende der 1990er-Jahre wurden agile Ansätze in vielen Softwareprojekten eingesetzt und gewannen an Bedeutung. Mit der Veröffentlichung des Agile-Manifests im Jahr 2001 stieg das Bewusstsein für Agilität und sein Einfluss auf die Softwarewelt nahm enorm zu.
Nach der Veröffentlichung des Agilen Manifests im Jahr 2001 rückte der Begriff der Agilität in den Fokus vieler Unternehmen. Der Fokus liegt darauf, die Zielqualität zu erhöhen, schneller auf Änderungen zu reagieren, Vorlaufzeiten zu verkürzen, häufiger neue Produktvarianten herauszubringen und Kosten zu senken. Für kleine und mittlere Unternehmen war es einfacher, agiles Management einzuführen und zu transformieren. Scrum ist das führende agile Framework, das Unternehmen dieser Größenordnung die schnellste Transformation bietet.
Die Transformation der traditionellen Kultur in Großunternehmen war nicht einfach. Aus diesem Grund wurden neue Methoden für die agile Transformation großer Unternehmen mit dem Konzept der skalierten Agilität entwickelt. Das heute beliebteste Framework für ein skaliertes agiles Vorgehen ist SAFe (Scaled Agile Framework).
Ein agiles Framework ist ein spezifischer Ansatz zur Planung, Verwaltung und Ausführung von Unternehmen. Agile Frameworks lassen sich im Allgemeinen in zwei Kategorien einteilen: Frameworks, die für Teams entwickelt wurden, und skalierte Frameworks, die Organisationen bzw. Unternehmen dabei helfen sollen, Agile in großem Maßstab über mehrere Teams hinweg zu implementieren.
Scrum ist ein Framework, das seit Anfang der 1990er-Jahre zur Verwaltung des komplexen agiler Softwareentwicklungsprozesses verwendet wird. Das Konzept von Scrum ist keine Methodik oder ein Prozess, sondern ein Rahmenwerk, in dem verschiedene Prozesse und Techniken existieren. Scrum wurde von Ken Schwaber und Jeff Sutherland entwickelt und leitet sich vom Begriff Rugby ab. Beim Rugby treffen sich Spieler für kurze Zeit und tauschen Ideen aus, um über ihren nächsten Zug im Spiel zu entscheiden. Im Rugby-Spiel bildete die Selbstorganisation, Führung und Zusammenarbeit des Teams die Grundlage des Begriffs Scrum.
Um also sagen zu können, dass man Scrum anwendet, ist es notwendig, alle Schritte im Framework zu durchlaufen. Scrum basiert auf Empirie und verwendet einen inkrementellen und iterativen Ansatz. Es gibt drei Säulen, die Scrum unterstützt: Transparenz, Beobachtung und Anpassung. Die zuständigen Teams arbeiten, indem sie diesen drei Themen die Bedeutung beimessen, die sie verdienen.
Es gibt Werte, die die in Scrum geleistete Arbeit leiten und helfen, die Arbeitsethik zu definieren, die das Scrum-Team haben sollte. Diese Scrum-Werte werden wie folgt aufgelistet:
Das Scrum-Framework besteht aus dem Scrum-Team, Rollen, Aktivitäten und Ergebnissen. Jede Komponente innerhalb des Frameworks dient einem bestimmten Zweck und ist notwendig, damit Scrum nutzbar und erfolgreich ist. Das Scrum-Team verwaltet die Beziehungen und Interaktionen zwischen ihnen, indem es Rollen, Aktivitäten und Ergebnisse verknüpft.
Kanban ist eine agile Methode, die in den 1950er-Jahren von Toyota eingeführt wurde. Im Softwareentwicklungsprozess wurde es erstmals 2004 von David J. Anderson mit einem Team bei Microsoft eingesetzt. Kanban konzentriert sich auf kontinuierliche Produktion und Lieferung. Kanban begrenzt die Anzahl der Jobs, an denen in jeder Phase des Softwareentwicklungsprozesses gearbeitet wird. Im Gegensatz zu Scrum hat Kanban keine bestimmte Ablaufzeit.
Die nächste Stufe wird für die Änderungen nicht erwartet und kann je nach Priorität sofort eingegriffen werden. Im Kanban gibt es keine Sonderrollen. Beim Kanban steht die Optik im Vordergrund. Der Prozess wird visualisiert und das Board mit den Arbeitspaketen mit dem Namen „Board“ ist für alle sichtbar. Kanban wird gegenüber Scrum bevorzugt, um die Anzahl der laufenden Arbeiten zu reduzieren, das Änderungsmanagement zu beschleunigen und die Visualisierung zu verbessern.
1996 wurde im Rahmen eines Projekts von Kent Beck und seinem Freund bei Chrysler die Extreme Programming-Methode entwickelt. Extreme Programming ist eine Ingenieurpraxis, die Softwareprojektteams dabei unterstützt, fehlerfreie und erfolgreiche Software zu entwickeln, wenn sich die Anforderungen ständig ändern und die Unsicherheit hoch ist. XP bietet eine einfache, aber effektive Umgebung, die es Teams ermöglicht, hochproduktiv zu sein.
Beim Extreme Programming arbeiten Manager, Kunde und Entwickler zusammen, und Projektteams können sich selbst organisieren, um Probleme so effizient wie möglich zu lösen. Das XP basiert auf 5 Grundwerten, 15 Prinzipien und 12 Praktiken.
Bei XP steht das Testen im Vordergrund. Bevor die Codierung abgeschlossen ist, werden Testszenarien von den Softwareentwicklungsteams vorbereitet, die Codierung durchgeführt und dann die Tests sofort durchgeführt. Ohne Kenntnis des Testumfangs kann mit der Softwareentwicklung nicht begonnen werden.
Kunden erstellen auch geschäftsorientierte, testbare und funktionale Testszenarien für Iterationen, und die gesammelten Komponenten sind so geplant, dass sie alle diese Tests erfolgreich bestehen. Bei erfolglosen Testszenarien kann je nach Kundenwunsch aus Kosten- und Zeitgründen auf dieses Szenario verzichtet werden. In XP arbeitet der Kunde mit dem kontinuierlichen Entwicklungsteam zusammen. Dies führt zu einer starken Kommunikation, der Früherkennung von Problemen und der Aufteilung von Verantwortlichkeiten.
|SCRUM||KAMBAN||XP|
|Rollendefinitionen||

Scrum-Master,
Produkteigentümer,
Entwicklungsteam spielen eine
Rolle.
Die Rolle des Projektleiters gibt es nicht.

Eine benutzerdefinierte Rollendefinition gibt es nicht.
Die Rolle des Projektleiters gibt es nicht.
|Es hat eine Kunden- und eine Teamrolle.|
|Job-Priorisierung||

Der Product Owner übernimmt die Priorisierung.
|Der Kunde priorisiert.||Der Kunde priorisiert.|
|Hinzufügen eines neuen Jobs||Während des Sprints können keine neuen Jobs hinzugefügt werden.||Neue Jobs können laufend hinzugefügt werden.||Es kann während der Iteration hinzugefügt werden.|
|Zeitkonzept||Die Zeit ist durch den Sprint begrenzt.||Es gibt keinen konkreten Zeitplan.||Eine monatliche Iteration kommt mit einer wöchentlichen Iteration heraus.|
|Meeting||Es gibt Sprintplanung, Daily Scrum, Sprintauswertung und Sprint-Flashback-Evaluierungsmeetings.||Es finden keine vorab vereinbarten Meetings statt.||Es finden keine vorab vereinbarten Meetings statt.|
Der Hauptzweck von skalierten agilen Ansätzen besteht darin, die Koordination zwischen Teams in Fällen sicherzustellen, in denen es mehr als ein Team gibt, die Portfolioloyalität zwischen Projekten aufrechtzuerhalten und die Agilität großer Organisationen zu skalieren. In diesen Situationen, in denen die Anzahl der Teams zunimmt und das Portfolio verwaltet werden soll, werden viele organisatorische Rollen in den verwendeten Modellen geändert und neue Rollen hinzugefügt.
SAFe ist eine der agilen Entwicklungsmethoden, die Anleitungen zur Bewältigung der Herausforderungen bietet, die bei der Entwicklung und Bereitstellung von Großprojekten mit kürzester Vorlaufzeit auftreten. Bei Scaled Agile Framework handelt es sich um eine Reihe erprobter Praktiken, die sich auf schlanken und agilen Ansätzen stützen, um insbesondere agile Teams für größere Projekte zusammenzubringen sowie zu synchronisieren und auszurichten. Die Hauptphilosophie von SAFe ist es, Werte zu schaffen – die kostbare Zeit einer Organisation sollte nicht mit einer Anwendung oder User Story verschwendet werden, die keinen Wert schafft.
Mit der neuesten aktualisierten Version 5.1 bietet Scaled Agile Framework - SAFe vier verschiedene Konfigurationen, die unterschiedliche Unternehmensgrößen und Entwicklungsumgebungen unterstützen können.
DevOps ist eine Reihe technischer Praktiken, die Kommunikation, Integration, enge Zusammenarbeit und Automatisierung ermöglichen. Abgeleitet aus der Kombination und Abkürzung der Wörter Entwicklung und Betrieb bezieht sich dieses Wort auf die harmonische und kooperative Arbeit dieser beiden Gruppen. Somit können ARTs kontinuierliche Produktionslinien effizienter betreiben.
DevOps-Teams zielen darauf ab, die Qualität und Häufigkeit von Lieferungen zu erhöhen, die Risikobereitschaft und Innovation zu verbessern, die Recyclingzeiten zu verbessern (Fehler nach der Bereitstellung auf die alte Praxis zurückzusetzen), die Häufigkeit und Schwere von Veröffentlichungsfehlern zu verringern, die Zeiten zur Fehlerbehebung zu verkürzen und Produkte zu erhalten, schneller zu vermarkten.
Die Tatsache, dass Scaled Agile Framework für groß angelegte Agilität verwendet werden kann und dass wir mehr Wissen und Erfahrung über SAFe besitzen als andere Frameworks sowie die klar definierten Rahmenprinzipien, Werte und Praktiken und das Mindestmaß an Prozesslücken im Framework wirksam sind, macht SAFe als agile Framework unschlagbar.
LeSS wurde 2008 von Craig Larman und Bas Vodde veröffentlicht und ist eine breit angelegte Version der Scrum-Technik. LeSS bietet zwei verschiedene große Scrum-Frameworks an. Die meisten Skalierungselemente von LeSS konzentrieren sich darauf, die Aufmerksamkeit aller Teams auf das gesamte Produkt und nicht auf „mein Team“ zu lenken. Für LeSS ist die „End-to-End“-Fokussierung vielleicht das wichtigste Problem, das es bei der Skalierung zu lösen gilt.
In LeSS arbeiten alle Teams in einem gemeinsamen Sprint, um in jedem Sprint ein gemeinsames auslieferbares Produkt zu liefern.
Es ist ein skalierter, agiler Ansatz, der 2004 von Ken Schwaber definiert wurde. Im Wesentlichen ist dieser Ansatz eine Weiterentwicklung des zuvor beschriebenen Scrum-Frameworks. Im Gegensatz dazu bezieht sich SoS sich auf die Meetings, die mit dem Upstream-Team zusätzlich zu den täglichen Meetings der normalen Scrum-Teams von SoS abgehalten werden. SoS ist ein Team, das durch Auswahl von einem oder zwei Botschaftern aus jedem Scrum-Team gebildet wird, wenn mehr als ein Scrum-Team koordinieren muss. Dieses Team trifft sich täglich, wöchentlich oder monatlich in der vom Team selbst festgelegten Häufigkeit und führt ähnliche Meetings vergleichbar wie die im Framework von Scrum beschriebenen täglichen Scrum-Meetings durch.
● Was jedes Team seit dem letzten Meeting erledigt hat
● Woran jedes Team bis zum nächsten Meeting arbeiten wird (sich verpflichten es abzuschließen).
● Welche Risiken, Probleme, Hindernisse betreffen andere Teams?
● Abhängigkeiten zwischen der Arbeit der Teams und ihrem aktuellen Status
Diese Meetings vermeiden auch das Risiko, dass Teams zusätzliche (unnötige) Arbeit in gleichem Maße leisten. Die Dauer der SoS-Meetings kann weiterhin vom Team bestimmt werden. Sie wird entsprechend der Anzahl der im SoS enthaltenen Scrum-Teams angepasst. Obwohl es keine Begrenzung für die Anzahl der Teams gibt, die in den SoS aufgenommen werden sollten, hat die Praxis gezeigt, dass sich bei mehr als 10 beteiligten Teams die Besprechungszeiten verlängern und die Mitglieder sich nicht auf die Besprechung konzentrieren können.
DAD ist ein prozessorientiertes, lern- und lösungsorientiertes Framework, das 2007 von Scott Ambler veröffentlicht wurde. Hauptmerkmale dieses Frameworks sind:
Im Grunde genommen wurde dieses Framework geschaffen, um die Verfahrenslücken zu schließen, die in Scrum nicht definiert waren. Was das DAD-Framework hybrid macht, ist, dass es von vielen Methoden wie agiler Modellierung, Kanban, Edge-Programmierung, Lean-Software-Entwicklung gespeist wird. Die Rollen im DAD-Framework sind Scrum weitgehend ähnlich.
Anders als bei Scrum gibt es beim DAD Framework eine Teamleiterrolle. Die Definition der Rolle ist eine Mischung aus der Rolle des Scrum-Masters in Scrum und der Rolle des architektonischen Eigentümers in agilen Techniken. Der Teamleiter ist die Person, die die Architektur sowie den DAD-Prozess immer kennt und das Team lenkt und leitet.
Die Rollen des Product Owners und des Teammitglieds in DAD sind die gleichen wie in Scrum. Es gibt auch sekundäre Rollen in DAD, dies sind: Experte unabhängiger Tester, Domänenexperte, technischer Experte und Adapter (Integrator).
Das DAD-Framework ist ein zielorientiertes Framework. In jeder Phase von DAD werden unterschiedliche Ziele definiert. Wenn wir diese Ziele unter den Phasen von DAD auflisten, sind sie wie folgt:
Da DAD ein lernorientiertes Framework ist, werden die Schleifen in jeder Iteration so betrieben, dass auch die Lernfähigkeiten der Teammitglieder innerhalb des DAD erhöht werden. Die People-First-Philosophie von DAD zielt darauf ab, Teammitglieder wertzuschätzen, sie wie in anderen agilen Methoden zu stärken, ihr Selbstbewusstsein zu steigern und so selbstorganisierte agile Teams mit Entscheidungsmacht zu bilden.
Das Scrum@Scale-Framework wurde von Jeff Sutherland geschaffen, einem der Schöpfer des agilen Manifests, das die Werte und Prinzipien der agilen Denkweise darlegt. Scrum@Scale ist ein agiles Framework, das es Organisationen ermöglicht, geschäftliche Agilität zu erreichen und eine größere Wirkung zu erzielen, indem das Scrum-Framework auf Teams ausgeweitet wird. Scrum@Scale ist bestrebt, Produkte und Dienstleistungen von höchstmöglichem Wert zu liefern und gleichzeitig Teamnetzwerke über Branchen und Disziplinen hinweg bei der Bewältigung komplexer Probleme zu unterstützen.
Scrum@Scale bietet die Tools, die Unternehmen benötigen, um leistungsstarke Teams aufzubauen. Es ermöglicht ihren Teams, in einem nachhaltigen Tempo zu arbeiten und gleichzeitig einen Mehrwert für den Kunden zu schaffen. Scrum@Scale erweitert das Scrum-Framework, um branchen- und disziplinübergreifend produktive Ergebnisse zu liefern, einschließlich Software, Hardware, Services, Betrieb und F&E (Forschung und Entwicklung).
Während Scrum einen Rahmen für die Entwicklung und Wartung komplexer Produkte durch ein einzelnes Team bietet, konzentriert sich Scrum@Scale (S@S) auf das gesamte Ökosystem von Teams, um die gesamte Unternehmenskultur zu verändern. Der Scrum@Scale-Ansatz basiert darauf, ein gesundes Scrum-Team aufzubauen und Veränderungen in der gesamten Organisation positiv zu beeinflussen.
Die gleichen Meetings wie im Scrum-Prozess sind auch in Scrum@Scale verfügbar.
Der einzige Unterschied zu Scrum ist hier das Scaled Daily Scrum. Wie das Daily Scrum in Scrum ist es ein tägliches Meeting, an dem ein Vertreter jedes Teams teilnehmen muss. Die Teilnahme des gesamten Teams ist nicht erforderlich. Es reicht aus, wenn jemand anwesend ist, der weiß, was in seinem Team vor sich geht.
Das Scaled Daily Scrum ist ein 15-minütiges Meeting, das die Mitglieder zusammenbringt, um Engpässe oder Probleme zu besprechen, die Teams daran hindern könnten, ihre Sprintziele zu erreichen, Wissen auszutauschen und Transparenz und Vertrauen zwischen allen Teams aufrechtzuerhalten.
Da Scrum@Scale auf Scrum basiert, verwendet es die Rollen des Product Owners und des Scrum Managers und sind dieselben Kompetenzen, die im Scrum Guide definiert sind. Verschiedene Verantwortlichkeiten werden in größeren Maßstäben wahrgenommen. In diesem skalierten Framework gibt es zwei Hauptrollen: den Scrum of Scrums Master (SoSM), der für den Scrum-Master-Zyklus verantwortlich ist, und den Chief Product Owner (CPO), der für den Product-Owner-Zyklus verantwortlich ist. Diese Rollen ähneln den Positionen des Product Owners und des Scrum Managers bei andere Scrum-Methoden.
Je nach Größe der Organisation oder Anwendung sind möglicherweise mehrere SoS erforderlich, um ein sehr komplexes Produkt bereitzustellen. In solchen Fällen kann ein Scrum of Scrum of Scrums (SoSoS) unter vielen SoSs erstellt werden. Die SM-Organisation (SoS, SoSoS und EAT) arbeitet als Ganzes, um die anderen Komponenten des Scrum-Master-Zyklus zu ergänzen.
Wenn Scrum skaliert wird, können sich organisatorische Probleme vervielfachen. In diesem Fall braucht Scrum@Scale ein Executive Action Team (EAT). Die Funktion des Executive Action Teams besteht darin, eine große Anzahl von SoS (oder SoSoSs) zu koordinieren. Dieses Team ist für die Transformationsstrategie verantwortlich und hat die Implementierung von Scrum-Werten, Rollen und Unterstützung bei der Entscheidungsfindung und Beseitigung von Barrieren. Eine wichtige Voraussetzung für EAT ist der Wille und die Macht der Top-Führungskräfte, die Organisation zu verändern.
Das Executive MetaScrum Team (EMT) hat die organisatorische Vision und legt strategische Prioritäten für die Organisation fest. So wie SoSs als SoSoS wachsen können, kann MetaScrums durch den gleichen Mechanismus expandieren. Dieses Team ist dafür verantwortlich, die organisatorische Richtung zu ändern oder zu entscheiden, welche Produkte oder Dienstleistungen umstrukturiert oder eingestellt werden müssen. Es richtet das Geschäft weiter an einer Roadmap aus und kann in einem regelmäßigen oder vorübergehenden Tempo gehalten werden.
Dieses Team besteht aus Finanz-, Personal- und Kundenverpflichtungen des CPO und des Geschäftsinhabers. EMT und CPO arbeiten eng zusammen, um notwendige Änderungen in Strategie, Finanzierung oder Ressourcenallokation anzugehen.
Das Nexus-Framework ist ein skaliertes agiles Framework, das von Ken Swabber erstellt und 2015 von Scrum.org veröffentlicht wurde. Laut dem Nexus-Leitfaden ist Nexus ein Framework, das die Arbeit von ungefähr drei bis neun Entwicklungsteams verbindet, die an einem einzigen Produkt-Backlog arbeiten, um einen integrierten Produktteil zu erstellen, der einem bestimmten Zweck dient und aus Rollen, Aktivitäten, Artefakten und den Regeln besteht.
Es wird empfohlen, maximal 9 und mindestens 3 Scrum-Teams in einem Nexus-Team zu haben. Innerhalb einer Organisation können beliebig viele Nexus-Teams aufgebaut werden, abhängig von der Größe der Organisation und der Anzahl der zu entwickelnden Produkte.
Nexus erweitert Scrum um eine neue Rolle und einige erweiterte Ereignisse und Artefakte.
Die erste der mit Nexus definierten Rollen ist das Nexus-Integrationsteam (NIT). Das Nexus-Integrationsteam befasst sich mit der Lösung aller technischen oder nicht-technischen Integrationsprobleme zwischen Scrum-Teams. Dazu gehören Probleme, Risiken, Hindernisse und Abhängigkeiten. Mitglieder dieses Teams können auch in verschiedenen Rollen innerhalb von Scrum-Teams arbeiten, sollten aber immer zuerst die Aufgaben des Integrationsteams priorisieren.
Denn jedes Problem, das das Funktionieren der Teams stören wird, ist viel wichtiger. Dieses Team besteht aus dem Product Owner, einem Scrum Master und gewählten repräsentativen Mitgliedern. Die NIT kann sich im Laufe der Zeit ändern, mit Ausnahme des Produkteigentümers.
Es gibt drei vom Nexus-Framework definierte Werke:
Das Nexus-Ziel ist ein gemeinsames Ziel für alle Nexus-Teams. Das Nexus-Sprint-Backlog ist das Ergebnis der ersten Sitzung der Nexus-Sprint-Planungsmeetings. Diese Liste ist die Summe der Arbeitselemente, zu deren Erledigung sich alle Scrum-Teams in diesem Sprint verpflichtet haben. Sie werden mit täglichen Nexus-Meetings aktualisiert. Der integrierte Produktteil ist die endgültige Ausgabe des Nexus.
Am Ende jedes Sprints muss jedes Nexus-Team ein funktionales, wertschöpfendes Produktstück produzieren, das in das Kernprodukt integriert werden kann. Der integrierte Produktteil wird den Stakeholdern beim Nexus-Sprint-Review-Meeting präsentiert, das am Ende jedes Sprints stattfindet. Von diesem Produktteil wird erwartet, dass es die Definition von „Fertig“ erfüllt.
Mit Nexus identifizierte Aktivitäten sind:
Diese Meetings sind auch zeitlich begrenzte Ereignisse, wie im Scrum-Framework angegeben.
Die Prinzipien und Werte, die in Scrum gelten, gelten auch in Nexus. Das wichtigste Prinzip von Nexus ist, dass die Teams, ihre Funktionsweise, Arbeit und Kommunikation transparent sind. Nexus hat absolut keinen Platz für das Verstecken von Informationen, das Bemühen, Fehler unsichtbar zu machen, und undurchsichtige Verhaltensweisen wie Fehlinformationen des Kunden.
Während die Entwicklungsteams von Spotify daran arbeiteten, ihre Agilität zu steigern, teilten sie ihre Erfahrungen und ihr Wissen. Jetzt inspirieren deren dokumentierten Praktiken, bekannt als das Spotify-Modell, viele Softwareunternehmen, ihre Arbeit besser zu strukturieren.
Das Spotify-Modell ist ein auf den Menschen ausgerichteter, autonomer Ansatz zur Skalierung von Agilität, der die Bedeutung von Kultur und Netzwerken betont. Dieses Modell hat Spotify und anderen Organisationen dabei geholfen, Innovation und Produktivität voranzutreiben, wobei der Schwerpunkt auf Autonomie, Kommunikation, Verantwortlichkeit und Qualität lag.
Die grundlegende Entwicklungseinheit bei Spotify ist Squad. Squad ist ähnlich wie das Scrum-Team aufgebaut. Dieses Team, das Design-, Entwicklungs- und Testaktivitäten gemeinsam durchführt, sind selbstorganisierte Teams (8 oder weniger Mitglieder), die agile Frameworks verwenden, einige davon Scrum, andere Kanban oder eine Mischung aus beidem. Nicht jeder Squad hat einen offiziell ernannten Teamleiter. Allerdings gibt es einen Product Owner.
Diese Struktur erhöht die Autonomie, was die Menschen glücklicher macht, da sie eine starke Quelle der Motivation ist. Darüber hinaus ist die Struktur in Squads schnell, da Genehmigungssysteme, Entscheidungsengpässe an der Spitze und Abhängigkeiten von anderen Teams vermieden werden. Der Product Owner ist dafür verantwortlich, die zu erledigende Arbeit zu priorisieren. Wie die Arbeit erledigt wird, steht nicht in seiner Verantwortung. Ein Team kann auch Zugang zu einem agilen Coach haben, der ihm hilft, seine Arbeitsweise zu entwickeln und zu verbessern. Spotify hat den Scrum Master in Scrum in “Agile Coach“ umbenannt. Coaches halten Retrospektiven, Sprint-Planungsmeetings und Einzelcoachings ab.
Eine andere Struktur in Spotify wird durch Tribes ausgedrückt. Es gibt einen Tribes Leader, der dafür verantwortlich ist, diesen Strukturen, die durch das Zusammenkommen mehrerer Squads gebildet werden, den bestmöglichen Lebensraum zu bieten. Tribes sind so konzipiert, dass sie kleiner als 100 Personen sind. Ein Tribe besteht aus Squad-Gruppen, die in verwandten Bereichen wie der Backend-Systeminfrastruktur arbeiten.
Chapter- und Guild-Rollen sind auch auf Spotify verfügbar. Ein Chapter ist definiert als eine kleine Familie von Menschen desselben Tribes mit ähnlichen Fähigkeiten und der gleichen Besonderheit (das ist der Kitt, der das Unternehmen zusammenhält). Jedes Chapter trifft sich regelmäßig, um spezifische Probleme im Zusammenhang mit seinem Fachgebiet zu besprechen. Zum Beispiel Chapter Testingenieure, Chapter Webentwickler oder Chapter Backend.
Das Guild ist eine „Interessengruppe“, die sich aus Menschen zusammensetzt, die Wissen, Werkzeuge, Codes und Praktiken organischer und mit größerer Beteiligung teilen möchten. Guilds umfassen normalerweise die gesamte Organisation, während Chapters immer eine Gruppe innerhalb des Gebietsschemas des Tribes sind. Einige Beispiele für Guilds sind: Web Technology Guild, Test Engineers Guild, Agile Coaches Guild usw. tatsächlich ist Spotify eine Art Matrixorganisation.
Das Risiko dieses Modells besteht darin, dass die Infrastruktur des Systems zusammenbricht, wenn sich niemand auf die Integration des Systems als Ganzes konzentriert. Um dies zu verhindern, kommt eine weitere Rolle „System Owner“ ins Spiel. Alle Systeme haben einen oder zwei Systembesitzer. Der Systembesitzer ist die Person(en), die bei technischen oder architektonischen Problemen im Zusammenhang mit dem System kontaktiert werden. Diese Person ist der Koordinator und leitet diejenigen, die die Codes auf dem System entwickeln. Der System Owner konzentriert sich unter anderem auf Themen wie Qualität, Dokumentation, technische Schulden, Stabilität, Skalierbarkeit und den Rollout-Prozess.
Zusammenfassend lässt sich sagen, dass es viele verschiedene agile Frameworks gibt, die je nach Situation und Anforderungen eingesetzt werden können. Jedes Framework hat seine eigenen Vor- und Nachteile, und es ist wichtig, das passende Framework für das eigene Projekt und Team auszuwählen.
Wenn du mehr darüber erfahren möchtest, welche agilen Frameworks es gibt und wie sie im Projektmanagement eingesetzt werden können, empfehlen wir dir unsere "Scaled Agile Framework"-Seite. Hier findest du verschiedene SAFe-Kurse, darunter auch unseren "Leading SAFe"-Kurs, der dir die Grundlagen von Agilität und SAFe vermittelt und dich auf die entsprechenden SAFe-Zertifizierungen vorbereitet.
Und wenn du auch dein Wissen und deine Fähigkeiten in anderen IT-Bereichen erweitern möchtest, schau doch mal auf unserer "Academy"-Seite vorbei. Dort findest du eine Vielzahl an Schulungen und Zertifizierungen zu verschiedenen IT-Themen, darunter auch agile Methoden. Wir freuen uns darauf, dir dabei zu helfen, deine Karriereziele zu erreichen!
Scrum.org. (n.d.). Scrum. https://www.scrum.org/
Scrum.org. (2020). Das Scrum Guide. https://scrumguides.org/scrum-guide.html
Scrum Inc. (n.d.). Scrum Inc. https://www.scruminc.com/
Scaled Agile, Inc. (n.d.). Scaled Agile Framework. https://www.scaledagileframework.com/
Scaled Agile, Inc. (2023). Skalierung von Agile [Webseite]. https://scaledagile.com/
Kanban University. (n.d.). Kanban Leitfaden. https://kanban.university/kanban-guide/
Extreme Programming. (n.d.). Extreme Programming. http://www.extremeprogramming.org/
Large-Scale Scrum (LeSS). (n.d.). Large-Scale Scrum (LeSS). https://less.works/
Agilest. (n.d.). Agilest. https://www.agilest.org/
Agile Modeling. (n.d.). Agile Modeling. http://agilemodeling.com/
OpenXcell. (2019, 19. Februar). Disciplined Agile Delivery - Ein umfassender Leitfaden. https://www.openxcell.com/blog/disciplined-agile-delivery/
Methods & Tools. (2014, 1. März). Einführung in Agile-Methoden [Webseite]. https://www.methodsandtools.com/archive/archive.php?id=104
Scrum@Scale. (n.d.). Scrum@Scale. https://www.scrumatscale.com/
Scrum.org. (n.d.). Der Online Nexus Guide. https://www.scrum.org/resources/online-nexus-guide
Spotify. (2012, 21. November). Engineering-Kultur [Blog-Post]. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
um dich für diese Schulungen mit Rabatt anzumelden
Event 1
Advanced Scrum Master Zertifizierung (SASM)
Event 2
DDD - Domain Driven Design Training
Event 3
Leading SAFe® 6.0 Zertifizierung
Event 4
Product Owner / Manager Zertifizierung (POPM)
Du suchst nach einer Schulung für ein ganzes Team, aber keines unserer Trainings entspricht Deinen Anforderungen? Kein Problem! Gerne konzipieren wir gemeinsam mit dir ein maßgeschneidertes Inhouse-Training, das optimal auf die Bedürfnisse deines Unternehmens zugeschnitten ist. Wir freuen uns auf deine Anfrage!