Prozessmanagement und Scrum - ein Widerspruch in sich?

Agile Ansätze legen großen Wert auf Selbstorganisation und Freiwilligkeit. Das agile Manifest von 2001 besagt, dass Individuen und Interaktionen einen höheren Wert haben als Prozesse und Werkzeuge. Somit stellt sich die Frage, ob bzw. wie Scrum und Prozessmanagement zusammen passen.

Vielleicht haben Sie die Situation auch schon erlebt: Das neu gegründete Scrum-Team ist im Unternehmen erfolgreich gestartet. Es arbeitet gewissenhaft nach den Rollen, Meetings und Artefakten von Scrum. Das Team steht da als Insel der Agilität, das wie ein Start-Up sein Schicksal selber in die Hand genommen hat. Nur: Es ist kein Start-Up und auch keine Insel, sondern ein Knoten im Netzwerk der Gesamtorganisation. Und das bedeutet: Es gibt Abhängigkeiten. So sind Konflikte schnell da, etwa wenn das Scrum-Team neue Mitglieder nach eigenen Vorstellungen rekrutieren möchte, der HR-Prozess dafür jedoch die Linie vorsieht. Oder wenn das Team zur Fertigstellung des Produktes mit Einkauf, Produktion oder technischer Dokumentation zusammen arbeiten muss, diese Funktionen jedoch nicht in Sprints arbeiten.

Eine Kostprobe gefällig, wie ein solcher Konflikt aussehen kann? Das Scrum-Team beansprucht, mit jeder Iteration ein potenziell auslieferbares Produktinkrement in der Hand zu haben. Doch der Prozess der technischen Dokumentation ist darauf nicht vorbereitet. Er sieht vielmehr vor, dass erst mit Ende der Entwicklung (wenn sich nichts mehr ändert) die Anleitungen erstellt werden und schließlich in die Übersetzung gehen.

Es gibt keine Inseln der Agilität

Nehmen wir die agilen Ansprüche eines Scrum-Teams ernst, dann kann es keine Inseln der Agilität geben. Eine Organisation muss auf lang oder kurz Wege finden, um die Widersprüche zwischen ihren Scrum-Teams um dem Rest der Organisation aufzulösen. Andernfalls bleibt das agile Versprechen, mit jedem Sprint ein fertiges Inkrement auszuliefern, Makulatur.

Nun können wir es uns einfach machen und behaupten, dass Prozesse einfach nur „agilisiert“ werden müssen. Um auf das oben genannte Beispiel der technischen Dokumentation zurück zu kommen: Der Prozess könnte so geändert werden, dass die Dokumentation ebenfalls iterativ und inkrementell entsteht. So würde diese im Gleichschritt mit der Entwicklung wachsen und mit dem letzten Sprint fertig sein.

So einfach ist das leider nicht. Denn die Unterschiede zwischen einem agilen Ansatz wie Scrum und dem, was wir unter „Prozessmanagement“ verstehen, gehen deutlich tiefer. Während wir mit Prozessen die Abläufe in Unternehmen gestalten und steuern wollen, ist in Scrum sehr wenig vorgebaut. Der Blick auf die klar definierten Rollen, Meetings und Artefakte in Scrum mag zwar den Eindruck wecken, dass es sich auch bei Scrum nur um ein weiteres Vorgehensmodell handelt. Bei genauerer Betrachtung wird jedoch erkennbar, dass Scrum gar nicht mit dem Anspruch antritt, ein Prozessmodell zu sein.

Denn viel wichtiger als das Konzert aus Rollen, Meetings und Artefakten ist in Scrum der Ansatz, mit einem minimalen Satz an Vorgaben einen offenen, weitestgehenden nichtdeterminierten Rahmen zu spannen, in dem die Abläufe durch empirische Erfahrungswerte überhaupt erst erprobt werden und dann kontinuierlich angepasst werden.

So gesehen muss die Frage, wie Prozesse modelliert werden sollen, von den Erfahrungen der Scrum-Teams ausgehend gestellt werden.

Der Satz aus dem agilen Manifest, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge, kann dann folgendermaßen interpretiert werden:

Weil wir mit Scrum einen offenen, weitgehend nichtdeterminierten Rahmen verwenden, in dem Teams die Voraussetzungen für ihre Lieferfähigkeit mit jeder Iteration reflektieren und anpassen, kann die Frage nach den richtigen Prozessen und Werkzeugen erst aus dieser Erfahrung heraus beantwortet werden.