Einführung in das Scaled Agile Framework (SAFe) mit Thorsten Janning

Veröffentlicht am 19. August 2020

Behandelte Themen

Einführung von Matthias Rauer

Warum und wann beginnen Unternehmen, über die Skalierung von Agile nachzudenken?

Scrum im Team auf größere Produkte anwenden

Die Grundzüge von SAFe

PI-Planning in SAFe

Vorteile von SAFe gegenüber andere Skalierungs-Ansätze

Wie agil ist SAFe wirklich?

Wie viel Prozess-Treue verlangt SAFe und wie viel Abweichung duldet das Framework

Ausblick auf die nächste Folge (die konkrete Implementierung von SAFe)

Transkription des Podcasts

Mit: Matthias Rauer von Seibert Media und Thorsten Janning von der Kegon AG

Matthias:

Hallo und Willkommen zu einem neuen Podcast von Seibert Media, der zugleich den Auftakt einer neuen Staffel bildet. Darin wollen wir uns über mehrere Folgen hinweg mit der Skalierung agiler Zusammenarbeits-Methoden in der Software Entwicklung und mit dem Scaled Agile Framework beschäftigen. Und wenn es um die Skalierung von Agile geht, gibt es im deutschsprachigen Raum nicht allzu viele Ansprechpartner, die darin so kompetent und praxiserfahren sind, wie unser heutiger Gast-Experte und seine Kollegen. 

Dr. Thorsten Janning ist als Management-Berater bei der Kegon AG in Wiesbaden tätig und Mitbegründer von Kegon, die, das darf man getrost sagen, eine Vorreiterrolle eingenommen haben und als eine der ersten Dienstleister in Deutschland überhaupt Unternehmen professionell und systematisch bei der Agile Skalierung unterstützt haben. Und Thorsten ist dankenswerterweise auch unermüdlich immer wieder aufs Neue, ganz von vorne anzufangen und Greenhorns wie unsereins geduldig ein paar Grundlagen näherzubringen. 

Thorsten Janning ist mir jetzt zugeschaltet. Hi Thorsten, schön, dass du dabei bist!

Thorsten:

Ja, Hallo, ich freue mich!

Matthias:

Ich bin Matthias Rauer und wir wollen jetzt in dieser Folge in aller gebotenen Kompaktheit eine kurze grundsätzliche Einführung zum Scaled Agile Framework anbieten. Thorsten, die Vorteile von Agile auf Teamebene in Form von Scrum, Kanban und verschiedenen Hybrid-Versionen sind bekannt und belegt. Höhere Qualität, Auslieferungen im festen Zeit- und Budget-Rahmen, zufriedenere Kunden, zufriedenere Teams, warum und wann fangen Unternehmen an, über die Skalierung von Agile nachzudenken?

Thorsten:

Ja, vielleicht kann ich da sogar ansetzen, bei dem, wie auch mich eben vorgestellt hast, weil das passt eigentlich ganz gut…

Matthias:

Gern.

Thorsten:

…weil, als wir die Kegon gegründet haben, haben wir ja gar nicht agil gemacht, sondern wir haben komplexe Projekte gemanagt. Und wir haben dann gesehen, dass eben Scrum und Kanban auf der Teamebene tatsächlich zu den Erfolgen führt, wie du es jetzt auch gerade beschrieben hast. Und wir haben das dann auch gemacht und fanden das auch irgendwie cool und dann haben wir gesagt, aber diese Projekte, die wir immer gemacht haben, wo viele Leute sind, wo komplexe Produkte entwickelt werden, das ist eben mehr als ein Team und wie kriegen wir das eigentlich agil hin und da sind wir auf die Suche gegangen und sind da ja dann später auch auf das Scaled Agile Framework gekommen. Was ich damit sagen will, ist, bei der Skalierung von Agilität geht es ja nicht darum, Agilität zu skalieren, sondern es geht darum, skalierte Komplexität von Problemen zu beherrschen. 

Ja, das heißt, wie kriegen wir diese Prinzipien, die es im Scrum gibt eigentlich auch auf größere Gruppen auf komplexe Produkte angewendet und das ist eigentlich der Sprung, wo man sagt, da müssen wir hin und da müssen wir die entsprechenden Werkzeuge finden und das war von Anfang an unser Betreiben. 

Matthias:

Und Kunden, die jetzt auf euch zukommen, die haben sicherlich festgestellt, dass Scrum im Team offenbar funktioniert und wie wir das jetzt auf unsere größeren Produkte anwenden. 

Thorsten:

Ja, ja, also es ist tatsächlich so, die meisten haben auf der Teamebene schon Erfahrungen gemacht, herumexperimentiert, teilweise gute, teilweise auch gar nicht so gute Erfahrungen gemacht, weil, es ist auch immer so, wenn du ein Scrum-Team in einer komplexen Organisation hast, dann hast du immer das Problem mit den Systemgrenzen. Ja, das heißt, wenn du ein agiles Team mit einer komplexen Organisation hast, dann kommt die Wirkung gar nicht so zustande, weil ja, es nur lokal ist, und agil hat immer mit Transparenz und Kommunikation im Gesamtsystem zu tun und insofern ist da tatsächlich der Bedarf dann da. 

Und du hast recht, ja, also dann kommen die Leute uns sagen, wir haben damit Erfahrung gemacht und wir sehen, entweder, es hat nicht gut geklappt aus dem Grund, was ich gesagt habe, oder es war eigentlich ganz gut und wir wollen das jetzt weitertragen. Auf jeden Fall haben wir den Eindruck, wir müssen das komplexe System agil machen und habt ihr da irgendwelche Hilfe. 

Matthias:

Dann lass uns doch jetzt mal direkt auf das Scaled Agile Framework zu sprechen kommen. Was führt denn SAFe ein, um so eine Skalierung von erhöhter Komplexität zu erreichen. Stell dir mal vor, wir stehen gerade zusammen ein paar Stationen im Bus und ich bitte dich, mir mal in drei oder fünf Minuten die Grundzüge von SAFe vorzustellen. Dieses große und durchaus beängstigende Prozess-Schaubild von SAFe hast du jetzt natürlich nicht zur Hand, versuche es doch trotzdem mal. 

Thorsten:

 Ja, also dieses Prozess-Schaubild braucht man dafür eigentlich auch gar nicht, weil also, ich gehe mal davon aus, du hast diese Grundidee vom Scrum verstanden, nämlich, dass es darum geht, dass ein cross funktionales Team arbeitet und das arbeitet auf der Basis dieses Prinzips Transparenz und Kommunikation. Also, nicht jeder arbeitet mit Scheuklappen irgendwie seine Spezialdisziplin ab und man hat irgendwelche schriftlichen Regeln, sondern man arbeitet gemeinsam mit den jeweiligen Kompetenzen und macht einen regelmäßigen Austausch und lernt gemeinsam quasi in diesem unsicheren Raum. Und das ist das, um was es auch in der skalierten Agilität mit dem SAFe geht. Das heißt, wie kriegen wir dieses crossfunktionale Arbeiten über die Teamgrenze hinaus. Und da ist es ja tatsächlich so, warum ist ein Team nicht größer als sieben oder zehn Leute? Ja, weißt du es?

Matthias:

Wegen der Kommunikation. 

Thorsten: 

Genau. Ja, wir als Menschen sind eben so begrenzt kommunikationsfähig, ja. Das heißt, nur zehn Leute können in dieser End-zu-End Kommunikation tatsächlich diese intensive Kommunikation beherrschen und was mir mit SAFe machen, ist, zu versuchen, das, was an Kommunikation notwendig ist, dementsprechend Form zu geben, dem Struktur zu geben. 

Und dahinter steckt eine Theorie, Danbar war ein Wissenschaftler, der hat halt diese Kommunikations-Komplexität mal versucht so in allen möglichen sozialen, historischen Strukturen nachzuhalten. Und der hat halt überall dieselben Muster erkannt. Also dieses Muster sieben bis zehn Leute mit der sehr intensiven End-zu-End Kommunikation und die nächste Danbar Zahl ist so bei 100/150 Leuten. Und dafür gibt es schöne Beispiele, dafür gibt es Beispiele im militärischen Bereich, also dass bei den Römern irgendwie…

Matthias:

Legionen-Kohorte…

Thorsten: 

Ja, genau, dass da im Prinzip diese Kommunikations-Komplexität wie sie dann notwendig ist, eben beherrscht werden kann. Mein Lieblingsbeispiel ist das Dorf. Ja also im Dorf, im klassischen Dorf, also nicht so einem Wohnviertel am Rande einer Stadt, sondern ein klassisches Dorf, das eigentlich immer so diese Größenordnung von Menschen zusammen hatte, wo du halt in der Familie die tägliche Kommunikation, dieser täglichen Komplexität, wo du nicht weißt, welche Probleme bringen die Kinder tatsächlich heute mit und wir werden das gemeinsam irgendwie über die Bühne bringen. Und im Dorf tatsächlich das, was später oft auch als anstrengende Transparenz empfinden, nämlich, dass du nichts für dich alleine hast, ja. Dass die Leute gucken, was machst du eigentlich. Das hat eben auf der anderen Seite genau diesen Effekt, dass, wenn jemand merkt, dass du Hilfe brauchst, dass er dir Hilfe anbietet, ja. Und dass du alle Leute so gut kennst, dass du weißt, zu wem du gehen musst, wenn du Hilfe brauchst. 

Und das, was das Dorf ist, das ist in der englischsprachigen Literatur der “Tribe”, ja. Und darum geht es in der skalierten Agilität. Wie kriegen wir eigentlich Kommunikations-Mechanismen und gemeinsame Arbeitsmuster in dieser Hundertschaft hin, um das, was im agilen Team schon ziemlich gut ist, dann über mehrere agile Teams tatsächlich machen zu können, das ist skalierte Agilität im SAFe. 

Matthias:

Wenn es um SAFe geht, bringen wir jetzt einmal ein paar konkrete Begriffe aus diesem Framework mit ein. Dann kommt schnell die Rede auf das sogenannte PI-Planning. Wir haben da in letzter Zeit auch relativ viel drüber geschrieben in unserem Blog. Das sei jedenfalls das wichtigste Ereignis in diesem SAFe-Prozess. Worum geht es denn da?

Thorsten:

Eigentlich geht es genau um das, was ich gerade beschrieben habe. Also erst einmal formal geht es darum, dass die Arbeit für die nächsten acht bis 12 Wochen geplant wird von unserem sogenannten Agile Release Train, das ist das, was ich vorhin als Tribe, als Dorf, dargestellt habe. Also dieses Team auf Agile Teams. Und was in diesem PI-Planning wirklich passiert, ist so ein Wechsel von dezentralen Entscheidungen innerhalb der einzelnen Teams und Alignment auf ein gemeinsames Ziel. Und dieses Wechselspiel von Alignment der Kräfte und dezentralen Kompetenzen, also jeder trifft die Entscheidungen dort, wo er halt die Kompetenz hat, das heißt, nicht alles wird dezentral gemacht, sondern also es braucht jeweils eben das Wissen für die Entscheidung. Und dieses Wechselspiel, das wird im PI-Planning gemacht. Das heißt, am Anfang wird gesagt, das sind die strategischen Ziele, das haben wir gelernt, darauf wollen wir eigentlich hinaus. Dann gehen die Teams in die Breakout Sessions und gucken, wie kriegen wir das eigentlich auf unsere konkrete Arbeit ab, merken sie, wir können das nicht alleine. Wir gehen auf die anderen Teams zu, wir managen die Abhängigkeiten zueinander, wann muss welches Team dem anderen eigentlich etwas zuliefern und dann gibt es wieder ein Alignment. Wenn wir das so machen, dann sind die Erwartungen gar nicht zu 100 % zu erfüllen, das heißt, wir haben eine Management-Sitzung und es werden sofort die notwendigen Priotisierungs-Entscheidungen getroffen, die sich aus der dezentralen Kompetenz, Planungsarbeit mit der dezentralen Kompetenz ergeben hat. Und dann geht es wieder los und sie sagen, ah, wenn wir die Entscheidung jetzt haben, dann können wir den Plan fertig machen. Wir sagen, ja, das läuft so und fertig ist es. Ja, also, Zusammenfassung, dieses Wechselspiel von Decentralized Decision Making und Alignment auf gemeinsame Ziele, dem Struktur und Form in so einem zweitägigen Meeting zu geben, das ist das PI-Planning. 

Matthias:

Das ist aber ein bisschen komplexer als so ein Sprint-Planning im Scrum Team. 

Thorsten:

Weil wir halt mit dem Kommunikations-Grenzen umzugehen haben. Ja, also erstens ist es auch nicht nur für zwei Wochen Arbeit und es ist nicht nur Arbeit für sieben Leute, sondern wir haben eben ungefähr für ein Vierteljahr die Arbeit von vielleicht 100 Leuten zu planen und dafür brauchen wir tatsächlich etwas mehr Aufwand. Andererseits ist es auch so, so ein Sprint-Planning braucht in der Regel auch schon fast einen halben Tag, ja. Und dann ist eigentlich zwei Tage gar nicht so schlimm. 

Matthias:

Nun gibt es an Scaled Agile Konzepten ja nicht nur SAFe. Sondern auch einige alternative Modelle, die teils auch andere Schwerpunkte setzen. Bei SAFe kommt diese Lean-Komponente noch mit herein. Es gibt auch zum Beispiel auch noch LeSS, Spotify, Nexus, die haben doch auch alle ihre Daseinsberechtigung, würde ich annehmen. Welche Vorteile hat denn deiner Ansicht nach SAFe, gegenüber anderen Skalierungs-Ansätzen? Wenn es überhaupt Vorteile hat. 

Thorsten:

Ja. Also erstmal sind all diese Ideen sehr sehr verwand. Also es geht immer um dieselben Dinge. Es gibt ein paar unterschiedliche Praktiken und de facto ist es dann tatsächlich so, dass wir nur unterschiedliche Berater-Schulen dann, die sich ein bisschen um Marktgründe streiten. Aber inhaltlich ist es erstmal sehr sehr verwand. Wenn man aber sagt, und de facto ist es auch so, dass wir in SAFe-Implementierungen gerne LeSS oder Nexus-Elemente mit implementieren, wo wir denken, dass es eigentlich entsprechend sinnvoll ist, weil wir nicht überall mit Kanonen auf Spatzen schießen müssen, ja. 

Wenn man aber sagt, was sind tatsächlich die Eigenschaften von SAFe, die es von den anderen eben auszeichnet, dann kann man sagen, SAFe hat nicht den Anspruch, alles sich selbst auszudenken. SAFe hat den Anspruch tatsächlich, gute Praktiken, bewährte Praktiken für sich zu adaptieren und daraus ein schönes Gesamtkonzept zu machen. Das ist also wirklich ein dauerhaft professionell weiterentwickeltes Framework. Jetzt im letzten Jahr beispielsweise finde ich sehr gelungen die Integration von Design Thinking Methoden für Produktmanager bei der komplexen Produktentwicklung. Und das hat uns dann wirklich sehr geholfen. Und von der reinen Fähigkeit her wird SAFe vor allem dort eingesetzt, wo wir ein gemeinsames Portfolio managen müssen und wo wir sehr komplexe Produkte von mehr als 500 oder 1000 Leuten machen, da kommen die anderen Frameworks auf jeden Fall an ihre Grenzen. 

Matthias:

Lass mich mal eine vielleicht bisschen provokante Frage stellen, die du aber vielleicht auch schon öfters mal gehört hast. Wie agil ist denn SAFe wirklich? Eine Stärke von Scrum ist ja zum Beispiel die schnelle Reaktionsmöglichkeit bei Anforderungsänderungen. Wenn du sagst, dass so ein PI-Planning im 12-wöchentlichen Rhythmus stattfindet, kommt mir das irgendwo so vor, als wäre da die Fähigkeit auf Anforderungsänderungen schnell zu reagieren vielleicht überschaubar. Wie sieht es denn hier mit dem Scaled Agile Framework aus? 

Thorsten:

Also erstmal, jede SAFe Implementierung genauso wie eine Scrum-Implementierung ist, so agil wie du sie tust, ja.

Matthias:

Okay.

Thorsten: 

Sklavische Regelkonformität, so wie du es jetzt gerade angedeutet hast, ja. Die ist im Scrum Scheiße und die ist im SAFe Scheiße, ja. Also wenn man sagt, oh, wir haben jetzt unseren Sprint geplant und da passt jetzt mal gar nichts mehr rein, und da ist aber ein Kunde, der hat ein Problem, das wäre eigentlich in einer Stunde zu lösen, du sagst, nee, die Regeln sind so, tut mir leid, klappt nicht, dann ist das blöd.

Matthias:

Ja, da gibt es dieses klassische Beispiel auf der Webseite müsste unsere Telefonnummer geändert werden…

Thorsten:

Ja genau. Und das ist totaler Quatsch. Und genauso ist es im SAFe auch. Vielleicht erzähle ich mal von einem Beispiel. Also wir hatten eine ziemlich frische SAFe-Implementierung. Wir hatten das erste PI-Planning gerade so 2-3 Wochen hinter uns, also es war eine Bank und wir hatten eine Roadmap vor uns, dass diese Bank wusste, die nächsten 15 Monate sind eigentlich davon geprägt, dass regulatorische Anforderungen, es war vor 2/3 Jahren, das Investment-Steuerreformgesetz, aber das ist vom Inhalt jetzt einmal zweitrangig. Dass das wirklich diese Roadmap der nächsten 15 Monate prägen wird und das eigentlich nicht viel Kapazitäten zusätzlich möglich sind. 

Und kam das, was halt dann kommen muss, nämlich da kam ein Kunde, ein Investor, und sagt, wir haben einen Sack voller Geld. Und er sagte, wenn ihr eure Banking-Prozesse ein bisschen anders macht, also anders abwickeln, meine Geschäfte anders abwickeln könnt, als heute ist, und das bis in drei Monaten, dann ist dieser Sack voll Geld bei euch in der Bank. Ja, und dann ist der sehr gesunde Reflex einer Bank, das ist mir jetzt eigentlich egal, ob ich SAFe mache oder nicht, ich will diesen Sack Geld bei mir in der Bank haben, ja. Das ist wie mit dieser Telefonnummer. 

Und was de facto dann gemacht wurde und darauf bin ich eigentlich immer noch sehr sehr stolz, ist, wir hatten ein PI geplant von November bis Februar, ja und es kam so im Dezember diese Anfrage. Im PI-Planning wird immer ein Ranking gemacht, also was von dem, was wir geplant haben ist jetzt eigentlich wirklich wichtig und was könnte eventuell auch hinten herunterfallen, wenn mal Not am Mann ist. Wir reden über die Bewertung von PI-Objectives, ja. Und da haben wir gesagt, das Niedrigste geränkte Ziel, das nehmen wir jetzt mal raus, um überhaupt diese Anforderungen des Investors zu verstehen. Das heißt also, wir bleiben dabei, Limitierung gehört in Progress und darum geht es bei dieser Beschränkungsregel, nicht zusätzlich etwas reinzunehmen, wir nehmen was raus und verstehen und machen Refinement auf diese Anforderung. Und als wir das gemacht haben, haben wir gesehen, hmm, wir können eigentlich unser PI bis Februar soweit zu Ende machen, bis auf zwei Kleinigkeiten. Die sind echt kritischer Pfad für den Zeitraum bis März, wo wir den Rest dann bedienen müssen. 

Und dann haben wir tatsächlich nochmal ein kleines PI-Objective rausgenommen, diesen kritischen Pfad mit reingenommen. Ansonsten die Sachen abgeschlossen, wie sie geplant waren und dann beim nächsten PI-Planning haben wir alle Kapazitäten für vier bis fünf Wochen nur auf die Investor-Sachen konzentriert. Also wieder Working-Progress limitiert, aber kurzfristig reagiert, um tatsächlich das erfüllen zu können und dann haben wir im März diese Investor-Story eingeführt, haben danach regulatorische Anforderungen weitergemacht. Jetzt kann man sagen, jetzt fehlen ja diese vier/fünf Wochen in den regulatorischen Anforderungen, wenn man die Kapazität nicht erhöht, stimmt auch. Wenn wir dann aber noch ein Verfahren haben, wie wir die Anforderungen, die so wie ein Rohrverstopfer da stehen, also das Gesetz kommt zum 1. Januar und dann müssen 100% Scope sein, wenn man dann sagt, ah, ein paar davon, dieser Anforderungen würden wir die Banklizenz riskieren, wenn wir die nicht erfüllen, die machen wir natürlich. Bei manchen kostet es nur eine Pönale Diese Pönale ist weniger als das was wir mit dem Investor verdient haben. Es ist eine ökonomische Entscheidung zu sagen, dann bezahlen wir halt die Pönale. 

Bei manchen ist es so, wir wissen, das Gesetz kommt zwar am ersten Januar, die Prüfung ist aber frühestens drei oder sechs Monate später. Können wir vielleicht auch später implementieren und alles ist noch gut, ja. Das heißt also, wenn man das mal versucht, ein bisschen aufzubrechen, und nicht immer das, was so als große Regel da steht, einfach mal als so eine große Wand zu akzeptieren, sondern die kleinen Risse darin mal in Richtung inkrementelles Arbeiten und Planen zu nehmen, dann wird man reaktionsfähig und dann ist auch dieses Framework wirklich agil. 

Matthias:

Damit haben wir meine letzte Frage, die ich hier auf dem Zettel zu stehen habe, glaube ich auch schon vorweggenommen. Wenn man so sich dieses Prozess-Diagramm anschaut, von dem ich eben vorhin schon gesprochen habe, dann kriegt man erst einmal einen Schreck, um Gottes Willen, was ist das für ein Prozess. Und man stellt sich vielleicht auch gleich die Frage, wie viel Prozess-Treue verlangt dann nun SAFe und wie viel Abweichung duldet dieses Framework. Und das klingt ja doch so, dass eine Menge Flexibilität doch gegeben sein kann. 

Thorsten:

Also Framework heißt nicht ein Standard der zu 100% im Detail zu befolgen ist. Framework ist ein Werkzeugkasten. Und in jeder Implementierung schauen wir, wie ist eigentlich die Situation und dann muss man natürlich aufpassen, dass man nicht in der Beliebigkeit landet. Und dafür haben wir ein Hilfsmittel und das sind unsere Lean Agile Principles. Da stehen solche Dinge drin, wie wir müssen möglichst dezentrale Entscheidungen treffen, es geht darum, intrinsische Motivationen bei den Mitarbeitern zu haben, es geht darum, dass wir die Working Progress managen, dass wir gemäß der Wertströme unsere Organisation strukturieren. Das sind alles solche Dinge, die in diesen Prinzipien stehen und wenn die eigentlichen Werkzeuge auf den jeweiligen Unternehmens-Kontext anpassen, dann haben wir diese Prinzipien und die grundlegenden Werte mit der Transparenz, dass wir daran entscheiden können, haben wir jetzt eigentlich eine Fassade gebaut. Oder ist das eine echte agile Organisation, auch wenn wir eben ein paar Regeln interpretiert haben. Ja, das heißt, damit schaffen wir es, dass wir nicht in die Beliebigkeit herunterfallen. Ja, also es geht tatsächlich darum, dieses Ziel zu erreichen. 

Trotzdem, ich will es mal umdrehen. Wenn wir fragen, warum wollt ihr eigentlich so etwas wie SAFe einführen, dann ist ein Grund für Unternehmen oft, wir wollen eine gemeinsame Sprache haben. Wir wollen tatsächlich dieselben Begriffe für dieselben Dinge verwenden und da hilft uns dieses Framework ungemein, ja. Dass wir eben einen Agile Release Train haben, dass wir wissen, was ein PI ist, dass wir wissen, wie eigentlich Teams miteinander kommunizieren und was wir für Meeting-Strukturen haben und wie wir die nennen. Dass sich jede Abteilung sich ihr eigenes Ding ausdenkt und wir im Hinterkopf halt Tibilitätsprobleme im Gesamtsystem haben. Und da wiederum hilft uns der Standard tatsächlich. 

Matthias:

Transparenz. Ok, lass uns an dieser Stelle einen Schnitt machen und die Folge hier abschließen. Thorsten, dir einstweilen vielen Dank. Das war sehr interessant und ich hoffe, das regt den ein oder anderen Hörer an, sich eingehender mit diesem Thema zu beschäftigen. Die Kollegen von Kegon sind dafür natürlich gute Ansprechpartner. Du bist auch in der nächsten Folge dabei. Dann wollen wir uns über die konkrete Implementierung von SAFe weiter unterhalten. Und die dabei vielleicht auftretenden Herausforderungen mal besprechen. Euch vielen Dank fürs Zuhören. Ich hoffe, wir hören uns dann beim nächsten Mal wieder, bis dahin. Macht es gut!

Thorsten: 

Ja, von mir auch, tschüss!