Agile Organisationsentwicklung: Ein Domänenmodell hält Projekte auf Kurs

In agilen Projekten wird iterativ gearbeitet. Alle Anforderungen stehen in einem Product Backlog, werden priorisiert und in den einzelnen Sprints schrittweise umgesetzt. Dabei wird bereits geschäftlicher Nutzen erzeugt und die jeweils neu erzeugten Funktionsbausteine soweit irgend möglich schon in den Echtbetrieb genommen. 
Aber kann dabei nicht auch großer Murks erzeugt werden? Kann es nicht vorkommen, dass man nach dem 25. Sprint feststellt, dass man sich in eine Sackgasse entwickelt hat? Können sich die neuen Anforderungen Nummer 94 und 95 nicht mit  den schon realisierten Funktionalitäten 1 bis 93 widersprechen? Wie sichert man eine konsistente Gesamtlogik des Projekts über all seine Sprints hinweg? 

Eine Antwort darauf heißt „Domänenmodell“.

Ein Projektbeispiel

Die Industriebau AG (IBAG) möchte ein Dokumentenmanagement einführen. Zwei ganz unterschiedliche Bereiche mit ihren Prozessen äußern ihr Interesse, als Pilotabteilungen zu fungieren. Es handelt sich

• um den Vertriebs-Außendienst mit seinen sehr komplexen Projekten (Vorentwürfe von großen Bauvorhaben, meist Lagerhallen mit Logistik, aber auch Verwaltungsgebäuden),
• und um die Personalabteilung mit ihren eher stark strukturierten Prozessen.

Herr Klingmann von der IT-Abteilung schlägt das klassische Vorgehen vor:

„Wir verfassen ein Lastenheft, gehen an den Markt, suchen eine passende Software aus. Und die wird dann implementiert und die Mitarbeiter geschult.“

Die Pilotabteilungen spielen in einem solchen Szenario keine Rolle. Die Gefahr ist groß, dass das  beschaffte DMS zu deren Anforderungen so gut passt wie ein Schuh von Zalando an den Fuß des Internetkunden: Es zwickt und kneift. (Dafür ging es total schnell und war supergünstig!)

Peter und ich als externe Berater bringen ein agiles Vorgehen ins Gespräch. Dabei werden die „Projektkunden“, nämlich die künftigen Anwender, aktiv in die Anforderungsdefinition einbezogen. Und diese Anforderungen werden nicht „am Stück“ umgesetzt, sondern iterativ. Die Umsetzung erfolgt so lange wie möglich mit „Bordmitteln“ wie Windows-Dateisystem oder Sharepoint. Die Beschaffung eines DMS soll möglichst erst nach einem Drittel der gesamten Projektlaufzeit erfolgen. So sichert man sich schnelles Feedback der Anwender und kann die Anforderungen nachjustieren.

Die Geschäftsführung als Budgetgeberin schließt sich unserer Argumentation an. Herr Klingmann bleibt skeptisch und kreuzt innerlich die Arme. „Mal zusehen, was die so machen.“

„Die“ lassen die Anwendervertreter der beiden Bereiche in zwei Workshops Storymaps entwerfen und Userstorys formulieren. Am Ende des Tages stehen wir mit 25 Userstorys des Vertriebs und 37 Userstorys der Personalabteilung da.

Am nächsten Tag sitzen wir mit der IT zusammen und schauen uns die Userstorys an. Welche Schlussfolgerungen für ein DMS ergeben sich daraus? Herr Klingmann macht aus seinen fortbestehenden Zweifeln keinen Hehl:

„Wir haben zwei Abteilungen von 14. Die zwei Abteilungen haben zusammen vielleicht 30 Prozesse (der Vertrieb hat wenige komplexe, die Personaler haben viele einfachere). Davon haben wir jeweils zwei ausgewählt (zugegeben die wichtigsten). Von diesen Prozessen haben wir Storymaps erstellt, aber daraus dann auch wieder nur jeweils fünf bis sechs Items ausgewählt.

Wie garantieren wir, dass diese ganz ganz eingedampfte Stichprobe wirklich auch ein gutes Bild von der Gesamtdimension der Anforderungen ergibt? Wie können Sie sicher sein wollen, wenn wir das DMS beschafft haben und dann noch eine ganz andere Abteilung ins Projekt reinnehmen – dass dann noch Anforderungen reinkommen, an die wir überhaupt nicht gedacht haben?“

Die Fachdiskussion über die Vorzüge des Wasserfalls

Herr Klingmann steht mit seiner Meinung nicht allein. Sie ist ja auch nicht von der Hand zu weisen. Als externe Berater könnten wir natürlich in die Rolle der gläubigen Scrum-Anhänger schlüpfen und seine Kritik einfach abbügeln. Zum Beispiel mit dem Hinweis, dass die herkömmliche Wasserfallmethode gescheiterte Projekte am Fließband produziert. Aber das wäre zu einfach.

Denn auch erfahrene Projektcoaches machen sich Gedanken über das Thema. In seinem Buch „Vorgehensmuster für Software-Architektur“ schreibt Stefan Toth /1/:

„Scrum und eXtreme Programming sind die am weitesten verbreiteten Vorgehensmodelle für agile Projekte. Beide wurden nicht für große oder komplexe Projekte entworfen  … Ein Symptom, das immer wieder zu beobachten ist, ist das Stocken des Entwicklungsprozesses in diesen Projekten. Nach Phasen, in denen  Features mit stetiger Geschwindigkeit ausgeliefert werden, gibt es Rückschläge und die Produktivität sinkt drastisch.“ (S. 21)

Und er beklagt:

„Die Reaktion auf diese Phänomene ist häufig alles andere als agil. Ich habe gesehen, wie ‚agile‘ Projekte Architektur großspurig wiedereinführen, eigene Architekturabteilungen wiederbeleben und dazu übergehen, wieder früh zu planen.“ (S. 22)

Aber warum sollte es nicht gelingen, Nachhaltigkeit – also Umsicht und vorausschauendes Denken – mit Agilität zu verknüpfen? 

 Abb. 1: Die Verbindung von Wasserfall mit zirkulären Prozessen hat eine jahrtausendealte Tradition. /2/

Stefan Toth empfiehlt eine Integration von Softwarearchitektur-Arbeit in Scrum-Projekten. Wir sind einen etwas anderen Weg gegangen und haben mit einer „Begriffsarbeit“ begonnen.

Eine Liste von Fundamentalbegriffen

Wir setzen uns mit zwei Anwendervertretern aus den Pilotabteilungen sowie Herrn Klingmann und Frau Zicek, einer weiteren IT-Kollegin, zusammen. Als Vorgehensweise schlagen wir vor:

„Wir gehen jetzt die 62 Userstorys durch. Aber wir machen uns überhaupt keine Gedanken über ihre Umsetzung. Sondern wir filtern sie nur daraufhin durch: Was enthalten sie für grundlegende Begriffe? Also die wichtigsten Worte, in denen die Anwender ihre Anliegen beschreiben?“

Wir machen uns ans Werk. Die erste Userstory lautet:

„Als Vertriebler wünsche ich mir, dass alle Dokumente vergangener Projekte bei Kunden gleicher Branche und Größenordnung einsehbar sind, um meine Kundenansprache spezifischer gestalten zu können.“

Welche sind die wichtigsten Begriffe? Wir einigten uns auf

• „Dokument“,
• „Projekt“,
• „Kunde“,
• „Branche und Größenordnung“.

Diese vier Begriffe formulierten wir um. Zum Beispiel ist „Projekt“ der Spezialausdruck des Vertriebs für „Vorgang“. Aus „Kunde“ machten wir „Person/Kontakt“, Und „Branche“, „Größenordnung von Unternehmen“ sind eigentlich Wissensthemen.

Aus der ersten Userstory hatten wir so vier Fundamentalbegriffe herausdestilliert. Mit allen Diskussionen und Hin und Hers hatten wir fast 20 Minuten gebraucht.

"Das ist ja ein Schneckentempo!", stöhnte Herr Klingmann. Und er rechnete hoch: "Wenn wir so weiter machen, sitzen wir in drei Tagen noch da!" Peter schaute mich an; ich schaute Peter an. Wir sagten gar nichts. Wie sollten wir auch? Burndown-Chart ist Burndown-Chart.

Ähnlich langsam ging es weiter. Nach etwa anderthalb Stunden hatten wir weitere vier Userstorys durchgearbeitet und waren auf neun Fundamentalbegriffe gekommen:

1. Vorgang
2. Prozess
3. Vorgangsteam
4. Person / Kontakt
5. Thema
6. Dokument
7. Einzelinformation
8. Gegenstand / Inventar
9. Attribut

Herr Klingmann schaute nur noch sorgenvoll auf die Uhr, enthielt sich aber jeder Bemerkung. Er hatte innerlich mit uns abgeschlossen.

Ab da ging’s aber auf einmal sehr schnell. Es kamen bei den folgenden 57 Userstorys nur noch zwei weitere Fundamentalbegriffe hinzu:

10.    Abfrage
11.    Aktivität.

Meistens ging es so:

„E-Mail, das ist ein neuer Begriff.“ – „E-Mail ist doch ein Dokument! Das haben wir doch schon.“ – „Dann hängen Sie’s doch bitte in die Spalte unter ‚Dokument‘.“ – „Ja, aber E-Mails enthalten oft auch Arbeitsaufträge. Das ist was Neues.“ – „Nein, das ist doch auch schon da. Ein Arbeitsauftrag ist nichts anderes als ein ToDo. Und das fällt unter Aktivität, haben wir schon vor einer halben Stunde gesagt.“

In nur etwa einer Stunde waren wir durch mit den Userstorys. Das Fazit von Peter und mir war:
„Sie sehen, dass schon innerhalb unserer Userstorys ab einem gewissen Punkt kein neuer Fundamentalbegriff hinzukam. Und wir gehen von einer hohen Wahrscheinlichkeit aus, dass dies auch für die nächsten 1.000 Userstorys in unserem Gesamtprojekt gelten wird. Natürlich können wir das nicht garantieren.“
„Sehen Sie?“, sagte Herr Klingmann mit etwas rechthaberischem Ton (innerlich war er nämlich schon auf dem Rückzug). „Sehen Sie? Garantieren kann man nichts!“
„Hoppla“, meldete sich auf einmal Frau Zicek. „Aber wie war das im SAP-Projekt vorletztes Jahr? Da haben wir uns diese Art von Arbeit überhaupt nicht gemacht, aber ein Riesen-Lastenheft. Und was war der Erfolg? SAP läuft immer noch nicht rund, obwohl der SAP-Berater hier schon sein Feldbett aufgeschlagen hat und der Gebührenzähler jede Minute läuft. Genau das, was wir hier machen, hat im SAP-Projekt gefehlt! Also, Herr Klingmann, ich find’s klasse!“

Ein bisschen arbeiteten wir noch weiter. Wir stellten eine Liste der Status auf, die ein Fundamentalbegriff annehmen kann (z. B. ein Vorgang „in Prüfung“, „aktiv“, „Wartezustand“, „erledigt“, „storniert“). Und wir untersuchten ein bisschen die Beziehungen der Fundamentalbegriffe untereinander („ein Prozess kann n Vorgänge haben, aber ein Vorgang nur einen Prozess – oder doch mehrere?“).

Das war’s dann aber schon.

Abb. 2.: Eine Liste von Fundamentalbegriffen und Unterbegriffen zu einem DMS-Projekt

Ein Domänenmodell

Was haben wir gemacht?

1. Wir haben uns auf Begriffe geeinigt, in denen Anwender und Entwickler (bzw. Software-Beschaffer) sich verständigen können. Diese „Begriffsarbeit“ wurde auf einmal im Projektteam als wichtig begriffen: „Wir reden nicht mehr aneinander vorbei.“ Dieser Aha-Effekt wird dazu führen, dass die Begriffsarbeit im ganzen Projektverlauf in die Breite und in die Tiefe geführt wird. Sie ist nicht losgelöst von der agilen Projektlogik, sondern ab jetzt in sie integriert.
2. Die gefundenen Begriffe bilden die Geschäftslogik ab, noch keine Softwarelogik./3/ Das führt übrigens auch auf Seiten der Anwender zu mehr Klarheit. Auch sie verstehen sich untereinander auf einmal viel besser.
3. Insofern bildet unser Vorgehen die ersten Schritte hin zu einem Domänenmodell im Sinne von Eric Evans. /4/ Wir sind in der Schilderung unseres Beispielprojekts durchaus noch am Anfang zu einem solchen Modell. Zwei bis drei weitere Projekttage müssen sich anschließen. Aber dann verfügen wir über eine Strukturdarstellung, die alle Anforderungen im Product Backlog wie eine „geistige Klammer“ einrahmt und für Konsistenz auf einer sehr fundamentalen Grundlage sorgt.
4. Wenn man eine DMS-Software aussuchen will, vielleicht nach 33% oder 50% der Projektlaufzeit, dann kann man zumindest folgende negative Aussage treffen: „Eine Software, die eine oder mehrere Fundamentalbegriffe aus unserem Domänenmodell überhaupt nicht im Fokus hat, können wir guten Gewissens von vornherein ausschließen. Sie ist für unsere Zwecke nicht komplex genug.“

Die Erarbeitung des Domänenmodells am Anfang eines agilen OE-Projekts hat übrigens viel mit „exponentiellem Lernen“ zu tun. Dazu mal bei Gelegenheit mehr.

Anmerkungen

/1/ Stefan Toth: Vorgehensmuster für Software-Architektur, Kombinierbare Praktiken in Zeiten von Agi-le und Lean, Hanser Verlag, 2015, Print-ISBN: 978-3-446-44395-2, E-Book-ISBN: 978-3-446-44425-6
/2/ Quelle: http://wizard.webquests.ch/pics/upload/2341/oberschlc3a4chtigeswasserrad1_400.jpg
/3/ Das unterscheidet die hier vorgestellte Vorgehensweise von der Softwarearchitektur von Toth. Das wäre der nächste Schritt. Was wir gemacht haben, wäre die Grundlegung eines Lastenhefts. Die Softwarearchitektur würde dem Pflichtenheft entsprechen.
/4/ Eric Evans: Domain-Driven Design. Tackling Complexity in the Heart of Software, Addison-Wesley, 2004, ISBN: 0-321-12521-5