Blog

Disciplined Agile bzw. das Development Framework geht ursprünglich auf IBM zurück. Später wurde es in ein eigenständiges Consortium übergeführt und wird dort – mittlerweile als Teil der PMI-Familie – weitergeführt. Entwickelt aus der agilen Realität (und nicht Theorie).Wir erleben mit der Einführung agiler Methoden immer wieder spannende Dinge bis blaue Wunder. Das hat viele Gründe, und jeder hat dazu vermutlich seine eigene Geschichte zu erzählen. Es hängt wohl auch von der jeweiligen Situation ab: Bin ich in einem echten IT-Entwicklungsprojekt unterwegs, leite ich ein Projekt mit einer IT-Entwicklungskomponente (als eine von mehreren Teilen) – meistens bei mir der Fall, oder beschäftige ich mich mit der Entwicklung einer Organisation in Richtung „Agilität“? Disciplined Agile verfolgt hier nicht einen beschreibenden Ansatz, der Prozessdiagramme auf eine Wand malt, die mitunter erheblich von der Realität abweichen. Sondern es geht von der gelebten Praxis aus, in der manche Dinge einfach anders laufen und von Einschränkungen betroffen sind. Und in der man ganz bewusst eine Wahl haben möchte, wie man vorgeht. Auch sind Elemente enthalten, die sonst oft wenig Beachtung finden – wie zum Beispiel das Risikomanagement. Stichwort „Einschränkungen und Abhängigkeiten“: Die gibt es nun einmal, so oder so. Disciplined Agile sorgt weder dafür, dass sie real verschwinden - oder auch nur aus dem Blickfeld (übrigens etwas, das ich bei Projekten mit agiler Entwicklung immer wieder erlebe), sondern schafft Verständnis dafür und sorgt für Strukturen, damit umzugehen und zugleich möglichst agil zu bleiben. Mehr als Development.Bei Disciplined Agile besteht der Lifecycle einer Entwicklung aus drei Phasen, wobei jede Phase auf konkrete Ziele verweist. In der Inception-Phase geht es um das Aufsetzen der Organisation und des Teams, den Scope, Releases, die Test-Strategie... unter Betrachtung des Umfeldes, wie zB der unternehmerischen Ausrichtung und Strategie, Architektur & Co. Bei den Anforderungen geht es klar auch um nicht-funktionale Themen, die nicht nur „auch wichtig“ sind sondern womöglich sogar ein kritisches Qualitätsmerkmal des Produktes darstellen, das erst zur wirklichen Annahme des Produktes führt. In der Construction Phase wird gebaut, wobei früh eine „IT-architektonische Stabilität“ sicherzustellen ist und man sich durch bewussten Fokus auf Qualität mit einer „Consumable Solution“ (in klarer Abgrenzung zu „Working Software“) beschäftigt und diese liefert. Natürlich sind insbesondere in dieser Phase die zahlreichen bekannten Methoden der agilen Entwicklung in Anwendung, die wir kennen und die gut funktionieren. Als dritte und letzte Phase gibt es die Transition, in der sichergestellt wird, dass die Lösung wirklich und ganzheitlich das beinhaltet, was man liefern wollte. Durch diese drei Komponenten werden jene Betrachtungselemente ergänzt, die bei einer reinen Entwicklung mit zB SCRUM (der ehrlicherweise primär im Einsatz befindlichen Methode der agilen Entwicklung) eher fehlen. Auch liegt der Fokus immer auf den Endzielen und dem Endergebnis – nicht auf den unmittelbar nächsten Schritt. Disciplined Agile sieht hier übrigens auch nicht nur einen einzigen Lifecycle-Typ vor, sondern mehrere. So kann man die Vorgehensweise passend zur jeweiligen Situation wählen – je nachdem, ob ich zB mehr explorative Elemente vor mir oder inwiefern ich Änderungen zu erwarten habe. Kritische Geister könnten nun sagen: Naja, das ist ein hybrider Ansatz, bei dem eine agile Methode in einem „Sandwich of prediction“ steckt. Hybrid durchaus, ja. Inception und Transition müssen jedoch weder besonders lang sein, noch überhaupt existieren – je nachdem, wie weit und reif die Teams und damit die Organisation sind. Bei laufenden Lieferungen mit entsprechendem Lean-Design (auch im Sinne einer kontinuierlichen Weiterentwicklung) habe ich evtl. irgendwann nur mehr die Entwicklung (Construction) als Element übrig. Spätestens beim Betrieb kommt auch das Thema DevOps auf den Tisch: Disciplined Agile beinhaltet auch Disciplined DevOps und damit eine integrierte Betrachtung von Entwicklung und Betrieb in einem sich ständig weiterentwickelnden Zyklus. Working Software: Nein. Consumable Solution: Ja.Die Idee einer inkrementellen Entwicklung ist natürlich schön, vorallem wenn ich feste Zeiten und einigermaßen fixe Ressourcen habe. In einer End-2-End Betrachtung ist aber so manches Inkrement zwar für sich funktionell, die Lösung aber in Summe doch nicht akzeptabel. Auch erleben wir immer wieder Schwierigkeiten beim Design der Systemarchitektur und der gleichzeitigen Entwicklung der Software sowie mit Abhängigkeiten von anderen Systemen und Prozessen. Dieser letzte Schritt einer integrierten Betrachtung des Systems findet bisher mitunter begleitet von Konflikten oder zumindest Reibungsverlusten statt – bei Disciplined Agile gibt es auch dafür Raum und Struktur. Skalierung bitte.Den Begriff der Skalierung höre ich immer wieder, wobei ich den Eindruck habe, er wird für unterschiedliche Dinge verwendet. Disciplined Agile greift das Thema auf, und zwar in zweierlei Hinsicht: Ein Mal geht es um die Skalierung aus der reinen Entwicklungsebene (ich spreche da gern vom „Entwicklungsprozess“) auf die Projekt- oder Programmebene. Das andere Mal wird die Skalierung in die gesamte Organisation betrachtet. Dadurch wird erkennbar, dass Disciplined Agile für unterschiedliche Personengruppen interessant und relevant ist. Insbesondere bestehenden SCRUM Masters, ProjektmanagerInnen aus der IT – aber auch Leuten aus dem PMO empfehle ich, sich das Thema einmal näher anzuschauen. Was gefällt mir bei Disciplined Agile am besten?

• Komplexe Dinge komplex sein lassen. Entwicklungsprojekte, ihr Umfeld in einem näheren Sinn (zB Falls sie Teil eines größeren Programmes sind) und in einem weiteren (die Organisation, der Markt usw.)... das ist eben komplex. Statt zu versuchen, Dinge zu vereinfachen, indem ich Dinge wegblende, gefällt mir besser, Strukturen zu haben, um mich damit zurechtzufinden.
• Ganzheitlich denken. Die Entwicklung ist oft ein Teil von etwas größerem. Sei es im Tun selbst (zB als Bestandteil eines Programmes), in der Organisation, in der Systemumgebung, in den Prozessen... Und natürlich aus Kundensicht (Stichwort End2End-Betrachtung). Diese Dinge mit zu betrachten ist zwar ein bisschen anstrengender, als darauf zu verzichten – es macht sich aber bezahlt.
• Integriert. Was in Disciplined Agile steckt entspricht in weiten Teilen dem, was sich mein Bauch und Kopf seit Beginn des „agile Booms“ denken. Durch den integrativen Ansatz kann man auch sehr leicht Verbindungen zu anderen Disziplinen, Wissensgebieten, Frameworks und Standards des Projektmanagements herstellen.

  Und das ist erst der Anfang. Da Disciplined Agile nun ein Teil der PMI Familie geworden ist, liegt auf der Hand, was als Nächstes kommt: Das bestehende Wissen wird weiter ausgetauscht, integriert und multipliziert. Und so wird dafür gesorgt, dass wir ständig neue Dinge erfahren, die in unseren Projekten (und in unserem Leben) gut funktionieren.