In der jüngeren Vergangenheit stoße ich immer wieder auf Diskussionen – sei es nun intern mit meinen Kollegen oder beim Stöbern an einschlägigen Stellen im Netz – ob und wie BPM und Scrum gemeinsam zu Einsatz kommen können und wenn ja, wie. Ich nehme das an dieser Stelle zum Anlass, einige Erfahrungen aus der Praxis darzustellen.

Der Dämpfer zuerst

Ein Blick in das agile Manifest fördert zunächst Ernüchterung zutage:

„Individuals and interactions over processes and tools”

Na toll, das klingt auf den ersten Blick wenig erfolgversprechend. Aber schauen wir hinter die Kulissen und machen uns ein eigenes Bild.

BPM: ein weites, facettenreiches Feld

Unbestritten ist, dass BPM ein weitreichender Themenkomplex aus technischen, fachlichen und Aspekten aus der Organisationsentwicklung ist.Die Umsetzung eines einzelnen Geschäftsprozesses stellt nur einen kleinen Ausschnitt dar. Da dieser Blog-Beitrag aber kein abendfüllender Ersatz für schlechtes TV-Programm sein soll, beschränke ich mich zumindest für den Moment auf die Konzeption und technische Umsetzung eines zuvor dafür identifizierten Geschäftsprozesses.

Was kann BPM beisteuern?

In der Regel folgen wir bei der Fragestellung von Konzeption und Modellierung der Methodik von Bruce Silver und anderen: Wir gehen über die BPMN und die Level 1, 2 und 3 vor.

Level 1 nutzen wir, um einen Überblick über den Gesamtprozess zu bekommen. Daraus lassen sich schon recht gut Inhalte und Verantwortlichkeiten sowie die Abhängigkeiten der fachlichen Einheiten – der Bausteine – des Gesamtprozesses ableiten, wenn das Level 1 einen ausreichenden Reifegrad erreicht hat.

Auf dieser Basis beginnen wir, mittels Level 2 die Prozessmodellierung in die Tiefe zu treiben. Da wir über das Level-1-Modell die Verantwortlichkeiten herausgearbeitet haben, können wir dies tatsächlich in den meisten Fällen seiteneffektfrei tun. Die konkrete Ausgestaltung eines Subprozesses A hat also in der Regel keinen Einfluss mehr auf die Inhalte von Subprozess B. Dies gilt für den Regelfall –  natürlich kann das vorkommen, aber durch ein reifes Level 1 lässt sich dies deutlich minimieren. Bestandteile von Level 2 sind insbesondere Prozessmodelle bis auf Task-Ebene und fachliche Fehler- und Ausnahmebehandlungen jenseits des „Happy Path“.

Mit Level 3 gehen wir recht pragmatisch um. Heißt: wir meinen damit nicht per se „ausführbares BPMN“. Generell verstehen wir darunter die Einbringung von technischen Gegebenheiten in die Prozessmodelle. Das ist einerseits die Unterfütterung mit konkreten Service-Modellen und Dialogen, andererseits zählen aber auch aus technischen Gründen notwendige Schritte wie beispielsweise die Ermittlung von prozessrelevanten Daten zu einer ID dazu.

Zusammenspiel mit Scrum

Die spannende Frage ist nun, wie sich dieses Vorgehen mit Scrum verheiraten lässt, bzw., wie sich die Elemente von Scrum daraus ableiten lassen.

Produktvision

Der Scrum-Prozess beginnt mit einer Produktvision. Für das Produkt eines umzusetzenden Geschäftsprozesses lässt sich diese recht gut durch ein Prozessdiagramm in BPMN Level 1 untermauern, konkretisieren und anschaulich an die Teammitglieder transportieren. Das entbindet den Product Owner aber nicht davon, eine wohlformulierte Vision zu verfassen. Diese sollte die Essenz dessen, was das Prozessmodell darstellt, transportieren und neben dem fachlichen Inhalt auch den Zweck bzw. das Ziel, den Geschäftswert und die Zielgruppe beinhalten. Wie gesagt, das Prozessmodell unterstützt die Vision, ersetzt diese aber nicht. Sie trägt aber definitiv zu deren Konkretisierung und zur Schärfung der Vorstellung des Produkts bei.

Backlog

Als nächstes gilt es, das Backlog mit Features und den dazugehörigen User Stories zu füllen und diese zu priorisieren.

Wir haben dabei folgenden Ansatz gewählt:

Das zuvor erstellte Prozessmodell haben wir so weit verfeinert, bis sich die fachlichen Anforderungen in Form von Prozessbausteinen (Prozess, Subprozess, Prozessschritt) identifizieren ließen und wir ihr Zusammenspiel und ihre jeweiligen Verantwortlichkeiten betiteln und bewerten konnten.

Dazu mussten wir keine flächendeckende Tiefenbohrung machen und auch nicht jede Eventualität oder fachliche Ausnahmesituation berücksichtigen. In Silver’schen BPMN-Sprech bedeutet das, dass wir uns oberhalb von Level 1 und deutlich unterhalb von Level 2 bewegt haben. Damit ist genau der Reifegrad des Modells gemeint, der weiter oben schon angesprochen wurde.

Aus den Prozessbausteinen, die wir zuvor aus den Anforderungen abgeleitet haben, haben wir dann jeweils ein eigenes Feature gemacht und dieses mit relevanten Abnahmekriterien versehen. Bei Prozessen und Subprozessen beschränkten sich Inhalt und Abnahmekriterien auf die Ablaufsteuerung bzw. deren Korrektheit. Die Features für die Prozessschritte rankten sich um die Geschäftslogik der durch die Schritte repräsentierten Services (Service Tasks) oder Dialoge (Human Tasks).

Ein Backlog in einer ersten Fassung inkl. Features hatten wir nun also. Allerdings waren die Features noch nicht nach Geschäftswert priorisiert und die Reihenfolge orientierte sich zunächst am Prozessablauf. Die Priorisierung warf dann einige spannende Fragen auf. Nämlich, ob ein Prozess oder die enthaltenen Services höher zu priorisieren sind. Für die Konzeption ist ein Top-Down-Vorgehen analog der Prozesshierarchie einfacher, weil grobe fachliche Einheiten in immer kleinere Teile zerlegt und beschrieben werden können. In der Entwicklung wirkt dagegen ein Bottom-Up-Ansatz intuitiver, da sich die entstandenen Bausteine so zu größeren Einheiten zusammenfassen lassen. Letztlich haben wir uns für einen pragmatischen Umgang entschieden und in der Entwicklung mit Elementen wie Mocks gearbeitet – was ja grundsätzlich keine schlechte Idee ist – oder in anderen Fällen die Einbindung von Services und damit Prozessschritten erst dann vorgenommen, als diese im Backlog an der Reihe waren.

Die tägliche Arbeit

Im Sprint haben wir dann die Konzepte und Modelle in die Tiefe getrieben. Neben einer strukturierten textuellen Beschreibung war das Ergebnis ein BPMN-Level-2-Modell. Das bedeutet, dass wir uns um Ausnahmebehandlungen Gedanken gemacht und die konkrete Fachlichkeit von Services sowie die Dialoge genauer beschrieben haben. Da wir uns vorher schon mittels des Level-1-Modells Gedanken über Abhängigkeiten und fachlich abgeschlossene Bereiche Gedanken gemacht haben, hielten sich spätere Umbaumaßnahmen erfreulicherweise im Rahmen. In der Regel haben wir bestehende Dinge erweitert und nicht substantiell geändert.

Aber natürlich haben sich Anforderungen geändert und das anfängliche Modell war Änderungen unterworfen, da wir anfänglich auch einfach „mal falsch lagen“ – das Leben ist gemein.

An dieser Stelle ist die Erkenntnis einer eigentlich bekannten Tatsache unumgänglich: ein Feature entspricht nicht einem Software-Artefakt. Bedeutet: das Fertigstellen eines Features heißt nicht, dass ein zugehöriges Artefakt nicht durch weitere Features geändert wird – genau das wäre die Illusion des Wasserfalls! Ein neuer Prozessschritt zieht neben der Erstellung eines Services oder Dialogs auch die Änderung des nutzenden Prozesses nach sich.

Ein Beispiel: die Anforderung, Rechnungen in Fremdwährungen bearbeiten zu können, kann zu einem Prozessschritt zur Umrechnung in Systemwährung, aber auch zu Änderung von mehreren bestehenden Services führen, die dann mit der Fremdwährung umgehen können müssen. In beiden Fällen müssen bestehende Artefakte geändert werden. Genau dieser flexible Umgang mit neuen oder geänderten Anforderungen und den damit einhergehende Refactorings sind Grundfesten von agilen Methoden.

Fazit

BPM und Scrum können sich, richtig angewendet, sinnstiftend ergänzen. Weder wirkte sich Scrum invasiv auf die BPM-Methodik aus, noch hemmte diese andersherum das Vorgehen mit Scrum. Vielmehr haben einige Elemente aus BPM sogar einen förderlichen Beitrag zum Vorgehen mit Scrum geleistet. Zurückblickend, aber auch ausblickend, würde es mir mittlerweile wahrscheinlich fast unorganisch vorkommen, in weiteren Projekten anders vorzugehen und den alten Wasserfall wieder rauszukramen.

Und nebenbei: die „processes“ im agilen Manifest beziehen sich weniger auf die Fachprozesse eines Unternehmens als auf das Vorgehensmodell bei der Produktentwicklung – Schwein gehabt ;-)