“So funktioniert Scrum in der Praxis: Der Projektmanager wird der Scrum Master. Der Business Analyst wird zum Product Owner. Die Entwickler bleiben Entwickler, und die Tester sind in in der Qualitätssicherung. Das Backlog wird zu einer “storified” Version vom Requirements-Dokument. Es macht keinen Unterschied ob eine Story in einem 4-Wochen Sprint fertig wird oder nicht – weil es einen fixen Scope und Deadline gibt. Nach einigen Sprints und 6 Wochen vor dem Release gibt es einen Code Freeze und SIT / CAT machen Tests und fixen Bugs. Dann wird der neue Code veröffentlicht.”
Einem Scrum-Puristen stellt es bei dieser Darstellung die Haare auf. Das hat doch nichts mit Scrum zu tun, werden sie sagen. Wer das für Scrum hält macht grundsätzlich etwas falsch.
Jetzt schauen wir uns ein anderes Beispiel an.
“So funktioniert SAFe in der Praxis: Der Programm-Manager wird zum Produktmanager. Der Projektmanager wird zum Release Train Engineer. Die Product Owner sind glorifizierte Business-Analysten, die tun, was der Produktmanager sagt. Die bestehenden Plattform-Teams werden in Agile Teams umbenannt. Die Gruppen/Team-Leads werden zu Scrum-Mastern. Folgend arbeiten alle daran, den im Program Increment (PI) festgelegten Scope bis zum vierteljährlichen Release-Termin fertig zu stellen. Und so läuft das immer wieder ab.
Nicken Sie gerade zustimmend und meinen “Ja, das beschreibt SAFe perfekt!”? Es passt zu dem was Sie über SAFe wissen? Aber wenn Sie wirklich viel über SAFe wissen würden, dann wären Sie über diese Beschreibung erbost. Ähnlich der Beschreibung von Scrum eingangs in diesem Post besteht die einzige Gemeinsamkeit in der Verwendung bestimmter Schlüsselwörter. Nichts vom SAFe Spirit oder der Essenz von SAFe ist in der Beschreibung erkennbar.
Es ist jedoch nicht ungewöhnlich, dass diese Missverständnisse mit Hingabe herumgeworfen werden. “SAFe ist nicht agil, es ist nur ein überarbeitetes Waterfall-Konzept mit einer Prise agiler Begriffe”. Aber haben Sie SAFe in der Praxis gesehen? Können Sie das mit Ihrer Erfahrung bestätigen? Ich habe Scrum auch in der Praxis gesehen. Und es ist nicht immer schön. Eigentlich ist es oft nicht schön – es sieht oft aus wie Frankensteins Monster mit missverstandenen Konzepten und Praktiken.
Glücklicherweise beurteile ich Scrum nicht danach. Ich habe an Kursen teilgenommen, Bücher gelesen, in Scrum-Teams als Entwickler, Tester, Product Owner und Scrum Master gearbeitet. Ich kann den Unterschied zwischen echtem Scrum und dem halbherzigen Pseudo-Scrum, den das obere Management als agil präsentiert bekommt, erkennen.
Haben Sie sich eigentlich schon die Zeit genommen, SAFe genauer zu studieren? Hat Sie schon der Umfang des SAFe Big Picture allein überzeugt, dass SAFe schlecht sein muss? Haben Sie Bücher über SAFe gelesen oder einen Kurs besucht? Haben Sie es in seiner Tiefe wie XP, Scrum oder Kanban kennengelernt? Mit welchen anderen Business-Agilitäts-Frameworks haben Sie es verglichen?
Oder lassen Sie einfach nur Ihre Vorurteile und Selbstgerechtigkeit Ihre Meinung über SAFe bestimmen?
Lassen Sie sich nicht von SAFe kritischen Artikeln, die oft voll von Vorurteilen sind, blenden. Ich lade Sie ein SAFe kennenzulernen. Wir praktizieren SAFe in Kundenprojekten und laden Sie ein SAFe in unserem Leading SAFe Training kennenzulernen.
Eine englische Version dieses Artikels von mir finden Sie auch auf meinem LinkedIn Profil.
