Intro⌗

Es war ein entspannter Abend. Eine lange Arbeitswoche lag hinter uns. Mit einem Drink in der Hand blickten wir von unseren Liegestühlen auf der Dachterrasse des Flughafens nicht nur auf einen wunderschönen Sonnenuntergang, sondern auch zurück auf ein perfekt gelaufenes PI-Planning. Das Produkt, so die Vorhersage, wird wohl doch schneller marktreif als gedacht. Jetzt noch schnell in den Flieger und die ganzen Annehmlichkeiten der First Class genießen, um morgen früh erholt die Familie wiederzusehen.

Dann klingelte Felipes[1] Telefon.

Zunächst mit sanfter Stimme antwortend, wurde Felipes Kopf zusehends röter. Beim Gang in eine abgelegte Ecke der Dachterrasse zeichneten sich deutlich seine Halsvenen ab. Erst als sich nach ein paar Minuten das Sicherheitspersonal auf ihn zubewegte, wurde sein Gebrüll ins Telefon von einem sachlichen „Talk to you tomorrow“ abgelöst, und er kehrte zurück.

Was war passiert?⌗

Einer der Release Train Engineers hatte offenbar in den PI-Plannings bewusst falsche Deliveries kommuniziert, übermäßig optimistische Schätzungen geliefert und Lieferausfälle verschwiegen, um einen Karrierevorteil zu erhaschen. Genauer nachgeforscht hatte sich gezeigt, dass selbst die Deliveries aus den ersten Sprints noch nicht funktionstauglich sind und APIs nicht funktionieren, was von den Teams wegen des Drucks vertuscht wurde. Tests gab es auch keine. Obwohl die Tests für die Zulassung gebraucht wurden, fanden sie sich weder in den Backlogs noch in den DoDs (Definition of Done). Mitten auf dem kritischen Pfad der Abhängigkeiten klaffte eine große schwere Planungswunde und ein tiefer Vertrauensverlust.

Für das PI-Planning wurden 40 (Teil-)ProductOwner, Produktmanager, Projektleiter, Architekten und Agile-Spezialisten über tausende Kilometer eingeflogen, um gemeinsam mit den Leuten vor Ort eine präzise Planung der nächsten drei Monate vorzunehmen. Reisekosten von über 100.000.-€ gesellten sich zu den ohnehin hohen Lohnkosten der Agile-Spezialisten und Managern. Ein Tiefschlag für jeden Budgetverantwortlichen.

Felipe tobte: „Dieser Agile-Mist ist eine großangelegte Verarsche, die Intransparenz und Unverbindlichkeit fördert. Beflügelt von Agile Coaches, die sich diese Projekt-Sabotage auch noch vergolden lassen“.

Aber warum konnte es so kommen?

Die Hintergründe⌗

Der Konzern haderte schon seit langem mit der Herausforderung, dass innovative neue Produkte zum Erhalt der Marktposition zwar gebraucht wurden, die Ideen aber nicht so wie erwartet sprudelten. Vor mehr als zehn Jahren wurde zögerlich und kaum sichtbar SCRUM[2] in den Entwicklungsteams eingeführt. Formell.

SCRUM per se war nie dafür gemacht, dass Ideen aus der Entwickler-Basis ihren Weg in ein Produktportfolio finden. Durch die Entscheidung für SCRUM wurde einem Handstreich die Innovationskraft der Mehrzahl der Ingenieure beerdigt und auf fachfremde Projektleiter und Manager übertragen, die sich eher entlang der -oft kaum verstandenen- Bedürfnisse der Kunden orientieren.

Disruptive Veränderung, die einen maßgeblichen Wettbewerbsvorteil bringt, ist im SCRUM-Kontext kaum möglich, obwohl Agilität genau mit dieser Maßgabe angetreten ist. So passiert bis heute Innovation im Digitalbereich fast ausschließlich durch Aufkauf von StartUps, deren Mitarbeiter im Rahmen des Kulturschocks nach der Acquisition das Weite suchen. Die SCRUM-Teams werden derweil durch Rituale abgelenkt und kleingehalten.

In einem Klima der Missgunst unter den Projektleitern entwickelte sich eine Fehlerkultur, die Passivität belohnte. Statt anzuerkennen, dass die Unverbindlichkeit von agilen Teams den Effekt noch verstärkte, wurden Agile Coaches gerufen, um dem Konzern endlich wieder innovative Produkte zu entlocken.

Jene Agile Coaches fanden aus ihrer oberflächlichen Perspektive eine perfekte Landschaft vor: Dutzende SCRUM-Teams, die alle besser zusammenarbeiten sollen. Auf Empfehlung der Agile Coaches wurde der gesamten Organisation SAFe (Scalable Agile Framework[3]) aufgedrückt.

Wofür SAFE gedacht war⌗

SAFe trat an, um in sehr komplexen Projekten sehr viele Entwicklern aus vielen unterschiedlichen Domänen zu koordinieren, und alle Abhängigkeiten zwischen Komponenten und Teams sichtbar werden zu lassen. Gleichzeitig sollten die Teams trotzdem agil arbeiten, also auch auf kurzfristige Veränderungen reagieren können. Dazu sollten sich die Repräsentanten der Teams regelmäßig zu Abhängigkeiten und der Planung absprechen, das in Form sogenannter „PI-Plannings“ passiert. Release-Train-Engineers stellen sicher, dass alle Schnittstellen, Deliveries und auch zeitlichen Abhängigkeiten identifiziert und schließlich auch umgesetzt werden. Nach den PI-Plannings ziehen sich die Teams mit ihren neuen Backlogs zurück und arbeiten im SCRUM-Modus die Pakete ab.

Was bei SAFE falsch lief⌗

Die Idee von SAFe ist dabei nicht grundsätzlich falsch. Wir alle wissen, dass Teamgrößen von jenseits 30 Leuten zusehends schlechter zusammenarbeiten, insbesondere wenn ihnen die falschen Regeln der Zusammenarbeit aufgedrückt werden.

SAFe geht leider davon aus, dass alle Beteiligten ehrlich und transparent fundierte Zusagen treffen und verlässliche Lieferzeitpunkte garantieren. In karriereorientierten Firmenkulturen sind Ehrlichkeit und Transparenz nicht sonderlich verbreitet, da das genaue Gegenteil zu Karrierevorteilen führt. Zu viele Projektleiter - neuerdings „Product Owner“- wollen ihr Management nicht enttäuschen, um doch noch die Leistungszulage zu bekommen. Auf falschen Annahmen wird also verdreht, getäuscht und belogen, dass sich die Balken biegen.

Zudem ist Softwareentwicklung eine kreative Tätigkeit, die -entgegen der Ansicht von Betriebswirten- nicht zeitlich deterministisch ist. Trotzdem werden konfliktscheue Entwickler ständig in die Enge getrieben, wenn es um Schätzungen geht. „Not acceptable“ lautet oft die unwirsche und zugleich beliebige Antwort des PO. Nach ein paar Zugeständnissen findet sich der Entwickler weitere Samstage und Sonntage am Rechner wieder, während sich seine Partnerin nach einem neuen Partner umschaut.

Einige Monate später wird der PO mit der Realität eines gescheiterten Projekts konfrontiert, während seine Entwickler sich als Gruppe in der Psychosomatischen Klinik bei der Bewältigung ihrer Burnout-Traumata wiedersehen.

Das System kann so nicht funktionieren. Es ist weder sinnvoll, noch ist es nachhaltig, menschlich oder ethisch vertretbar. Es ist krank.

Weg mit den ganzen Frameworks!⌗

So charmant und einfach die Agile-Frameworks daherkommen, umso mehr zeigen sie, wie leicht es einfache Lösungsvorschläge im Management haben, die sich nicht mit den Details der komplexen Realität beschäftigen wollen.

Die Realität ist immer komplex: Komplexe Produktideen treffen auf komplexe Individuen in der Entwicklung und Produktion, die das Produkt umsetzen sollen, zugleich aber einem komplexen Arbeitsmarkt voller Headhunter ausgesetzt sind. Zuletzt soll das Produkt auch noch auf einem komplexen Markt in einem komplexen Produktkontext überzeugend funktionieren.

Das einfache Anwenden von vorgefertigten Schablonen aus der Agilitätstrickkiste wird dieser Herausforderung nicht gerecht. Es bedarf einer genauen Analyse der alten Fehler und der Anforderungen an künftige Produktentwicklungsmodelle.

Weg mit den Fachfremden⌗

Angesprochen auf die Misstände, äußerten sich die meisten Entwickler einvernehmend: Fachfremde Leute sollten bitte nicht mehr reinquatschen, wie die Entwickler ihren Job zu erledigen hätten. Entwickler wissen am besten, wie sie zu gutem Code kommen. Da hilft es auch nichts, wenn sie täglich in einem als „StandUp“ getarnten Reporting Erfolge vortäuschen müssen, um nicht das Opfer von Micro-Management zu werden. Keine Quality-Manager, die noch nie Code gesehen haben. Keine Wirtschaftsinformatiker mehr, die einem die effiziente Produktion von Code erklären wollen, ohne je Code gesehen zu haben. Genauso wenig hilft es, in der Retro der anderen Abteilung bei ihren Problemchen zuhören zu müssen, wenn man selbst nichts davon versteht und es auch nicht interessiert.

Viel wichtiger wäre, wenn sich vorgelagerte Manager mal ordentlich Gedanken machen würden, wie denn nun die Produkte aussehen sollten. Statt jeden Tag eine neue Produktidee ausprobieren zu wollen, würde vielleicht mancher zusätzlicher Kunden- und Nutzerkontakt helfen. Oder man übergibt die Sache einfach mal Experten aus dem Feld der Usability oder Human Factors. Als Psychologen verstehen sie sozial-menschliche Zusammenhänge sowieso besser als ein Ingenieur, der durch Karriereambitionen in der Rolle des Projektleiters oder PO hängengeblieben ist. Stichwort: Peter-Prinzip[4].

Die Lösung: FCFS!⌗

Dementsprechend schaut die Lösung auch erschreckend einfach aus. Mein Kollege Mike L. [5] postulierte kürzlich das Prinzip der „Five cross-functional silos“ (FCFS). Fünf Bereiche, die ihre Arbeitsweise für sich selbst individuell organisieren, so wie es für die beteiligten Kollegen am besten funktioniert.

Ob sich im Silo dabei aus Versehen auf SCRUM-ähnliches Vorgehen geeinigt wird oder die Silos gänzlich andere Wege der produktiven Zusammenarbeit finden, bleibt den Silos überlassen. Jedes Silo handelt selbstverantwortlich. Jeder Themenbereich bleibt dabei in seiner Domäne. Niemand wird mit fachfremden Details der anderen Silos abgelenkt. Insbesondere werden die Silos nicht mehr von Agilisten genervt und von Reportingzwängen des Managements behelligt.

SAFe Silos

Das Management kippt ihre Produktidee in die Silos, die dann den für sich relevanten Teil herausarbeiten. Sowohl Architektur, Implementierung als auch Test wird den Fachexperten der Silos überlassen. Die nötigen Absprachen zwischen den Silos gestalten die Silos untereinander. Der Fokus liegt komplett auf Expertenarbeit in den jeweiligen Domänen.

Durch die individuelle Würdigung des Fachexpertentums und der individuellen Interaktion zwischen Silos passen die Schnittstellen zueinander, so dass die Integration nach Abschluss der Arbeiten in den Silos ein Kinderspiel ist. Die Rolle von Sales ist hier interessiert-wertschätzend und kreativ, statt wie früher als Hilfsarmee des fordernden Managements aufzutreten.

Fallstricke bei der Umsetzung⌗

Bei der Umsetzung des Prinzips der „Five cross-functional Silos“(FCFS) wird schnell Gegenwehr erkennbar. Agilität kennt den Begriff des „Waste“, der unnötigen und entbehrlichen Aktivitäten. Auch in der agilen Welt sollte Waste minimiert werden. Der Fokus sollte immer auf Wertschöpfung liegen. Doch seit der Einführung von SAFE und ähnlichen Frameworks kennt den Begriff scheinbar niemand mehr, und Waste wurde an vielen Stellen wieder Normalität.

Bei der Einführung der „Five cross-functional silos“ (FCFS) wird sehr schnell erkennbar, wie viele fachfremde Vollzeitposten sich in der Projektwelt eingenistet haben, ohne zur Wertschöpfung beizutragen. Insbesondere wird erkennbar, dass von den Release Train Engineers bis hinauf ins Management SAFe als Vorwand für die eigene Unentbehrlichkeit ohne erkennbarem Wertschöpfungsbeitrag genutzt wurde.

Mit den „Five cross-functional silos“ (FCFS) wird hier endlich aufgeräumt. Es wird klar erkennbar, dass eine Vielzahl an Vollzeitstellen in Wahrheit die Motivation der Wertschöpfenden beschädigt und die Produktivität stranguliert haben. Es ist nicht der Fehler der Entwickler, dass sich viel zu lange die Falschen Leute in Projekten mitfüttern ließen.

Fazit⌗

SAFe und andere agilen Frameworks sind vorgefertigte realitätsferne Prozessschablonen, die Intransparenz und Frustration fördern. Statt Lösungen, die die Individuen in ihrer Wertschöpfung würdigen, nisten mit SAFe fachfremde produktivitätshemmende Störer im System.

Mit einem konsequenten Fokus auf die Fachexpertise gibt es mit den „Five cross-functional silos“ (FCFS) einen Ansatz, in dem endlich wieder Produktivität und Exzellenz im Mittelpunkt steht. Alle Entwickler sind es leid, sich von technisch minderqualifizierten Managern, Agilisten und Leuten aus anderen Domänen reinquatschen zu lassen. Mit „Five cross-functional silos“ (FCFS) können Entwickler sich endlich wieder auf komplizierte Algorithmen, Innovation und Problemlösungen konzentrieren.

Und: Für diejenigen, für die „Five cross-functional silos“ (FCFS) zu sperrig ist: FCFS kann auch „Fair Coding For Software developers“ bedeuten. Und das wird es am Ende auch sein.