Eine Alternative zu SAFe, die Teams selbst gestalten können

Beim Scaled Agile Framework (kurz SAFe) scheiden sich die Geister. Einige sehen es als Hilfe für große Unternehmen. Für andere hat SAFe gar nichts mit Agilität zu tun. Es gibt andere Strukturmodelle wie Scrum @ Scale, Scaled Professional Scrum (Nexus), LeSS oder DAD. Aber es gibt einen viel einfacheren Weg zur Skalierung, den Teams selbst steuern können.

Im Lean Coffee am 05.07.2022 hatten wir eine schöne Diskussion über die Alternative zu SAFe. Danke Doris für dieses Thema.

SAFe ist schwierig

Ich finde SAFe toll. Es macht einen Vorschlag, wie die Geschäftsführung eines Unternehmens Geld und Zeit einsetzen will, um die Ziele des Unternehmens zu erreichen. Ich mag auch das PI-Planning, bei wirklich alle Beteiligten mal im Quartal zusammenkommen, um die weitere Planung abzustimmen.

Ich finde SAFe schrecklich, weil eine Organisation nur mit sich selbst beschäftigt ist. SAFe macht viele Menschen richtig unglücklich. (Doris hat dazu etwas in diesem Beitrag geschrieben. /1/)

Ich habe für mich das Fazit gezogen, dass ich in keine SAFe-Projekte hineingezogen werden möchte.

Warum SAFe so verlockend ist

Ich habe einige Leute getroffen, die sich stark für Strukturen machen, wie SAFe sie vorschlägt. Sie argumentieren, dass ihre Produkte so komplex sind und dass man viele Spezialisten braucht, um etwas zu bauen. Diese Leute brauchen eine Struktur. SAFe macht hier ein Angebot. Für viele Manager bietet SAFe eine Lösung, die zur Komplexität des Produktes passt.

Und hier liegt der Ansatz zur Lösung ohne SAFe.

Wir brauchen mehr Experten

Große Unternehmen unterhalten komplizierte Strukturen, weil sie zu wenig Spezialisten haben. Um die Struktur vom Bauen zu trennen, brauchen wir mehr Experten.

Die Teammitglieder können anfangen, sich gegenseitig auszubilden. Der Aufwand ist nicht höher als der, sich mit SAFe herumzuschlagen. Diese Verantwortung liegt bei den Teams. Mit dem Buch Toyota Talent gibt es ausreichend Anleitung, wie man so etwas organisiert. /2/

Expertise aufbauen braucht Zeit. Aber ich stimme nicht der Aussage zu, dass es ohne hochspezialisierte Leute nicht geht. Denn dies würde ja bedeuten, dass man keine neuen Leute ausbilden kann, dass niemals Fehler auftreten und dass man niemals Projekte gemeinsam machen kann. Für mich ist das eine Ausrede, eine Schutzbehauptung, nichts ändern zu wollen.

Bild von Diggity Marketing auf Pixabay

Wir brauchen mehr Automatisierung und Unterstützung beim Bauen

SAFe (und ähnliche Strukturen) argumentieren, dass ein Team allein nichts bauen kann. Warum muss das so bleiben? Mit Continuous Delivery und DevOps gibt es praktische Anleitungen, um das Bauen zu automatisieren. /3, 4/

Auch hier können sich die Teams im Rahmen von regelmäßigen Open Spaces zusammentun. Sie können die Hindernisse herausfinden und Lösungen entwickeln. Ziel muss sein, dass jedes Team autark neue Features hinzufügen kann.

Damit wir nicht auf komplizierte Strukturen von SAFe angewiesen sind brauchen wir also 2 Dinge:

Wir bilden uns in den Unternehmen viel stärker gegenseitig aus, damit wir nicht von einzelnen Spezialisten abhängig sind.
Wir automatisieren das Bauen, damit jedes Team autark ausliefern kann.

Ziel sind kleine, autonome, interdisziplinäre Teams.

Jetzt muss die Organisation noch klären, an welchen Themen sie arbeiten will. Dazu gibt es neben SAFe auch andere Ideen: Flightlevel, Executive MetaScrum, Hoshin Kanri, OKRs. Ich finde für solche Klärungen auch Open Spaces gut.

Literatur

/1/ Doris Weißgerber: Safe mit SAFe?, Teamworkblog, erschienen am 17. Mrz 2022, abrufbar unter https://www.teamworkblog.de/2022/03/safe-mit-safe.html
/2/ Liker, Jeffrey K. ; Meier, David: Toyota Talent : Developing Your People the Toyota Way. Madison: McGraw Hill Professional, 2007. Deutsche Ausgabe: Liker, Jeffrey K. ; Meier, David P.: Toyota Talent : Erfolgsfaktor Mitarbeiter - wie man das Potenzial seiner Angestellten entdeckt und fördert. M: FinanzBuch, 2007.
/3/ Humble, Jez ; Farley, David: Continuous Delivery : Reliable Software Releases through Build, Test, and Deployment Automation. Amsterdam: Pearson Education, 2010.
/4/ Kim, Gene ; Debois, Patrick ; Humble, Jez ; Forsgren, Nicole ; technology), John Willis (Writer on information: The DevOps Handbook, Second Edition : How to Create World-Class Speed, Reliability, and Security in Technology Organizations. Portland, Oregon: It Revolution Press, 2021.

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Erfahrung mit Vibe-Coding - und warum das keine Teamprobleme löst

Die KI-Werkzeuge zum Erstellen von Werkzeugen für die tägliche Arbeit werden immer besser. Die selbstgestrickten Tools erleichtern die eigene Arbeit. Aber für den Einsatz im Team fehlt noch etwas.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Wenn Leisten Leistung kostet

Immer. Immer "on". Immer mehr. Immer schneller. Und natürlich: Immer besser. Das ist die Welt, in der wir heute leben. Eine Welt der Dauerleistung. Und die hat ihren Preis: Wir werden schwächer. Sofern wir nicht die Grundlagen guten (Selbst-)Managements beherzigen und Pausen machen. Also zur richten Zeit das wirklich Wichtige tun.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen.

A shared file storage is not a library

In over 90% of cases where we advise organizations on filing systems, we find that they are organized by topic. This system quickly leads to chaos because outdated documents are not disposed of quickly enough. So why does everyone think to structure their filing system by topic? I believe we have the wrong idea.

From False Starts to Precision Landing: The Evolution of Requirements Management

Requirements management originated in U.S. rocket programs between 1945 and 1970. A small management trick contributed to the success of the Apollo program.

Wie läuft ein Projekt zum Entwickeln von Szenarien ab?

Seit 2016 beschäftigen Edgar und ich uns intensiv mit der Szenariotechnik. Szenarien sind ein wirkungsvolles Werkzeug, um Projekte oder ganze Geschäftsmodelle auf ihre Zukunftstauglichkeit zu testen.

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Das Teamwork-Blog

Dieses Blog durchsuchen