Dean Leffingwell – Der Erfinder des SAFe Framework
Tino Volbracht:
Andreas, erzähle doch mal: Wie war denn das damals? Wie hat Dean Leffingwell dieses Thema rübergebracht?
Andreas Becker:
Also es war 2013. Ich bin da voller Erwartungen in diese 4-tägige Ausbildung gegangen und es war grauenhaft. Gefühlt 500 Folien hat er runtergespult. Er ist ja Amerikaner, hat irgendwie einen amerikanischen Slang, hat noch genuschelt und dann 500 Folien in 4 Tagen. Also ich bin raus und habe gedacht: „Naja, es mag ja vielleicht ein passendes Framework sein, aber die Schulungen, so wie der die hält 🙁 – und wir sollten die auch so halten. Also mit den vielen Folien. Vielleicht nicht mit dem genuschelten, amerikanischen Slang – werde ich niemals machen.“ So bin ich da raus.
Und was habe ich daraus gelernt? Vergiss die Folien. Lege sie beiseite und mache das mit Flipcharts, mit Stellwänden und leite das ganze Bild her. Denn wenn man da draufkuckt, ist man ja manchmal ein bisschen erschlagen. Also wenn ich das Thema irgendwie schulen muss, verwende ich keinerlei Folien.
Tino Volbracht:
Hört sich gut an. Warum bist du damals da hingegangen? Was war der Grund dafür? Hattest du einfach nur Interesse, das mal zu lernen, oder gab es wirklich einen Kunden, der skalieren wollte?
Andreas Becker:
Ja, also aus der Not heraus bin ich da hin. Also es war 2013 und 1, 2 Jahre vorher habe ich begonnen, mit anderen bei einem Kunden Scrum zu etablieren. Und da muss man dazusagen: Das waren 16 Scrum Teams und die haben aber ein Produkt entwickelt. Das heißt, die einzelnen Bestandteile eines Teams waren fast schon wertlos. Nur die Ergebnisse aller 16 Teams waren wertvoll.
Ja, und angefangen haben wir mit Scrum. Wir haben uns einen Scrum Guide genommen, haben gesagt: „So, wir machen hier Scrum.“ Ich selbst war Scrum Master, agiler Coach von 2, manchmal von 3 Teams. Entsprechende Kollegen haben die anderen Teams übernommen. Und es hatte Gründe, weshalb wir an unsere Grenzen kamen.
Was waren die Schwierigkeiten beim agilen skalieren?
Tino Volbracht:
Was waren das für Gründe? Also was waren die 2, 3 schwierigsten Sachen?
Andreas Becker:
Ja, also das Erste habe ich eben schon gesagt. Nur die Gesamtheit aller Teamergebnisse war tatsächlich nutzbar. Das Zweite ist: Wir haben uns natürlich Kunden eingeladen, die regelmäßig in Reviews uns Feedback geben sollten zu dem gelieferten Entwicklungsstand, und die haben wir in die einzelnen Teams geschickt und haben gesagt: „Ja, kuckt euch das an.“
Und da haben wir die Rückmeldung bekommen: „Was sollen die einzelnen, kleinen Ergebnisse? Wir wollen das Gesamtergebnis sehen – die Integration von allem.“ Das hatten wir so in dieser Form bis dahin nicht. Und was auch natürlich ein ganz großer Schmerzpunkt war, war dass man die Abhängigkeiten hatte. Wir hatten technische und fachliche Abhängigkeiten zwischen diesen 16 Teams und wir sind in jedem Sprint sozusagen im Blindflug. Und was auch noch hinzukam – das ist der letzte Punkt: Wir hatten massive architektonische Herausforderungen – den Umbau dieser Software.
Scrum of Scrum hat die Schmerzen nicht behoben
Kann ich vielleicht nachher noch was dazu sagen, warum und wieso, aber das waren so die 4 Punkte, weshalb wir gesagt haben: „Wir können nicht einfach nur Scrum machen.“ Wir haben natürlich versucht, mit Scrum of Scrums das zu kompensieren, das hat aber leider nicht gereicht. Also wir sind da nicht hingegangen, haben gesagt: „Wir machen jetzt SAFe, weil SAFe so toll ist“, sondern wir haben etwas gesucht, was uns die Schmerzen lindert.
Also wir haben es erst mal versucht möglichst einfach: „Lass uns nur bei Scrum bleiben.“ OK, das hat nicht gereicht: „Wir müssen uns irgendwie abstimmen. OK, dann lass uns jede Woche so ein Scrum of Scrums aufsetzen.“
Tino Volbracht:
Was hat denn gefehlt? Also warum hat Scrum of Scrums nicht gereicht?
Andreas Becker:
Da haben wir schon begonnen. Da waren wir mitten im Sprint und haben mitten im Sprint dann erkannt: „Wow, wir haben hier Abhängigkeiten zwischen den Teams“, und mitten im Sprint das aufzulösen, da war es schon zu spät. Und da kommen wir vielleicht in ein paar Minuten zu einer Besonderheit. Das liefert nur SAFe, wie man das in den Griff kriegen kann.
Tino Volbracht:
Ja, sehr interessant. Ich freue mich darauf. Wie wollen wir es heute machen, Andreas? Wie bringen wir das Thema rüber? Ich meine, so ein Prozessmodell zu erklären ohne Flipchart, das ist schon nicht ganz so einfach. Hast du eine Idee? Können wir das anhand von Beispielen machen?
Andreas Becker:
Ich würde einfach dieses Beispiel der 16 Teams nehmen. Ist zwar schon ein paar Jahre her, ich habe in der Zwischenzeit das auch mit mehr oder weniger Teams gemacht, aber das hat sich in mein Gehirn gebrannt, dieses Beispiel mit den 16 Teams. Und das, was wir damals gemacht haben, und das, was SAFe Framework ausmacht, das gilt bis heute.
Tino Volbracht:
Alles klar, dann starten wir durch.
Tino Volbracht:
Wie viele Mitarbeiter sind das ungefähr? 100 Mitarbeiter?
Die Abhängigkeiten waren das Problem beim agilen Skalieren
Andreas Becker:
So grob 100 und ich sage vielleicht mal, um was es da eigentlich ging. Das war eine Software für die Sozialversicherung, das heißt, Krankenversicherungssoftware. Krankenkassen haben diese Software eingesetzt zur Verwaltung ihrer Versicherten. Und ihr wisst, es gibt hunderte von Krankenversicherungen. Die setzen natürlich alle auf bestimmte Lieferanten von Software und das war einer davon.
Jetzt haben wir begonnen, agil zu arbeiten – weg vom Wasserfall, hin zu Agile, haben 16 Scrum Teams aufgesetzt mit all dem, was man unter Scrum versteht: Backlog, Product Owner, Scrum Master, Teams zwischen 4 und 8 Personen. User Stories haben wir genutzt. Muss man ja nicht. Man spricht ja allgemein nur von Backlog Items. Wir haben uns schnell für die User Story entschieden.
Und so haben wir gestartet mit 2-Wochen-Sprints. Manche hatten auch 3-Wochen-Sprints, manche hatten montags begonnen, manche mittwochs. Jeder hat also sein Ding gefunden und das war erst einmal auch soweit in Ordnung. Und dann begannen die Probleme: Massive Abhängigkeiten zwischen den einzelnen Teams. Und wie ich eben schon sagte: Nachdem die Sprints gestartet haben, haben wir versucht, das irgendwie zu koordinieren, aber das war schon zu spät und wir haben meistens das Sprint-Ziel gerissen.
Und das musste anders werden. Auch die Product Owner fühlten sich überfordert und sagten: „Also so fühlen wir uns in unserer Rolle völlig unwohl. Dass wir da so blind in diesen Sprint reingehen, das kann so nicht weiterlaufen.“ Und was ich vorhin auch schon sagte: Naja, die eingeladenen Kunden aus den Krankenversicherungen, die die Software einsetzen, die sagten: „Hey Leute, ihr wollt uns doch jetzt hier nicht in die Sprint Reviews einladen und uns Teilergebnisse zeigen. Wir sind am Gesamtergebnis, an der Integration von allen 16 Teams interessiert. Das wollen wir sehen.“
Tino Volbracht:
Hatten denn damals alle Scrum Teams den gleichen Takt oder gab es erst 6, 7 Scrum Teams, die haben etwas getan, und darauf aufbauend kamen die nächsten 6 Scrum Teams?
Agile Skalierung bedarf Synchronisierung
Andreas Becker:
Nein, also wir haben begonnen natürlich mit einem Pilot, klar, aber dann hatten wir die 16 Teams am Start. Im Takt waren die, allerdings waren die nicht synchronisiert. Wie ich eben schon sagte: Die einen begannen montags, die nächsten mittwochs, 2-Wochen-, 3-Wochen-Sprints. Und mit SAFe endete das. Also nach dieser SAFe Schulung von Dean Leffingwell, wo ich vorhin schon zum Einstieg sagte, wie er das gemacht hat – das hatte Potenzial nach oben, aber vom Inhalt her haben wir uns da ziemlich viel abgekuckt und gesagt: „Ja, also jetzt versuchen wir das mal.“
Das heißt, erst mal wurden die ganzen Teams synchronisiert. Alle in einem Takt, alle in 2-Wochen-Sprints und alle am selben Tag begonnen, am selben Tag geendet. Warum? Wir wollten am Ende der 16 Sprints die Ergebnisse integrieren, dass wir das Gesamtergebnis haben – also spätestens da.
Die sollten die ganze Zeit integrieren auf eine entsprechende Systemtestumgebung, aber spätestens am Ende des Sprints musste die Gesamtintegration aller 16 Teams vorhanden sein. Und das ist jetzt ein erstes Event, was Scrum nicht kennt. „System Demo“ heißt das – eine Demonstration des Gesamtergebnisses. Das ist ein Kernevent, was man nutzen kann, um das Gesamtergebnis zu sehen, und genau da haben wir dann unsere Stakeholder, also die Kundschaft, eingeladen. Beim SAFe Framework heißen die „Business Owner“. Wenn ihr auf dieses Bild irgendwann mal schaut und sagt: „Ach, da gibt es ja so viele andere Rollen.“ Die Kunden heißen „Business Owner“.
Tino Volbracht:
Das heißt, der erste Unterschied ist, dass ihr alles synchron gemacht habt. Das hat doch wahrscheinlich gut geknallt, oder?
Andreas Becker:
Naja, also erst mal mussten wir uns natürlich darauf einigen mit den Teams. Sie hatten natürlich ihre Zeiten und ihre Tage lieb gewonnen, nenne ich das jetzt mal, und es lag auch bis dahin in der Eigenverantwortung der Teams. Das mussten wir ihnen ein Stück weit nehmen aus den aber eben genannten Gründen, dass wir tatsächlich zu einem integrierten Gesamtergebnis kommen. Das heißt, die Prinzipien, die wir auf der Scrum Ebene kennen – also es gibt einen Sprint, es gibt verschiedene Rollen, es gibt bestimmte Events, Planning, Introspective, Review – das alles gibt es beim SAFe Framework noch einmal mit anderem Namen, aber jetzt für alle 16 Teams.
Das heißt, um diese 16 Teams wird eine Klammer gebildet und das heißt „ART“. „Agile Release Train“. Das ist das, was man ganz häufig auf diesen Bildern sieht. Es wird dargestellt wie so ein Zug. Das ist die Klammer über diese 16 Teams – die Synchronisation der Arbeit über allem.
Und da kommen jetzt noch ein paar Rollen hinzu, zum Beispiel der RTE. Das ist der Release Train Engineer. Das ist sozusagen der Scrum Master für diese Klammer. Das heißt, die Moderation, das Identifizieren und möglichst Lösen von Impediments, das Coachen von den ART-Rollen, das obliegt diesem RTE. Das heißt, sozusagen der Scrum Master für diesen ART.
Tino Volbracht:
Das hört sich für mich jetzt erst mal an wie Scrum of Scrums, oder? Das heißt, ich habe eine Teamebene, bei der habe ich diese verschiedenen Rollen, und ich habe eine Ebene darüber. Und da habe ich jetzt verstanden, die haben die gleichen Rollen, nur übergreifend.
Andreas Becker:
Und nur einmal. Also wenn ich 16 Scrum Master hätte, habe ich diesen RTE nur einmal, weil über diese 16 Teams wird einmal diese Klammer gebildet. Das ist der ART. Dafür gibt es eine Rolle, die diese Aufgaben für diese Klammer übernimmt.
Der Produktmanager ist im SAFe Framework
Tino Volbracht:
Wie ist es bei dem Product Owner? Gibt es auch einen übergreifenden Product Owner im SAFe Framework?
Andreas Becker:
Ja, genau. Der heißt dann aber nicht mehr „Product Owner“. Der heißt im SAFe Framework „Produktmanager“ und der hat auch ein eigenes Backlog, das heißt, auf der Teamebene haben wir nach wie vor ein Team. Das heißt dort „Team Backlog“. Nicht „Product Backlog“, sondern „Team Backlog“.
Und auf der ART-Ebene haben wir auch ein Backlog. Das heißt jetzt allerdings „Program Backlog“ und nicht „Product Backlog“.
Also die Begrifflichkeiten sind manchmal so ein bisschen verwirrend. Das hängt einfach damit zusammen: Oberhalb der Teamebene haben wir die Program Ebene. Dafür gibt es ein Backlog. Da sind üblicherweise keine Stories drinnen, sondern Features. Was ist jetzt ein Feature? Ein Feature ist auch wieder die Klammer über mehrere User Stories.
Ich hatte ja vorhin gesagt, in unserer Ausgangssituation hatten wir Abhängigkeiten zwischen den Teams – inhaltliche, fachliche Abhängigkeiten. Das heißt, ein Feature konnte nur erledigt werden von mehreren Teams und diese funktionale Klammer bildet das Program Backlog mit den Features. Und dafür verantwortlich ist der Produktmanager.
Tino Volbracht:
Hat man dann auch noch Epics?
Andreas Becker:
Ja, die hat man auch, allerdings noch mal eine Ebene obendrüber auf der Portfolioebene. Die wollen wir heute hier ausklammern. Warum? Das, was wir heute besprechen, das sind die ersten 2 Ebenen – einmal die Teamebene und die Program Ebene. Das Ganze heißt im SAFe Framework „SAFe Essential“ und lässt sich losgelöst vom ganzen Rest etablieren.
Tino Volbracht:
OK, das heißt, auf Teamebene habe ich weiterhin meine Stories, eine Ebene darüber habe ich meine Features. Also viele Stories aus vielen Teams ergeben dann ein Feature. Und wenn ich das Ganze noch weitertreiben möchte und noch größere Organisationen habe, dann nennt sich das „Epics“, habe ich verstanden. Also viele Features ergeben ein Epic.
Andreas Becker:
Genau.
Tino Volbracht:
OK.
Andreas Becker:
So lässt sich das erklären, allerdings, wie gesagt, da gibt es noch ein paar Besonderheiten. Das würde allerdings heute den Rahmen sprengen.
Der Product Owner hat im SAFe Framework nicht mehr die Power wie bei Scrum
Tino Volbracht:
Mal eine Frage zu dem Product Owner. Was mir auffällt, ist: In Scrum heißt es ja, das soll die Person sein, die auch für den wirtschaftlichen Erfolg steht. Das heißt, was ich verstanden habe: Wenn es noch mal einen darüber gibt, dann ist er ja nicht komplett verantwortlich. Dann ist der ja nur für seinen Teil verantwortlich innerhalb seines Teambereichs. Konterkariert das nicht mit Scrum?
Andreas Becker:
Doch, das hängt aber damit zusammen, dass wir hier gar kein Scrum machen, sondern wir machen ja SAFe. So, das heißt, wir haben auf der Teamebene, nennen wir das mal, „agile Teams“. Die haben auch kein Product Backlog, sondern sie haben ein Team Backlog. Da ist ihre gesamte Arbeit drinnen. In meinem Fall mit den 16 Teams könnte man sagen, es waren 16 Komponenten, die wir hier hatten. Wir haben zwischenzeitlich überlegt, ob man das auflösen kann.
Man hört ja ganz viel, oder hat man damals auch schon gehört, von sogenannten „Feature Teams“. „Lass uns doch nach Feature Teams strukturieren“, das haben wir angedacht und alle Simulationen, die wir durchgeführt haben, haben festgestellt: Dann haben wir trotzdem wieder Abhängigkeiten. Und das ließ sich auch nicht so einfach umsetzen.
Tino Volbracht:
Was ist ein Feature Team?
Andreas Becker:
Naja, ein Feature Team wäre ein Team, das für eine bestimmte Funktionalität verantwortlich ist. Ende-zu-Ende-Funktionalität. Das hatten wir so in dieser Form ja nicht. Eigentlich hatten wir 16 Komponenten.
Tino Volbracht:
OK, also Feature Team wäre dann die komplette Architektur im Prinzip von Design über Frontend, Middleware, Backend, alles, was notwenig ist, um wirklich das Ding vor Kunden zu bringen.
Andreas Becker:
Genau, aber dann halt nur eingeschränkt für eine bestimmte Art von Feature. Also das haben wir schon angedacht. Das hätten wir so auf die Schnelle nicht hinbekommen und deswegen haben wir gesagt: „Als Ausgangssituation akzeptieren wir mal das, was wir haben. Wir haben nämlich 16 Teams jeweils für eine Komponente.“ Und das hat auch gut gepasst. Und zum Produkt Owner: Die waren sehr technisch orientiert, das heißt, die konnten zu ihrer Komponente ganz viele Fragen auch, wenn die aus dem Team kamen, beantworten und die waren ganz stark in einer eher technischen Rollen und haben die hervorragend ausgeführt.
Und diese Marktsicht, die du da eben angesprochen hast, das hat das Produktmanagement ausgeführt. Das heißt, wir hatten eher eine Innensicht, eine Teamsicht durch die Product Owner und eine Nach-Außen-Sicht durch das Produktmanagement.
Ich bin ein Freund der agilen Prinzipien und wir hatten ja vor einigen Wochen hier eine Sitzung, wo wir die agilen Prinzipien mal anhand von Fußball durchgegangen sind (nachzuhören unter: Agile Prinzipien anhand von Fussball erklärt), und wir haben diese Prinzipien erfüllt, denn eins ist: IT und Fachbereich soll täglich zusammenarbeiten. Und genau das haben wir auch gemacht, denn sowohl Product Owner als auch das Produktmanagement waren vorhanden. Die waren jeden Tag da und konnten Entscheidungen treffen.
Das heißt, wir haben kein klassisches Scrum gemacht, aber das agile Prinzip war erfüllt. Und das ist für mich ausschlaggebend gewesen. Wir sind ganz schnell dabei, was und wie wir es machen. Und ganz häufig wir das Wozu vergessen.
- Wozu machen wir das denn eigentlich?
- Was wollen wir erreichen?
Nicht das Framework ist wichtig, sondern was hinten rauskommt
Und wenn wir zum Beispiel Produkte entwickeln, regelmäßig liefern und die Kunden sind begeistert, nur mal als Beispiel, dann ist mir völlig egal, ob das jetzt mit Scrum, Kanban, SAFe Framework, LeSS, oder wie diese ganzen Frameworks auch heißen, erreicht wird. Mir geht es darum: Was kommt sozusagen hinten raus? Wie können wir das übergeordnete Ziel, was wir eigentlich mit der agilen Entwicklung erreichen wollen – wenn wir das erreichen, dieses Ziel, dann ist mir sozusagen das Framework egal. In der Situation hat halt das SAFe Framework geholfen.
Tino Volbracht:
Ja, das stimmt. Ich habe noch mal eine Frage. Und zwar zu dem Product Owner, weil da ist für mich der größte Bruch, weil auf der ersten Ebene machen wir ja schon Scrum, habe ich verstanden, und es gibt ja auch den Product Owner. Ist das so, dass die Product Owner sich mehr um die Technik kümmern und das Produktmanagement ist dann das alte Produktmanagement?
Andreas Becker:
Im Endeffekt haben wir hier ein gemeinsames Team. Das Produktmanagement, ausgefüllt durch eine Rolle, bildet ein Team mit allen Product Ownern. Die bilden ein Team und arbeiten gemeinsam an dem Feature Backlog. Verantwortlich ist, wenn es nur einen gibt, der Produktmanager. Es könnte theoretisch mehrere geben, aber gemeinsam arbeiten die dran, auch wenn wir da einen Verantwortlichen haben. Es ist wie auf der Teamebene.
Auf der Teamebene, wenn wir beispielsweise Scrum machen, dann gibt es einen Verantwortlichen für das Product Backlog – das ist der Product Owner. Aber selbstverständlich können auch Teammitglieder an Stories mitarbeiten. Da ist ja explizit auch in vielen Fällen gewünscht und erforderlich. Es gibt zwar einen Verantwortlichen, der auch für die Priorisierung verantwortlich ist, aber trotzdem können andere mit- und zuarbeiten. Und genauso haben wir das auf alle Fälle gemacht. Produktmanager und Product Owner haben ein Produktmanagementteam gebildet.
Der Planungsprozess im SAFe Framework
Tino Volbracht:
Wie funktioniert denn die Priorisierung? Also wie läuft dieser Planungsprozess für die 2 Wochen ab?
Andreas Becker:
Ja, der Planungsprozess läuft über 2 Wochen hinaus. Da sprichst du etwas Interessantes an. Bevor wir in den ersten Sprint gehen, machen wir ein sogenanntes „PI Planning“, „Programm Increment Planning“. Also „PI“ steht für „Program Increment“.
Das heißt, ich hatte ja vorhin gesagt, die Klammer über die 16 Teams bildet die Program Ebene, und auch hier haben wir ein Increment, so wie wir das auch im Sprint haben. Das ist das Gesamtergebnis. Und dafür können wir, so schlägt es zumindest SAFe mal vor, eine 2-tägige – ja, du hörst richtig – Planungskonferenz machen, wo alle Teammitglieder und alle Rollen und auch Stakeholder in einen Raum gehen.
Also 16 Teams sind in einem Raum 2 Tage. Wenn man das erzählt, gerade einem Manager, der das dann vielleicht auch organisieren müsste und bezahlen, der kommt leicht ins schwitzen und sagt: „Was ist denn das? Das ist das totale Chaos.“
Tino Volbracht:
Warte mal kurz. Wie oft machen die das? Alle 2 Wochen für 2 Tage?
Andreas Becker:
Nein, nein, nicht alle 2 Wochen. Alle 8 Wochen möglicherweise. Kommen wir gleich noch mal drauf. Aber bevor wir starten, machen wir dieses PI Planning. Alle in einem Raum initial mal 2 Tage. So, was passiert da? Wenn wir den Vorschlag vom SAFe Framework übernehmen, gibt es erst mal einen Impuls durch das Management, denn irgendwo gibt es ja noch irgendeinen, der diese Firma führt, vielleicht gegründet hat und auch eine Vision vielleicht hat.
Und viele Entwickler sehen diese Leute häufig gar nicht. Das heißt, wir fangen mal damit an, dass er über die Entwicklung, die Vision seiner Firma berichtet, sagen wir mal, eine halbe Stunde, Stunde.
Der Architekt im SAFe Framework
Dann haben wir auf der Programmebene, so wie wir das Produktmanagement haben, auch noch mal einen Systemarchitekten. Der hat nicht wie im klassischen die Hoheitsgewalt, dass er Entscheidungen treffen kann. Der ist eher beratend tätig und der führt ganz häufig eine Community of Practice für architektonische Fragen ein und holt regelmäßig aus den Teams die Leute, die die besondere Fähigkeit haben, an der Architektur zu arbeiten, zusammen zu einem Team und man vereinbart zum Beispiel allgemeine Regeln, die für alle gelten. Das heißt, es wird nicht von oben bestimmt, sondern das wird gemeinsam erarbeitet. Also gerade wenn es darum geht, das Ganze zu integrieren, braucht es ein paar Leitplanken. Und diese Leitplanken, wie gesagt, werden aber nicht vorgegeben, sondern die werden zusammen mit den Teammitgliedern durch jemanden moderiert.
Tino Volbracht:
Interessant. Ist das dann sowas wie eine Community of Practice, die sich bildet?
Andreas Becker:
Ja, genau. Ja, absolut.
Tino Volbracht:
OK.
Andreas Becker:
Eine Community of Practice. Architektur. So, und in dieser 2-tägigen Planungskonferenz berichtet der dann natürlich: Was hat denn diese Community of Practice zum Beispiel für Randbedingungen festgelegt? Was haben die denn erarbeitet? Dass das jedem an dieser Stelle auch bekannt ist.
Das Unterbrechen der Features in User Stories im SAFe Framework
Dann tritt das Produktmanagement auf und stellt mal priorisierte Features, die als nächstes anstehen. Und dann wird gearbeitet. Die Teams ziehen sich die priorisierten Features und brechen die in User Stories runter. Und vor allem sind jetzt die User Stories interessant, die Abhängigkeiten zwischen den Stories haben. Das wird visualisiert. Ziel und Zweck ist es, diese Abhängigkeiten sichtbar zu machen und aktiv die zu managen und nicht einfach in den Sprint zu starten, sondern in dem Moment, wo wir wissen: „Wir haben eine Abhängigkeit. Ich will irgendeine Funktionalität umsetzen, ich brauche aber von deinem Team erst eine Anpassung an der Schnittstelle und ihr braucht dafür einen Sprint, das heißt, ihr macht die Anpassung an der Schnittstelle im 1. Sprint. Wir machen im 2. Sprint unsere funktionale Erweiterung.“
Tino Volbracht:
Da würde mich noch mal interessieren: Wie macht man das wirklich hands-on? Also mal angenommen, es gibt eine User Story und 2 Teams sind beteiligt. Einer muss ja mal anfangen, jetzt zu analysieren – Team 1, sagen wir mal, und dem fällt auf: „Oh, da brauchen wir noch irgendwelche Daten aus einer bestimmten Schnittstelle von Team 2.“
Alle Teams sitzen bei der Planungsrunde in einem Raum
Andreas Becker:
So, deswegen sitzen die alle in einem Raum. Die sitzen alle in einem Raum, alle 16 Teams – jeder an einer Tischgruppe, nicht durcheinander. Also jedes Team hat eine eigene Tischgruppe und möglichst viele Abstände. Das hat jetzt nichts mit Corona zu tun, sondern das ist ja auch eine entsprechende Lärmentwicklung. Und jedes Team arbeitet erst mal an seinem Tisch. Und jetzt stellen wir fest: „Oh, wir brauchen vom Team, was 3 Tische weiter sitzt, beispielsweise eine Anpassung oder eine Vorarbeit.“
Warum sitzen die jetzt alle in einem Raum? Um genau die Kommunikationsbarrieren niedrig zu halten. In dem Moment, wo ich da einfach rübergehen kann und sagen kann: „Hey Leute, wir können jetzt hier nicht weiterarbeiten. Wir brauchen erst mal von euch hier eine entsprechende Zuarbeit“, dann können die das einplanen und wir würden das sofort visualisieren. Wir gehen nach vorne, da gibt es ein großes Board, da werden alle Abhängigkeiten visualisiert und man sieht am Ende dieser 2 Tage: Wo sind Abhängigkeiten? Wer muss was eigentlich tun? Dieses Ergebnis dieser Sichtbarmachung von Abhängigkeiten wird danach nicht in die Mülltonne gekloppt, sondern das heben wir auf.
Ich habe ja vorhin gesagt, das Produktmanagement und die Product Owner, die bilden ein Team, das heißt, die gucken da jede Woche oder auch zweimal in der Woche, je nachdem wie häufig die sich treffen, drauf, schauen:
- „Wie weit sind wir denn?
- Welche User Story haben wir schon umgesetzt?
- Wo gibt es möglicherweise Verschiebungen?“ Und dann sieht man anhand der visualisierten Abhängigkeiten: Wo gibt es Verschiebungen? Wo müssen wir möglicherweise umplanen?
Das agile Prinzip “Direkte Kommunikation” wurde im SAFe Framework abgedeckt
Tino Volbracht:
Noch mal eine Frage dazu: Initial, habe ich jetzt verstanden, ist es ja auch eine gute Idee, wenn SAFe auf diese Fragestellung eine Antwort hat. Scrum hat darauf ja keine Antwort. Da müsste man sich irgendwas überlegen und das finde ich schon mal gut.
Andreas Becker:
Darf ich da noch einhaken? Das finde ich nämlich ganz wichtig. Wir haben letztes Mal über ein agile Prinzipien gesprochen und das war direkte Kommunikation. Direkte Kommunikation in das Team hinein und innerhalb des Teams. Und diese Planungskonferenz über 2 Tage ist genau die Antwort auf dieses Prinzip. Da entsteht kein Stille-Post-Prinzip: „Irgendeiner hat irgendwas erzählt und der trägt das jetzt in irgendein Team“, sondern alle sind zusammen. Die kriegen mit:
- Was für Features werden vorgestellt?
- Wie wird das runtergebrochen?
- Wer kann was übernehmen?
Und dieses Prinzip: Wir wollen kommunizieren ohne Stille Post, das wird genau dadurch erfüllt, dass wir die Leute zusammenbringen. Das ist mir noch mal wichtig zu sagen, dass wir nicht mit Repräsentanten arbeiten – es kommen aus jedem Team 1, 2 Leute, sondern alle sind zusammen.
SAFe Framework hat viele Best Practises eingebaut
Tino Volbracht:
Ich finde das interessant, weil ganz häufig wird ja das Wort „Best Practice“ zerrissen in Projekten genauso wie im agilen Vorhaben, wenn man sagt: „Das ist immer einmalig und wir wollen diese Best Practice gar nicht mehr hören.“
Andreas Becker:
Also SAFe Framework sagt im Prinzip: Wenn du keine bessere Idee hast, dann mach doch mal das. Versuche das doch mal. Und selbstverständlich sieht jede SAFe Implementierung anders aus.
Ich kenne auch viele, die haben sich nur Teile davon rausgeholt, haben sich inspirieren lassen. Zum Beispiel die Sache mit diesem gemeinsamen Planen. Wir haben sonst von SAFe nichts übernommen, aber das. Haben gesagt: „Also, wir wollen regelmäßig zusammenkommen, das Prinzip der direkten Kommunikation erfüllen und planen die nächsten Wochen tatsächlich gemeinsam, weil sie viele Abhängigkeiten haben.“ Wenn ich keine Abhängigkeiten habe, dann brauche ich auch nicht 100 Leute in einen Raum zwängen.
Dann kann ich isoliert mit jedem Team arbeiten. Wer das hat – super. Wer kein SAFe braucht, kann sich glücklich schätzen. Das möchte ich an der Stelle auch mal sagen.
Reflexion durch Inspect & Adapt
So, aber man kann sich selbstverständlich da inspirieren lassen. Und das, was auf der Teamebene gilt, gilt natürlich jetzt auch auf dieser Program Ebene. Wir haben auch da so etwas wie eine Retrospektive, das heißt nur nicht so. Es heißt „Inspect and Adapt Workshop“. Ist nichts anderes als eine Retrospektive auf dieser Klammerebene, auf dieser Program Ebene. Das heißt, auch da wird angepasst: Was hat gut funktioniert? Was hat schlecht funktioniert? Was müssen wir überarbeiten? Welche Experimente können wir starten?
Tino Volbracht:
Treffen sich da wieder alle 100 Leute?
Andreas Becker:
Nein, da treffen sich jetzt nicht 125 Leute, sondern in diesem Falle treffen sich die Rollen aus dieser Program Ebene und tatsächlich Vertreter aus den Teams. Das gilt tatsächlich dafür. Nur für die Planung kommen alle zusammen.
Kurze Zusammenfassung der Ebenen im SAFe Framework
Tino Volbracht:
OK. Gut, ich fasse noch mal kurz zusammen. Das heißt, wir haben jetzt über das Thema Planung gesprochen. Es gibt also ein Produktmanagement, das ist übergreifend für die Planung verantwortlich, dann gibt es darunter die Product Owner der einzelnen Teams. Die ziehen sich dann aus dem großen Backlog in ihr kleines Team Backlog die Dinger rein. Die Teams müssen dann gucken, dass die einzelnen Stories auch alleine abgearbeitet werden können und dass es da keine Verzahnungen gibt zu anderen Teams. Auflösen tut man das in diesem 2-Tages-Workshop alle 8 Wochen.
Dann haben wir die Realisierung. Das ist im Prinzip ganz normales Scrum, wir könnten aber auch Kanban nutzen. Wir sind da nicht in ein bestimmtes Korsett gezwungen. Dann haben wir darüber gesprochen: Am Ende gibt es eine Retrospektive übergreifend auch noch mal. Die Teams machen wahrscheinlich auch ihre Retros?
Andreas Becker:
Ja, genau.
Tino Volbracht:
Genau. Was fehlt denn noch?
Der Zeitplan im SAFe Framework
Andreas Becker:
So, was fehlt noch? Das ist genau der Zeitplan oder – ich mache vieles mit Fußballvergleichen – der Spielplan. Wir machen ganz häufig 3 oder 4 Sprints und diese 3 oder 4 Sprints sind genau Betrachtungszeitpunkt dieser Planungskonferenz, dieser PI Planning. Interessant an dieser Art der Planung ist: Ihr konzentriert euch auf Abhängigkeiten. Alles, was unabhängig eingeplant werden kann in die Sprints, wird unabhängig gemacht. Nur wo wir Abhängigkeiten haben, da lege ich ein Augenmerk drauf. Jetzt habe ich gesagt, 2 Tage brauchen wir dafür.
Ja, wann machen wir das denn? Holen wir denn jetzt alle Leute mitten im Sprintbetrieb einfach heraus? Nein, das machen wir nicht, denn da gibt es eine Besonderheit. Die kennt man so in anderen agilen Frameworks auch nicht. Die Empfehlung ist: Mach 4 Entwicklungs-Sprints. Das sind 8 Wochen. So, und danach mach einen sogenannten IP-Sprint. IP steht für „Innovation und Planung“. 2 Wochen. In der 1. Woche mach mal was anderes.
Viele Teams klagen darüber, dass sie im Tagesgeschäft und im Abarbeiten von Stories untergehen und keine Zeit haben für kreative Weiterentwicklung – einfach mal was überlegen über den Tellerrand hinaus. Und diese 1. Woche dieses besonderen Sprints kann genau dafür genutzt werden, einen Designsprint zum Beispiel zu machen oder eine Woche für neue Prototypen. Und die 2. Woche würden wir nutzen für Weiterbildung, für Pflege unserer Umgebungen und für diese 2-tägige Planung oder auch für Refinements.
Also die 2 Wochen sind locker gefüllt, aber es ist kein klassischer Sprint. Also das, was in Scrum gilt: Nach einem Sprint kommt sofort der nächste und wieder der nächste und der nächste und wir sind immer in diesem ewigen Sprintzyklus, das gilt im SAFe Framework nicht.
4 Sprints, 1 besonderer Sprint, der sich der Innovation und der Planung widmet. Und danach geht das wieder von vorne los. Das heißt, die eben angesprochene PI Planung, vor allem für die Abhängigkeiten, gilt für 4 Sprints und dann beginnt das wieder von vorne.
Wann wird deployed?
Tino Volbracht:
Wird etwas darüber ausgesagt, wann die Software auf die Produktion deployed werden kann?
Andreas Becker:
Jeden Tag.
Tino Volbracht:
Also sagt SAFe dazu, erst nach 4 –
Andreas Becker:
Nein, nein, jeden Tag. So, das heißt, das, was ich eben beschrieben habe, ist die reine Planung. Wenn ich in der Lage bin, zu entwickeln und zu releasen jeden Tag, dann mache ich jeden Tag. Das ist völlig losgelöst. Ich muss hier nicht die 4 Sprints warten und sagen: „So, aber jetzt.“ Wenn ich in der Lage bin, es sofort zu tun, dann mache ich es sofort. Also es ist völlig entkoppelt voneinander.
Gibt es einen Puffer-Sprint?
Tino Volbracht:
OK, weil ich habe mir gerade vorgestellt: Man würde diese 4 Sprints dann machen und dann gibt es 2, 3 Teams, die sind ein bisschen schneller unterwegs und die können dann auch neue Prototypen/Spikes entwickeln und dann gibt es 1, 2 langsame Teams und im Prinzip wäre das dann die heiße Phase und die müssen alles andere nacharbeiten. Das ist dann quasi der Puffer-Sprint, der gemacht wird.
Andreas Becker:
Das ist super, dass du das sagst – Puffer-Sprint. Der Sprint heißt ja jetzt „IP-Sprint“ und der hieß früher „HIP-Sprint“. Wir sind ja mittlerweile bei SAFe Framework in der 5. Version. In der 2. und 3. Version hieß der noch „HIP“ und das H stand für „Hardening“. Und das ist genau das, was du ansprichst. Also jetzt noch mal einen Puffer zu haben, um das ganze hart zu machen. So, und was ist passiert? Die Leute – das kannst du dir jetzt vorstellen –
Tino Volbracht:
Das habe ich mir nämlich gedacht.
Andreas Becker:
Sagen: „Ach, da kommt ja noch der Hardening Sprint und dann haben wir noch Zeit, um da uns um die Qualität zu kümmern, also lass und doch mal schlampern.“ Also dieses Signal: „Wir haben da noch einen Puffer-Sprint“, das wollen wir nicht geben.
Tino Volbracht:
Macht Sinn.
Wie viele Personen können in einen SAFe Framework ART?
Andreas Becker:
Die Frage, die auch ganz häufig kommt: Wie viele Leute werden denn in so eine Klammer, also in so einen ART aufgenommen? Da gibt es auch eine ganz klare Empfehlung. Und die Empfehlung heißt: 125 Leute.
Da habe ich gedacht: Wieso 125? Und das basiert auf einem Professor, der heißt Dunbar und der hat sich völlig losgelöst von Softwareentwicklung oder Produktentwicklung oder agilem Treiben mit Dorfstrukturen beschäftigt. Den hat interessiert: Wie viele Leute müssen eigentlich in einem Dorf leben, damit man sich kennt, damit man weiß: Was macht der andere? Was treibt der so? Man kommt noch ins Gespräch. Also das, was eben in so einem Dorf gilt. Irgendwann endet das doch mal. Also in der Großstadt haben wir das natürlich nicht. So, und irgendwann kippt das mal, dass man sich eben nicht mehr kennt, dass man eben nicht mehr zu jedem Hallo sagt und weiß, was der Nachbar am Wochenende getrieben hat.
Und dieses Kippen ist etwa oberhalb von 125. Also es bricht jetzt auch keine Katastrophe aus, wenn wir 126 sind, aber irgendwann nach 125 bricht dieses Prinzip der Dorfstruktur. Und wir wollen im Prinzip, auch wieder um die agilen Prinzipien zum Leben zu bringen, ja genau so eine, ich sage jetzt mal, Dorfstruktur haben.
Ich möchte wissen:
- Wer ist der Ansprechpartner? Wer ist das?
- Wer ist hierfür zuständig? Wer macht das?
Und deswegen versucht man tatsächlich, so einen ART nur mit 125 Leuten zu bestücken. Wenn das nicht geht, braucht man einen 2. Also wenn wir jetzt 200, 300 Leute sind, dann brauchen wir nebendran noch einen 2. ART.
Ab wie vielen Personen ergibt SAFe Sinn?
Tino Volbracht:
Was würdest du denken, ab welcher Größe macht das Sinn, dass man über SAFe nachdenkt?
Andreas Becker:
Naja, also wir haben ja, wenn wir von Scrum sprechen, Größenbegrenzungen auf alle Fälle einstellig. Das heißt, wir brauchen viele Teams und ich würde es weniger an der Größe festmachen, sondern an den Abhängigkeiten. Wenn ich ein großes Produkt habe, das ich nicht mehr von einem Team entwickeln lassen kann, und wenn zwischen den Teams Abhängigkeiten bestehen, dann macht es durchaus Sinn, dadrüber nachzudenken, mit SAFe zu arbeiten – zumindest mit dieser Ebene SAFe Essential. Wenn ich das dann noch weiterdenke und sage: „OK, wie ist es denn jetzt mit dem Portfoliomanagement beispielsweise? Wie können wir das denn jetzt noch agil integrieren?“, dann müssen wir genau über die oberste Eben sprechen, aber das genau wollten wir ja heute nicht.
Tino Volbracht:
Und nach oben hin gibt es keine Grenzen, oder?
Andreas Becker:
Also ich hatte ja eben gesagt, dann braucht man einen ART und noch einen ART. Und, genau, wir können das Spiel lange treiben.
Tino Volbracht:
Andreas, vielen Dank für den tollen Überblick. Ich denke, wir können keinen 2-Tages-Workshop im Podcast machen. Das wäre ein bisschen viel dafür. Wenn jetzt jemand sagt: „Mich interessiert dieses Thema, ich würde aber gerne so einen 2-Tages-Workshop machen“, bist du der Richtige dafür?
Andreas Becker:
Ja, aber nur, wenn ich die Folien weglassen darf und wir das interaktiv machen können.
Tino Volbracht:
Ich glaube, dafür ist jeder dankbar. Das stimmt. Wo findet man dich im Internet?
Andreas Becker:
Unter AgilerTaktik.coach.
Tino Volbracht:
AgilerTaktik.coach, alles klar. Dann werde ich die Adresse mal verlinken in den Shownotes. Also da kannst du später noch mal nachkucken, draufklicken und dann kommst du zu Andreas’ Internetseite. Alles klar.
Andreas Becker:
Kann ich noch einen Satz dazu sagen? AgilerTaktik.coach, weil ich ganz viel mit Fußball erkläre.
Tino Volbracht:
Ja, das ist schön plastisch. Alles klar. Andreas, vielen Dank und bis zum nächsten Mal. Mach’s gut.
Weiterführende Links:
Das Modell inkl. Poster-Download
