Nachdem sich Agile Testing in agilen Teams etabliert hat, gibt es in einem skalierten Kontext neue Herausforderungen für das Testen. Am Beispiel von SAFe beschreibt dieser Artikel, wie diese Herausforderungen in einem Framework zur agilen Skalierung adressiert werden können.

Inhalt:

Testen in einem agilen Team

Seit der Veröffentlichung des Agilen Manifests [1] und der Einführung von Scrum [2] vor nunmehr fast 20 Jahren haben sich grundsätzliche Prinzipien und Praktiken des Testens in einem agilen Team entwickelt und in der Praxis etabliert und bewährt (auch wenn es neben Scrum weitere agile Vorgehensweisen gibt, wollen wir uns zur Vereinfachung an Scrum orientieren).

Die Herausforderung für das Testen bestanden vor allem darin, dass Scrum zu dem Thema erstmal nichts beiträgt. Im Scrum Guide [3] wird “Testen” exakt dreimal erwähnt:

  • The Development Team: “Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis. […] Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.” [4]
  • Product Backlog: “Product Backlog items often include test descriptions that will prove its completeness when ‘Done’.” [5]
  • Definition of “Done”: “Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.” [6]

Diese vermeintliche Lücke hat sowohl Vor- als auch Nachteile: der große Vorteil besteht darin, die mit dem Testen verbundenen Aufgaben wirklich als gemeinsame Verantwortung des Teams zu verstehen, weil es eben kein entsprechendes Teilteam gibt, dem man diese Aufgabe delegieren könnte. Der Nachteil bestand darin, dass sich Agile Testing in einem agilen Team erstmal über die Jahre entwickeln musste – was es aber auch erfolgreich getan hat. Die Umsetzung der agilen Werte und Prinzipien finden sich inzwischen in zahlreichen Ideen und Praktiken des agilen Testens wieder, wie z.B. den Testquadranten, der Testpyramide oder im (Behavior/Acceptance) Test Driven Development.

Testen in einem skalierten Kontext

Herausforderungen der agilen Skalierung

Bevor man sich Gedanken zum Testen in einem skalierten Kontext macht, sollte man sich zunächst generelle Herausforderungen einer agilen Skalierung anschauen. Neben den oben erwähnten Herausforderungen einer geeigneten Implementierung der agilen Ideen in einem einzelnen Team, ergeben sich nun gewisse Wachstumsschmerzen, insbesondere zwei Aspekte sind hier von Interesse:

  • Die Softwareentwicklung einer Organisation ist mehr als die Summe einzelner Teams: An einem Produkt arbeiten häufig mehrere Teams, nicht nur eines. Das Produkt ist mehr als die Summe der Inkremente der einzelnen Teams und der Entwicklungsprozess ist mehr als die Summe der Vorgehensweisen einzelner Teams. Es bedarf geeigneter Formen der Skalierung und Zusammenarbeit der unterschiedlichen Rollen, Events, und Artefakte auf teamübergreifenden Ebenen. Dieses Thema wird im Scrum Guide überhaupt nicht betrachtet, aber es gab auch hierzu schon früh geeignete Ergänzungen wie z.B. Scrum of Scrums [7].
  • Eine Organisation ist mehr als die Softwareentwicklung: Auch wenn Scrum eigentlich nicht spezifisch auf die Softwareentwicklung zugeschnitten ist, so haben sich die agilen Ideen und Vorgehensweisen doch primär in den entsprechenden IT-Abteilungen und -Bereichen der Organisationen entwickelt und ausgebreitet. Mit der Zeit hat sich dann gezeigt, dass agile Vorgehensweisen nur dann sinnvoll umgesetzt werden können, wenn sie ganzheitlich und organisationsweit umgesetzt werden. Reibung gibt es insbesondere an den Stellen, an denen der agile Teil einer Organisation an den nicht-agilen Teil der Organisation stößt – und diese Stelle liegt häufig an den Schnittstellen der Softwareentwicklung zur restlichen Organisation.

Herausforderungen des skalierten agilen Testens

Typische Herausforderungen für das Testen in einem skalierten agilen Kontext liegen insbesondere in der Fragestellung, wie adäquat sowohl mit team- als auch sprint-übergreifenden Testaktivitäten umgegangen werden soll: Ein Gesamtprodukt ist mehr als die Inkremente der einzelnen Teams – ebenso umfasst der Test des Gesamtprodukts mehr als die Tests der einzelnen Storys in den Teams. Dies betrifft sowohl das Testen der Integration und der Ende-zu-Ende-Funktionalität als auch nicht-funktionale Anforderungen wie die Performanz oder das Lastverhalten.

Daraus entstehen u.a. folgende Herausforderungen:

  • Verantwortung für teamübergreifende Testaktivitäten: Diese Verantwortung muss geklärt werden, entweder indem diese Aufgaben zwischen den Teams verteilt werden oder durch die Etablierung zusätzlicher Testteams. In dem Zusammenhang müssen dann ggf. auch teamübergreifende DoD und Story-/Kanban-Boards etabliert werden.
  • Einbindung teamübergreifender Stakeholder: Ende-zu-Ende-Funktionalitäten und nicht-funktionale Anforderungen werden u.U. team- und sprint-übergreifend durch Epics formuliert. Die jeweiligen Epic-Owner müssen zur Formulierung der Acceptance Criteria und beim Einsatz von Behavior-Driven Development in die Testaktivitäten eingebunden werden.
  • Teamübergreifende Sprint-Reviews: Zur Abnahme der Ende-zu-Ende-Funktionalitäten und übergreifenden nicht-funktionalen Anforderungen müssen neben den teamspezifischen Sprint Reviews auch teamübergreifende Entsprechungen etabliert werden.
  • Teamübergreifende technische Infrastruktur: Nicht zuletzt erfordert dies alles auch eine gemeinsame, teamübergreifende technische Infrastruktur zur kontinuierlichen Integration der verschiedenen Inkremente und Deployment des Gesamtprodukts.

Alle diese Punkte können nur sinnvoll geklärt werden, wenn teamübergreifend die Skalierung und Zusammenarbeit der unterschiedlichen Rollen, Events, und Artefakte etabliert ist – nicht nur aus Sicht des Testens, sondern in allen beteiligten Disziplinen bzw. Organisationseinheiten.

Das Scaled Agile Framework (SAFe)

Es gibt verschiedene Frameworks zur agilen Skalierung in einer Organisation, welche das Thema jeweils unterschiedlich adressieren, u.a. Nexus [8], LeSS [9], DA [10] und SAFe [11]. Jedes dieser Frameworks hat andere Schwerpunkte, eine unterschiedliche Ausprägung, Vor- und Nachteile und ist für einem bestimmten Kontext geeignet. An dieser Stelle soll nun weder die Bedeutung solcher Frameworks noch die jeweiligen Unterschiede diskutiert werden, vielmehr soll am Beispiel von SAFe diskutiert werden, wie eine solches Framework aussehen kann und welche Bedeutung es für das agile Testen haben kann.

Das Scaled Agile Framework (SAFe) kombiniert Agile mit Ideen aus dem Lean Product Development, DevOps und Systems Thinking und richtet sich dabei an die gesamte Organisation, das Ziel ist ein Lean Enterprise (SAFe-spezifische Konzepte und Elemente sind im folgenden kursiv gesetzt). Als Einstieg in das Framework bietet sich das Big Picture an, in dem alle Elemente des Frameworks (“Full SAFe”) dargestellt sind – und das sind nicht wenige:

Full SAFe im Big Picture [11]

SAFe stellt damit ein sehr umfangreiches Framework dar und versteht sich selbst als “knowledge base of proven, integrated principles, practices, and competencies” [12]. Ein Großteil der Elemente von SAFe basieren somit auf bereits existierenden, umfangreichen Arbeiten (z.B. von W. Edwards Deming, Donald G. Reinertsen, Dean Leffingwell) sowie bereits etablierten Prinzipien und Praktiken (z.B. Kanban, Value Stream Mapping).

Dean Leffingwell

© Scaled Agile, Inc.
Include this copyright notice with the copied content.

Read the FAQs on how to use SAFe content and trademarks here:
https://www.scaledagile.com/about/about-us/permissions-faq/
Explore Training at:

Training Calendar

Hier zunächst ein paar wesentliche Elemente von SAFe, welche im folgenden Abschnitt in den Kontext des Testens gesetzt werden sollen:

  • Die vier Core Values repräsentieren die grundlegenden Schlüsselmerkmale von SAFe: Alignment, Built-In Quality, Transparency und Program Execution.
  • Die sieben Core Competencies beschreiben erfolgskritische Kompetenzen zur Implementierung von SAFe: Lean-Agile Leadership, Continuous Learning Culture, Team and Technical Agility, Agile Product Delivery, Enterprise Solution Delivery, Lean Portfolio Management und Organizational Agility.
  • SAFe definiert drei hierarchische Ebenen: Essential, Large Solution und Portfolio, wobei weder alle Ebenen noch alle Elemente bei einer SAFe-Implementierung zwingend umgesetzt werden müssen.
  • Den eigentlichen und wirklich SAFe-spezifischen Kern bildet dabei der Agile Release Train (ART), welcher das Alignment, die Kollaboration und die Auslieferung mehrerer Agile Teams synchronisiert.

Eine reduzierte und für den Einstieg geeignetere Sicht auf das Framework ist das “Essential SAFe”, welches bereits alle wesentlichen Elemente aus Sicht des Testens beinhaltet:

Essential SAFe im Big Picture [11]

SAFe und Testen

Zunächst einmal kann man festhalten, dass Testen in SAFe eine wesentliche Rolle spielt. Das Thema findet mit seinen entsprechenden Prinzipien, Praktiken, Rollen und Aufgaben in allen Elementen mehr oder weniger viel Beachtung und wird in den sog. Advanced Topics [19] ausführlich behandelt. Hierzu muss man wissen, dass es nicht den einen großen “SAFe-Guide” (analog zum Scrum Guide) gibt, sondern sich die Beschreibung des Frameworks aus hunderten einzelner Artikel mit Beschreibungen der Elemente zusammensetzt. Hierbei wird deutlich, dass SAFe stark auf etablierte Prinzipien und Praktiken des Agile Testing aufbaut und so z.B. die Idee der Agile Testing Matrix [13] aufgreift.

Built-In Quality

Das Thema Qualität – und dementsprechend auch das Thema Testen – bildet als Buil-In Quality eines der vier Schlüsselmerkmale (der Core Values) von SAFe und ist somit quasi in die DNA des Frameworks fest eingebaut. Durch die Anwendung der Philosophie des Systems Thinking soll dadurch das System als Ganzes optimiert werden und macht Qualität zur Aufgabe aller Beteiligten. Dieser ganzheitliche Ansatz spiegelt sich in mehreren Dimensionen wider und deckt alle Ebenen des Frameworks ab:

  • Flow: Erzielung eines kontinuierliches Flusses durch Etablierung einer Continuous Delivery Pipeline und Anwendung des Test-First-Ansatzes mit dem Ziel eines Release on Demand. Durch frühes und automatisiertes Testen soll die Delivery Pipeline bestmöglich unterstützt werden um kontinuierlich lieferfähig zu sein.
  • Architecture & Design Quality: Built-In Quality beginnt bereits bei der Architektur und dem Entwurf des Systems, beides hat einen wesentlichen Einfluss auf die Testbarkeit des Systems. Eine geeignete Modulariserung des Systems erleichtert bspw. das Mocking von Komponenten.
  • Code Quality: Inspiriert durch Praktiken des Extreme Programming (XP) wird hier insbesondere Test-Driven Development (TDD) zur Unterstützung auf Teamebene gefordert. Der Test-First-Ansatz findet sich entsprechend auch noch in vielen weiteren Elementen von SAFe wieder.
  • System Quality: Die einzelnen Inkremente der Teams müssen auch auf der Systemebene wie erwartet funktionieren. Dies wird unterstützt durch Behavior-Driven Development (BDD) sowie Qualitätssicherung der Ende-zu-Ende-Funktionalität, bspw. durch einen hohen Automatisierungsgrad nicht-funktionaler Tests als Teil der Continuous Integration und Continuous Delivery.
  • Release Quality: Alle zuvor genannten Dimensionen unterstützen die Fähigkeit der Organisation, so schnell wie möglich (und nötig) zu lernen und zu releasen. Ein wichtiger Aspekt ist hier, eine geeignete Skalierung der Definition of Done auf dem Weg Team → System → Solution → Release.

Beispiel für skalierbare Definition of Dones [14]

Team and Technical Agility

Team and Technical Agility ist eine der sieben Core Competencies von SAFe. Team Agility adressiert die kritischen Fähigkeiten zum Aufbau von Lean-Agile Performing Teams, Testen hat hierbei einen festen und hohen Stellenwert im define/build/test/deploy-Zyklus.

Interessant ist dann aber der Teil Technical Agility, in dem wesentliche Lean-Agile-Prinzipien und die Umsetzung des Core Values Built-In Quality beschrieben werden, durch die das Team schnell und zuverlässig Lösungen liefern kann. Dies sind u.a.:

  • “Establish Flow”: Agile Teams bewegen sich in einem schnellen, flussbasierten System, um schnell entwickeln und mit hoher Qualität releasen zu können. Tests sollen früh, oft und auf allen Ebenen ausgeführt werden, und zwar für Code-Änderungen (mittels Test-Driven Development), für die Akzeptanzkriterien der Storys (mittels Behavior-Driven Development) sowie die Benefit Hypothesis (mittels Lean-UX-Prozess, dieses Thema soll an dieser Stelle aber nicht vertieft werden).
  • “Think Test First”: Zur Sicherstellung eines steten Flusses an Wert sind Tests auf allen Ebenen erforderlich, und zwar idealerweise nach dem Test-First-Ansatz (erst testen, dann umsetzen) und für alle Artefakte – Features, Story und Code. Testen ist somit inhärenter Bestandteil der Entwicklung und verschiebt sich noch mehr vom Ende zum Anfang der Entwicklung (auch bekannt als Shift-Left-Testing). Die Tests müssen dafür schnell und automatisiert sein, was auf den unteren Ebenen typischerweise eher erreicht werden kann, als auf den oberen Ebenen – hierbei bezieht sich SAFe dann auch richtigerweise auf die Testing Pyramide.

BDD und TDD unterstützen das Shift-Left-Testing [15]

  • Create Stories with Behavior-Driven Development

    © Scaled Agile, Inc.
    Include this copyright notice with the copied content.

    Read the FAQs on how to use SAFe content and trademarks here:
    https://www.scaledagile.com/about/about-us/permissions-faq/
    Explore Training at:

    Training Calendar

    “Create Stories with Behavior-Driven Development”: Konsequenterweise sollen auch die Acceptance Tests automatisiert werden, das Mittel der Wahl ist hier – wie schon mehrfach erwähnt – Behavior-Driven Development.

  • “Design for Quality”: Built-In Quality erfordert, dass bereits während der Architektur und Entwurf, das System auf Qualität ausgelegt und testbar entworfen wird, unterstützt durch Coding Conventions, Pairing und Collective Ownership.
  • “Implementing with Quality”: Test-First für die Implementierung bedeutet natürlich die konsequente Anwendung von Test-Driven Development.
  • “Continuously Integrate and Deploy with Quality”: Schnelle und häufige Tests erfordern die entsprechende Infrastruktur, unterstützt durch Continuous Integration und Continuous Delivery (mehr dazu im nächsten Kapitel).

Agile Product Delivery

Agile Product Delivery ist eine weitere der sieben Core Competencies mit Bedeutung für das Testen. Sie umfasst die Definition, den Aufbau und die Bereitstellung eines kontinuierlichen Flusses von wertvollen Produkten und Dienstleistungen für den Anwender und die Stakeholder.

Zwei wesentliche Dimensionen stellen dabei dar:

  • Develop on Cadence; Release on Demand: Die Teams sollen in einem steten, koordinierten und synchronisierten Rhythmus (cadence) entwickeln und dabei potentiell auslieferbare Inkremente des Systems erstellen. Diese Inkremente sollen jederzeit bei Bedarf veröffentlicht werden können, wobei sich die Release-Zeitpunkte dann zwischen sehr niedrigen aber auch höheren Frequenzen bewegen können.
  • DevOps and the Continuous Delivery Pipeline: Neben der Etablierung einer DevOps-Kultur und den entsprechenden Prinzipien unterstützt eine geeignete Continuous Delivery Pipeline die Entwicklung gemäß Develop on Cadence; Release on Demand.

Continuous Delivery Pipeline [16]

Hervorzuheben ist dabei insbesondere die Continuous Integration, bestehend aus den Aktivitäten Develop, Build, Test End-to-End und Stage. In Anerkennung der Tatsache, dass (wie oben beschrieben) eine vollständige kontinuierliche Integration u.U. nicht sinnvoll ist, spricht SAFe hier auch von der Idee der “Continuish Integration” mit dem Ziel, die richtige Balance zwischen funktionalem Umfang, Testaufwand und Frequenz zu finden.

Der Agile Release Train

Der Agile Release Train (ART) ist ein Team von agilen Teams, welches gemeinsam mit anderen Stakeholdern Systeme inkrementell entwickelt, ausliefert und ggf. betreibt. Ein solcher ART umfasst mehrere Teams mit insgesamt 50 bis 125 Personen, mehrere ARTs werden dann auf der nächsten Ebene, der Solution, in einem Solution Train synchronisiert. Dadurch ist es theoretisch möglich eine Entwicklungsorganisation von mehreren tausend Personen abzubilden.

ART Programm und Team Events [16]

Ein ART ermöglicht die synchronisierte und getaktete Planung und Umsetzung von Sprints für das System und synchronisiert dabei die Iterationen der einzelnen Teams. Ein ART dauert typischerweise 8 bis 12 Wochen, das Ergebnis ist ein Product Increment (PI). Die Planung eines ART erfolgt in einem gemeinsame PI-Planning. Für einen ART werden neben den bekannten Rollen auf Team-Ebene (Scrum Master, Product Owner, Development Team) korrespondierende Rollen auf der Programmebene definiert, u.a. der Release Train Engineer (RTE), Product Management und der System Architect.

Daneben gibt es weitere Funktionen, aus Sicht des Testens die wichtigste ist dabei das System Team. Dieses unterstützt beim Aufbau und Weiterentwicklung der Continuous Delivery Pipeline sowie der Durchführung von funktionalen Ende-zu-Ende-Tests sowie teamübergreifender nicht-funktionaler Tests. Das System Team soll somit die teamübergreifenden Testaktivitäten koordinieren, technisch unterstützen sowie entsprechende Tests durchführen. Konkrete Aufgaben des Teams sind dabei:

  • Aufbau der Entwicklungsinfrastruktur: Aufbau und Wartung der Continuous Delivery Pipeline inkl. Bereitstellung automatisierter Tests im Rahmen der Continuous Integration sowie Bereitstellung der Plattform zur Unterstützung von System und Solution Demos.
  • Integration der Lösung: Teilnahme am PI-Planning sowie den zugehörigen vor- und nachbereitenden Aktivitäten inkl. Backlog Refinement zur Definition von Integrations- und Testaufgaben sowie Unterstützung der einzelnen Teams in spezifischen Testaufgaben.
  • Ende-zu-Ende-Testen: Konsolidierung der manuellen und automatisierten Tests der einzelnen Teams in übergreifende Test-Suiten sowie Entwicklung und Durchführung von funktionalen Ende-zu-Ende-Tests und übergreifenden nicht-funktionalen Tests (insbesondere Performance-Tests).
  • System und Solution Demos: Technische Unterstützung der System und Solution Demos (mehr Details weiter unten).
  • Kompetenz für Releases: Das Systen Team bündelt somit die Erfahrungen und Fähigkeiten, die notwendig sind, um die gesamte Lösung zu bauen und bereitzustellen.

Wichtig ist hierbei aber, dass das System Team kein unabhängiges Testteam darstellen soll und dadurch die Verantwortung der Teams für die übergreifenden, integrativen Tests entfällt. Vielmehr muss hier die richtige Balance zwischen den Verantwortlichkeiten der Teams und den Verantwortlichkeiten des System Team gefunden werden. Der optimale Punkt kann und soll sich dabei immer weiter vom System Team zu den einzelnen Teams verschieben:

Die optimale Balance der Integrationsaufwände zwischen Agile Teams und System Team [17]

Ein wichtiger Synchronisationspunkt während eines ART sind die System Demos, diese entsprechen im Prinzip den Iteration-Reviews der einzelnen Teams, aber auf Programm-Ebene.

Die System Demo stellt als signifikantes Event eine integrierte Sicht auf die neuen Features aller Teams der aktuellsten Iteration im ART bereit. Der Zweck besteht darin, das System in einer entsprechenden Systemumgebung zu testen und zu evaluieren und Feedback von den relevanten Stakeholdern einzuholen.

Idealerweise wird hierfür das vollständiges System integriert, jedoch kann es Komponenten geben (z.B. Hardware, Mechanik oder Komponenten von Lieferanten), welche sich nicht praktikabel oder ökonomisch sinnvoll innerhalb der Continuous Integration abbilden lassen. In jedem Fall sollte eine verzögerte Integration vermieden werden und eine Kostenoptimierung bei der Integration gefunden werden. Diese – ggf. nur teilweise Integration – liegt auf einer U-Kurve zwischen einer vollständigen und keiner Integration. Sofern eine vollständige Integration zu aufwändig ist, können bspw. Mocks eingesetzt oder auch die Frequenzen der Integration reduziert werden:

U-Kurven Kostenoptimierung bei der Integration [18]

Agile Testing in einem skalierten Kontext implementieren

Die hier genannten Aspekte sind aus Sicht des Testens sicherlich wesentlich, bilden aber auch nur einen kleinen Teil des kompletten Frameworks ab. In jedem Fall ist es hilfreich und sinnvoll, sich detailliert mit SAFe auseinanderzusetzen, um das Framework als Ganzes zu verstehen und in den richtigen Kontext setzen zu können.

Sofern sich das Testen in einem SAFe-basierten Kontext abspielt, sind die umfangreichen Prinzipien, Praktiken und Hinweise, die SAFe zum Thema Agile Testing liefert, eine hervorragende Grundlage. Testen ist dort ein wesentlicher Bestandteil und sollte auch entsprechend implementiert und gelebt werden. Aber auch in einem Kontext, in dem SAFe keine Rolle spielt, kann man viele Aspekte des Frameworks für die Implementierung nutzen.

Ein Großteil dessen, was SAFe zum Agile Testing sagt, ist in der Tat nichts Neues – Ideen und Konzepte wie die Testmatrix, Testpyramide, Test First, Shift Left, Continuous Testing, BDD, TDD, CI/CD sind bekannt und etabliert. SAFe erfindet hier auch nichts Neues, sondern sammelt Best Practices ein und fügt sie in einen sinnvollen Rahmen – was ja grundsätzlich der Idee von SAFe entspricht, da es eben eine “knowledge base of proven, integrated principles, practices, and competencies” [12] ist.

Die SAFe-spezifischen Aspekte und Ideen rund um’s Testen sollten dann aber zusätzlich bei einer Implementierung Berücksichtigung finden, insbesondere:

  • Die Synchronisation der einzelnen Teams mittels PI-Planning und System Demo
  • Die Idee des System Team
  • Die Idee der “Continuish Integration“
  • Und ganz grundsätzlich die konsequente Ausrichtung an den Ideen des Lean Product Development, DevOps und Systems Thinking.

Über den Autor

Florian Fieber ist Berater und Trainer mit den Schwerpunkten Teststrategien, Testprozessverbesserung und agiler Skalierung. Er ist zertifizierter “SAFe® Program Consultant (SPC)” und unterstützt seine Kunden bei der agilen Skalierung aus der Sicht des Testens.

Quellen

[1] Agile Manifesto, https://agilemanifesto.org

[2] Wikipedia – Scrum, https://en.wikipedia.org/wiki/Scrum_(software_development)

[3] Scrum Guide, https://www.scrumguides.org/scrum-guide.html

[4] Scrum Guide – Development Team, https://www.scrumguides.org/scrum-guide.html#team-dev

[5] Scrum Guide – Product Backlog, https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog

[6] Scrum Guide – Definition of “Done”, https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done

[7] Agile Alliance – Scrum of Scrums, https://www.agilealliance.org/glossary/scrum-of-scrums/

[8] Nexus Guide, https://www.scrum.org/resources/online-nexus-guide

[9] Large Scale Scrum (LeSS), https://less.works/

[10] Disciplined Agile (DA), https://www.disciplinedagiledelivery.com

[11] Scaled Agile Framework (SAFe), https://www.scaledagileframework.com

[12] SAFe – White Paper, https://www.scaledagile.com/resources/safe-whitepaper/

[13] SAFe – Agile Testing, https://www.scaledagileframework.com/agile-testing/

[14] SAFe – Built-In Quality, https://www.scaledagileframework.com/built-in-quality/

[15] SAFe – Team and Technical Agility, https://www.scaledagileframework.com/team-and-technical-agility

[16] SAFe – Agile Product Delivery, https://www.scaledagileframework.com/agile-product-delivery/

[17] SAFe – System Team, https://www.scaledagileframework.com/system-team/

[18] SAFe – System Demo, https://www.scaledagileframework.com/system-demo/

[19] SAFe – Advanced Topics, https://www.scaledagileframework.com/advanced-topics/