„Agile Kultur”
Wesentliche Elemente der „agilen Kultur” (vgl. Kap. 08A03) werden praktiziert, insbesondere:

Craftsmanship und Clean Code
Craftsmanship (SW-Entwicklung als professionelles Handwerk) (vgl. Kapitel 08A02, 7.4.2) ist etabliert, insbesondere:

Langlebige Wertströme …
„Value Streams” sind langlebige Wertströme zur Erzielung eines wirtschaftlichen Nutzens. Sie umfassen die Gesamtheit aller Anforderungen, Systemdefinitionen und Entwicklungs- und Auslieferungsschritte, die dazu dienen, für ein bestimmtes Geschäftsthema (z. B. ein spezifisches Segment des Versicherungsgeschäfts) ein integriertes System zu realisieren und zu warten, das dem Unternehmen, einem bestimmten Kunden/Kundenkreis und den Nutzern einen zeitlich unbegrenzten Fluss von Mehrwert bietet (s. „Value Streams” in [1]).

Ich benutze hier und im Folgenden das SAFe (s. Kap. 08S01, 3.3.3) als Illustration für ein agiles Framework der SW-Entwicklung, das auch das Programm- und Portfoliomanagement umfasst. Es ist dem Leser überlassen, was davon er in seinem Kontext nutzen möchte.

… statt nur einzelner Projekte
„Value Streams” sind keine einzelnen – stets zeitlich begrenzten – Projekte. Bestimmte Entwicklungs- und Auslieferungsschritte (etwa zur Neuentwicklung von Teilen des integrierten Systems) können jedoch als Projekte innerhalb eines Value Stream angesiedelt und abgewickelt werden.

Value Streams und Portfoliomanagement
Value Streams sind abgeleitet aus und verbunden mit den längerfristigen und umfassenden strategischen Themen und Initiativen des unternehmensweiten Portfoliomanagements.

Die bisherige Form des Portfoliomanagements kann jetzt noch beibehalten werden. In der Regel ist dies auf die Budgetierungsperiode für ein ganzes Geschäftsjahr angelegt und daher nicht sehr flexibel. Es kann in einem späteren Schritt flexibilisiert werden. Allerdings:

ART als Rückgrat der SW-Entwicklung
Ein „Agile Release Train” (s. „Agile Release Train” in [1]) ist das Gefäß für die sich selbst managende Gemeinschaft all jener Teams, die Beiträge für einen bestimmten Value Stream leisten. Agile Release Trains (ARTs) sind das Rückgrat der agilen SW-Entwicklung umfassender Lösungen unter Beteiligung von hundert bis mehreren tausend Personen. Jeder ART ist ein organisatorisches Konstrukt zum kontinuierlichen Schaffen (Definieren, Entwickeln, Ausliefern, Warten) von Geschäftswert für einen Value Stream und ermöglicht die Ausrichtung aller zu ihm gehörenden Teams auf gemeinsame Ziele und das Management der Abhängigkeiten zwischen den Teams durch die Teams selbst.

Im Zug sitzen alle beteiligten Teams
Die zu einem ART beitragenden Teams umfassen typischerweise insgesamt 50 bis 100 Personen. Bei mehr als 150 Personen (entsprechend der Dunbar-Zahl, das ist die maximale Anzahl Personen, mit denen eine Einzelperson soziale Beziehungen pflegen kann) muss der Value Stream thematisch so unterteilt werden, dass sich dann mehrere ARTs bilden lassen.

In Unternehmen mit weniger als 100 Entwicklern sollten einzelne ARTs nicht weniger als je drei Teams (insgesamt etwa 20 Personen) umfassen. In Unternehmen mit weniger als etwa 25 Entwicklern können alle einen einzigen ART bilden, aber nur dann, wenn sie gemeinsam an einem einzigen funktionalen Themenbereich (einem Value Stream) arbeiten.

Keine übergreifenden Teams!
Entwicklungsteams müssen so gebildet sein, dass jedes Team Beiträge nur für einen einzigen ART leistet. Innerhalb jedes ART (und nicht ART-übergreifend!) gibt es ein „Deployment Operations Team” (s. „DevOps” in [1]).

Releases =Haltestellen des ART
Die Teams, die im selben ART, also „im selben Zug”, sitzen, sind auf ein gemeinsames Ziel und einen gemeinsamen Zeitplan und Lieferrhythmus auf der Basis von Releases – die Haltestellen des ART – ausgerichtet und unterstützen so den gleichmäßigen Fluss der Produktentwicklung.

Können alle Teams zu 100 % einem und nur einem ART zugeordnet werden?

Können die Teams innerhalb eines ART möglichst unabhängig von anderen Teams oder teamexternen Spezialisten arbeiten? Also so:

Pro ART Feature- und Component-Teams
Wie in Kap. 08A03, 3.5.3 beschrieben, wird es in jedem ART sowohl Feature- als auch Component-Teams geben.

Sehr oft kann das alle Teams eines ART umfassende Deployment der Teamergebnisse nicht von jedem Team selbst geleistet werden. Dann wird es pro ART ein Deployment-Operations-Team (s. „DevOps” in [1]) geben. Ein mehrere ARTs übergreifendes Deployment-Operations-Team ist nicht zu empfehlen.

Die Teamleiter sind herkömmlicherweise Rahmensetzer sowohl dafür, „WAS” das Team zu leisten hat, als auch für das „WIE”. Der Vorteil ist, dass es von der Welt außerhalb des Teams betrachtet den Teamleiter als einzigen Ansprechpartner für dieses Team gibt. Der Nachteil ist, dass das „WAS” dann allzu sehr von den Möglichkeiten des Teams, „WIE” es die Arbeit leisten kann (Kompetenzen, Auslastung einzelner Spezialisten, Entwicklungsinfrastruktur), bestimmt wird. Das jedoch widerspricht dem Ziel, für das Unternehmen/die Nutzer den optimalen „Wert zu schaffen”, als Dach des House of Lean (s. Kap. 08S01, 2.2).

„WAS” formulieren = Produktmanagement
Deshalb ist es essenziell, die Rahmensetzung für das „WAS” und das „WIE” auf zwei Rollen aufzuteilen, die personell getrennt bleiben. Damit diese klare Trennung gelingt, sollte die Verantwortung für das „WAS” keinesfalls der bisherige Teamleiter und auch niemand aus dem Team übernehmen. Es sollte besser eine Person aus dem Produktmanagement sein.

„WAS” mit Team erarbeiten …
Das „WAS” beschreibt all das, „was” das Team derzeit und künftig zu liefern hat: User Stories, zukünftige Features, technische Stories, Fehlerbehebungen, Infrastrukturarbeiten, Spikes, Refactorings und so weiter (s. [3]). Vieles davon wird anlässlich der Release-Planungen (daran nehmen alle Teams des ART teil) vom Team erkannt und formuliert. Dokumentiert ist das im „Team Backlog” (s. „Team Backlog” in [1]), einer nach Abarbeitungsreihenfolge geordneten Liste all dieser Dinge.

… verantwortlich bleibt Backlog Owner
Verantwortlich jedoch für diese Liste und alles, was dort enthalten ist, sowie für die Reihenfolge ist ausschließlich der „Team Backlog Owner”, der zum Agilen Team gehörende „Product Owner” (s. „Product Owner in [1]). Er ist als einzige Person für die Verwaltung des Team Backlog verantwortlich auch dann, wenn er einzelne seiner Aufgaben von anderen Personen (etwa im Team oder vom Produktmanagement) ausarbeiten lässt.

Team Backlog statt Product Backlog
Ich spreche hier ganz bewusst nicht (wie bei Scrum) von „Product Owner” und „Product Backlog”, sondern vom „Team Backlog Owner” und „Team Backlog”. Denn dann, wenn etliche Feature- und Component-Teams gemeinsam ein umfassendes SW-Produkt herstellen, ist es nicht realistisch, dass dieses Produkt von nur einem einzigen Product Owner verantwortet wird, der für jedes Team ein spezifisches Backlog verwaltet und mit jedem Team die Planungen und Reviews macht. Eingebürgert hat sich die Praxis, dass alle Teams eigene Owner für ihre Backlogs haben (allenfalls für zwei Teams einen), die dann ein „Team der Owner” bilden, das dann vom „eigentlichen” Product Owner repräsentiert wird. Außerdem ist es weit hergeholt, bei einem Component Team von einem „Product Backlog” und einem „Product Owner” zu sprechen, da dieses Team ja Systemkomponenten oder systemnahe Services und keine „Produkte” im eigentlichen Sinn realisiert.

Nur der Team Backlog Owner verantwortet das „WAS”
Der Team Backlog Owner entlastet das Team vom Klären widersprüchlicher und vom Priorisieren vieler gleichzeitig vorliegender Anforderungen diverser Anspruchsgruppen. Jedes Team verhandelt das „Was” seiner Arbeit ausschließlich mit seinem Team Backlog Owner, einschließlich der nichtfunktionalen Anforderungen. Die Teams sind für den von ihnen realisierten Lieferumfang nicht mehr gegenüber ihrem Teamleiter und diversen anderen Anspruchsgruppen (Auftraggeber, Nutzer, QA, Architektur …), sondern nur noch ihrem Team Backlog Owner gegenüber direkt verantwortlich.

Der Interessenabgleich hat im Produktmanagement auf den Ebenen des Programm- und Portfoliomanagements stattzufinden (s. „Product Owner”, Tabelle 1 in [1]). Die Formulierung im Scrum Guide [3]:

ist in größeren Organisationen nicht umsetzbar. Wichtig bleibt jedoch, dass nur der Team Backlog Owner die Ergebnisse des Interessenabgleichs durch das Programm- und Portfoliomanagement im Backlog festhält und sie nur von ihm allein gegenüber dem Team vertreten werden.

Wie-Verantwortliche
Die bereits vorhandenen Teamleiter werden „Wie-Verantwortliche” im Sinn eines Scrum Master oder Agile Master (s. „Scrum Master” in [1] und in [3], Abschnitt „The Scrum Master”). Sie sind nicht mehr verantwortlich für das „Was”. Sie bleiben die Vorgesetzten der Entwickler. Das ist auch kein Widerspruch zu Scrum (vgl. Kap. 08A03, 4.4 u. 4.5) oder eine Behinderung der Selbstverwaltung des Teams, sondern eine für das Team wichtige Unterstützung [4].

Die Team Backlog Owner hingegen sollten zur Organisationseinheit „Produktmanagement” oder „Servicemanagement” gehören. Dass damit die Teamleiter (bzw. die Teams als solche) nicht mehr für das „Was” zuständig sind, führt oft zu Irritationen bei den Kunden oder Nutzern. Bisher konnten sie ja direkt den Teamleiter oder ein Teammitglied ansprechen, um Änderungswünsche erfüllt zu bekommen.

Agile Teams als Org.-Einheiten der Linie mit Teamleitern
Die agilen Teams sind keine temporären Projektteams, sondern längerfristig stabile Feature- oder Component-Teams. Deshalb werden sie als Organisationseinheiten der Primärorganisation mit jeweils einem Teamleiter als Führungskraft gebildet. Nur so ist gewährleistet, dass die individuelle Förderung der Teammitglieder auf der Basis der Tag für Tag beobachteten Arbeit erfolgt und nicht „aus der Entfernung via Informationen aus dritter Hand”, wie es bei Matrixorganisationen oft der Fall ist.

Der Teamleiter setzt gegenüber dem Team und vertritt und verteidigt gegenüber außen den Rahmen für das „Wie” zur Durchsetzung des Grundsatzes „Nicht nur funktionierende Software, sondern auch gut gefertigte Software” und der Prinzipien des Clean Code Development. Das Team konzentriert sich innerhalb dieses Rahmens auf die professionelle Realisierung und das Testen des vom Team Backlog Owner vertretenen „Was”.

Produktinkremente in kurzen Intervallen oft nicht machbar
Idealerweise wird beim agilen Vorgehen in jeweils sehr kurzen Zeitabständen ein auslieferbares Software-Inkrement erzeugt. Beim iterativen Vorgehen (etwa bei Scrum-Sprints) ist das alle zwei bis vier Wochen, beim flussorientierten Vorgehen (etwa bei Kanban) immer dann, wenn etwas fertig ist. Oft aber, insbesondere wenn etliche Teams parallel an einem Software-Inkrement arbeiten, oder bei technologisch heterogenen Systemen, ist es schlichtweg nicht durchführbar, in so kurzen Abständen ein über alle Teams und Technologien hinweg im Gesamtsystem getestetes und zuverlässig lauffähiges Inkrement auszuliefern – einschließlich der dazu nötigen Benutzer- und Betriebsdokumentation (s. Kapitel 08A03, Abb. 3).

Überforderung der Nutzer vermeiden
Und die Nutzer? Sind sie gewillt, regelmäßig alle zwei bis vier Wochen oder noch häufiger neue und geänderte Softwarefunktionen zu erhalten und zu erlernen und ihre Arbeitsabläufe darauf abzustimmen?

Wenn pro ART die Zeitpunkte der (nicht unbedingt regelmäßigen) externen Releases mittelfristig abgeschätzt sind, stellt sich folgende weitere pro ART zusammen mit allen Teams des ART zu beantwortende Frage:

Zeitpunkte interner Releases
Interne Releases sind für die eigentlichen Nutzer unsichtbar. Sie dienen der Software- oder Produktentwicklung zur kurzfristigen und realitätsnahen Integration und Validierung der Resultate (s. 1in „Release” in [1] und Abb. 3 in „psi-release” in [1]).

Und zwar so, dass die Beiträge aller Teams in eine betriebsnahe Integrationsumgebung erfolgreich überführt und dort sowohl technisch (inklusive aller nichtfunktionalen Anforderungen) als auch fachlich erfolgreich getestet werden können. Ein Richtwert in großen Unternehmen mit heterogenen Systemlandschaften sind acht bis zehn Wochen.

Abschied vom „eisernen Dreieck”
Das Programmmanagement (s. „Program Portfolio Management” in [1]) dient der teamübergreifende Koordination der Funktionalitäten umfangreicher Systeme pro ART als Abfolge stets gleich langer Iterationen (= interne Releases) von acht bis zehn Wochen mit fixierten Qualitätsanforderungen, jedoch mit mittel- und langfristig veränderlichem Umfang (kein „eisernes Dreieck”: fester Umfang → fixe Termine → feste Kosten, s. Kap. 08S01, 3.2). Ergebnisse des ART sind regelmäßig vorhandene Potentially Shippable Increments (PSIs). Sie werden in einer dynamischen „Roadmap” (s. „Roadmap” in [1]) geplant.

Nur nächstes PSI verpflichtend
Die Beschreibung des unmittelbar nächsten internen Releases der Roadmap stellt eine Verpflichtung gegenüber dem Unternehmen dar. Für die Ausgestaltung der späteren Releases gibt es keine verbindlichen Zusagen, deren Umfang ist bestenfalls unscharf.

Kunden wollen längerfristige und verbindliche Zusagen
Dass Pläne für zukünftige interne Releases nicht für unternehmensexterne Verpflichtungen – also gegenüber den Kunden – genutzt werden sollten, ist bei vielen Kundenaufträgen jedoch schwierig durchzusetzen. Gegenüber den Kunden wird es in der Regel eine längerfristige und verbindlichere Planung zukünftiger, jedoch EXTERNER Releases der Kundenlösungen geben müssen – mit dem damit verbundenen Risiko, dass sich diese längerfristigen Planungen nicht umsetzen lassen.

Option: Agiler Festpreis
Verträge auf der Basis des „Agilen Festpreises” [5] sind eine Lösung, wenn es ein gutes Vertrauensverhältnis mit dem Kunden gibt.

Die Roadmap repräsentiert die jeweils aktuelle Sicht der Prognosen des Unternehmens für die zukünftigen Releases. Diese Sicht ist stets Änderungen unterworfen, da sich Entwicklungsergebnisse, Geschäftsprioritäten und Kundenbedürfnisse ändern können. Deshalb sollen Pläne für zukünftige interne Releases nicht für unternehmensexterne Verpflichtungen genutzt werden. Verpflichtend gegenüber dem Unternehmen ist nur der unmittelbar bevorstehende interne Release. Inwieweit daraus auch eine Verpflichtung für einen dem Kunden ausgelieferten (also externen) Release abgeleitet wird liegt in der Verantwortung des Produktmanagements.

Produktmanager im Programmmanagement
Auf der Ebene des Programmmanagements legen die Produktmanager (es gibt aber auch viele andere Bezeichnungen für diese Rolle) die Features des Systems als dynamische Roadmap fest. Die Rolle des „Product Owners” gemäß Scrum Guide ist dafür dann gut anwendbar, wenn jeweils ein Team allein ein Produkt, vertreten von einem Product Owner, entwickelt. In größeren Unternehmen jedoch sind, wie bereits vorher in 2.1.5 beschrieben, die Verantwortlichkeiten eines Product Owner im Sinne von Scrum oft so breit, dass sie auf technologisch orientierte Team Backlog Owner und auf den Markt oder die Nutzer fokussierte Produktmanager verteilt sind. Letztere nehmen ihre traditionellen Verantwortlichkeiten sowohl bezüglich der Produktdefinition als auch der Präsentation der Lösung gegenüber dem Markt wahr. Unabhängig von der firmenspezifischen Bezeichnung nimmt der Produktmanager/das Produktmanagement vor allem folgende Verantwortungen wahr:

Jede Timebox zur Realisierung eines PSI (= interner Release) eines ART beginnt mit einem Planungstreffen als Kick-off der Release-Erarbeitung. Diese Release-Planung für das nächste PSI dient der Klärung seines Kontextes und der Ausrichtung der am ART beteiligten Teams auf die Geschäftsziele des Releases. Die Vorgabe für das Release-Planungstreffen ist die aktuelle Vision zusammen mit den Zielen des kommenden Releases und der Zusammenstellung der dafür benötigten und priorisierten Features im Programm-Backlog dieses ART.

Planungsmeeting mit ALLEN Mitgliedern aller beteiligten Teams
Im Unterschied zu sonst üblichen Vorgehensweisen des Programmmanagements planen ALLE Mitglieder der am ART beteiligten Teams (also typischerweise 50 bis 100 Personen) das Release gemeinsam an ein bis zwei Tagen unter Nutzung bewährter Techniken zur Moderation großer Gruppen (s. Abb. 3 in „Release Planning” in [1]). Die Teams zerlegen die für das nächste PSI in Betracht kommenden Features des Programm-Backlogs in jene Stories, die sie als Team bearbeiten können. Das ergibt die Team Backlogs für das nächste PSI (den anstehenden internen Release). Während dieses Prozesses klären die Teams ihre Schnittstellen zu anderen Teams. Sie schätzen den Umfang ihrer Stories und verhandeln in Kenntnis ihrer Kapazität (= Arbeitsgeschwindigkeit), was sie leisten oder nicht leisten können und damit über Veränderungen des Release-Umfangs mit dem Team Backlog Owner und dem Produktmanagement. Zusätzlich zu dieser Planung verpflichten sich die Teams gegenüber ihrem Team Backlog Owner auf die zu erreichenden Release-Ziele und priorisierten Features. Die Ergebnisse der Release-Planung fließen in die Aktualisierung der Roadmap des ART ein.

Ist das nicht viel zu aufwändig und daher „unbezahlbar”?

Ungewöhnlich – aber hoch effizient!
Hier die Rechnung:

Zehn Teams (= 60 Personen) arbeiten gemeinsam an einem internen Release eines ART und es gibt fünf interne Releases pro Jahr:

→ 2 Tage × 5 Releases × 60 Personen = 600 Personentage/Jahr

→ Pro Person 180 „produktive” Tage pro Jahr × 60 Personen = 10.800 Personentage/Jahr

Agil = Kooperation/Konversation, nicht Auftragserteilung „von oben”
Wenn solche kooperativen Arbeitsweisen als viel zu teuer abgelehnt werden mit dem Hinweis, dass es ja genüge, wenn die Team Backlog Owner allein (also nur zehn statt 60 Personen) all das in nur einem halben Tag erledigen, ist das ein Zeichen für eine immer noch stark auf „Auftragserteilung von oben” und „Koordination durch Repräsentanten” geprägte Kultur. Es hat sich dann noch nicht die Einsicht durchgesetzt, dass ein Unternehmen erst durch die fortlaufende Konversation aller das Unternehmen umfassenden Mitarbeitenden und Stakeholder entsteht.

„Agil” als Fassade?
„Agile” Vorgehensweisen werden dann bestenfalls nur als „Fassade” sichtbar sein, nicht aber gelebt werden. Das jedoch erzeugt mehr Irritationen und Verunsicherungen als Nutzen. Wenn die Kultur nicht stimmt, sollten besser die alten Vorgehensweisen praktiziert werden.

Inwieweit einzelne Teams innerhalb dieser PSI-Erarbeitung in Anlehnung an Scrum in Sprints, kontinuierlich mit Kanban oder Scrumban, einer Kombination aus beidem, oder nach eigenem Muster arbeiten, kann den Teams überlassen werden. Für die Teams ist mit der Relase-Planung pro ART der Rahmen für das „WAS” gesetzt. Der Teamleiter hat die Verpflichtung, den Rahmen für das „WIE” zu setzen, um die Erreichung des „WAS” zu erleichtern.

Jedes Team wählt seine Vorgehensweise selbst
Die passenden Details der Arbeitsweise – das Bild im Rahmen – können die Teams selbst wählen. Es liegt insbesondere an den sehr eng kooperierenden Teams, sich selbst gemeinsam angemessen zu organisieren und allenfalls synchronisierte Sprints zur besseren Kooperation und Transparenz zu vereinbaren. Teams mit einem hohen Anteil fortlaufend und unplanbar eintreffender Wartungs- und Supportaufgaben hingegen arbeiten besser auf der Basis von Kanban oder Scrumban mit regelmäßigen teamübergreifenden „System Demos”.

Entscheidend ist, dass jedes Team seine in der Release-Planung zugesagten Ziele erreicht. Das „WIE” liegt in der Verantwortung der Teams.

Keine Methode um ihrer selbst willen
Schenken Sie „Methodendogmatikern” keinen Glauben. Glauben Sie vor allem nicht daran, dass ein bestimmtes Vorgehen wie insbesondere Scrum zuerst 1:1 gemäß einem der beiden heute vorliegenden Regelwerke (dem „Scrum Guide” der scrum.org und dem „Core Scrum” der Scrum Alliance) praktiziert werden muss, bevor es teamspezifisch angepasst wird. Gehen Sie auch hier von Anfang an agil vor: Praktizieren und intensivieren Sie im Team all das, was passt, und verändern Sie Ihre Praktiken schrittweise. Die dokumentierten Regeln der diversen Rahmenwerke dienen der Orientierung, nicht als „Gesetze”. Und wenn sich eine dieser Regel als „schmerzhaft” herausstellt, dann hören Sie damit auf und machen Sie etwas Passenderes. Ihr Unternehmen lebt nicht vom Einhalten fremder Regeln, sondern von den Ihre Kunden zufriedenstellenden und sie hoffentlich auch begeisternden Produkten und Dienstleistungen, die das Unternehmen „schmerzfrei” und gewinnbringend realisieren kann.

Denken Sie auch stets daran, dass auf der Ebene des Teams die SW-Entwicklung als professionelles Handwerk (Craftsmanship) wichtiger ist als das Befolgen irgendwelcher teamextern definierten Vorgehensregeln, um nicht nur funktionierende, sondern gut gefertigte Software zu realisieren.

Tagesaktuell sichtbarer Arbeitsfortschritt
Für die Arbeit bis zur Lieferung des nächsten PSI (interne Releases) haben alle Teams unabhängig von ihrem Vorgehen jedoch diese Transparenz zu gewährleisten:

Gleichzeitig steht die Sicherstellung der Qualität und nicht der Menge der in jedem PSI gelieferten Ergebnisse im Vordergrund. Deshalb gibt es diese weitere Regel:

Projekte passen nicht zur agilen Entwicklung im ART
„Projekte” in ihrer in der IT weit verbreiteten Bedeutung stehen im Widerspruch zur agilen SW-Entwicklung (s. Kap. 08A01, 3.2). Andererseits verhilft das „Projekt” als organisatorisches und kommerzielles Konstrukt zu einer starken Fokussierung darauf, bestimmte Ergebnisse innerhalb einer definierten Zeit mit definierten Kosten zu erzielen, und es schafft dafür spezielle temporäre Verantwortlichkeiten (Lenkungsausschuss, Projektleiter, Projektteam). Wenn jedoch in einem Unternehmen alles als „Projekt” betrachtet und organisiert wird, führt das zu kaum zu bewältigenden Koordinationsproblemen, zu einem Übermaß an projektbedingten Meetings und bei den in der Regel gleichzeitig an mehreren Projekten beteiligten Mitarbeitenden zu einem die Produktivität beschränkenden Multitasking.

Mit Widerspruch pragmatisch umgehen
Mit dem Widerspruch zwischen der projektunabhängigen kontinuierlichen Arbeit in einem ART einerseits und der zeitlich begrenzten Fokussierung auf Projekte kann so umgegangen werden:

Portfoliomanagement zur Umsetzung der Geschäftsstrategie
Das Portfolio (alles zu „Portfolio” in [1]) umfasst die Gesamtheit der strategischen Themen (s. Abb. 1 in „Portfolio Vision” in [1]). Deren Prioritäten steuern die Investitionen auf Unternehmensebene. Aufgabe des Portfoliomanagements ist es, dass die zukünftig geleistete Arbeit tatsächlich der Umsetzung der Geschäftsstrategie dient. Die strategischen Themen bestimmen die Portfolio-Vision, dargestellt als umfangreiche Initiativen in Form von Epics. Sie fließen im Verlauf der Zeit in verschiedene Agile Release Trains ein.

Die Verantwortung für die Erarbeitung der Themen und Epics tragen die Portfoliomanager, das sind entweder die „Owners” der Geschäftsbereiche oder die Produktgremien und andere Personen, die gegenüber ihren Stakeholdern verantwortlich sind.

„Themen” des Portfolios sind langlebig
Zweck der vom Portfoliomanagement erarbeiteten Themen ist es, auf dem Markt differenzierende und konkurrenzfähige Kernprodukte anzubieten. Diese Themen haben eine weitaus längere Lebensdauer als die Epics. Gruppen solcher Themen können bis zu einem Jahr oder länger unverändert bleiben.

Es gibt zwei Arten von aus den strategischen Themen abgeleiteten Epics:

„Epics” beschreiben wertschaffende Ergebnisse eines „Themas”
Epics sind Entwicklungsvorhaben zur Lieferung wertschaffender Ergebnisse für ein Investment-Thema und werden im Portfolio Backlog festgehalten, priorisiert, geschätzt und laufend gepflegt. Vor der Release-Planung eines ART werden sie vom Programmmanagement und den Team Backlog Owners in spezifische Features aufgeteilt.

Epics können dargestellt werden in Stichworten, in Form nutzersprachlicher „Stories”, in ein oder zwei Sätzen, als Video, als Prototyp oder in irgendeiner anderen Form, die geeignet ist, die Absicht der Produktinitiative auszudrücken. Ziel der Epics ist die Beschreibung der strategischen Absicht, nicht die Genauigkeit. Mit anderen Worten: Ein Epic muss nur so weit im Detail beschrieben werden, wie damit eine zukünftige Diskussion darüber ausgelöst werden kann, welche Features ein Epic impliziert.

Je ein Portfolio-Kanban für Business- und Architektur-Epics
Busines-Epics werden im Kanban-System der Business-Epics (s. „Business Epic Kanban” in [1]), Architektur-Epics im Kanban-System der Architektur-Epics (s. „Architectural Epic Kanban” in [1]) erfasst. In beiden Kanban-Systemen erfolgt der weitere Bearbeitungsfluss unter Einhaltung der für Kanban typischen „Work In Progress”(WIP)-Begrenzungen.

Wie in der vorherigen Konstellation (Entwicklung und Unterhalt umfassender Individuallösungen) im Abschnitt 2.1.1 beschrieben. Dabei wird besonders darauf geachtet, die modulare, serviceorientierte Architektur der Plattform konsequent einzuhalten und fortlaufend zu optimieren. Dabei verfolgen alle das Ziel, dass kundenspezifische Lösungen die eigentliche Plattform weder komplizierter machen noch mit separaten Speziallösungen unterlaufen.

„Value Streams” sind – wie ebenfalls in der vorherigen Konstellation beschrieben – auch hier als langlebige Werteströme zur Erzielung eines wirtschaftlichen Nutzens zu verstehen.

Werteströme für Plattform und Kundenlösungen
Nun aber gibt es zwei verschiedene Arten von Werteströmen:

Beide Arten umfassen die Gesamtheit aller Anforderungen, Systemdefinitionen und Entwicklungs- und Auslieferungsschritte, die dazu dienen, ein integriertes System (die Plattform oder eine umfassende Kundenlösung auf ihrer Basis) zu realisieren und zu warten.

„Value Streams” sind auch hier keine einzelnen – stets zeitlich begrenzten – Projekte, auch nicht im Fall kundenspezifischer Lösungen.

Werteströme (Value Streams) von Strategie bestimmt
Wie aber können die Value Streams beider Arten gebildet werden? In „Value Streams” in [1] werden einige essenzielle Fragen als Orientierungshilfe gestellt. Es wird dabei auch klar, dass die Festlegung der Value Streams von der strategischen Ausrichtung des Unternehmens geprägt sein muss und nicht primär eine Frage nur der operativen Optimierung ist.

Zwei Strukturprinzipien bieten sich an:

Value Streams als ARTs implementieren
Beide Strukturprinzipien liefern Value Streams, die im Bereich der Entwicklung und Wartung als Agile Release Trains (ARTs) implementiert werden und Teams mit insgesamt höchstens 150 Personen pro ART umfassen sollten. In einem großen Unternehmen dieser Art mit 6.000 Mitarbeitenden wird es also etwa 50 bis 60 ARTs und ebenso viele Value Streams geben, die es auf der Ebene des Portfoliomanagements abzustimmen gilt.

Trotz der Neustrukturierung in Value Streams kann die bisherige Form des – in der Regel auf der Budgetierungsperiode für ein ganzes Geschäftsjahr und daher nicht sehr flexiblen – Portfoliomanagements eventuell noch beibehalten und erst in einem späteren Schritt flexibilisiert werden. Allerdings:

Das für die vorherige Konstellation (Entwicklung und Unterhalt umfassender Individuallösungen) in 2.1.3 Geschriebene trifft auch hier zu, jedoch mit diesen Erweiterungen:

Beim Strukturprinzip „Value Streams einerseits für die Produktlinien der kundenneutralen Plattform und andererseits für charakteristische Arten kundenspezifischer Lösungen” gibt es zwei Gruppen von Teams: Einerseits die Teams in den Agile Release Trains für die Entwicklung der Plattform und andererseits die Teams in den Agile Release Trains für kundenspezifische Lösungen. Wenn hingegen die Value Streams nur von kundenunabhängigen Produktlinien der Plattform bestimmt werden, gibt es keine zwei Gruppen von Teams bzw. ARTs.

Jeder dieser ARTs umfasst Teams mit insgesamt 50 bis 100 (max. 150) Personen und jeder ART ist ein weitestgehend autonomes soziales Handlungssystem, um das kaum zu leistende zentralistische Management Hunderter Teams und Spezialisten zugunsten des Vertrauens in die Selbststeuerungsfähigkeit sozialer Systeme abzubauen.

Abstimmung der Plattform-/Kundenlösungs-ARTs
Wie aber kann im Fall „Value Streams einerseits für die Produktlinien der kundenneutralen Plattform und andererseits für charakteristische Arten kundenspezifischer Lösungen” sichergestellt werden, dass die ARTs der Weiterentwicklung der Produktlinien der kundenneutralen Plattform von den ARTs der kundenspezifischen Lösungen befruchtet werden und dass umgekehrt die ARTs der kundenspezifischen Lösungen die Neuerungen der Plattform rasch kennenlernen?

Formalisierte Abstimmung via Repräsentanten unrealistisch
Die Abstimmung der Weiterentwicklung der Produktlinien der Plattform mit der Entwicklung kundenspezifischer Lösungen ist mit formalisierten Prozessen und Verantwortlichkeiten in Gestalt von Repräsentanten der Teams, die diese Koordination leisten sollen, kaum machbar. Stattdessen sind die für eine agile Unternehmenskultur essenziellen Kommunikationsräume zu schaffen.

Themenzentrierte „Communities” als Kommunikationsräume
In vielen Unternehmen bewährt sind Kommunikationsräume in Form themenzentrierter „Communities” quer zur Linienstruktur. Im vorliegenden Fall wären das quer zu den ARTs der kundenspezifischen Lösungen gebildete Gruppen, die die ARTs der kundenneutralen Plattform erweitern. Beispielsweise so: Eine als ART implementierte Produktlinie der Plattform befasst sich mit „Fakturierung und Zahlung”. Alle Spezialisten in den ARTs der kundenspezifischen Lösungen, die sich dort mit „Fakturierung und Zahlung” beschäftigen, bilden zusammen mit den „Plattformleuten” des ART „Fakturierung und Zahlung” mehre Plattformgruppen zum Thema „Fakturierung und Zahlung”. Mehrere deshalb, damit jede dieser Gruppen nicht mehr als etwa 25 Personen umfasst. Jede dieser Gruppen trifft sich monatlich zu einem „Führungs-Meeting”, wie im Abschnitt „Anpassbare Kreise statt starrer Hierarchien” (Kap. 08A03, 4.1) beschrieben wurde. Die Erkenntnisse der einzelnen Plattformgruppen zum Thema „Fakturierung und Zahlung” fließt in die Planungsmeetings des ART „Fakturierung und Zahlung” ein. Dort sind ja alle Mitglieder dieses ART in den diversen Plattformgruppen zu diesem Thema vertreten.

Ungewohnt – aber sehr effektiv!
Wenn derartige Kommunikationsräume als „zu teuer” abgelehnt werden, ist das auch hier – wie bereits vorhin beim Aufwand für die Planungsmeetings pro ART erwähnt (Abschnitt 2.1.9) – ein Zeichen einer noch stark auf „Auftragserteilung von oben” und „Koordination durch Repräsentanten” geprägten Kultur. Es hat sich dann noch nicht die Einsicht durchgesetzt, dass ein Unternehmen erst durch die fortlaufende Konversation aller das Unternehmen umfassenden Mitarbeitenden und Stakeholder entsteht.

Hier ist das in der vorherigen Konstellation (Entwicklung und Unterhalt umfassender Individuallösungen) im Abschnitt 2.1.4 dazu Geschriebene ohne Einschränkungen oder Ergänzungen anwendbar.

Das gilt auch für diese nächsten Schritte:

Siehe Abschnitt 2.1.5

Siehe Abschnitt 2.1.6

Siehe Abschnitt 2.1.7

Siehe Abschnitt 2.1.8

Siehe Abschnitt 2.1.9

Siehe Abschnitt 2.1.10

Siehe Abschnitt 2.1.11

Siehe Abschnitt 2.1.12

Wesentliche praktizierte Elemente
Wesentliche Elemente der „agilen Kultur” werden praktiziert, insbesondere:

Craftsmanship ist etabliert
Craftsmanship (SW-Entwicklung als professionelles Handwerk) ist etabliert, insbesondere:

Die in temporären Projektteams des Dienstleisters oder der Kunden arbeitenden Mitarbeitenden nach Möglichkeit so einsetzen, dass:

Üblicherweise sind die Projektleiter Rahmensetzer sowohl dafür, „WAS” das Projektteam zu leisten hat, als auch für das „WIE”. Der Vorteil ist, dass es pro Projektteam aus Kundensicht einen einzigen Ansprechpartner sowohl für das „WAS” als auch für das „WIE” gibt. Der Nachteil ist, dass das funktionale „WAS” allzu sehr vom machbaren „WIE” (Kompetenzen im Team, Auslastung einzelner Spezialisten, Entwicklungsinfrastruktur) bestimmt wird und umgekehrt der Projektleiter das „WIE” zu sehr einschränkt. Deshalb ist es essenziell, die Rahmensetzung für das „WAS” und das „WIE” auf Rollen aufzuteilen, die personell getrennt sind. Projektleiter = „WAS”-Verantwortlicher = Team Backlog Owner
Damit diese klare Trennung gelingt, sollte die Verantwortung nur für das „WAS” (nicht das „WIE”) der gegenüber dem Kunden in Erscheinung tretende Projektleiter übernehmen. Mit dem „WAS” beschreibt der Projektleiter all das, „was” das Team derzeit und künftig zu liefern hat: User Stories, zukünftige Features, technische Stories, Fehlerbehebungen, Infrastrukturarbeiten, Spikes, Refactorings usw. Auch wenn einzelne dieser Dinge im Team erarbeitet werden, bleibt er als Projektleiter allein verantwortlich für diese Liste und alles, was darin enthalten ist, und für die Reihenfolge der Einträge. Er ist als einzige Person für die Verwaltung des Team Backlog verantwortlich.

Der Projektleiter als Team Backlog Owner entlastet das Team vom Klären widersprüchlicher und vom Priorisieren vieler gleichzeitig vorliegender Anforderungen diverser Anspruchsgruppen. Das Team verhandelt das „WAS” seiner Arbeit ausschließlich mit seinem Projektleiter als Team Backlog Owner, einschließlich der nichtfunktionalen Anforderungen. Das Team ist für den realisierten Lieferumfang nur gegenüber seinem Projektleiter als Team Backlog Owner und nicht diversen anderen Anspruchsgruppen direkt verantwortlich.

„WIE”-Verantwortlicher = Agile Master
Neben dem Projektleiter als Team Backlog Owner hat jedes Projektteam einen „Wie-Verantwortlichen” im Sinn eines Scrum Master oder Agile Master. Im Unterschied zu den für längere Zeit existierenden Teams der vorherigen zwei Konstellationen sind sie keine Teamleiter. Im Einvernehmen mit der – hier aber von der tagtäglichen Arbeit „ihrer” Mitarbeitenden entkoppelten – Führungsperson kümmert sich dieser Agile Master auch um die individuelle Förderung der Teammitglieder auf der Basis der von ihm Tag für Tag miterlebten Arbeit.

(Bei in Teams des Kunden entsandten Mitarbeitenden des Dienstleisters ist auch das nicht gegeben. Dort muss sich die von der tagtäglichen Arbeit „ihrer” Mitarbeitenden entkoppelte Führungsperson bei ihrer Führungsarbeit auf Informationen des Kunden stützen.)

Inwieweit Projekte „agil” abgewickelt werden können, ist umstritten (s. Kap. 08S01, 3.2).

Wenn der Kunde mit dem Begriff „Projekt” jedoch nicht bereits zu Beginn klare und detaillierte Ziele und vereinbarte zeitliche und finanzielle Ressourcen versteht, sondern einverstanden ist, dass die Ziele zu Beginn nur grob definiert und im Projektverlauf im Rahmen der Termine und Kosten in Absprache mit ihm ohne ein langwieriges Change Request Management verändert werden können, ist ein inkrementell-adaptives Vorgehen möglich. Im Rahmen der Initialisierungsphase wird dann ein Projekt-Backlog, bestehend aus „Features” (nicht bereits aus „Stories”) als eine der wichtigsten Grundlagen der Projektsteuerung erarbeitet.

Das agile Projektvorgehen insgesamt kann auf der Basis eines – auf das unbedingt nötige Minimum „zurechtgeschnittene” – PRINCE2 oder DSDM erfolgen.

Die vertragliche Regelung sollte auf einem „agilen Festpreis” [5] beruhen.

Ideal alle zwei bis vier Wochen
Idealerweise sollte beim agilen Vorgehen alle zwei bis vier Wochen, beim flussorientierten Vorgehen immer dann, wenn etwas fertig ist, ein auslieferbares Software-Inkrement erzeugt werden. Das setzt jedoch voraus, dass das möglicherweise recht heterogene System des Kunden ein in so kurzen Abständen in seinem System getestetes und zuverlässig lauffähiges Inkrement auszuliefern erlaubt und die Nutzer beim Kunden gewillt sind, regelmäßig alle zwei bis vier Wochen oder noch häufiger neue und geänderte Softwarefunktionen zu erhalten und zu erlernen und ihre Arbeitsabläufe darauf abzustimmen.

Projektleiter klärt
Vom Projektleiter zu klären ist daher:

Die Antwort bestimmt die Häufigkeit der externen, also effektiv ausgelieferten und produktiv gesetzten Releases.

Wenn für das Projekt die Zeitpunkte der (nicht unbedingt regelmäßigen) externen Releases mittelfristig abgeschätzt sind, stellt sich folgende weitere zusammen mit allen Teams des Projekts zu beantwortende Frage:

Deren Takt ist regelmäßig und nie länger als jene minimale Dauer, in der alle zum internen Release beitragenden Teams gemeinsam ein „Potentially Shippable Increment” (PSI) so erzeugen können, dass die Beiträge aller Teams in eine betriebsnahe Integrationsumgebung erfolgreich überführt und dort sowohl technisch (inklusive aller nichtfunktionalen Anforderungen) als auch fachlich erfolgreich getestet werden können.

Hier ist das in Abschnitt 2.1.9 dazu Geschriebene sinngemäß anwendbar, wobei „Agile Release Train” durch „Projekt” ersetzt ist und das „Programmmanagement” durch den „Projektleiter”.

Inwieweit einzelne Teams innerhalb der Realisierung eines PSI in Anlehnung an Scrum in Sprints oder mit Kanban oder Scrumban oder nach eigenem Muster arbeiten, kann auch hier den Teams überlassen werden. Für die Teams ist mit der Release-Planung pro Projekt der Rahmen für das „WAS” gesetzt. Der Agile Master hat die Verpflichtung, den Rahmen für das „WIE” zu setzen, ohne dabei das „WAS” zu erschweren.

Alles Weitere entspricht dem für die vorherigen zwei Konstellationen zu „Agile Arbeit auf Teamebene” bereits Geschriebenen.