Das Scaled Agile Framework (SAFe) wurde für die Herausforderungen von mittelgroßen bis zu den größten Organisationen der Welt geschaffen. Solche Programme beinhalten mehrere agile Teams mit 50 bis 100 Menschen, die teilweise sogar hunderte bis tausende Beteiligte haben.

Reichen Scrum und Kanban aus?

Was aber ist mit kleineren Organisationen, mit einer handvoll Entwicklerteams? Wird SAFe dort benötigt? Reichen Scrum und Kanban gerade so aus? Wie immer laut die Antwort: Es kommt darauf an. In diesem Artikel möchten wir beleuchten, wie sich Praktiken von SAFe auch in kleineren Teams einsetzen lassen, so dass Ihre Teams mit Ihrer Organisation wachsen können.

Falls ein reines Softwareteam in kürzeren Releasezyklen arbeitet, liegt es auf der Hand Kanban oder Scrum zu wählen. Während die gesamte Bandbreite an SAFe-Praktiken sicher nicht sinnvoll ist, können auch kleine Entwicklerteams von den Vorteilen des Scaled Agile Frameworks profitieren. Jedoch nur wenn  mindestens eine oder mehr der folgenden Voraussetzungen erfüllt sind:

Es handelt sich um ein strategisches Softwareprodukt mit langer Lebensdauer

Umso länger die Lebensdauer eines Softwareproduktes ist, umso wichtiger ist es, die Entwicklung der Software eng mit der Strategie des Unternehmens zu verzahnen. Scrum bietet nur wenig Unterstützung für die Verknüpfung von Geschäfts- und Entwicklungszielen über einzelne Sprints hinaus.

Abhängigkeiten zu mehreren Nicht-Softwareteams

Es ist gängige Praxis, dass Unternehmen ein relativ kleines Software-Team besitzen, welches Lösungen für die anderen Teams zwecks Integration entwickelt. Beispielsweise finden sich Softwareteams in der Situation wieder, dass sie Teil eines Dienstleistungs- oder Hardwareunternehmens mit einem stattlichen Produktportfolio sind, aber lediglich einer geringen Anzahl an Software-Assets. Software-Unternehmen, deren Produkt stark auf die Bedürfnisse der einzelnen Kunden angepasst wird, stehen vor einem ähnlichen Problem: Alle beteiligten Teams müssen sich untereinander austauschen und auf Prioritäten und Zielsetzungen festlegen.

Bedarf für langfristige Investitionen wie DevOps besteht

Fokussiert man sich darauf, Sprint für Sprint das nächste Set an umgesetzten Userstories auszuliefern, ist das Ergebnis ein tolles Produkt. Aber was ist mit dem Skills des Teams? Die Investition in DevOps ist sicher eine lohnende Investition für höhere Qualität und eine schnellere Marktreife. Aber zu einem richtigen DevOps-Team wird man nicht über Nacht. Es werden sorgfältige Planung und Umsetzung gebraucht, wie bei jedem Projekt. Die in der Entwicklung eingesetzten Technologien zu ändern oder die Software-Architektur zu modernisieren sind ähnliche langfristige Investitionen, die richtig große Projekte sind.

Voraussichtliche Skalierung von klein auf mittelgroß

Falls ein Startup (ein neues Unternehmen oder interne Organisationseinheit) großes Potenzial für Wachstum hat, ist es durchaus sinnvoll auf schnelle Skalierung vorbereitet zu sein und agile Methoden dort einzusetzen, wo sie gebraucht werden. Falls aber die wichtigsten agilen Fertigkeiten nicht von Grund auf aufgebaut werden, wird skalieren schwierig, schmerzhaft und herausfordernd.

Die sechs SAFe-Praktiken für kleine Teams

Es besteht natürlich die Möglichkeit, die folgenden vier Themen mit Scrum oder Kanban zu lösen, aber die Erfahrung hat gezeigt, dass die Anwendung der folgenden sechs SAFe-Praktiken dazu führen, viel effektiver mit diesen Problemen umzugehen.

  1. Strategische Themes

Kleine und große Unternehmen benötigen eine Strategie um erfolgreich zu sein. Es ist ein kritischer Erfolgsfaktor zu verstehen, wie die Produkte eines Unternehmens Mehrwert generieren. Wie diese Produkte beim Kunden Prozesse beeinflussen und welche konkreten Vorteile sie erbringen. Produktqualität und User-Experience sind beide wichtig für langanhaltenden Erfolg. Ein Softwareteam benötigt zusätzlich zur Produktstrategie einen Plan, wie die eigenen Entwicklungsfähigkeiten geschärft werden können, um sich kontinuierlich zu verbessern, produktiver zu werden und konkurrenzfähig zu bleiben.

Das Scaled Agile Framework bietet zwar nicht direkt die Werkzeuge um diese Pläne und Strategien zu entwerfen, aber beinhaltet sogenannte Strategic Themes. Das sind Geschäftsziele, die das Portfolio eines Teams mit der Unternehmensstrategie verknüpfen.

Strategische Themes wurden bereits erfolgreich während der Sprint- (bzw. Iterations-) Planung eingesetzt, um sicherzustellen, dass Teams an den strategisch richtigen Aufgaben arbeiten. Manche Werkzeuge wie zum Beispiel Visual Studio Team Services (VSTS) ermöglichen es, die Aufgaben eines Teams mit einem Theme zu taggen, was dabei hilft, den Backlog mit der Strategie abzugleichen. Falls eine Strategie existiert, ist der zusätzliche Aufwand, um Strategic Themes zu bestimmen  vernachlässigbar gering.

  1. Programm-Epics

Typischerweise behandeln Scrum-Teams Epics als sehr große User Stories, die sich nicht innerhalb von einem Sprint abhandeln lassen. SAFe definiert Epics als “Vorhaben, die so schwerwiegend sind, dass sie eine Analyse über einen leichtgewichtigen Business-Case und eine Freigabe für Budget benötigen, um umgesetzt werden zu können”. Die Anforderung, einen Business-Case vorzubereiten ist nicht das Besondere an dieser Stelle, sondern viel mehr die Herausforderung sicherzustellen, dass ein Epic zum einen realisierbar bleibt und zum anderen signifikanten Mehrwert generiert.

SAFe besitzt eine umfangreiche Hierarchie an Epics, um richtig skalieren zu können: Portfolio-Epics, Value Stream-Epics und Programm-Epics. Portfolio- und Value Stream-Epics sind für kleinere Entwicklungsvorhaben nicht relevant. Programm-Epics sind dafür umso wichtiger. Wenn ein Team an einem zu einem strategischen Theme verknüpften Programm-Epic arbeitet, dann schöpft das Team Mehrwert für etwas, das genau an der Strategie und den Wertvorstellungen des Unternehmens ausgerichtet ist.

Epics sind für kleine Teams nützlich, denn diese beschreiben Schlüsselvorhaben, die gerade im Gange sind und entweder von Beteiligten oder dem Team selbst definiert wurden. Software-Teams sollten zusätzlich zu Business-Epics auch Enabler-Epics im Backlog haben, um die Architektur oder DevOps-Fähigkeiten zu verbessern.

Da signifikante Vorhaben auch signifikante Investments von Menschen benötigen, wird die Definition eines leichtgewichtigen Business Cases für jedes Epic empfohlen, bevor über Freigabe oder Absage entschieden wird. Ein solcher Prozess ist gerade dann nützlich, wenn das Team mehrere Stakeholder bedienen muss und jedes Vorhaben im Sinne der jeweiligen Priorität und Kapazität betrachtet werden muss, um entsprechende Kompromisse zu verstehen und schließen zu können.

  1. Program Kanban

Das Scaled Agile Framework setzt auf Kanban um Initiatives (Vorhaben) auf Portfolio-, Value Stream- und Program-Ebene zu verwalten. Die Programm-Ebene ist für ein kleines Team ausreichend. Besonders nützlich wird diese Ebene, falls das Team mehrere Stakeholder zu bedienen hat, die jeweils eigene Epics zur Umsetzung anbieten.

Das Program Kanban des Scaled Agile Frameworks stellt einen einfachen und transparenten Prozess zur Erfassung, Analyse, Freigabe und Nachverfolgung von Epics zur Verfügung.

Abgeschlossene Epics sind durch folgende Zustände gewandert: Funnel, Review, Analysis, Backlog, Implementing und schlussendlich Done. Ein komplexer Ablauf. Für ein kleines Team ist der Prozess der Analyse von Epics sehr einfach. Trotzdem sollten diese logischen Schritte berücksichtigt werden. So weiß der Product Owner, dass das Team für den nächsten Releasezyklus den bestmöglichen Geschäftswert generieren kann. Die Schlüsselvorhaben als Epics im Program Kanban zu verwalten benötigt wenig Aufwand aber gibt volle Transparenz für die Prioritäten des Teams auf Programm und Portfolio-Ebene.

  1. Features

Features sind nicht wirklich Teil der Definition von Scrum, sondern lediglich Aufgaben im Produkt-Backlog. Viele Scrum-Teams übernehmen User Stories aus eXtreme Programming (XP) und titulieren große User Stories als Epics und bündeln verwandte Stories als Themes.

Das Scaled Agile Framework definiert ein Feature als einen Dienst des Systems, der ein bestimmtes oder mehrere Bedürfnisse des Nutzers bedient. Features übertreffen Epics und sind über ihre Vorteile und Akzeptanzkriterien definiert. Features sind genau das, wonach sie klingen: Diejenigen Charakteristiken, die die Kernfunktionalität des vorgeschlagenen Produktes ausmachen. Den Fortschritt und die Planung des Teams an Kunden, abhängige Projekte oder das Management  nur über User Stories zu kommunizieren kann mitunter schwierig sein. Features, wie definiert von SAFe, schaffen hier Abhilfe. Der Umfang von Features ist passend und verständlich – im Gegensatz zu User Stories, die oft zu klein und fragmentiert sind.

Was Features so nützlich macht: Sie sind passend für PIs gehalten. So werden Features zu konkreten Deliverables, die eine klare und deutliche Kommunikation mit Stakeholdern ermöglicht.

  1. Planung von PIs

Klassische Scrum-Teams arbeiten in zyklischen Sprints. Meist dauern diese zwei Wochen an und innerhalb dieses Rahmens findet die Planung und Umsetzung von Arbeit statt. Öfter als gewünscht können Scrum Teams aber lediglich wirkliche Transparenz zur geplanten Arbeit nur für den nächsten Sprint bieten. Zusätzlich vielleicht den Backlog, der eine grobe Übersicht dazu gibt, in welcher Reihenfolge User Stories vermutlich implementiert werden. Es wird auf allerlei Variationen von PowerPoint- bzw. Excel-basierten Roadmaps gesetzt, um den Bedarf an Projektplanung, die über den nächsten Sprint hinausgeht zu befriedigen.

Backlog-Werkzeuge können dabei helfen, Stories für künftige Sprints zu planen und basierend auf der Velocity des Teams und der Anordnung im Backlog Vorhersagen zu treffen.

Ein Program Increment (PI) im Scaled Agile Framework bedeutet: ein auf Kadenzen basierender Intervall, der zum Entwickeln und Validieren eines inkrementellen Schrittes in der Erschaffung eines Systems genutzt wird, um Mehrwert fürs Geschäft zu generieren und Feedback zu erhalten. Die Dauer eines PIs beträgt in der Regel acht bis zwölf Wochen bzw. vier bis sechs Sprints.

Ähnlich der Planung von Sprints in Scrum bietet SAFe mit dem PI Planning eine Möglichkeit diese besonders großen Iterationen zu planen. SAFe-PI Planning lässt sich eins zu eins auch für kleine Teams anwenden. Man plant für acht bis zwölf Wochen. Dieser Zyklus ist kurz genug, um sinnvoll planen zu können und lang genug, um dem Team zu ermöglichen etwas von Mehrwert zu erschaffen: potenziell veröffentlichbare Features. Die PI-Planung ist sinnvoll verbrachte Zeit für alle Teilnehmer. Das Team bekommt ein Update fürs große Ganze von der Business-Seite inklusive Vision und Prioritäten und entwickelt einen agilen Plan. Die Stakeholder können bei der Planung direkt mitwirken. Stakeholder bekommen auch einen Überblick über die für ein PI geplante Arbeit der einzelnen Teams. Für ein kleines Team kann die PI-Planung zu einem langen Arbeitstag komprimiert werden, damit die investierte Zeit mit den Benefits in Einklang bleibt.

  1. Innovation und Iterationsplanung

Thomas Edison hat seinen Ansatz für Innovation mit “einem Prozent Inspiration und 99 Prozent Durchhalten” beschrieben. Anders gesagt: Innovation benötigt nicht nur kreative Köpfe, sondern auch viel harte Arbeit. In der nie aufhörenden, kontinuierlichen Entwicklung von Produkten steckt immer das Risiko, dass ein Team ohne Pause Sprint für Sprint arbeitet und am Ende erschöpft und ausgebrannt ist. Sprints können hektisch werden und für kleine Teams wird es schwierig an den Aufgaben mit niedriger Priorität zu arbeiten, die viel Potenzial für Innovation bergen.

Auch das Scaled Agile Framework bietet keine magischen Lösungen, die es Entwicklern ermöglicht, viel freie Zeit für Innovationen zu haben.  Am Ende eines jedes Program Increments gibt es eine IP Iteration (Innovation & Planning-Iteration). In diesem Sprint werden keine Stories geplant, sondern Zeit für Dinge geschaffen wie die finale Integration von Systemen, Tests oder Performance- und Security-Tuning. Hier wird ebenfalls die Retrospektive auf Programmebene gehalten, bekannt als I&A (Inspect & Adapt). Während der I&A-Phase werden die Resultate eines PIs den Stakeholdern demonstriert, mit Problem-Solving Workshop und Retrospektive im Anschluss. Während einer IP-Iteration wird auch das nächste PI geplant.

Wie der Name aber bereits sagt, ist das auch die Zeit für Innovation. In dieser Zeit können Hackathon durchgeführt oder Innovationen umgesetzt bzw. Verbesserungen an der Infrastruktur, dem Code oder der Architektur vorgenommen werden. Und zu guter letzt hat das Team eine Pause vom hektischen Software-Entwicklungsalltag. Ein Teil dieser Pause kann auch für die persönliche Weiterentwicklung bzw. Schaffung neuer Kompetenzen genutzt werden.

Zusammenfassung

Scrum und Kanban sind für sich natürlich ausreichend für kleine Teams. Trotzdem gibt es vier Umstände, für die ausgewählte SAFe-Praktiken zusammen mit Scrum und Kanban effektiver sein können:

  • Wenn es sich um strategische Softwareprodukte mit langer Lebensdauer handelt
  • Wenn Abhängigkeiten mit mehreren Nicht-Software-Teams vorhanden sind
  • Wenn der Bedarf für langfristige Investitionen wie DevOps besteht
  • Wenn eine voraussichtliche Skalierung von klein auf mittelgroß ansteht

All diese Umstände lassen sich natürlich auch nur mit Scrum oder Kanban regeln, aber die Erfahrung hat gezeigt, dass die folgenden SAFe-Praktiken ein effektiveres Handeln ermöglichen:

  1. Strategische Themes fassen die strategischen Prioritäten des Portfolios zusammen und helfen Teams dabei, sich an der Geschäftsstrategie auszurichten
  2. Program Epics definieren die wertschöpfenden Vorhaben, worauf sich ein Team konzentrieren und wonach es den Backlog sortieren sollte
  3. Program Kanban zeigt die Prioritäten und den Status von Epics für Stakeholder auf
  4. Features sind detaillierter als Epics und ermöglichen eine effektive Kommunikation zwischen Team und Stakeholdern. Features sind genau auf die Länge von Program Increments (PI) ausgelegt.
  5. PI Planning findet regelmäßig statt und ermöglicht es, ein gemeinsames Verständnis für die Prioritäten und Ziele für die nächsten acht bis zwölf Wochen zu erreichen
  6. Die Innovation & Planning (IP)-Iteration am Ende eines jeden PIs ermöglicht dem Team eine wohlverdiente Pause vom Day-To-Day zu nehmen und Zeit mit der Findung von Innovationen und der Bildung neuen Skills zu verbringen.

Wir hoffen, dieser kurze Überblick konnte Ihnen das Scaled Agile Framework auch für kleine Teams schmackhaft machen. Wenn Sie weitere Informationen wünschen, wenden Sie sich einfach an unser Team.

Braintime Leistungen zum Scaled Agile Framework

Wir bieten Ihnen umfassende Leistungen zum Scaled Agile Framework:
    • Schulung – Wir vermitteln das Knowhow für Scrum, XP, Kanban und SAFe mit Seminaren und Coaching.
    • Beratung – Von der Einführung bis zum regelmäßigen Review der Fortschritte – wir beraten Sie umfassend.
    • Werkzeugunterstützung – Wir zeigen Ihnen, wie Sie SAFe auf Atlassian JIRA abbilden können.