Enabler Teams versus Community of Practise: Ein Erfahrungsbericht aus einer großen Bank 

In großen Organisationen mit mehreren Duzend bis mehreren hundert Entwicklern gibt es im Rahmen von agilen Transformationen sehr bald Fragen und Diskussionen über die richtige Skalierungsstrategie. Agiles arbeiten ist inzwischen in sehr vielen großen Organisationen angekommen. Allerdings haftete SCRUM – als der bedeutendste Vertreter der agilen Methoden – schon immer etwas der Makel an, diese Methode würde nicht gut skalieren. Der Vorwurf war vor 10 oder 15 Jahren vielleicht noch berechtigt, aber die Methode hat sich mit zunehmender Verbreitung weiterentwickelt und Skalierung ist heute dank den darüber liegenden Projektmanagement Ansätzen wie Nexus, LeSS oder SAFe – zumindest theoretisch – kein Problem mehr.

In der konkreten Praxis tun sich Organisationen aber oft noch schwer, was zum Teil daran liegt, dass es in dieser Praxis auch um Bereiche geht, die in den gerade zitierten Ansätzen gar nicht so explizit erfasst werden.  

Daher habe ich in diesem Artikel die Form eines Erfahrungsberichtes gewählt, der ein spezielles Problem behandelt:  

Wie arbeiten viele Teams an einer großen Software so zusammen, dass es keine Bottlenecks und wenig Abhängigkeiten gibt?  

Als Beispiel dienen meine Erfahrungen aus einer deutschen Großbank, in der viele Teams viele Frontend-Produkte parallel erstellt haben, die alle Services aus dem Core-Banking bidirektional nutzten.  

Das Problem

Die oben genannten Frontend ART’s verwendeten im Kern natürlich die klassischen Core-Banking Funktionen, z.B. zur Übertragung einer SEPA Transaktion oder das Abfragen meines Kontostandes oder meines Investmentportfolios, die natürlich in allen Frontends den Kunden oder Bankberatern zur Verfügung stand.  

Das Core-Banking System selbst wurde von nicht agil arbeitenden Teams betreut, ein Umstand, der vielen sicher auch nicht unbekannt sein dürfte und in großen Organisationen aus naheliegenden Gründen wohl immer noch und bestimmt noch eine ganze Weile die Realität beschreibt.  

Um die Zugriffe auf das Core-Banking System zu sichern, wurde eine spezielle API konzipiert mit der alle ART’s und natürlich auch das Core-Banking-System selbst kommunizierten. Also im Grunde ein klassischer und vernünftiger Architekturansatz. Genau so weit würden jetzt auch die Empfehlungen der agilen Projektmethoden wie SAFe & Co. gehen. Aber genau hier geht das Problem eigentlich erst los und dies muss in der Praxis gelöst werden.  

Die Frage ist: Wer stellt diese API so zur Verfügung, dass alle ART’s, die durch dieses Nadelöhr gehen müssen, dennoch mit vollem Schub, parallel zueinander und entsprechend ihrer individuellen Prioritäten, Zeitplänen, Kapazitäten ihre Features implementieren können?

Die Ansätze

Dazu wurden nun drei Ansätze diskutiert und wir haben uns schließlich für einen dieser Ansätze entschieden.  

Ansatz 1: Das Enabler Team 

Wer sich mit SAFe schon etwas vertraut gemacht hat, ist in jedem Fall dem Principle #1 begegnet: 

„Take an economic view“. D.h. etwas (zu) pauschalisiert ausgedrückt, „Business Value First“ (Herr Trump hat dieses Grundprinzip ebenfalls für sich entdeckt).  

Gleichzeitig hat SAFe die Notwendigkeit gesehen, dass wir bestimmte technische Voraussetzungen benötigen, um Business Value zu schaffen. Diese müssen geschaffen werden, auch wenn sie selbst keinen Business Value darstellen. Daher hat man sie „Enabler“ getauft. Sie ermöglichen Business Value, sind selbst aber keiner.  

Es ist schon sehr einsichtig, dass man nach Principle #1 also immer etwas argwöhnisch auf die Enabler schaut und diese nicht überhandnehmen sollten. Daher ist der Ansatz eines Enabler Teams – also nicht nur eine Enabler Story, sondern gleich ein ganzes Team – in jedem Fall kritisch zu hinterfragen.  

Das Enabler Team, sollte ein Team aus Spezialisten sein, welches die API zur Verfügung stellt, mit dem alle anderen ART’s dann arbeiten können.

Denn es ist natürlich klar, dass eine solche API in einer Organisation mit einem so sensiblen Geschäftszweck wie eine Großbank, ein neuralgischer Punkt ist; sowohl aus technischer- als auch aus Geschäftsperspektive (inklusive Datenschutz, Security, Fraudprotection, Compliance, etc.).  

Die Vorteile liegen zunächst auf der Hand:

• Ein hochspezialisiertes Team ist sehr leistungsfähig 
• Compliance bleibt durch dieses eine Team sehr gut gewahrt 
• Code wird nur einmal entwickelt und steht allen zur Verfügung 
• Einheitliche Code-Stile und damit gute Codequalität und Wartbarkeit 

Aber, ein solcher Ansatz birgt auch einige Risiken: 

• Die Organisation kann nur langsam skalieren.  
• Das Team muss intensiv mit allen ART’s kommunizieren, um deren Requirements herauszubekommen, was viel Overhead mit sich bringt 
• Individualisierung von Funktionen ist schwer möglich, z.B. könnte die mobile App aus Performance-Gründen auf viele für sie ohnehin nicht darstellbare Informationen verzichten wollen, oder sie brauchen einen speziellen Offline-Modus, die andere nicht brauchen  
• Die Priorisierung der Requirements wird schwierig, denn jeder ART sieht seine Requirements natürlich hoch priorisiert 

Das Abwägen von Vor- und Nachteilen macht natürlich nur vor dem Hintergrund von vernünftigen Alternativen Sinn. Da dieser Ansatz neben den offensichtlichen gewichtigen Vorteilen auch Nachteile hat und diese umso stärker zum Tragen kommen, je mehr das Unternehmen skaliert, hat man beschlossen, alternative Szenarien zu diskutieren.  

Nur um das Problem noch einmal einzuordnen: Der ART „mobile App“ ist gerade erst vor einigen Jahren hinzugekommen. Die Bank war mit dem Launch der mobile App so erfolgreich, dass sie ihren „mobile Moment“ schon nach 3 Jahren erlebten, also der Moment, in dem mehr Transaktionen über die App abgewickelt wurden, als über das Online-Banking. Und in dieser Zeit wurde auch das Online-Banking funktional immer mehr aufgewertet. Ohne diese beiden Entwicklungen-, bzw. vor diesen beiden Entwicklungen hatte sich die Frage nach einer Alternative zu einen Enabler Team gar nicht gestellt. Es ist also eine grundsätzliche Frage, sondern eine Frage, die bei sich ändernden Umständen erst entstehen kann.  

Ansatz 2: Community of Practice (CoP) 

Ich verwende den Begriff CoP hier zur Beschreibung eines alternativen Ansatzes, obwohl der Begriff hier vielleicht in seiner originären Bedeutung nicht so ganz korrekt ist. Aber er scheint mir sehr passend zu sein.  

Dieser zweite Ansatz wurde erarbeitet mit dem Ziel, die Vorteile des ersten Ansatzes nicht zu gefährden und gleichzeitig die Nachteile des zweiten Ansatzes zu überwinden. Daher werde ich hier nicht Vorteile und Nachteile gegenüberstellen, sondern den Ansatz beschreiben. Denn es kommt darauf an, ob es diesem Ansatz plausibel gelingt das Ziel zu erreichen. Dabei sollten natürlich keine neuen Risiken auftreten. Genau darauf sollte in einer Organisation, die sich für diesen Ansatz entscheidet, dann besonderes Augenmerk gelegt werden.  

Dieser Ansatz geht davon aus, dass es die gemeinsam genutzte API gibt und sie technisch in der Form existiert, wie sie auch im ersten Ansatz angelegt ist. Sie soll soweit wie möglich Funktionen nur einmal implementieren, aber eben auch Individualisierungen zulassen, wenn sie erforderlich sind. Sie soll ein hohes Maß an Compliance haben, also den Coderichtlinien, vorgegeben durch die Architekturorganisation entsprechen und damit natürlich auch allen Qualitätsstandards genügen.  

Und doch soll es möglich sein, dass die Organisation beliebig skalieren kann und damit die ART’s ihre eigenen Prioritäten setzen und entsprechend ihrer eigenen Kapazitäten Features implementieren können. Gleichzeitig – und das ist im agilen Projektmanagement eben auch ein sehr hohes Gut – sollen die ART’s ihre Selbstorganisation und den Aufbau von vertikalem (end-to-end) Domainwissen stärken können.  

Das sind zusammengenommen schon ziemlich hohe Ansprüche, die weit über das Technische hinausgehen. Daher ist die ganze Diskussion eben auch nicht nur von Architekten geführt worden, sondern von verschiedenen Vertretern der ganzen Organisation, unter anderem eben auch von den agile Coaches, die mit der SAFe Einführung betraut waren.  

Der Ansatz lehnt sich etwas an das „Open Source“ Modell an, denn Open-Source Software ist heute sehr verbreitet und hat seinen festen Platz in der Industrie gefunden. Fast alle Unternehmen haben damit nachhaltige Erfahrungen gesammelt und können auf diese nun zurückgreifen.  

Der Ansatz führt die Weiterentwicklung der API in die einzelnen ART’s und den darin beheimateten Scrum-Teams zurück. Damit ist es grundsätzlich jedem Team gestattet, Veränderungen an der API selbständig vorzunehmen. Einer größtmöglichen Skalierung steht damit nichts mehr im Wege. 

Aber natürlich birgt ein solcher Ansatz hinsichtlich Qualität, Sicherheit und Compliance sehr hohe Risiken, die dieser Ansatz adressieren muss! Denn nach wie vor gilt, dass die API wegen ihrer besonderen Bedeutung natürlich besonders geschützt werden muss.  

Dies sollte durch folgende Maßnahmen erreicht werden:  

1. alle Entwickler, die an dieser API arbeiten, müssen sich dafür speziell lizensieren lassen, also eine Art API-Fahrerlaubnis erlangen. Dazu mussten sie spezielle Kurse besuchen und tatsächlich eine Prüfung ablegen, in den sie nachweisen mussten, dass sie die Architektur ebenso verstanden haben, wie auch Kenntnisse über Compliance, Coderichtlinien etc. haben.  
2. Durch ein kleines Core-Team, welches aus Lead-Entwicklern und Architekten besteht, wird diese Lizensierung überwacht, es werden regelmäßig und stichprobenhaft Code-Reviews gemacht und eine Lizenz kann bei Verstößen auch wieder entzogen werden.  
3. Alle Entwickler, die an der API arbeiten dürfen, sind in einer Community of Practice zusammengeschlossen und treffen sich dort regelmäßig, um sich zu synchronisieren. Diese Treffen sind mit den Sprints der Teams synchronisiert, sodass alle Änderungen, die ein Team eines ART plant in der CoP noch reflektiert werden können. Damit bleibt die CoP jederzeit über alle geplanten Änderungen an der API informiert.  

Natürlich gelten auch hier die „best Practices“ einer DevOps Kultur bis hin zum Release on Demand, damit die einzelnen ART’s und Teams die von Ihnen entwickelte Funktionalität auch in ihren eigenverantwortlich festgelegten Release-Zyklen nutzen kann.  

Ansatz 3: Microservice Architektur 

Dieser Ansatz wurde sehr schnell wieder verworfen. Nicht, weil er nicht gut oder sinnvoll wäre, aber er war in diesem Setup praktisch nicht durchführbar. Trotzdem möchte ich diesen Ansatz als weitere Alternative kurz erwähnen, auch wenn wir mit diesem Ansatz leider keine praktischen Erfahrungen sammeln konnten.  

Der Ansatz sieht vor, dass es keine einheitliche API gibt, sondern jeder ART seine eigene Schnittstelle in das Core-Banking System entwickelt.  

Fazit 

Alle drei Ansätze haben ihren Platz in Organisationen. Man kann nicht per se sagen, welcher Ansatz zum Tragen kommen muss. Wir haben bei der Bank den zweiten Ansatz gewählt und damit gerade im Hinblick auf die bessere Skalierbarkeit der einzelnen ART große Fortschritte erzielt. Ich hätte gerne auch den dritten Ansatz ausprobiert, denn einiges spricht auch für diesen. Man sollte ihn in jedem Fall im Auge behalten und vielleicht noch detaillierter ausarbeiten, als ich es hier in diesem Artikel leisten kann.  

Was aber das Wichtigste ist, war die Erkenntnis, dass diese Frage auf keinen Fall nur technisch beantwortet werden soll. Die Antwort sollte immer auch im Kontext der Ziele der agilen Transformation stehen.

Man sollte sich wirklich die Mühe machen, einen Ansatz zu finden, der allen Zielen gerecht wird, zumindest sollten alle Perspektiven gleichmäßig beleuchtet werden.