Disciplined Agile – Ein vielseitiges Prozess-Framework

12. Juni 2019 Mariusz Nosol

Agil arbeiten – das ist das Ziel vieler Unternehmer, die ihre Firma erfolgreich in die Zukunft steuern möchten. Doch was tun, wenn Team und Projekte über eine gewisse Größe hinauswachsen, und die in Scrum & Co mit Absicht ausgelassenen Aspekte nicht länger unbeachtet bleiben können?

Agiles Arbeiten

Aus der Studie „Agile Arbeit 2019“ von Corporate Legal Insights (CLI) geht hervor, dass von 104 befragten deutschen Kapitalgesellschaften aus 18 Branchenclustern stolze 97,11% agile Arbeit in Zukunft für unabdingbar halten. 67,30% haben oder planen eine Strategie zur Umsetzung agiler Arbeitsmethoden, und rund ein Drittel haben noch keinen Plan.

Mit Lean und Agile-Methoden zur arbeiten, das bedeutet Abläufe verschlanken und effektiv aufeinander abzustimmen. Wer bereits agil arbeitet, der kennt bestimmt schon Managementmethoden wie das japanische Kanban oder Scrum. Sie erlauben es kleinen, wendigen Teams, schrittweise und transparent an einem Produkt zu arbeiten, um zügige und qualitativ hochwertige Ergebnisse zu liefern.

Unter ständigem Feedback des Kunden können Produkte so fortwährend verbessert und verfeinert werden, und auf Veränderungen und spezifische Kundenwünsche können Teams angemessen reagieren.

In übersichtlichen Teams ist das kein Problem. Was aber wenn agiles Arbeiten in komplexeren Umgebungen angewandt werden soll?

Wie im Kleinen, so im Großen?

Laut der Studie von CLI werden agile Methoden am häufigsten in den Unternehmensbereichen IT (46,15%), Produktentwicklung (45,19%) und Marketing (39,42%) benutzt. Doch oft bleiben agile Arbeitsmethoden eben in diesen Bereichen – selten sind sie in einem Abteilungsübergreifenden Kontext verankert.

Der Trend ist längst bei größeren Organisationen angekommen, und es gibt für die Umsetzung agiler Arbeitsmethoden in einem solchen Umfang einige Frameworks, die es einer näheren Betrachtung wert sind. Die drei bekanntesten hierbei sind Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) und Disciplined Agile (DA).

In diesem Artikel widmen wir uns dem Disciplined Agile Prozess-Framework. Das Besondere an diesem Framework ist, dass es in seiner Umsetzung nicht auf eine Methodologie setzt, sondern die Anwendung der meistbenutzten agilen Arbeitsweisen ermöglicht. Es erlaubt die Integration vieler Aspekte der anderen beiden Frameworks sowie Kanban, Scrum u.v.m. und ist daher in Unternehmen jeglicher Größe anwendbar.

Diszipliniert und Agil

DA ist unterteilt in die Segmente Disciplined Agile Delivery (DAD), Disciplined DevOps, Disciplined Agile IT (DAIT) und Disciplined Agile Enterprise.

Das Herzstück von DA bildet DAD – hier ist die Lieferung von IT-Lösungen von A bis Z definiert: von der anfänglichen Modellierung und Planung, der Erstellung des Teams und Sicherstellung der Finanzierung hin zur durchgängigen Architektur, durchgängigen Tests, durchgängiger Entwicklung und Kontrolle im gesamten Lebenszyklus.

Aufbauend hierauf fokussieren Disciplined DevOps und DAIT auf die Abstimmung der Abläufe im gesamten IT-Bereich des Unternehmens, um so Entwicklungszyklus, Betrieb, Support, Datenmanagement und andere Bereiche so effektiv und unkompliziert wie möglich zu gestalten.

Die Disciplined Agile Enterprise ist dann das Endergebnis, das aus den obigen Bausteinen bestehende Unternehmen, welches in der Lage ist, Marktveränderungen schnell wahrzunehmen und sich dementsprechend anzupassen.

Auf ganzer Linie

Ein agiles Unternehmen zu werden – das ist das Ziel. Daher konzentriert sich DA nicht nur auf den IT-Bereich, sondern bezieht auch andere Abteilungen mit ein – die Bereiche Marketing, Vertrieb und Beschaffung zum Beispiel können alle von den agilen Arbeitsweisen profitieren.

Einer der entscheidenden Vorteile von DA ist die Umsetzung agiler Lösungen, ohne dabei auf nur eine einzige Methodik zu setzen – DA ist sozusagen agnostisch in seiner agilen Weltanschauung. Prozesse sind hauptsächlich Amalgame aus Agile und Lean-Methoden, aber auch traditionelle Arbeitsweisen sind mit dabei, wie z.B. Kaizen, die Idee der durchgängigen Verbesserung aller Vorgänge und Abläufe.

Den Team-Mitgliedern wird innerhalb des Framework der Freiraum gegeben, sich je nach Kontext ihrer Aufgaben die geeigneten Arbeitsweisen auszusuchen (Way of Working [WoW]) – darunter auch Elemente der anderen beiden Frameworks SAFe und LeSS.

Ein weiterer Vorteil ist, dass DA sowohl Agilität als auch Risikobewusstsein fördert. Dies ist insbesondere in streng regulierten Branchen wichtig.

Prinzipien

Unternehmenskultur ist ein wichtiger Teil der Umsetzung von agilen Arbeitsweisen, insbesondere wenn das über verschiedene Abteilungen hinweg geschehen soll. Die zugrundeliegende Kultur von DA ist in den folgenden sieben Grundsätzen definiert.

1. Kunden entzücken – Kunden sollen entzückt werden (EN: Delight Customers), indem nicht bloß ihre Bedürfnisse und Erwartungen erfüllt werden, sondern indem sie darüber hinaus echte Freude am Produkt haben.

2. Großartig sein – Großartige Teams bestehen aus motivierten Menschen (EN: Be Awesome), die ihre Arbeit in einer guten Umgebung und mit der nötigen Unterstützung erledigen können.

3. Pragmatismus über Purismus – Effektives Arbeiten geht über Agilität hinaus (EN: Pragmatism). Wenn traditionelle Methoden effektiv sind, dann sollen sie mit einbezogen werden.

4. Kontext ist wichtig – jede Person, jedes Team und jede Organisation ist einmalig und benötigt eine einmalige, effektive Strategie, die konstant weiterentwickelt werden muss (EN: Context Counts).

5. Die Wahl haben – Jede Situation erfordert eine andere Herangehensweise (EN: Choice is Good). Teams haben Kontrolle über Abläufe und Prozesse und müssen in der Lage sein, zu experimentieren. So finden sie heraus, was in der Praxis funktioniert und was nicht. Die ideale Lösung kann frühzeitig gefunden werden, wenn die Teams sich der verschiedenen Optionen und der einhergehenden Kompromisse bewusst sind.

6. Optimierte Abläufe – Eine Organisation ist ein komplex-adaptives System, in dem interagierende Teams und Gruppen sich auf individueller Basis weiterentwickeln. Eine erfolgreiche Strategie setzt voraus, dass Teams koordiniert arbeiten und dass die Zusammenarbeit verbessert und verfeinert wird (EN: Optimize Flow).

7. Unternehmensbewusstsein – Wenn Mitarbeiter das Unternehmen als eine Einheit wahrnehmen, in der sie eine aktive Rolle spielen, dann sind sie dazu motiviert, die Gesamtbedürfnisse der Organisation zu verstehen (EN: Enterprise Awareness). Sie streben danach, die Gesamtziele zu erreichen und nicht nur die einzelnen Ziele der individuellen Abteilungen. Bewährte Verfahren werden öfter geteilt und in verschiedenen Kontexten angewandt – so wird doppelte Arbeit vermieden.

Rollen

Beim Scrum gibt es drei Rollen – ScrumMaster, Product Owner und Team Member. DA hat aber viele verschiedene Rollen. Hauptsächlich führt die Größe der Projekte und übergreifende Natur von DA dazu, dass die Rollen ein wenig zahlreicher sind.

DAD, Disciplined DevOps, DAIT und DAE haben unterschiedliche Rollen. Werfen wir im Folgenden einen Blick auf die 10 Rollen des Herzstücks, DAD. Diese sind in jeweils fünf Hauptrollen und Nebenrollen eingeteilt.

Die folgenden fünf Hauptrollen sind bei jedem Projekt die Regel, bei jeder Projektgröße.

1. Stakeholder: eine Person, die direkt mit dem Ergebnis der Lösung verbunden ist.

2. Team Member: fokussiert auf die Erstellung der eigentlichen Lösung.

3. Team Lead: schafft und unterhält produktive Arbeitsbedingungen.

4. Product Owner: ist die Kontaktperson für eventuelle Fragen zur Lösung.

5. Architecture Owner: ist verantwortlich für die IT-Architektur. In kleinen Teams ist er oder sie auch der Team Lead.

Die Nebenrollen kommen je nach Größe des Projekts ins Spiel. Es gibt fünf Nebenrollen.

1. Specialist: Spezialisten wie zum Beispiel Agile Business Analysts sind manchmal nötig, um die Umgebung zu bestimmen, in der die Lösung eingeführt werden soll.

2. Domain Expert: Fachleute wie Steuerexperten werden manchmal gebraucht, wenn zur Entwicklung des Lösung bestimmtes Fachwissen benötig wird.

3. Technical Expert: Technische Experten wie User Experience-Spezialisten werden hinzugezogen, um z.B. ein Interface zu gestalten.

4. Independent Tester: der Großteil der Tests wird von Leuten aus dem DAD-Team durchgeführt, doch einige Teams werden durch unabhängige Tester unterstützt, die z.B.
Penetrationstests und Leistungstests durchführen.

5. Integrator: bei großen DA-Teams, die nochmal in kleinere Teams unterteilt sind, werden ein oder zwei Integratoren benötigt, die die einzelnen Lösungen in das Gesamtteam einbringen.

Die Hauptrollen sind, wie oben erwähnt, bei jedem DAD-Projekt mit dabei. Die Nebenrollen aber kommen nur bei verschiedenen Größenordnungen und über einen bestimmten Zeitraum in Spiel.
Der größere Umfang erfordert, das technische Aspekte mit einbezogen werden, die bei Scrum ignoriert werden. So wird bei DAD zum Beispiel die Rolle des Architecture Owner aus dem Bereich Agile Architecture genutzt.

Die Rollen sind aber nicht als starre Positionen zu verstehen. Die Rolle des Team Leads beispielsweise kann von einer Person zur anderen Wechseln, wenn die Urlaubsplanung oder andere Umstände dies erfordern.

Alle Teammitglieder sind gleichberechtigt – DA legt den Hauptfokus auf den Menschen und auf das Erlernen neuer Fähigkeiten. Traditionelle Rollen wie Projektmanager kommen in DAD nicht vor, doch die Aufgaben dieser Rolle werden sehr wohl wahrgenommen und auf andere Weise integriert.

Phasen

Wie bereits erwähnt, ist bei DAD die Zustellung von IT-Lösungen von Anfang bis Ende definiert, auf Basis von Scrum und Kanban Lifecycles sowie zweier Lifecycles, die Continuous Delivery unterstützen, und jeweils einen Exploratory und Program Lifecycle. Die Teams können dann ihre Methoden aussuchen und sie in den drei Phasen umsetzen, die DAD festlegt: Auftakt (Inception), Entwicklung (Construction) und Übergang (Transition).

1. Auftakt
Die Teams werden aufgestellt und die Planung entwickelt. Die agilen Teams erstellen einen Rahmen für das Projekt und bereiten eine brauchbare Lösung vor. Zu den Zielen dieser Phase gehören die ursprüngliche Modellierung, Planung und Organisation sowie die Identifizierung, Priorisierung und Auswahl der Projekte und die Definierung der ersten Anforderungen des Release-Plans.

2. Entwicklung
In dieser Phase wird die Lösung schrittweise entwickelt. Das kann auf Basis von Iterationen (oder Sprints) passieren oder auf Basis eines Lean- bzw. Continuous Flow-Ansatzes. Hier kommt die vielseitige Natur von DA zum Vorschein. Teams nutzen Prozesse aus Scrum, XP, Agile Modeling, Agile Date u.v.m. Du den Zielen gehören: eine bewährte Architektur finden, die Priorisierten Aufgaben und die Rückstände abarbeiten, um eine einsetzbare Lösung zu entwickeln, die dann den Stakeholdern präsentiert wird. Jegliche Änderungen werden in Betracht genommen und in wiederholten Iterationen umgesetzt.

3. Übergang
In dieser Phase wird die Lösung veröffentlicht, normalerweise in einigen kurzen Iterationen, die in der Produktion enden. Änderungswünsche werden auch hier in Betracht genommen und in einer weiteren Entwicklungsiteration bearbeitet.

Fallbeispiel – Barclays Agile Transformation

Barclays, eine Bank, die immerhin schon 325 Jahre existiert, begann Anfang 2015 mit der Konzernweiten Transformation von traditionellen Hierarchien hin zu agilen Arbeitsmethoden. Die Wahl fiel dabei auf DA. Schauen wir uns anhand dieses Beispiels die daraus entstandenen Vorteile etwas genauer an.

Ausgangslage

Das Unternehmen verfügte bereits vor der Transformation über Teams, die mit Lean und Agile arbeiteten. Doch diese Teams arbeiteten relativ isoliert, und die Methoden wurden nicht breiteren Firmenkontext angewandt. Es waren sozusagen agile Inseln, die es zu verbinden galt.

Jedes Glied der Wertschöpfungskette sollte agil werden – von der Konzepterstellung bis zur Cash-Generierung. Das Endziel war eines der Prinzipien von DA: Delight the Customer – den Kunden zu entzücken.

Die Wahl des Frameworks

Die Agilitäts-Experten hatten die Wahl zwischen SAFe, LeSS und DA.

Eine Skalierung in einem Unternehmen dieser Größe erforderte ein Framework, das flexibel und stabil genug war, um eine effektive Skalierung zu ermöglichen. Gleichzeitig mussten Risiken und Wertschöpfungsfaktoren beachtet werden. Der Risikoaspekt, sowie zahlreiche Compliance-Erfordernisse, waren in diesem Fall besonders wichtig.

SAFe und LeSS sind in einem bestimmten Kontext passende Lösungen. Doch in dem mehr als 130.000 Mitarbeitern starken Unternehmen, welches tausende von Teams hat, musste eine flexiblere Lösung her. DA hat diese Flexibilität: je nach Kontext kann man aus einer Reihe von Methoden die richtige raussuchen – sogar SAFe und LeSS-Abläufe. Die Wahl fiel also auf DA.

Die Umsetzung

Innerhalb des ersten Jahres arbeiteten mehr als 800 Teams agil.

Um den Fortschritt in den einzelnen Teams zu messen, wurden Agility Levels eingeführt: Level 1 für Teams, die noch präskriptiv und praxisorientiert arbeiteten – nach dem alten Stil also – und jeweils Levels, 2, 3 und 4 für Teams die mehr Ausgangs- und Ergebnisorientiert waren. So konnte jedes Team in seinem eigenen Rhythmus voranschreiten.

Die Levels waren ein Indikator für die Agilitätsreife der Teams und bestanden aus einer Anzahl von Aspekten: Concept-to-Cash, Qualität, Teamstruktur, technische Kompetenz, bewährte Verfahren, fortlaufende Lieferung, usw.

So konnten die Teams experimentieren und sich richtig entwickeln. Die Schwierigkeit bestand darin, die Ziele der Geschäftsführung von den Beurteilungen der Teams deutlich zu unterscheiden. Manager mussten dabei großes Vertrauen zu den Teams aufbringen, die sich konstant selbst beurteilten.

Schulungen und Unterstützung von Agilitäts-Experten wurde ebenfalls bereitgestellt.

Die Vorteile

Die Durchsatzleistung ist um 300% gestiegen – also die durchschnittliche Anzahl an Stories, die jeden Monat pro Anwendung fertig gestellt werden.

In mehr als 80 Anwendungen ist die Komplexität der Codes ist um 50% gesunken. Gleichzeitig ist die Testabdeckung um 50% gestiegen.

Auch wurden weit weniger Rückstände verzeichnet, und mehr als die Hälfte aller strategischen Anwendungen erbringen mindestens alle 0-4 Wochen einen Mehrwert bei der Produktion.

Des weiteren sind die Mitarbeiter nach der Transformation glücklicher.

Fazit

DA eignet sich sehr gut für Unternehmen, die agile Arbeitsweisen in mehreren oder all ihren Abteilungen umsetzen möchten. Anpassungsfähig und flexibel, kann das Framework nicht nur mehrere agile Arbeitsmethoden vereinen, sondern auch Faktoren wir Risiko und Compliance mit einbeziehen.

Die Zielorientierte Lösung nutzt das beste aus vielen Welten, um in komplexen Umgebungen durch pragmatische Ansätze agile Arbeitsweisen einzuführen, die Problemlos Legacy Systeme integrieren können.

Das Ergebnis ist, das alle Teams Unternehmensbewusst handeln. Sie wissen, wie ihre Aufgaben effektiv erledigt werden können, und was für Auswirkungen das auf das Unternehmen als Ganzes hat.

Geschäftsperspektive

DA eignet sich sehr gut für die Abteilungsübergreifende Umsetzung agiler Methodologien im Gesamtkontext Ihres Unternehmens. Das flexible Framework erlaubt es Ihren Teams, sich ihre Arbeitsmethoden aus einer großen Auswahl an agilen Methoden auszusuchen und dabei Faktoren wie Risiko und Compliance im Auge zu behalten. Einige Beispiel der Geschäftsvorteile von DA sind erhöhter Kundenfokus, bessere Lieferrhythmen und Durchsatz und weniger Probleme mit ihren Produkten.

Quellen

Unsere Empfehlungen