Wenn Organisationen sich in eine agile Transformation begeben, werden sie an irgendeinem Punkt über das Bilden von agilen Teams nachdenken müssen. Dabei kann die Ausgangslage in einzelnen Unternehmen oder IT-Abteilungen recht unterschiedlich sein und die Frage, wie sich die agilen Teams zusammensetzen und wie sie zueinander stehen kann dann schon zu einer kniffligen Herausforderung werden.

Ich werde also oft gefragt, wie die Organisation, in der ja teilweise sehr viele Teams arbeiten, sich mit diesen Teams aufstellen soll. Meine Empfehlung hier ist, dass eine Organisation sich daran orientiert, was stabil ist. Denn man möchte ja nicht ständig seine Organisation strukturell umbauen, weil einige Gegebenheiten sich geändert haben. Aber was ist schon in unserer Welt stabil. Das hat sich in den letzten Jahren teilweise und zur Überraschung Einiger ziemlich verändert.

Früher waren die Technologien noch recht stabil!

Agile Transformation

Demzufolge gab es Frontend-Abteilungen, Backend-Abteilungen, Testfactories, Datenbank-Teams, UI/UX-Teams, etc. Oft waren das gar keine Teams, sondern ganze Abteilungen. So kann man natürlich schlecht cross-funktional arbeiten. Und die Technologien ändern sich ständig, gestern Struts, heute Angular oder React, morgen vue.js, gestern manuelle Tests, heute Testautomation, gestern native iOS und Android, heute React Native und Progressive Webapps, und so weiter.

Auch die Themen, selbst die Großen, ändern sich natürlich ständig. DSGVO Initiativen, große Migrationen, bei einer Bank die Einführung von mobile Payment, bei einer Airline die Einführung neuer Buchungsklassen, usw.

Und schließlich ändern sich die Menschen ebenfalls, die Fluktuation ist größer geworden, der Einsatz von Offshore/Nearshore Teams für Organisationen interessanter, viele arbeiten mit externen Freelancern oder mit Dienstleistern.

Diese Orchestrierung lässt sich am Einfachsten in Verticals gestalten und bevor ich darauf eingehe, wie sich das machen lässt, reflektieren wir noch einmal den Unterschied zwischen horizontalen- und vertikalen Organisationen. Denn die Versuchung ist groß, bei der Bildung von Teams das altbewährte horizontale Muster zu verwenden und ebenso groß ist später die Enttäuschung, wenn der „agile Effekt“ dann ausbleibt.

Scrum Sprint: Warum 1 Woche effektiver ist

Horizontale Organisation

Eine horizontale Organisationsstruktur entspricht den klassischen Projektmethoden und damit auch den klassischen Implementierungsmethoden (Wasserfall).

Sie ist sehr auf effizientes Arbeiten (Maximierung der Arbeitsteilung) ausgelegt und benötigt daher bestimmte Voraussetzungen, insbesondere hinreichende Spezifikationen, die eine vollständige Planung des Prozesses gewährleisten, Stabilität der Anforderungen über einen längeren Produktzyklus hinweg, stabile Expertenteams, usw. Voraussetzungen, die heute wegen kürzeren Time-to-Market Zyklen, Risiken durch desruptive Technologien, gestiegener Komplexität der Anwendungen, etc. im Grunde so nicht mehr gegeben sind.

Horizontale Teams organisieren sich entlang von Funktionen (nicht Funktionalität) oder auch Technologien. Funktionen wären z.B. die oben bereits erwähnten Operations-Team, Test-Factory, Backend-Teams usw.. Technologien wären z.B. .Net Team, iOS Team / Android Team, etc. Die Charakteristik ist immer die Gleiche. Solche Teams sind Gruppen von Experten für bestimmte Funktionen oder Technologien, die hocheffizient die Teile des Produktes betreuen für die ihre Skills spezialisiert sind.

Bezogen auf das Produkt sind sie nicht unabhängig, bezogen auf ihre Funktion oder Technologie schon. Ihnen fällt es zB. leicht, neue Experten in ihren Reihen auszubilden. Eine Gesamtsicht auf das Produkt oder eine end-to-end Sicht auf Teile des Produktes haben sie allerdings nicht, sie kennen immer nur einen Ausschnitt einer Wertschöpfungskette.

Vertikale Organisation

In einer vertikalen Organisation orientieren sich die Teams wie oben schon angesprochen an bestimmten Wertschöpfungsketten. Damit werden die Teams notwendig cross-funktional, sie vereinen alle Skills, die notwendig sind Features einer Wertschöpfungskette zu implementieren.

Vertikale Organisationen versuchen, effektiv zu sein (Maximierung der Fokussierung auf ein Thema) und der wichtigste Effekt ist, Commitmentfähigkeit herzustellen, wenn die Voraussetzungen für effizientes Arbeiten nicht mehr uneingeschränkt vorliegen.

Dadurch soll eine Organisation flexibler werden, denn neue Anforderungen (Themen) können schneller analysiert und bewertet werden, da vertikale (cross-funktionale) Teams einen besseren Überblick über die fachliche end-to-end Architektur des Produktes haben. Die Teams arbeiten in Bezug auf das Produkt unabhängig, da sie einen bestimmten Bereich des Produktes end-to-end verantworten.

Die Etablierung einer starken DevOps-Kultur, eines der wichtigen Ziele einer agilen Transformation, ist ohne die Einführung von crossfunktionalen Teams kaum denkbar. Technologisch müssen die Nachteile, die sich daraus natürlich auch ergeben durch unterstützende horizontale Strukturen ausgeglichen werden (CoP, Gilden, Workgroups), was zeigt, dass vertikale Organisationen nicht nur und uneingeschränkt Vorteile haben. Sie sind vielmehr eine Reaktion auf die oben genannten veränderten Umstände.

Cross-funktionale Teams in Verticals

Vertikal orientierte Organisationen bilden also gerne cross-funktionale Teams heraus.

Damit ist für viele Organisationen der Fall bereits erledigt, aber das ganz oben beschriebene Problem löst sich damit aber leider noch nicht in Luft aus. Das Problem war, wie Organisationen mit vielen hundert Mitarbeitern, diese cross-funktionalen Teams orchestrieren. Die Antwort ist natürlich naheliegend und leicht zu erraten: vertikal. Und doch ist das in der Praxis gar nicht so leicht zu bewerkstelligen. Ganz besonders dann nicht, wenn es sich bei dem Produkt um eine große monolithische Anwendung handelt, also ein Build mit vielen Millionen Zeilen Code. Denn nur, wenn eine Organisation sich agil aufstellt, wird damit nicht auch gleich ein komplettes Redesign des Monolithen in z.B. Microservices erfolgen können.

Der richtige Zuschnitt sollte also in mehreren Phasen erfolgen und es sollten dabei möglichst viele Akteure der Organisation eingebunden werden. Meine Empfehlung wären folgende Schritte

Scrum goes Hollywood – Über Kommunikation in Scrum

Roadmap für vertikale Transformation

Schritt 1A: Definition funktionaler Gruppen

Im ersten Schritt muss evaluiert werden, ob das Einrichte von Verticals über das System überhaupt möglich ist. Es geht zunächst darum, funktionale Gruppen zu identifizieren. Es geht in diesem Schritt explizit noch nicht darum, schon zu sehen, ob diese funktionalen Gruppen auch in technisch unabhängige Ergebnistypen zu schneiden sind. Es soll in diesem Schritt eine rein funktionale Perspektive eingenommen werden, die möglichst unabhängig von allen technischen Zwängen und Erwägungen eingenommen werden kann.

Da dieser Schritt für den gesamten Prozess fundamental ist, sollten hier möglichst viele Teile der Organisation eingebunden werden. Die Hauptrolle sollten die Business Analysten der Organisation spielen, denn sie sollten die fachliche Architektur der Anwendung am besten kennen und sämtliche darin implementierte Geschäftsprozesse am besten beschreiben können. Vorstellbar wäre, dass zunächst eine Liste mit allen Geschäftsprozessen erstellt wird und diese in einem zweiten Schritt sinnvoll gruppiert werden. Die Anzahl der Gruppen spielt dabei zunächst noch keine Rolle, denn die Gruppen können später weiter aggregiert werden.

Schritt 1B: Analyse der technischen Architektur

Auch wenn die Hauptanalyse im Schritt 1 aus einer funktionalen Perspektive betrieben werden sollte, kann parallel und zunächst unabhängig davon auch eine Analyse der Architektur erfolgen. Selbst für einen gewachsenen Monolithen sollte mal analysiert werden, ob sich in der Architektur nicht auch Objektgruppen identifizieren lassen, die selbst in der bestehenden monolithischen Architektur nicht besser gekapselt werden können. Zweitens sollte analysiert werden, wie aktuell die Skill- und Arbeitsstruktur der Softwareentwickler aussieht, wer ist worauf spezialisiert und beschäftigt sich schwerpunktmäßig mit welchen Themen. Auch daraus lassen sich Rückschlüsse für etwaige Verticals schließen, zumindest werden solche Informationen für die Diskussionen in den Folgeschnitten dringend benötigt, um später einen Konsens zu finden.

Schritt 2: Erster Entwurf für Verticals

Die Idee ist, ähnliche Geschäftsprozess, bzw. Geschäftsprozesse, die in einer sehr engen Wechselwirkung stehen, zu einem Vertical zusammenzufassen. Diese Verticals sollen später in die Verantwortung von einer Gruppe von Menschen kommen, die sich in einem oder in mehrere kleine cross-funktionale Teams organisieren (in SAFe nennt sich das ein ART-Agile Release Train). Diese Verticals können natürlich unterschiedlich groß sein, und je nach anstehenden Themen, können sie auch unterschiedlich skalieren. Es wäre natürlich empfehlenswert, die Verticals so zu setzen, dass

–        Die Verticals perspektivisch einigermaßen Stabil sind

–        Die Hauptgeschäftsprozesse gut repräsentieren und der Organisation damit vertraut werden

–        Die meisten anstehenden Themen (Anforderungen) klar einem Vertical zuzuordnen sind

Schritt 3: Überprüfung der Verticals

Wenn die Verticals vorläufig und aus funktionaler Perspektive gebildet wurden, sollte eine Validierung innerhalb verschiedener Teile der Organisation erfolgen. Die Verticals werden die Heimat von Teams und Teammitglieder werden. Sie werden aber auch gleichzeitig strukturierender Gegenstand der Kommunikation in der Organisation werden, weshalb sie eben möglichst stabil sein sollten. Sie werden dabei als Referenz für die Anforderungsanalyse, mithin den gesamten Demandmanagementprozess gesehen und es werden viele KPI‘s auf ihnen abgebildet. Daher braucht es einen breiten Konsens in der Organisation. Und perspektivisch sollen sie auch technisch unabhängiger werden, weshalb auch die Architekten und IT-Ingenieure einen Blick darauf werfen müssen. Gegebenenfalls sollten in diesem Schritt die Verticals noch mal justiert werden.

Schritt 4: Zuordnung der Teams zu den Verticals

Nachdem die Verticals nun definiert sind, sollten die Teams zu den Verticals zugeordnet werden. Dafür gibt es natürlich verschiedene Verfahren, Mitarbeiter dürfen sich auf Verticals bewerben oder sie werden administrativ bestimmt, oder wie auch immer. Ersteres würde natürlich auf das Commitment der Mitglieder einzahlen, aber auch für die anderen Varianten kann es Gründe geben. In jedem Fall sollten die Teams dann einem echten agilen Muster entsprechen, d.h. sie sollen cross-funktional sein, nicht mehr als 9 Mitglieder haben, denen ein Product Owner und ein Scrum Master zur Seite stehen

Schritt 5: Arbeitsfähigkeit der Verticals herstellen

Mit der Definition und Einrichtung der Verticals ist noch nicht alles getan. Jetzt müssen die Verticals arbeitsfähig werden. Dabei sind noch einige Punkte zu überdenken und einzurichten. Welche genau das sind, sollte eine Analyse in Phase 3 ergeben. Grundsätzlich sollten aber folgende Fragen geklärt werden: – Hat ein Vertical einen Business Owner (oder Chief PO, oder wie auch immer er genannt wird)? Meine Empfehlung: Ja – Wie wird mit den noch immer vorhandenen technischen Abhängigkeiten der technischen Artefakte umgegangen? Meine Empfehlung: Es sollte aus jedem Vertical eine Empfehlung für eine Roadmap der Herauslösung von Ergebnistypen für ihre funktionalen Einheiten erstellt werden – Wie sieht künftig der Demandmanagementprozess aus und wie können die Verticals hier effektiv eingebunden werden?

Weitere Fragen können natürlich beliebig hinzukommen. Aber dann kann es schon mal losgehen. Der ART sollte regelmäßig während der ersten PI Plannings den Zuschnitt diskutieren und eventuell justieren, bis die Stabilität gefunden ist und alle Teams effektiv mit der Organisation zusammenarbeiten können.

Scrum Velocity berechnen

Case Study: Einführung von Verticals bei in einer Bank für die mobile App Teams

1.Ausgangssituation

In der Digital Factory der Bank wird mit ca. 80 bis 100 Mitarbeitern (davon 90% Externe) unter anderen die Mobile Banking App entwickelt. Diese ist im Backend am Core-Banking System angeschlossen und implementiert wesentlich UseCases, die auch im Online-Banking App oder im Filialbanking abgebildet sind. Daraus ergaben sich große technische und fachliche Abhängigkeiten in andere Systeme (z.B. technisch ins Core-Banking, fachlich ins Online-Banking). Zudem verteilte sich die mobile App auf zwei Plattformen (iOS, Android), es gab also zwei technische Versionen. Der ART (Agile Release Train) „Mobile“ hatte sich wesentlich horizontal organisiert, d.h. es gab separate iOS-Teams, Android-Teams, Test-Teams, Infrastruktur Teams, Backend-Teams, System-Teams, UI/UX Teams. Dies führte zu großen Problemen in Bezug auf Performance, Abhängigkeiten, Production Awareness und Produktionsbetreuung, Release Planung und Qualität und Prognosefähigkeit für weitere große Features (z.B. DSGVO, ApplePay Einführung).

2.Ziele

Die Einführung von Verticals sollte wesentlich folgende Probleme lösen:

• Die Abhängigkeiten zwischen den ART Teams sollte reduziert werden, in dem Teams vertikale Verantwortung übernehmen können und Features selbständig und unabhängig end-to-end und plattformübergreifend implementieren können
• Trotz vieler Externer Mitarbeiter (hohe Fluktuation) sollte in den Teams ausreichend Domainwissen aufgebaut werden, um kritische Bugs oder neue Funktionalität schneller bewerten zu können sowie das Onboarding neuer Mitarbeiter sollte erleichtert werden

Durch die Crossfunktionalität der Teams in den Verticals sollte das agile Mindset gestärkt werden, d.h. Teams sollten mehr selbstorganisiert und selbstverantwortlich arbeiten können

3.Implementierung

In einer ersten Phase wurde quer durch den ART mit allen maßgeblichen Beteiligten (Business Analysten, Architekten, Management, Agile Master) versucht, Verticals zu definieren, die sowohl technisch machbar, vor allem aber funktional sinnvoll sind. Diese Definitionsphase hat ca. 6 Wochen gebraucht, bis ein tragfähiger Kompromiss gefunden wurde. Es wurden drei Verticals definiert:

• SEPA Transaktionen: Alle klassischen Banking Funktionen (Kontoführung, Überweisung, etc.)
• Investment: Alle Funktionen rund um Investmentportfolios
• Services: Alle Funktionen, die sich mit allgemeinen Services beschäftigen (Passwort Änderung, Adressänderung, Settings, Authentifizierung, etc.)

Natürlich gab es weiterhin Abhängigkeiten zwischen den Verticals, vor allem zwischen SEPA und Services bzw. Investment und Services, die sowohl funktionaler-, als auch technischer Natur waren. Ein enger Austausch der PO’s zwischen den Verticals musste also sichergestellt sein (Cross-Team Refinements, PI Plannings, etc.). Auch gab es natürlich Anforderungen (z.B. DSGVO), die gleichzeitig alle Verticals betrafen.

Im zweiten Schritt wurden die cross-funktionalen Teams gebildet. Cross-funktional bezog sich auf die Umsetzung der in einem Team vorgesehenen UserStorys. Jedes Vertical bestand aus 2 bis 4 Teams mit jeweils max. 9 Mitgliedern. Jedes Team hatte sowohl iOS, als auch Android Entwickler, Backend Entwickler, Tester.

Auf ART Ebene, also außerhalb der Teams existierte ein vorgelagertes „Ideation Team“ (Business Analysten), die die Themen der kommenden Etappen aufbereitet haben und gemeinsam mit den PO’s der Teams das nächste PI Planning vorbereitet haben (Epics). Dadurch wurden die PI Plannings wesentlich effektiver und die Teams waren aufkommende Themen besser vorbereitet, was dazu führte, dass die Themen schneller umgesetzt werden konnten, insbesondere aber im PI Planning bereits geschätzt waren, sodass das Management eine klare Priorisierung vornehmen konnte.

Im dritten Schritt wurde das Setup in einer Etappe verprobt. Insbesondere sollte herausgefunden werden, wie die Cross-funktionalität der Teams funktioniert.

Ist es besser im Vertical ein Team mit gemischten iOS und Android Entwickler zu haben, oder ein iOS Team und ein Android Team? Wie werden Architekten aus der Organisationsebene eingebunden? Wie werden Abhängigkeiten zwischen den Teams aufgelöst? Wie werden horizontale Strukturen in Form von CoP’s und Gilden funktionieren?

Die Ergebnisse wurden in jedem PI Planning thematisiert, es gab im PI Planning neben fachlichen Themen vor allem auch Themen, die das Agile Setup betreffen, Infrastruktur-Themen, HR-Themen, etc.