Skalieren von Agile-Programmen mit SAFe

Das Wichtigste zuerst, um schneller Ergebnisse zu erwirtschaften

F: Bei uns arbeiten mehrere Teams an der gleichen Funktion oder dem gleichen Projekt. Ich weiß, dass ein Scrum of Scrums-Meeting dabei helfen kann, alle Teams auf dem gleichen Stand zu halten. Aber was ist, wenn alle diese Teams auch noch an verschiedenen anderen Funktionen arbeiten? An einem bestimmten Punkt ist das dann nicht mehr möglich.

A: An einem SoS-Meeting sollte immer nur eine Person aus jedem Team teilnehmen. Was noch wichtiger ist: Sie sollten Wertströme aufzeichnen, die die Funktionsentwicklung in einer geringeren Anzahl von Teams zusammenfassen. Gerade deshalb, weil diese Koordination so wichtig ist, konfigurieren wir die Organisation neu. Wenn wir die Arbeit durch die Teams weiterleiten und versuchen, ähnliche Arbeiten zu bündeln, sind keine 100 Teams nötig, die koordiniert werden müssen, um Wert zu erzielen.

F: Welche Vorschläge können Sie für Agile-Teams machen, die mit einer Wassserfallorganisation zu tun haben und für die Teile eines Projekts von den Wasserfallteams geliefert werden müssen?

A: Sie müssen dafür sorgen, dass Agile-PSI-Endpunkte an den Liefermeilensteinen ausgerichtet sind, nach denen sich das Wasserfallteam richtet. Sie werden sehr wahrscheinlich mehrere PSIs vor einem wichtigen Wassserfall-Lieferdatum haben. Versuchen Sie, die Abhängigkeit Ihres Agile-Teams so gut wie möglich von den Lieferungen des Wasserfallteams abzugrenzen, um Engstellen möglichst zu minimieren. Wenn diese Abgrenzung nicht möglich ist, sollten Sie objektive Beweise dafür bereithalten, dass Ihre Agile-Teams von den Wasserfallteams blockiert werden. Dies führt dann hoffentlich zu einer engagierten Diskussion mit dem Management darüber, warum dies so ist.

F: Produkt-Backlog: Wie stellen Sie sicher, dass das Design von Long-Pole-Funktionen und -Funktionalität direkt beachtet wird, und nicht erst als zu kompliziert angesehen wird, um es direkt am Anfang zu betrachten?

A: Programmmanager, die für das Programm-Backlog von Funktionen verantwortlich sind, sollten versuchen, die Funktionen mit höherem Risiko und höherer Komplexität im Backlog nach oben zu bringen (wenn sie als wichtig gelten), dabei aber trotzdem ein Gleichgewicht mit anderen, weniger risikoreichen und komplexen Funktionen beibehalten. Hierdurch ist es für die Teams wahrscheinlicher, dass sie etwas innerhalb eines PSI liefern können. Eine Funktion im Backlog zu übergehen, weil sie als zu komplex oder risikoreich angesehen wird, und nur die einfachen Arbeiten zu planen, ist kein guter Agile-Ansatz.

F: Sollten Defekten auch Punkte zugewiesen werden, wie dies bei User Storys für Funktionen der Fall ist?

A: Ja. So steht Ihnen ein eindeutiges Maß für den Durchsatz (die Geschwindigkeit oder Velocity) Ihres Teams zur Verfügung, das die gesamten Arbeiten umfasst (Storys und Defects).

F: Welche Art von Entwickler- oder QA-Umgebungen nutzen Sie, wenn der veröffentlichte Code nicht der QA-Umgebung entspricht? Wie und wo testen, prüfen und duplizieren Sie Bugs?

A: Die Agile-Teams sollten über eine Entwickler-Bereitstellungsumgebung verfügen, die der Produktionsumgebung entspricht, und zwar eben aus den in der Frage genannten Gründen. Das Agile-Team, das die Funktion entwickelt hat, sollte auch weiterhin für sie verantwortlich sein.

F: Wie kann ein Team 10 Wochen im Voraus Schätzungen vornehmen?

A: Ein wichtiger Schritt hin zur Agile-Reife besteht darin, dass Teams in der Lage sind, mittelfristig zu planen und die Lieferung von Storys innerhalb der nächsten drei bis sechs Sprints vorhersagen zu können. Wichtig ist hierbei, dass keine detaillierten Aufgaben geplant werden, sondern eher Storys in Sprints aufgenommen werden, wobei die kurzfristigen eben zuverlässiger sind als die längerfristigen. Um diese Aufgabe gut erledigen zu können, muss ein Team bereits ein gewisses Geschwindigkeitsniveau (Velocity) erreicht haben. Anders ausgedrückt, die Anzahl von Points, die in jedem Sprint geliefert werden. Hierdurch liegt das Hauptaugenmerk bei der Verbesserung des Teams dann eher auf dem Erreichen von Konsistenz, und nicht so sehr auf der Schnelligkeit. Um eine mittelfristige Planung bzw. PSI-Planung vornehmen zu können, muss außerdem das gesamte Team anwesend sein.

F: Die Kultur spielt für viele eine große Rolle. Wie managen Sie die Kommunikation zwischen Silo-Teams, wenn die verschiedenen Teams nicht gewöhnt sind, miteinander zu kommunizieren?

A: Dies ist ein kultureller Wandel und zeigt, warum ein starkes objektives Coaching und spezielle Förderung so wichtig für die erfolgreiche Umsetzung von Agile-Prinzipien ist.

F: Wie wirken sich ständige, wichtige Geschäftsanforderungen in letzter Minute auf das Backlog auf Portfolio-Ebene und die Planung künftiger Releases aus?

A: Wenn diese Änderungen in letzter Minute nicht anhand des normalen Pflegeprozesses des Programm-Backlogs verwaltet werden, hat dies gravierende Auswirkungen auf Ihre vorhandenen Pläne. Wenn Sie Änderungen der Release-Planung zulassen, nachdem die Agile-Teams sich dieser Planung verschrieben haben, dann haben Sie den Planungsprozess im Grunde zunichte gemacht, und die Teams können keine vorhersagbare Kadenz festlegen. Hier wird ein starker Release Train Engineer (RTE) benötigt, der sicherstellen kann, dass Arbeitsvereinbarungen eingehalten werden.

F: Wie berücksichtigen Sie die Arbeit an Elementen, die nicht funktional sind oder zur Compliance gehören? Werden diese als Overhead angesehen und daher von der Kapazität der Einzelnen oder der Teams abgezogen?

A: Das trifft zu, wenn die NFR- oder Compliance-Elemente auf alle neuen Funktionen umgelegt werden. Betrachten Sie sie einfach als Teil der Definition of Done für die Funktion.

F: Alle großen Unternehmen sind auf verschiedene Standorte verteilt und agieren in mehreren Zeitzonen. Wie führen Sie in diesem Fall Meetings auf Programmebene durch?

A: Der Agile Release Train von Dean Leffingwell besagt, dass Sie den gesamten Train (bis zu 150 Personen) für ein 10-Wochen-Release für zwei Tage zur Planung zusammenbringen sollten. Dies fordert von den leitenden Mitarbeitern ein gewisses Engagement. Wenn nicht jeder entsendet werden kann, dann sollten wenigstens die Team Leads teilnehmen. Mögliche Risiken und Hürden sollten am besten sofort ermittelt werden, damit bei der Planung alle beisammen sind.

F: Wenn Sie 5–10 Teams haben, wie vermeiden Sie dann, dass jedes einzelne Teammitglied an allen täglichen Scrum-Meetings teilnimmt, um nicht den Anschluss zu verlieren?

A: Gute Scrum Master erinnern ihre Teammitglieder daran, dass sie ihrem aktuellen Team verpflichtet sind. Der Release Train Engineer muss zusammen mit dem Systems-Team und dem Produkt-Management-Team sicherstellen, dass die Informationen ordnungsgemäß bis zum Executive Team vordringen. Außerdem müssen sie sich um die Abhängigkeiten zwischen den einzelnen Teams kümmern, damit die einzelnen Teammitglieder nicht das Gefühl haben, dass sie unbedingt an den täglichen Scrum-Meetings der anderen Teams teilnehmen müssen. Dies kann auch ein Hinweis darauf sein, dass eine zu enge Koppelung zwischen den Teams besteht.

F: Wie werden bei diesem Modell die Performance-Tests für alle Komponenten durchgeführt?

A: Dies liegt in der Verantwortung des Systems-Engineering-Teams auf der Programmebene von SAFe.

F: Ist es möglich, die Umsetzung dieser Ideen in CA Agile Central zu veranschaulichen? Sind entsprechende Videos verfügbar?

A: Ihr Technical Account Manager kann Ihnen dies demonstrieren.

F: Wie ist Ihre Einstellung zur fortlaufenden Bereitstellung im Vergleich zur 10-Wochen-Bereitstellung?

A: CA Agile Central unterstützt als Plattform und Coaching-Organisation sowohl SAFe als auch die fortlaufende Bereitstellung sowie eine hybride Form dieser beiden Ansätze. Wenn Sie jedoch einen hybriden Ansatz verfolgen möchten, empfehlen wir Ihnen, dass Sie sowohl über Erfahrung bei der Skalierung innerhalb Ihrer Organisation (damit Sie auswählen können, was am besten funktioniert) als auch für die Organisation basierend auf Ihren Erfahrungen, welche Aspekte effektiv sind, verfügen. Obwohl SAFe sehr präskriptiv ist, können Programme damit bis zu 150 skaliert werden.

F: Stimmt es, dass die Geschwindigkeits-Normalisierungslogik mehr oder weniger bedeutet, dass "1 Punkt = 1 Tag Aufwand" normalisiert wird?

A: Das stimmt. Diese Anleitung stammt von Dean Leffingwell und soll Punkte im gesamten Unternehmen zusammenfassen. 

F: Wir haben 12 einzelne Teams. Ich könnte sie mir stattdessen in 3 bis 4 Programmen vorstellen. Gibt es dafür erwiesene Vorteile? Ich könnte mir mehr Effizienz, mehr Bewusstsein für Abhängigkeiten etc. vorstellen.

A: Ja. Durch die Ausrichtung einzelner Scrum-Teams um einen einzelnen Werte-Stream können Sie sicherstellen, dass Bemühungen auf Teamebene um integrierte Funktionen herum ausgerichtet werden, die Kunden echten Wert bringen (unter Berücksichtigung von Kontoabhängigkeiten, Integrationsanforderungen etc.).  Dadurch wird außerdem sichergestellt, dass die Ausführungs- und Strategiezweige Ihrer Produktentwicklungsorganisation so ausgerichtet sind, dass Sie nicht nur Dinge richtig erstellen, sondern auch die richtigen Dinge erstellen.

F: Können Sie Ziele beschreiben?

A: Die Festlegung eines Ziels für jedes PSI ist entscheidend, um sicherzustellen, dass die Ausführung an der Strategie ausgerichtet ist.

F: Sie haben die Rolle des Projektmanagers angesprochen. Welche Aufgabe hat der Business-Analyst?

A: Der Business-Analyst wird als epische Eigentümerrolle in SAFe dargestellt. In der Regel arbeitet ein epischer Eigentümer jeweils mit einer von zwei Epic Storys, die in dessen Fachgebiet und aktuelle Geschäftsmission fallen. Auf dieser Website erhalten Sie weitere Informationen.

F: Wie sieht es damit aus, die Unterstützung des Managements zu erhalten, und zwar in dem Sinne, dass dieses versteht, was Agile wirklich ist, und nicht nur sagt, es sei eine „gute Idee“?

A: SAFe-Konzepte basieren auf Agile- und Lean-Konzepten und das Verständnis und die Unterstützung seitens des Managements sind ein wichtiger Erfolgsfaktor. Dean Leffingwell beginnt seine Schulung für Führungskräfte mit einer Erklärung des House of Lean. Entscheidend ist hier, dass das Management in Lean-Denken, Produktentwicklungsfluss und Agile-Entwicklung geschult wird.

F: Wie normalisieren Sie die Geschwindigkeit (Velocity) über mehrere Teams hinweg? Geschwindigkeit ist im Allgemeinen eine teamzentrierte Kennzahl.

A: Im Kontext von SAFe empfiehlt Dean Leffingwell Folgendes für normalisierte Team-Geschwindigkeiten, die die wirtschaftliche Basis für die Schätzung von Arbeit bieten.

  • Geben Sie dem Team für jeden Vollzeitentwickler und -tester im Team acht Punkte (für Teilzeitmitarbeiter entsprechend anpassen).
  • Ziehen Sie für jeden Urlaubstag oder Feiertag der Teamitglieder einen Punkt ab.
  • Suchen Sie nach einer kleinen Story, die innerhalb eines halben Tages codiert und innerhalb eines halben Tages getestet und validiert werden kann. Nennen Sie sie 1.
  • Schätzen Sie jede andere Story im Verhältnis zu dieser ein.
  • Gehen Sie nicht zurück (machen Sie sich keine Gedanken über erneute Kalibrierung).

Dieses Thema kann kontrovers sein (sogar unter unseren Coaches hier bei CA Agile Central) und wird ausführlich in unserem Leading SAFe-Kurs dargestellt.

F: Wie können Sie nicht zweckbestimmte Teams überwinden, oder geht das nicht?

A: Im Kontext von SAFe ist es grundlegend, dass sich die DBT(Define/Definieren, Build/Erstellen, Test/Testen)-Teams dem Release Train widmen, für das sie Funktionen liefern. Weitere Informationen finden Sie hier. Auf Programmebene erklärt SAFe Rollen wie Architektur, UX, Systemteam und Services, die auf Programmebene gemeinsam genutzt werden.

F: Ich würde gerne Ideen hören, wie man schätzen kann, wie viel Ihres Programm-Backlogs ein Release ausmacht, ohne das herkömmliche Projektmanagement hinzuzuziehen. Geschwindigkeit funktioniert auf Teamebene gut, auf Programmebene gibt es jedoch mehr Abhängigkeiten.

A: In SAFe wird empfohlen, das Funktions-Backlog eines Programms auch in Story-Punkten zu schätzen, und Geschwindigkeit soll beim Release-Planungsprozess helfen. Weitere Informationen finden Sie hier.

F: Mein Unternehmen besitzt ein langes Defekt-Backlog. Wie können mehrere Teams während einer Sprint-Planungssitzung am besten aus demselben Backlog schöpfen? 

A: In SAFe wird eine Release-Planungssitzung empfohlen, die sämtliche Arbeit umfasst, die von den Teams geliefert werden muss, die an einen gemeinsamen Werte-Stream liefern (in SAFe als Release-Train bezeichnet). Genauere Informationen finden Sie in dieser Beschreibung eines Release-Planungsmeetings in SAFe.

F: Würden Sie Ihr Programm in einem Projekt in CA Agile Central strukturieren oder würden Sie ein Projekt pro Team vorsehen?

A: Wir empfehlen eine Struktur, bei der das Programm ein Projekt in CA Agile Central ist, das untergeordnete Projekte für jedes Team aufweist, das an den Funktionen im entsprechenden Programm-Backlog arbeitet. Stellen Sie sich die Projektstrukturen als Backlog-Container vor, wobei jedes Team ein eigenes eindeutiges Backlog besitzen sollte, das in dem allgemeinen Programm-Backlog zusammengefasst ist. Weitere Informationen finden Sie im Thema zum Einrichten Ihrer Hierarchie.

F: Ist der Produktverantwortliche auf Teamebene dann nicht künstlich oder nur ein Beauftragter des Programmmanagers, wenn der Programmmanager so gut definiert ist?

A: Im Kontext von SAFe behält der Produktverantwortliche das Eigentum am Team-Backlog und die Priorisierung. Da der Produktverantwortliche Teil eines größeren Teams aus Produktverantwortlichem und Produktmanager sein wird, erhalten sie Input aus dem Programm-Backlog, der ihr Backlog beeinflussen wird.

F: Wofür steht UX?

A: UX steht für „User Experience“ (Benutzererfahrung). Benutzererfahrung unterstreicht die empirischen, affektiven, aussagekräftigen und nützlichen Aspekte von Mensch-Computer-Interaktion und Produkteigentum.

F: Was passiert, wenn unterschiedliche Teams aufgrund der unterschiedlichen Arbeitstypen unterschiedliche Sprint-Längen verwenden? Wäre es nicht zu präskriptiv, zu sagen, dass alle Sprints das gleiche Anfangs- und Enddatum haben müssen?

A: Wenn verschiedene Teams in einem einzelnen Agile Release Train zusammenkommen, ist es äußerst wichtig, dass sie denselben Sprint- und Release-Rhythmus haben. Das bedeutet zwar, dass alle Sprints dasselbe Anfangs- und Enddatum besitzen, wenn Sie jedoch ein Data-Warehouse-Team haben, das einen längeren Sprint benötigt, würden wir zwecks Übereinstimmung mit Sprint-Grenze und -Rhythmus des allgemeinen Agile Release Train einen Rhythmus von vier Wochen empfehlen (anstatt drei).

F: Gilt bei mehreren Teams für alle Teams derselbe zweiwöchige Sprint-Zyklus? Oder können die Sprints gestaffelt werden?

A: Es ist entscheidend, dass Teams desselben Agile Release Train synchronisiert sind und denselben Sprint-Rhythmus aufweisen.  Der häufigste Rhythmus sieht zweiwöchige Sprints vor. Zudem sind alle Teams innerhalb eines Agile Release Train auf einen PSI(Potentially Shippable Increment, potenziell lieferbares Inkrement, oder Potentially Shippable Release, potenziell lieferbare Release)-Zeitplan synchronisiert, der in der Regel 10 bis 12 Wochen lang ist.

F: Wie gehen Sie mit einem Rhythmus oder einer Release eines neuen Systems um, für das eine Entwicklungsdauer von sechs Monaten gilt und an dem mehrere Teams beteiligt sind?

A: Starten Sie den zehnwöchigen Rhythmuszyklus. Sie haben Ihren Werte-Stream und Ihre Teams bereits identifiziert. Nehmen Sie sich viel Zeit, um Ihre Führungskräfte in SAFe zu schulen, und starten Sie dann einen ersten zehnwöchigen PSI-Zyklus.

F: Wird ScrumAlliance eine neue Rolle neben SCM und CSPO einführen?

A: Nein, ScrumAlliance plant nicht, eine neue zertifizierte Rolle auf Ebene von Scaled Agile einzuführen, Es gibt jedoch eine SAFe Agilist-Zertifizierung, und CA Agile Central bietet den entsprechenden Zertifizierungskurs an.

F: Wofür steht PSI?

A: PSI steht für „Potentially Shippable Increment“ (potenziell lieferbares Inkrement) (Release). Dies bezieht sich auf das Ergebnis am Ende der längeren Timebox. Trotzdem haben Sie am Ende der einzelnen Sprints weiterhin potenziell lieferbare Inkremente. In diesem Fall handelt es sich um den Rhythmus, in dem die Arbeit aller Teams integriert werden kann.

F: Wie arbeiten Produktmanager (Programm) und Produktverantwortlicher (Team) zusammen?

A: Der Produktmanager ist leitender Produktverantwortlicher für alle Produktverantwortlichen im Team. Ähnlich wie der Release Train Egineer (RTE) Uber Scrum Master ist.

F: Können Sie einige wichtige Faktoren nennen, die bei der Umstellung einer Organisation von Wasserfall zu Agile zu berücksichtigen sind?

A: Zu den wichtigen Erfolgfaktoren zählen aktive Unterstützung durch Führungskräfte und Leitung für Ihre skalierte Agile-Initiative, ein fokussierter und inkrementeller Übernahmeansatz, fachmännische Leitung von jemanden mit Erfahrung in skalierten Agile-Einführungen und organisatorischer Veränderung, dedizierte Coaching-Unterstützung auf Team- und Programmebene und ein skalierter Agile-Einführungsplan, der nicht nur auf den Prozess abzielt, sondern auch auf Organisationstruktur, Mitarbeiter und Rollen, Kennzahlen und Anreizsysteme.

F: Sollte es einen Scrum-Master pro Gruppe geben? Würden mehrere Scrum-Master unterschiedliche Aspekte managen (Kommunikation gegenüber Analyse)?

A: Auf Teamebene gibt es im Allgemeinen einen Scrum-Master pro Scrum-Team.  Im Laufe der Reifung der Teams kann ein Scrum-Master möglicherweise mehrere Teams unterstützen. Es würden nicht mehrere Scrum-Master eingesetzt, damit sich die einen um Kommunikation und die anderen um Analyse kümmern. Ein einziger Scrum-Master unterstützt Agile-Praktiken in einem Scrum-Team und hilft, das Scrum-Team während eines Sprints vor externen Einflüssen zu schützen. Sie müssen auch sicherstellen, dass Hindernisse für den Erfolg des Scrum-Teams beseitigt werden.

F: Gibt es all diese Rollen zusätzlich zu den Scrum-Rollen? Das sieht nach sehr viel Overhead aus.

A: Die Rollen auf Programmebene sind als neue Konzeption der vorhandenen Rollen in der Organisation anzusehen. Ein Beispiel ist ein Mitglied des PMO, das für die Verfolgung des Status von Programmlieferbestandteilen verantwortlich ist. Innerhalb eines SAFe Agile Release Train kann diese Person stattdessen die Rolle des Release Train Engineer übernehmen.

F: Warum der Fünf-Sprint-Zyklus?

A: Zwar mögen 12 Wochen logischer erscheinen, jedoch liegen Sie mit 10 Wochen knapp unter dem vierteljährlichen Rhythmus, sodass Sie Zeit haben, die Ergebnisse des PSI einzubeziehen und als Input für die breitere vierteljährliche Steuerung auf strategischer Ebene zu nehmen. Im Allgemeinen können Teams 3 bis 6 Sprints voraus planen.

F: Gilt für PSI-Demos derselbe Rhythmus wie für Sprint-Demos?

A: PSI-Demos erfolgen in regelmäßigem Rhythmus. Während Sprint-Demos am Ende eines jeden Sprint-Inkrements erfolgen, gibt es PSI-Demos am Ende der einzelnen PSI-Inkremente. PSI-Demos sind für geschäftliche Interessenvertretern in der Regel weitaus aussagekräftiger und nützlicher, da in diesem Forum ganze Funktionen demonstriert werden. Das ist eine gute Gelegenheit, um sicherzustellen, dass sich Interessenvertreter Zeit für die Teilnahme nehmen.

F: Erreicht SAFe auch ausgelagerte und Offshore-Entwicklungsteams gut, wenn diese einen Teil der Arbeit liefern, der mit Teams vor Ort koordiniert werden muss?

A: Ja, in der Regel haben Organisationen, die Scaled Agile implementieren, global verteilte Teams. Da Coaches von CA Agile Central die Einführung von Agile Release Trains unterstützen, wenden sie Strategien für eine effektive verteilte Zusammenarbeit und Planung an.

F: Können Sie zum Systemteam weiter ins Detail gehen? Aus welchen Mitarbeitern besteht es? Wie unterscheiden sich ihre Kenntnisse und Fähigkeiten von denen anderer? Wie werden sie motiviert? 

A: Hier finden Sie einen guten Überblick über das Systemteam.

F: Wie kann sichergestellt werden, dass die Organisation synchron bleibt, ohne zahlreiche Meetings durchführen oder 100 Mitarbeiter zu einem einzigen Meeting einladen zu müssen?

A: Die Scrum of Scrums-Struktur funktioniert hier gut. Denken Sie daran, dass an einem SoS-Meeting immer nur eine Person aus jedem Team teilnehmen sollte. Zudem sollten Sie Wertströme aufzeichnen, die die Funktionsentwicklung in einer geringeren Anzahl von Teams (innerhalb eines einzelnen Agile Release Train) zusammenfassen. Gerade deshalb, weil diese Koordination so wichtig ist, konfigurieren wir die Organisation neu. Wenn wir die Arbeit durch die Teams weiterleiten und versuchen, ähnliche Arbeiten zu bündeln, müssen wir nicht so viele Mitarbeiter und Teams koordinieren, um Wert zu erzielen.

F: Wie passt die Rolle des Programmmanagers in diesen Framework?

A: Programmmanager, die für das Programm-Backlog von Funktionen verantwortlich sind, sollten versuchen, die Funktionen mit höherem Risiko und höherer Komplexität im Backlog nach oben zu bringen (wenn sie als wichtig gelten), dabei aber trotzdem ein Gleichgewicht mit anderen, weniger risikoreichen und komplexen Funktionen beibehalten. Hierdurch ist es für die Teams wahrscheinlicher, dass sie etwas innerhalb eines PSI liefern können. Eine Funktion im Backlog zu übergehen, weil sie als zu komplex oder risikoreich angesehen wird, und nur die einfachen Arbeiten zu planen, ist kein guter Agile-Ansatz.

F: Ist der Projektmanager weiterhin der technische Produktverantwortliche?

A: Die Rolle des Projektmanagers würde sich je nach Fähigkeiten der Person ändern. Er könnte gut als PO eingesetzt werden, wenn er die Fähigkeiten hat, diese Rolle erfolgreich zu erfüllen. Möglicherweise ist er aber besser für zahlreiche andere Rollen im Agile-Kontext geeignet, etwa den Scrum-Master oder Produktmanager.

F: Manchmal müssen wir mit der Einführung von Architekturelementen (Basisblöcke) beginnen, die nicht demonstriert werden können. Dies kann einige Wochen so bleiben. Wie gehen wir damit um (dass kein Geschäftswert demonstriert werden kann)?

A: Der Wert liegt in der Entdeckungsarbeit auf Achitekturebene, mit der definiert wird, ob die erforderliche Arbeit durchführbar ist. Die demonstrierbare Komponente definiert, welche Arbeit getan werden muss und wie sie im zukünftigen Werte-Stream im Kontext des architektonischen Wegs durchgeführt wird.

F: Haben wir ein Glossar für die ganzen Akronyme?

A: Ein Glossar mit Begriffen finden Sie unter www.scaledagileframework.com.

F: Wie wissen wir, dass die Epic Storys und Funktionen ausreichend durchdacht sind, um für die nächste Aufgliederungsebene bereit zu sein?

A: Sie können einen Entdeckungsprozess aus einem Portfolio-Kanban mit Beendigungsrichtlinien in jeder Spalte erstellen, um zu bestimmen, ob eine Epic Story oder User-Story weiterentwickelt werden kann. Weitere Informationen finden Sie hier und hier.  

F: Können wir die Release-Planung verkürzen?

A: Zwei Tage sind die Regel, und dies hängt von der Anzahl an Personen ab, die an der Release-Planung beteiligt sind. Sie wurde auch schon in nur 1,5 Tagen erledigt. Das mag immer noch lang erscheinen, jedoch ist die Planung wichtig, um sicherzustellen,dass Ihre Teams für die nächste Release an den richtigen Dingen arbeiten. Dieses Planungsmeeting ist entscheidend, um sicherzustellen, dass Ihre Teams und Release Trains abgestimmt sind.

F: Das Team auf Programmebene umfasst viele Rollen. Wie arbeiten sie zusammen? Welche Art von Interaktionen und Meetings sind erforderlich?

A: Die kurze Antwort lautet, dass es mehrere vorgegebene Kontrollpunkte und Interaktionen gibt, die ein Funktionieren von SAFe ermöglichen. Der zweitägige Workshop „Leading SAFe" geht sehr detailliert auf diese Frage ein. Wenden Sie sich an Ihr Kontoteam, wenn Sie eine genauere Besprechung dieses Themas wünschen.

F: Was beschreibt das Diagramm zum architektonischen Weg? Unterschiedlichen Aufwand für architektonische Elemente?

A: Der architektonische Weg ist ein fortlaufender Aufwand. Das Diagramm zeigt die stetige Bereitstellung von Architekturfunktionen im Zeitablauf.

F: Können Sie einige Strategien für das Managen von Entwurfsiterationen nennen, die in Entwicklungsiterationen fließen? Und wohin passt die Ausarbeitung von Anforderungen? Wie würden Sie die Priorisierung zwischen architektonischen und geschäftlichen Funktionen managen?

A: Dean Leffingwell bezeichnet dies als Aufrechterhaltung eines architektonischen Wegs. Die entsprechenden Regeln sind einfach und agil:

  • Diese Teams wiederholen wie alle anderen Agile-Teams im Programm auch.
  • Der Verdienst gehört dem funktionierenden Code, nicht Modellen und Entwürfen.
  • Zeit ist wesentlich – es sollte nur einiger Iterationen bedürfen, um die neue Architektur unter Beweis zu stellen.

F: Wie oft sollten Scrum of Scrums-Meetings stattfinden?

A: Laut Dean Leffingwell werden SoS-Meetings nach Bedarf abgehalten. In der Regel legt der Release Train Manager die Frequenz nach Bedarf fest.

F: Wie erzielen wir Transparenz für Funktionen, die User Storys in verschiedenen allgemeinen Projekten (gleiche Hierarchieebene) in CA Agile Central haben?

A: Wenn Sie CA Agile Central Portfolio Manager mit der Portfoliohierarchie über der Story-Hierarchie anwenden, können Sie Funktionen auf dieser Ebene anzeigen. Sprechen Sie mit Ihrem Vertriebspartner, um herauszufinden, wie Sie CA Agile Central Portfolio Manager nutzen können.

F: Ist es Ihrer Meinung nach kein guter Ansatz, einen Produktmanager als Produktverantwortlichen einzusetzen? Warum würden Sie empfehlen oder davon abraten, einen PM in der Rolle des Produktverantwortlichen vorzusehen?

A: Es ist schön, wenn unterschiedliche Personen diese Rollen ausüben, wir wissen jedoch, dass dies in der Praxis nicht immer möglich ist. Einige Organisationen geben die Rolle des PM und PO an ein Team aus Personen, von denen jeder auf natürliche Weise die Rolle einnimmt, die am besten zu ihm passt. Das funktioniert gut für den Start Ihrer SAFe-Transformation, im Laufe der Zeit werden Sie aber unterschiedliche Personen in dieser Rolle sehen wollen.

F: Haben Sie Referenzen für Best Practices in Branchen, die Scaled Agile zur Verbesserung der Lebenszyklen von Hardware- oder Softwareprojekten eingesetzt haben?

A: Unsere Erfahrung hat gezeigt, dass Hardware meist längere Rhythmen erfordert, sodass Lieferbestandteile zwischen Hardware- und Softwareteams an PSI-Grenzen koordiniert würden.

F: Müssen sich Programmmanager mit der Taxonomie der Softwareentwickler und -tester gegenüber Leads befassen? 

A: Nicht täglich. Die Programmmanager sind auf Ebene des SAFe-Programms tätig und helfen bei der Ergänzung der Backlogs der Teams. Es ist jedoch besser für Programmmanager, nicht im luftleeren Raum zu agieren und zu wissen, was die Teams tun. An dieser Stelle hilft ein Tool wie CA Agile Central. Es hilft Ihnen dabei, zu sehen, wie Ihre Teams funktionieren.

F: Wie viel Schätzung oder Dimensionierung erfolgt bei der Release-Planung?

A: Die Dimensionierung von Funktionen basiert auf dem Weighted Shortest Job First (Gewichtete kürzeste Operationszeit zuerst) von Donald Reinertson. Wenn Sie Funktionen in Storys aufgliedern, die in Sprints geplant sind, werden die Storys in Punkten geschätzt (wie normaler Scrum).

F: Was sind die Unterschiede zwischen den Geschäftsfunktionen, die in ein PSI eingehen, und den Funktionen, die in einen Team-Sprint eingehen? Können Sie Beispiele nennen?

A: Die Geschäftsfunktionen werden zusammen mit den architektonischen Funktionen im PSI geplant. Im Agile Release Train gliedern Sie die Funktionen dann in untergeordnete Storys, um einem Team in einem Sprint zugeordnet zu werden.

F: Welche Beziehung besteht zwischen Produktmanager und Release-Team? In Scrum entscheiden POs, welche Funktionen am wichtigsten sind, was auch damit zusammenhängt, was zuerst veröffentlicht werden muss. Was, wenn PM und Release-Team kollidieren?

A: Das Agile-Release-Managementteam umfasst in der Regel Senior-Vertreter aus dem Produktmanagement, um Konflikte zu mindern.

 

F: Wie viel Zeit sollten Produktverantwortliche mit ihren Scrum-Teams verbringen?

A: Der Produktverantwortliche ist ein Mitglied des Teams, sodass die Verfügbarkeit für das Scrum-Team wesentlich ist.

F: Wird das Programm-Backlog in Story-Punkten geschätzt? Wenn ja, von wem?

A: Das Programm-Backlog wird anhand des „Weighted Shortest Job First“ dimensioniert, wodurch wir ein wirtschaftliches Modell für die Priorisierung verwenden können. Es kann von Vertretern des Agile-Teams oder Architekten dimensioniert werden.

F: Ist das Systemteam ein QA-ähnliches Team oder ein Team aus Entwicklern?

A: Das Systemteam ist eher das Team, das auf die Leistung von Unterstützung beim Erstellen und Verwenden der Entwicklungsumgebungs-Infrastruktur fokussiert ist: kontinuierliche Integration, Build-Umgebungen, Testplattformen.

F: Gibt es Spickzettel für das CA Agile Central-Reporting?

A: Zettel zum CA Agile Central-Reporting finden Sie hier.

F: Wie können wir Agile-Prinzipien in einem Projekt zur Technologiemigration mit großer Plattform implementieren, bei dem sich die Geschäftsanforderungen nicht allzu sehr vom normalen Geschäft unterscheiden?

A: Agile-Praktiken und -Prinzipien entstehen ursprünglich aus der Idee des richtigen Erstellens. Durch das Senken der Kosten individueller Änderungen und das Verbessern der Qualität durch inkrementelle Arbeitsgewohnheiten werden im Allgemeinen die Beziehungen zwischen der Implementierungsgruppe und den verschiedenen Interessengruppen verbessert.  Dadurch wird wiederum die Beziehung aufgebaut, um zukünftige Amforderungen effektiver zu bearbeiten.

F: Was passiert mit einer Agile-Anwendung auf eine neue Produktlinieneinführung, wenn die allererste Lieferung allgemeine Architekturlösungen und 3 bis 6 Monate Arbeit für etwa 30 bis 40 Ingenieure erfordert? Die Markteinführungszeit ist wesentlich.

A: Die Skalierung von Agile in dieser Umgebung ist wesentlich für den Erfolg. Der Fokus auf Funktionen und Epic Storys ermöglicht ein deutlich schnelleres Feedback und Lernen durch die Organisation, was die Wahrscheinlichkeit einer erfolgreichen Einführung erhöht. Agile ist zu den Lean-Startup-Ansätzen auf Enterpriseebene kompatibel, die in den meisten Aspekten eine Voraussetzung für den Erfolg sind. Sorgen Sie für eine starke Konzentration auf die Bereitstellung der wichtigsten Funktionen und Epic Storys, selbst wenn dies zu einer weniger optimalen Team- oder Funktionszuordnung führt.

F: Wie überzeugen Sie einen Programmmanager, Agile in einer Umgebung zu skalieren, die nur ein Scrum-Team und andere Ein-Personen-Teams besitzt?

A: Denken Sie an den Aspekt der Risikominderung. Welche Risiken bestehen für die Fähigkeiten der Organisation, wenn Sie einen der Mitarbeiter eines Ein-Personen-Projekts verlieren? Teamverantwortung gibt Gelegenheit für übergreifende Schulungen und Risikominderung. Was noch wichtiger ist: Teams ermöglichen eine organisationsweite Reduzierung von unfertigen Leistungen (Work-In-Process, WIP), was zu einer schnelleren Bereitstellung von Fähigkeiten und verbessertem Fokus sowie verbesserter Qualität der Ergebnisse führt.

F: Ist SAFe ein CA Agile Central-Begriff?

A: Nein. SAFe steht für Scaled Agile Framework® (SAFe). Es entwickelt sich sehr rasch als Standardansatz der Branche für die Skalierung von Agile im Unternehmen.

F: Können Sie Kanban-Teams (1 bis 2 Mitarbeiter) und Scrum-Teams im Rahmen eines Projekts haben?

A: So arbeiten wir in der Praxis, obwohl dies keine offizielle Komponente von SAFe ist. Wir suchen im Allgemeinen nach Teams mit einer geschäftlich begründeten Durchlaufzeit von unter 10 Arbeitstagen als potenzielle Teams für die Übernahme von Kanban oder anderen, auf kontinuierlichen Flüssen basierten Ansätzen.

F: Können Sie Agile-Prinzipien auf Wartungsprojekte anwenden?

A: Wir haben durch die Anwendung von Agile of ein Wartungsprojekt bereits außerordentliche Verbesserungen gesehen. Es ist genauso wichtig, das Team auf die Arbeit mit dem höchsten Wert zu fokussieren, vielleicht umso mehr, da es so viele Anfragen gibt. Es ist genauso wichtig, gute Entwürfe, Qualität und Flexibilität einzusetzen, um Prioritäten ändern zu können.

F: Gibt es Fallstudien zur Verwendung von SAFe in einer Data-Warehousing-Umgebung?

A: Telstra, ein australischer Telekommunikationsanbieter und CA Agile Central-Kunde, hat hier eine öffentliche Präsentation eingestellt.

F: Ich arbeite in einem nicht-softwarebezogenen Entwicklungsteam und habe versucht, die Agile-Methodologie für Projekte mit einer Laufzeit von 5 bis 7 Monaten einzuführen. Glauben Sie, das wird funktionieren?

A: Wir erleben viele Erfolge bei der Anwendung von Agile in einer nicht-IT-bezogenen Umgebung. Ein gutes Beispiel ist die CA Agile Central-Software selbst. In jeder Abteilung verwenden wir Elemente von Agile: Accounting, Marketing, Vertrieb und Führungsteam. Bei vielen Gruppen funktioniert Scrum mit Iterations-Timeboxes gut. Bei sehr ungleichmäßiger (viel und wenig) oder sehr spezialisierter Arbeit funktioniert Kanban besser. Entscheidend ist es, sich auf den Wert zu konzentrieren, in kleineren Chargen zu arbeiten, Arbeit sichtbar zu machen, Qualität zu integrieren und die Selbstorganisation von Teams zu ermöglichen. SAFe bietet eine Möglichkeit, die Arbeit von vielen Teams zu koordinieren, sodass sie bei Lieferungen zusammenarbeiten können.

F: Wie fängt man kurzfristige Änderungen bei der Routineplanung auf?

A: Kurzfristige Änderungen sind genau das, worauf Agile ausgelegt ist. Teams jeder Ebene – Team, Programm und Portfolio - müssen solche Entscheidungen treffen können und die Fähigkeit entwickeln, intelligente Entscheidungen über die Annahme von Änderungen zu treffen. Da das Team in jedem Sprint neue Informationen verarbeiten kann, werden weniger Änderungen als Notfälle angesehen. So kann etwas, das früher als Notfall angesehen wurde, jetzt bis zum nächsten Sprint warten.

F: Wie erreichen Sie mit synchronisierten Sprints bei jedem Meeting das richtige Publikum?

A: Der beste Ansatz ist eine kombinierte Demo. Bei CA Agile Central können in einer Stunde all unsere Teams präsentieren. Der Großteil des Unternehmens nimmt zumindest virtuell teil. Ein anderes Unternehmen hatte ein Wirtschaftsausstellungsmodell für Demos, wobei Interessenvertreter im Raum herumgehen, um die für sie wichtige Arbeit anzusehen. Für die Planung auf Sprint-Ebene ist dies möglicherweise zu detailliert für das Publikum. Es sollte daher besser an PSI oder Release Train Planung teilnehmen.

F: An welcher Stelle passen administrative Teams in dieses Modell? Sind diese kleiner und eher auf Wartung fokussiert als auf neue Entwicklung?

A: Bei einem zu kleinen Team - weniger als fünf Vollzeitmitarbeiter - ist Scrum zu aufwendig. Die meisten echten Wartungs-/Verwaltungsteams verwenden nicht Scrum, sondern das für sie nützlichere Kanban.  Kanban bietet dieselbe Fokussierung auf Wert, Priorisierung, Zusammenarbeit, Transparenz und Qualität, verwendet jedoch keine Timeboxes.

F: Bitte erklären Sie den 10-Wochen-Framework.

A: Laut SAFe-Empfehlung sollten PSIs (Potentially Shipable Increments, potenziell lieferbare Inkremente) 8 bis 12 Wochen betragen, am besten 10. Der Zeitraum soll nur etwas kürzer sein als ein Quartal, damit die Ergebnisse der PSIs bei der vierteljährlichen strategischen Planung auf Portfolio- und Enterprise-Ebene berücksichtigt werden können.

F: Wie verwalten Sie Releases mit einer Mischung aus Agile und Wasserfall und einem gemeinsamen Release-Datum, wobei integriertes Testen als Ganzes vorgenommen werden muss?

A: Hier ist die HIP-Iteration wesentlich. Das Härten ist der Zeitpunkt für das integrierte Testen, das in der Regel durch Lieferteams und Systemteam gemeinsam erfolgt. Wichtig für den Erfolg ist hier, dass die Wasserfallteams ihre Arbeit, einschließlich Funktionstests, abschließen, wenn die Scrum-Teams den letzten Sprint abschließen.  Dann wird sämtliche Arbeit integriert und während HIP getestet.

F: Ist Funktion ein Synonym für Fähigkeit?

A: Das kann es sein. Einer unserer Kunden hat Fähigkeit mit verschiedenen definierten Funktionen definiert. Eine Fähigkeit könnte auch eine MMF (Minimal Marketable Feature, Funktion „Minimal marktfähig“) oder MVF (Minimal Viable Feature, Funktion „Minimal rentabel“) sein.

F: Erklären Sie, wie die Normalisierung der Geschwindigkeit vorgenommen wird und welche Auswirkungen dies auf einzelne Teams hat.

A: SAFe spricht von dem Ansatz ein Entwickler oder eine QA-Person = 1 Story-Punkt pro Tag über eine Iteration minus Scrum-Overhead. Es gibt viele Gespräche und eine Kontroverse im Hinblick auf normalisierte Geschwindigkeit.

F: Ist das Systemteam ein Sprint-Team? Welche Art von Backlog-Elementen kann dieses Team besitzen?

A: Dies wird sowohl als Sprint-Team als Teil eines einzelnen ART (Agile Release Train) angewendet als auch als Team für die Unterstützung mehrerer ARTs und eigener Storys und Aufgaben in jedem ART. Häufig umfassen die verwalteten Backlog-Elemente Infrastruktur, kontinuierliche Integrationen und End-to-End-Testing.

F: Wo werden die Anforderungen definiert? Anscheinend ist kein Business-Analyst (BA) im Team. Und wie sieht es aus mit dem Wechseln von Ressourcen zwischen Teams in Abhängigkeit von den mehreren Teams zugewiesenen Storys?

A: Anforderungen werden auf Funktions- und Detailebene der User Storys definiert und erstellt. Die herkömmliche Rolle eines Business-Analysten wird nicht in SAFe definiert. Jedoch übernehmen sie häufig die Rolle des Produktverantwortlichen (Product Owner, PO) oder stimmen sich mit dem PO ab. Wir mögen beständige Teams, sodass wir die Arbeit gerne durch die Teams weiterleiten.

F: Wie würden Sie SAFe mit gemischten Agile- und Wasserfall-basierten Teams auf das Release-Train-Konzept anwenden?

A: Wir haben mit Kunden zusammengearbeitet, die mit Teams begannen, die immer noch das Wasserfall-Prinzip benutzen und Stage-Gates oder Funktionen abgleichen, die sie liefern, und mit dem Agile-Portfolio und Agile-Teams abgleichen. Viele dieser Unternehmen spüren jetzt langsam die Nachteile gemischter Methodologien und suchen nach Möglichkeiten, auf Scrum umzustellen.

F: Gibt es einen Grund dafür, dass der Zeitrahmen 10 Wochen beträgt und nicht kürzer oder länger ist?

A: Die 10 Wochen entsprechen ungefähr einem vierteljährlichen Release-Rhythmus. Ein Grundsatz in SAFe lautet, in einem bestimmten Rhythmus zu entwickeln und bei Bedarf zu veröffentlichen. Daher wird das PSI für den Rhythmus verwendet und es kann jederzeit veröffentlicht werden, sofern eine kontinuierliche Erstellung und Bereitstellung vorgenommen wird, bei der keine HIP-Iteration erforderlich ist.

F: Wie stellen Sie ein architektonisches Backlog in CA Agile Central dar?

A: In CA Agile Central ist dieses architektonische Backlog in Portfolioelementen wie architektonischen Epic Storys, Funktionen und Storys enthalten. 

F: Wie gehen Sie mit PSI-Releases im Vergleich zu tatsächlichen Produkt-Releases in CA Agile Central um, da nur eine davon eine CA-Agile Central-Release sein kann?

A: Wir empfehlen die Verwendung der CA Agile Central-Release als Timebox, die an Agile Release Train ausgerichtet wird. Verwenden Sie dann Tags oder ein benutzerdefiniertes Feld, um tatsächliche Releases wie v2.1, v2.2 etc. nachzuverfolgen.

Feedback

Benötigen Sie weitere Informationen? Die CA Agile Central-Community ist Ihre zentrale Anlaufstelle für Self-Service und Support. Treten Sie der CA Agile Central-Community bei, um dem CA Agile Central-Support Feedback mitzuteilen oder Fälle zu melden, Antworten zu finden oder mit anderen Benutzern zusammenzuarbeiten.