Die agile Entwicklung ist eine Softwareentwicklungsmethode, die sich als äußerst wirksames Mittel gegen die Engpässe in den Arbeitsabläufen durchgesetzt hat, die bei der traditionellen Wasserfallmethode auftreten können und Unternehmen einst viel Zeit und Geld kosteten. Die meisten modernen Softwareentwicklungsprojekte jeglicher Größenordnung werden in irgendeiner Form agil durchgeführt.
Agile Standard-Frameworks haben jedoch auch Probleme mit der Skalierbarkeit, da sie für Teams mit maximal 9 Mitgliedern konzipiert sind. Als Reaktion darauf wurde eine Reihe von Scaled Agile Frameworks entwickelt, die die Koordination mehrerer agiler Teams ermöglichen, die an verschiedenen Teilen eines größeren Softwaresystems arbeiten. Alle Vorteile von Agile, aber unter Berücksichtigung des Problems der Skalierbarkeit.
In diesem Blog befassen wir uns mit den Details der gängigsten Scaled-Agile-Frameworks, die zur Koordinierung mehrerer Teams verwendet werden, mit der Frage, welches Framework für welche Bedingungen am besten geeignet ist, und mit einem praktischen Leitfaden für eine effektive Implementierung.
Das Problem der Skalierbarkeit von Standard-Agile-Frameworks
Das Problem mit den üblichen agilen Frameworks wie Scrum, Lean und der Kanban-Methode ist, dass sie nur Teams von 5-9 Personen zulassen. Diese Obergrenze kann natürlich ignoriert werden, doch würde dies den Zweck eines dafür konzipierten agilen Rahmens weitgehend zunichte machen. Und es hätte unweigerlich Auswirkungen auf die Effizienz und Qualität der Arbeit.
Ein Team von 5-9 Softwareentwicklern kann jedoch viel zu klein sein, um das Arbeitsvolumen eines großen, komplexen Entwicklungsprojekts zu bewältigen, das in absehbarer Zeit veröffentlicht werden soll. Daher haben viele Unternehmen mehr, manchmal sogar viel mehr als nur ein agiles Softwareentwicklungsteam, das an verschiedenen Teilen großer Projekte arbeitet.
Wenn es jedoch nicht gelingt, die Arbeitsabläufe mehrerer Teams, die für verschiedene Teile eines Softwaresystems verantwortlich sind, effektiv zu synchronisieren, führt dies zu genau der gleichen Art von kostspieligen Engpässen, wie sie in der Vor-Agile-Ära nur allzu häufig zu beobachten waren. Um die Methodik effektiv zu skalieren, wurde eine neue Art von Agile-Ansatz benötigt – Scaled Agile Frameworks.
Die bekanntesten und beliebtesten Scaled Agile Frameworks sind:
- SAFe (Scaled Agile Framework)
- DAD (Disciplined Agile Delivery)
- SoS (Scrum-of-Scrums)
- LeSS (Large-Scale Scrum)
Jeder dieser Ansätze wurde entwickelt, um die mit Agile verbundene Steigerung der Geschwindigkeit und Qualität der Softwareentwicklung zu erleichtern, wenn mehr als ein agiles Team an demselben Projekt arbeitet. Die Bedingungen, unter denen jede dieser Methoden am effektivsten ist, sind jedoch unterschiedlich, und es gibt auch ein Element persönlicher Präferenz.
Wir werden jedes dieser verschiedenen Scaled Agile Frameworks untersuchen und ihre Stärken und Schwächen sowie die Art des agilen Softwareentwicklungsprojekts, für das sie am besten geeignet sind, näher erläutern. Doch zunächst werfen wir einen kurzen Blick darauf, wie sie sich entwickelt haben.
Die Entwicklung der Scaled Agile Frameworks
Es hat sich gezeigt, dass sich Innovation, Entwicklung und Evolution in einem stressigen und unter Druck stehenden Umfeld, in dem man „etwas tun muss“, deutlich beschleunigen. Krieg hat unsägliches Elend über die Menschheit gebracht. Es ist aber auch kein Zufall, dass er – und gerade die Kriegsgefahr – auch der Auslöser für einen großen Teil der bedeutendsten technologischen Innovationen in der Geschichte der menschlichen Zivilisation war.
Agile Softwareentwicklungsteams und ihr Management sind zwar glücklicherweise nur selten gezwungen, in einem militärischen Kontext zu arbeiten, aber sie arbeiten häufig unter erheblichem Druck. Und Drucksituationen, in denen die effektivste Lösung zur Vermeidung von Produktivitätsengpässen gefunden werden muss, haben in der Vergangenheit zur Entwicklung neuer scaled Agile frameworks geführt, die dem jeweiligen Kontext besser gerecht werden.
Seit der Veröffentlichung des Agile Manifesto im Jahr 2001 wurden zahllose Softwareentwicklungsteams in einem agilen Ansatz geschult und arbeiten danach. Agile Frameworks konzentrierten sich jedoch auf kleinere Softwareentwicklungsprojekte mit einem einzigen Team.
Die Veröffentlichung von „The Enterprise and Scrum“ von Ken Schwaber im Jahr 2007 war eine Reaktion auf die zunehmende Akzeptanz von Agile durch größere Unternehmen und die Anwendung der Methodik im Rahmen größerer, komplexerer Softwareentwicklungsprojekte. Es folgten spezifischere Scaled-Agile-Frameworks, die auf die besonderen Bedürfnisse verschiedener Entwicklungsszenarien mit mehreren Teams ausgerichtet waren, wie die 2008 veröffentlichte LeSS-Methodik (Large-Scale Scrum) von Larman und Bodde, gefolgt von Dean Leffingwells SAFe (Scaled Agile Framework) im Jahr 2011.
Diese Scaled Agile Frameworks konzentrieren sich auf die Synchronisierung mehrerer Teams, die an demselben Projekt arbeiten, sowie auf die Integration von Support-Teams, die die Kanban-Methode verwenden.
*Kanban ist eine visuelle Workflow-Management-Methode, die von Toyota in den 1940er Jahren entwickelt wurde. Die hochgradig visuellen Qualitäten eines Kanban-Ansatzes erleichtern eine bessere Kommunikation darüber, welche Arbeit wann erledigt werden muss. Außerdem werden Hinweise standardisiert und Prozesse verfeinert, wodurch Verschwendung reduziert und der Wert maximiert wird.
Scrum-Frameworks werden in der Regel in komplexen Umgebungen eingesetzt, in denen Ursache und Wirkung nicht immer sofort offensichtlich sind und die Ergebnisse nicht vorhersehbar sind. Der Kanban-Ansatz wird für komplizierte Systeme verwendet, die auf Regeln und deterministischen Prozessen basieren. Beide können als Scaled Agile Frameworks verwendet oder kombiniert werden.
Die beliebtesten Scaled Agile Frameworks
Jedes der beliebten Scaled Agile Frameworks, die wir uns hier ansehen, hat seine besonderen Stärken und unvermeidlichen Schwächen. Doch welches eignet sich am besten für die verschiedenen Arten von Projekten, an denen Ihre Entwicklungsteams möglicherweise arbeiten? Im Folgenden werden die vier wichtigsten Scaled-Agile-Frameworks vorgestellt und ihre wichtigsten Eigenschaften, Stärken und Schwächen aufgezeigt. Spezifische Umstände eines Entwicklungsprojekts können auch bedeuten, dass die beste Methodik eine Mischung aus den für das eine oder andere Framework typischen Ansätzen und Techniken sein kann; scheuen Sie sich also nicht, gegebenenfalls mit einem Hybridmodell zu arbeiten.
Das Scaled Agile Framework (SAFe)
SAFe verspricht großen Unternehmen mit großen Entwicklungsprojekten ein Scaled Agile Framework „out of the box“. Es ist eine der beliebtesten Skalierungslösungen für Projekte, an denen mehr als ein agiles Entwicklungsteam beteiligt ist – und in der Regel mindestens mehrere. Das SAFe-Framework gilt jedoch weithin als ressourcen- und kostenintensiv, da es ein hohes Maß an technischem Fachwissen für seine effektive Umsetzung erfordert.
Wie SAFe funktioniert
SAFe Stärken
- – Ein integrierter Satz von Entwicklungspraktiken
- – Standardisierung der Synchronisierung von Planungs- und Ausführungsprozessen zwischen einer großen Anzahl von agilen Entwicklungsteams
- – Definition und Standardisierung von Rollen in großen Unternehmen mit mehreren Hierarchieebenen
- – Schnelle Einführung ohne Änderung der Unternehmensstruktur
- – Möglichkeit der Wahl eines agilen Frameworks (Scrum, Kanban, XP, etc.) auf der Ebene des agilen Entwicklungsteams
SAFe Risiken und Schwächen
- – Mehrere Hierarchieebenen
- – Vorwurf, nicht „agil genug“ zu sein
- – Starr/Unflexibel
SAFe Anwendungsbeispiel
Intel führte SAFe zwischen 2012 und 14 in seine Softwareentwicklungsprozesse ein, um zwischen 2012 und 2013 von fünf Scrum-Teams, die an einem einzigen Projekt arbeiteten, auf 33 Teams zu kommen. Und dann auf 170 Scrum-Teams bis 2014. Die Entwicklung wurde in 2-wöchigen Sprints abgeschlossen und 8 Release Trains (ART) wurden innerhalb von nur 2 Monaten bereitgestellt.
Hewlett Packard, Swisscom, Cisco, Tomtom, Sony, Fitbit, KLM, Philips sind nur einige der anderen großen Namen, die SAFe eingeführt haben.
Wann & wo SAFe anwenden
SAFe wird für große Unternehmen empfohlen, in denen mehrere große Entwicklungsprojekte gleichzeitig laufen.
Large-Scale Scrum (LeSS)
LeSS ist eine Weiterentwicklung des Scrum-Rahmens und des agilen Ansatzes. Der Schwerpunkt liegt auf der Abflachung der Hierarchie und der Beseitigung von Kommunikationsdefiziten. Ein PO (Product Owner) (oder Area PO im Falle von LeSS Huge) steht immer in direktem Kontakt mit den verschiedenen agilen Entwicklungsteams und leitet sie aus einer geschäftsstrategischen Perspektive. Der LeSS-Ansatz fördert die Bildung von Teams, die sich auf Funktionen konzentrieren, im Gegensatz zu funktionalen Silos, die es jedem Team ermöglichen, unabhängig voneinander Geschäftswert zu liefern.
Die echte Einführung von LeSS kann jedoch eine Herausforderung sein und erfordert in der Regel Investitionen in organisatorische Veränderungen und die Ausbildung von Einzelpersonen sowie eine Änderung der agilen Denkweise auf persönlicher Ebene.
LeSS Stärken
- – Minimaler Satz von Regeln
- – Starkes Skalierungspotenzial der Produkteigentümerschaft
- – Ermöglicht ein innovatives, aufgeschlossenes und motiviertes Umfeld
- – Fördert eine starke prinzipielle Ausrichtung
- – Bietet unterschiedliche Modelle für mittlere und große Organisationen: LeSS und LeSS Huge
LeSS Risiken und Schwächen
- – Radikal agiler“ Ansatz
- – Häufig Widerstand von Seiten des mittleren Managements, das um Einfluss ringt
- – Schwierige Integration in große traditionelle Organisationen mit mehreren Hierarchieebenen
LeSS Anwendungsbeispiel
Interessanterweise ist eines der größten und besten Beispiele für die Einführung von LeSS das von Nokia Networks. Es wurde 2005 von Craig Larman und Bas Vodde, die das LeSS-Framework ursprünglich entwickelt hatten, im Rahmen eines Scrum-Pilotprojekts eingeführt. Nokia führte LeSS dann 2007 auf organisatorischer Ebene ein, wobei Dutzende von agilen Softwareentwicklungsteams mit insgesamt ca. 500 Mitarbeitern an zwei F&E-Standorten einbezogen wurden. 500 Personen an zwei F&E-Standorten. Bei Nokia wurde ein LeSS Huge scaled Agile Framework „by the book“ mit Requirement Areas, Area Product Owners, Feature Teams, etc. eingesetzt.
Zu den anderen namhaften Unternehmen, die LeSS und LeSS huge scaled agile frameworks eingeführt haben, gehören Huawei, Ericsson, JP Morgan Chase, Bank of America, UBS und Telecom Australia.
Wann & wo LeSS anwenden
LeSS empfiehlt sich für mittelständische Unternehmen, die an ihrem eigenen Produkt oder einem Start-up arbeiten, oder für die Forschungs- und Entwicklungsabteilungen größerer Unternehmen. Da der Schwerpunkt auf Feature-Teams und nicht auf funktionalen Teams liegt, bedeutet der LeSS-Ansatz, dass agile Softwareentwicklungsteams schneller arbeiten können.
Scrum-of-Scrums (SoS)
SoS oder Scrum-of-Scrums war das erste weithin anerkannte Scaled Agile Framework und geht auf das Jahr 2001 und die Geburt von Agile als Softwareentwicklungsmethodik zurück. Nach den täglichen Scrum-Meetings treffen sich die Botschafter oder Scrum Master der Teams zu einem weiteren Treffen, das als Scrum-of-Scrums oder Meta-Scrum bezeichnet wird.
SoS konzentriert sich auf teamübergreifende Abhängigkeiten für etablierte Scrum-Teams. Die Methodik wird von einigen nicht als Scaled-Agile-Framework-Ansatz im eigentlichen Sinne betrachtet, wird aber von einer Vielzahl großer Organisationen erfolgreich zur Skalierung agiler Teams eingesetzt. Also…
SoS Stärken
- – Einfachheit
- – Erfordert keine zusätzlichen Rollen
- – Geringe Kosten für die Implementierung
SoS Risiken und Schwächen
- – Beschränkungen bei der Skalierung und Dokumentation
- – Unvollkommene Lösung für teamübergreifende Abhängigkeiten in größerem Maßstab
- – Möglichkeit des Rollbacks zu Statusbesprechungen
Scrum of Scrums (SoS) Anwendungsbeispiel
Das erste vollständig dokumentierte Beispiel für die Skalierung des Scrum-Ansatzes für Agile war 1996 bei IDX Systems, fünf Jahre bevor das Agile Manifest überhaupt veröffentlicht wurde. Der Ansatz von IDX bestand darin, die gesamte Organisation in eine Art von ineinandergreifenden Scrums zu verwandeln, und zwar auf eine Art und Weise, die dem, was als Scrum-of-Scrums-Framework bekannt wurde, ziemlich ähnlich war. Jeder Teil der Organisation war teambasiert, einschließlich des Managementteams, zu dem Vizepräsidenten, Direktoren und Architekten gehörten.
Wann & Wo SoS anwenden
SoS wird nur für Projekte empfohlen, an denen eine begrenzte Anzahl agiler Entwicklungsteams beteiligt ist, in der Regel bis zu 3 oder 4.
Welches Scaled Agile Framework ist am beliebtesten?
Derzeit ist das SAFe Scaled Agile Framework die am häufigsten verwendete der vier beliebtesten Methoden. Aus den Daten des 15. State of Agile-Jahresberichts geht hervor, dass auf das Framework 37 % aller Scaled Agile-Methoden entfallen, die von Organisationen im Jahr 2020 eingesetzt werden, gefolgt von SoS mit 9 %, Enterprise Scrum mit 6 % und dem Spotify-Modell mit 5 %.
Wie wählt man das richtige Scaled Agile Framework?
Da die agile Entwicklung iterativ und inkrementell ist, ist sie streng kontextabhängig, und der effektivste Rahmen, der eingesetzt werden kann, hängt von der jeweiligen Situation ab. Bei der Wahl eines Rahmens für die Skalierung mehrerer agiler Teams ist es oft ratsam, einen flexiblen Ansatz zu verfolgen und ein Grundgerüst von Grundlagen und Prinzipien zu wählen, das dann an die Besonderheiten des jeweiligen Falles angepasst werden kann.
Eines der besten Beispiele dafür, wie ein Unternehmen eine skalierte agile Methodik auf seine spezifischen Bedürfnisse zugeschnitten hat, ist Spotify, das in Stockholm ansässige Start-up-Unternehmen für Musikstreaming, das die herkömmliche Musikindustrie „aufgemischt“ hat und Mitte Dezember 2021 einen Wert von 44 Milliarden Dollar hat.
Anpassung Ihres eigenen Scaled Agile Framework – die Fallstudie zum Spotify-Modell
Spotify hat eine Reihe von Elementen des Scrum-Frameworks identifiziert, die für das Unternehmen nicht gut funktionierten. Also beschlossen sie, sich von einigen Scrum-Rollen, Artefakten und Ereignissen zu trennen. Das Ergebnis war ein eigenes, maßgeschneidertes, Scaled Agile Framework, das heute als „Spotify-Modell“ bezeichnet wird. Und laut dem 15. State of Agile-Bericht ist Spotifys Neugestaltung des skalierten Scrum-Modells heute das drittmeist genutzte skalierte Agile-Framework weltweit.
Das Spotify-Modell ist zwar ein großartiges Beispiel dafür, wie man ein Scaled Agile Framework auf die Bedürfnisse eines bestimmten Kontexts zuschneiden kann, aber es zu kopieren und einzufügen, könnte für viele andere Organisationen ein Fehler sein. Und warum? Es gibt eine Reihe von Komplikationen, die die Integration dieser Methodik ohne eine umfassende Organisationsreform erschweren. Eine Herausforderung ist die Notwendigkeit, eine „Truppe“ zu bilden – eine unabhängige Gruppe von Personen, die selbständig, aber am selben Ort zusammenarbeiten.
Das Spotify-Modell könnte auch für Ihre Organisation die perfekte Lösung sein. Es gibt keine pauschale Antwort. Ganz gleich, ob Sie sich für eine Scaled Agile-Methode „von der Stange“ oder für eine maßgeschneiderte Lösung entscheiden – wichtig ist, dass Sie sich zunächst genau überlegen, warum dies der richtige Ansatz für Ihre Organisation als Ganzes oder für ein bestimmtes Projekt ist. Und dann zu beobachten und anzupassen, wenn die Erfahrung lehrt, was gut funktioniert und was nicht. Schließlich handelt es sich um einen agilen Rahmen, und die Anpassungsfähigkeit sollte in die Denkweise bei seiner Einführung integriert werden.
Scaled Agile Frameworks – die wichtigsten Erkenntnisse
Zusammenfassend lässt sich sagen, dass sich die „agile“ Entwicklung von Natur aus nicht gut skalieren lässt, weshalb große Organisationen dazu neigen, Scrum auf eine Unternehmensebene zu skalieren. Und das ist die Grundlage für alle Scaled Agile Frameworks. Die Skalierung von Agile kann für große Unternehmen und andere Organisationen, die mehrere Entwicklungsteams koordinieren müssen, zahlreiche Vorteile bringen. Wie bei den meisten Organisations- und Projektmanagement- oder Moderations-Frameworks wird Scaled Agile jedoch nicht unbedingt immer oder sogar oft besonders gut implementiert und ausgeführt.
Aber wenn man es gut macht und den Schwerpunkt auf Zusammenarbeit, Transparenz und Vertrauen zwischen den agilen Entwicklungsteams und dem Management legt, kann das von Ihnen gewählte skalierte agile Framework das Engagement der Mitarbeiter erheblich steigern, die Produktivität verbessern, die Markteinführung beschleunigen und allgemein zu qualitativ besseren Softwareprodukten führen.
Um den größtmöglichen Nutzen zu erzielen, sollten Sie jedoch sicherstellen, dass Sie das am besten geeignete skalierte Agile-Framework für Ihren speziellen Kontext ausgewählt haben:
- – SAFe ist ganzheitlich, hat aber mehrere Hierarchieebenen und kann daher starr sein;
- – LeSS verkörpert ein minimalistisches Regelwerk und ermöglicht es, ein innovatives, offenes und motivierendes Umfeld zu schaffen, aber große Organisationen mit mehreren Hierarchieebenen werden sich schwer tun, es vollständig zu übernehmen.
- – SoS ist einfach und kostengünstig zu implementieren, aber in Bezug auf Skalierbarkeit und Dokumentation begrenzt.
- – Informieren Sie sich auch über das Spotify-Modell und die Anpassungen von Enterprise Scrum.
Alles in allem: Welches dieser Scaled Agile Frameworks würden Sie wählen? Oder welche Mischung aus Komponenten von mehr als einem? Nicht sicher? K&C verfügt über einen reichen Erfahrungsschatz aus Hunderten von agilen Entwicklungsprojekten, die wir durchgeführt haben und die das gesamte Spektrum von Umfang und Komplexität abdecken. Wenn Sie glauben, dass Sie diese Erfahrung nutzen können, kontaktieren Sie uns einfach. Wir würden uns freuen, Details über Ihre bevorstehenden Projekte oder allgemeinere organisatorische Agile-Herausforderungen zu erfahren. Wir können Ihnen sicher helfen!
