Eine Einführung in das Scaled Agile Framework (SAFe) und das Problem dabei genügend Luft zu bekommen…

Beginnt man sich mit dem Scaled Agile Framework (SAFe) zu beschäftigen und sucht eine Kurzeinführung SAFe, dann fällt der Blick zuerst auf das sogenannte „Big Picture“ welches die Startseite von http://www.scaledagileframework.com dominiert.

Hat man bisher bereits Erfahrungen mit agilen Teams gesammelt und ist stets dem Agilen Prinzip

Simplicity–the art of maximizing the amount of work not done–is essential. (http://agilemanifesto.org/principles.html)

gefolgt, dann kommt es häufig zu einer Gegenreaktion im Sinne von „DAS kann doch nicht agil sein!“.

Es gibt nun diverse kurze Einführungen in SAFe die hauptsächliche auf die Elemente, Struktur und Abläufe fokussieren, wie sie im Big Picture abgebildet sind.Sehr schön ist beispielsweise das SAFe 4-0 in 5 Minuten Video von Inbar Oren:

Diese Darstellungen sind sehr nützlich, um einige wichtige Praktiken und Mechanismen zu verstehen. SAFe alleine auf die konkreten Praktiken zu reduzieren ist allerdings weniger hilfreich, weil diese recht konkret sind und sicherlich nicht in jedem Kontext passend.

Mein Ansatz in Trainings zum Scaled Agile Framework ist deshalb, relativ viel Zeit mit Themen wie

zu verbringen. Gerne wedel ich dabei auch mit den Büchern von Donald Reinertsen (Flow) und Kotter (Change Management) herum.

Dies sind Grundlagen, die sicherlich nicht direkt die konkreten und aktuellen Probleme der Teilnehmer adressieren. Sie müssen jedoch verstanden sein, damit SAFe im eigenen Kontext richtig interpretiert und adaptiert werden kann.

Vor ein paar Tagen durfte ich nun sehr kurzfristig für meinen Kollegen Thorsten Janning, dem ersten deutschen SPCT, kurzfristig einspringen, um eine Kurzeinführung SAFe beim Agile Roundtable Rhein-Main zu geben.

Was tun, wenn keine Zeit für eine intensive Vorbereitung da ist? Klar, man nimmt sich eine der Standardpräsentationen und eine gehörige Portion Improvisation dazu. Meine Wahl fiel auf die „SAFe in 8 Pictures“ Präsentation, wie sie über die ScaledAgileFramework.com Seite verfügbar ist (http://www.scaledagileframework.com/videos-and-presentations/).

safe8picturestalk1

 

Schön, ich habe ca. 45 Minuten Zeit und kann einen komprimierten Überblick über SAFe geben. Da Prinzipien, Werte und das House of Lean nicht Teil dieser Präsentation ist, kommen diese Dinge auf ein Flip und ich erkläre (leider nur) kurz etwas dazu.

safe8picturestalk2

Es gab nur einen kleinen Schönheitsfehler bei diesem Plan – statt der erhofften 45 Minuten gabs für alles zusammen nur einen Slot von 20 Minuten.

Sehr schön, vor allem wenn man bedenkt, dass ein beliebtes Feedback für die zweitägigen Trainings ist, dass diese mindestens drei Tage lang dauern sollten :-)

Egal, nicht erschrecken lassen sondern Gas geben und noch ein bisschen Humor einstreuen, u.a. die Frage wer denn diesen Satz lesen kann:

safe8picturestalk3

Eine kurze Summar im Sinne von „Hey, da gibts auch noch etwas reduziertes“ mit dem Hinweis auf das Essential SAFe gabs am Schluss auch noch …

Für mich waren die 20 Minuten (die ich recht gut einhalten konnte) ein spannender, schneller Sprint mit der zentralen Frage: „Hole ich Luft oder geht noch ein weiterer Satz?“. Die Antwort war zumindest zwei mal ein lautes Luftholen :-). Na, da steckt doch noch ein bisschen Energie in den alten Knochen …

Da ich früher gehen musste, konnte ich die versprochenen Zertifikate „I survived the SAFe speed run“ doch nicht an die Teilnehmer verteilen – vielleicht das nächste Mal :-).

 

Bas Vodde zu Large-Scale Scrum (und SAFe)

Die Konferenz Adventures with Agile (AWA) fand vor kurzem in London statt. Einige interessant Vorträge sind via YouTube zugänglich, u.a. ein Vortrag von Donald Reinertsen sowie ein Vortrag von Bas Vodde, einem der beiden Autoren von LeSS.

Bas Vodde geht in seinem Vortrag auf die Entstehung und Grundsätze des Large-Scale Scrum (LeSS) ein. Personen die sich mit der Skalierbarkeit agiler Ansätze beschäftigen bekommen hierbei interessante Einblicke, wie LeSS bei Nokia Networks sich langsam herausgebildet hat.

Interessant ist, welche Grundzüge von LeSS Bas betont:

  • Bei der Produktentwicklung stets den Kunden bzw. den Kundennutzen im Auge behalten (customer centric whole product focus) und eben nicht abstrakte Prozesse- oder Systemlandschaften mit deren „Ownern“ befriedigen.
  • Die Bedeutung von Feature-Teams. Ohne Feature-Teams ist LeSS nicht möglich, da nur mit Feature-Teams Abhängigkeiten aufgelöst bzw. drastisch reduziert werden können.
  • Die Unterscheidung zwischen „Multi-Team Scrum“ (LeSS) und „Multiple Scrum-Team“ Ansätzen und die unterschiedliche Sichtweise auf die Skalierung von Scrum Praktiken.
  • Verlagerung von Verantwortung (und Entscheidungsbefugnissen) in das Team bzw. in die Teams. Damit geht einher, dass koordinierende Rollen abgeschafft werden. Für Koordination, Abstimmung und Klärung sind die Teams alleinig verantwortlich.
  • Der grundlegende Überzeugung „Less is More„: Durch konsequente Eliminierung von Prozesselementen (Rollen, Artefakte, Prozess-Schritten) wird Raum geschaffen für echte, für mehr Verbesserungen. Dahinter steckt das Zusammenspiel von übertragener Verantwortung und geschaffenem Gestaltungsspielraum durch konsequente Reduzierung von Vorgaben.

 

Im zweiten Teil wird „dem Elefanten im Raum“, dem Scaled Agile Framework (SAFe) einiges an Zeit eingeräumt. Bas erklärt, weshalb er Ansätze wie SAFe für schädlich für eine echte Agilisierung von Unternehmen hält. Im besten Fall wäre SAFe ein „workaround in a context where the real (hard) questions are not answered“. Hierbei bezieht er sich u.a. auf die Etablierung von Featureteams, die sich im Großen und Ganzen selbst organisieren können (Verantwortung übernehmen, Gestaltungsspielraum erhalten), was letztendlich dem Aufbrechen aller existierender Strukturen entspricht.

Diese Einschätzung wurde vor mehr als einem Jahr aus meinem LeSS Kurs auch durch Craig Larman vermittelt. Viele LeSS Praktiken oder Ideen können zunächst in einem „mäßigen“ Umfeld erfolgreich eingeführt werden. Ähnlich wie einer Scrum-Einführung im Kleinen, stößt man aber schnell an die Grenzen, falls die Trägerorganisation an ihren existierenden Strukturen und Rahmenbedingungen festhalten will.

Ein Muster, das sich übrigens auch in Larman’s Laws of Organizational Behavior wieder findet:

Larman’s Laws of Organizational Behaviour

  1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
  2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
  3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, „religion“, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
  4. Culture follows structure.

http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

 

Large-Scale Scrum Site available

During a presentation @ QS-Tag 2014 in Nuremberg this November I summarized Large-Scale Scrum / LeSS like that:

less-summary