SAFe ist wahrscheinlich auch das präskriptivste aller Skalierungs-Frameworks. Vielleicht ist das der Grund, warum viele große Unternehmen ihre Skalierungsreise mit SAFe beginnen. Wie bereits erwähnt, bedeutet das nicht unbedingt, dass SAFe das Skalierungsframework der Wahl sein sollte. Tatsächlich habe ich noch keine erfolgreiche SAFe-Implementierung gesehen.
Bei RedAgile als Audioversion.
Foto: DasScrumTeam
Oder SAFe…wow, geil. Der Blueprint für die gesamte Organisation. Einfach einmal einführen und Du bist agil oder, oder?
Nee, bist Du nicht!
Inspiriert durch den Artikel zu 10 Jahren von Nadelka, CEO von Microsoft:
Die amerikanische Psychologin Carol S. Dweck (* 1946) unterscheidet zwischen zwei Typen von Schülern: der erste hält Erfolg für eine Frage von Begabung, kann Fehler nicht aushalten und bricht, wenn der Erfolg ausbleibt, hilflos zusammen; der zweite orientiert sich am Aufgabenmeistern und hat die Überzeugung verinnerlicht, dass Erfolg hart erarbeitet werden muss. Wie in empirischen Studien nachgewiesen werden konnte, sind die Erfolgsaussichten des letztgenannten Typs wesentlich höher als die des ersteren.[2]
Bei Heise liest es sich wie folgt:
Nadella verordnete Managern und Mitarbeitern einen “Growth Mindset”. Das Konzept des Growth Mindset geht auf die amerikanische Psychologin Carol Dweck zurück, die über Schüler und ihre Einstellung zum Versagen forschte. Nach dieser Denkschule sind Fähigkeiten und Intelligenz erlernbar und Herausforderungen bieten Gelegenheit zu lernen. Menschen mit einem Growth Mindset bringen ein gehöriges Maß an Arbeit und Durchhaltevermögen auf, um ihre Fähigkeiten zu erweitern und ihre Ziele zu erreichen. Menschen mit einem “Fixed Mindset” hingegen meiden Aufgaben, die als zu groß empfunden werden, geben bei Schwierigkeiten auf und sehen Kritik als Bestätigung ihres Misserfolges.
Das ganze erinnert sehr stark an agiles Vorgehen, denn bei Scrum heißt:
Scrum basiert auf Empirie und Lean Thinking. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. Lean Thinking reduziert Verschwendung und fokussiert auf das Wesentliche.
In seinem Blogpost zeigt es Boris Gloger sehr deutlich: Scum adressiert nur die drei Rollen Developer, Product Owner und Scrum Master. Ein Business Analyst kommt darin nicht vor. Der kommmt aus Model-V bzw. dem bekannteren Wasserfall. Selbstredend kann ein oder mehrere Developer die gewünschten Fähigkeiten eines Business Analysten inne haben. Ein sehr häufig noch vorkommendens Mißverstädnis ist eben, dass Developer immer nur Softwareentwickler sind. Nein, es ist ein multifunktionales Team, das die Fähigkeiten vereint, um gemeinsam produktiv arbeiten zu können und Produkte abliefern zu können.
Das meint, es kann ein Scrum Team sein, dessen Developer folgender Berufsbildern entstammen: Kardiologen, Psychologen, Designer, Grafiker, Fronteendentwicker, Backendentwickler, Juristen, Datenschützer und die Person für den Klima- und Umweltschutz. Alle vereint, das next cutting edge think nach der Apple Watch zu erstellen (das Ding zum “Sehen” ist halt für den Massenmarkt überaus teuer und so werden keine nennenswerten Verkaufszahlen generiert).
Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles,
nützliches Increment zu schaffen. Scrum definiert drei spezifische Ergebnisverantwortlichkeiten
innerhalb des Scrum Teams: Developer:innen, Product Owner:in und Scrum Master:in
„There is no magic in SAFe …except maybe for PI Planning.”
Der Ausspruch von SAFe-Erfinder Dean Leffingwell
Das Sprint Review ist kein Abnahmemeeting!
