open oose: Agiles BPM

Ich habe mir letzten Freitag einen Seminartag bei oose in Hamburg gegönnt. Das Thema des Seminars war „Agiles Business Process Management“ und wurde gehalten von Andrea Grass und Christian Weiss, einem der Geschäftsführer von oose.

Nachdem wir uns zunächst vergegenwärtigt hatten, wie der typische Ablauf der Geschäftsprozessmodellierung aussieht (Analysieren – Entwerfen – Umsetzen – Messen) und wie BPM-Projekte klassifiziert werden können, wurde die agile Welt aufgegliedert in

• Praktiken: Timeboxing, User Stories, Daily Scrum, Retrospektiven, Backlog, …
• Vorgehen, Rahmenwerke: SCRUM, APM, Kanban, X, …
• Prinzipien: inkrementelle Entwicklung, häufiges Feedback, Selbstorganisation, direkte Kommunikation, …
• Werte: Menschen und Zusammenarbeit vor Prozessen und Tools (siehe Agiles Manifest)

Nach einem sehr interessanten Ausflug in die Inhalte des Buches Denkwerkzeuge der Höchstleister, kam dann ein äußerst anschauliches Spiel agiler Praktiken. Die Trainer nannten es das

Energieballspiel

Der Product Owner gab uns einen Eimer voll Tennisbälle und wies uns an, „Energiebälle“ herzustellen, indem ein Ball von einem zum anderen Team-Mitglied geworfen wird. Dabei durfte die Weitergabe der Bälle nur durch die Luft geschehen und nicht an den linken oder rechten Nachbarn. Zudem musste der Energieball von jedem Team-Mitglied mindestens einmal berührt werden und am Ende wieder am Ausgangspunkt ankommen.

Für jeden Energieball im Zieleimer gab es einen Punkt, für jeden Ball, der nach Zeitende noch „im System“ war, gab es einen Minuspunkt. Vor dem Spiel sollten wir eine Schätzung abgeben, wieviele Punkte wir in einem 2-minütigen Sprint erzielen würden. Nach jedem Sprint hatten wir zwei Minuten Zeit für eine Retrospektive und erneute Schätzung.

Zwischen den Sprints verunsicherte uns der Product Owner verbal und beim letzten Sprint störte er gar aktiv das Geschehen durch Herausnahme eines Team-Mitglieds.

Die Erkenntnisse aus diesem Spiel waren sehr anschaulich:

• Die Retrospektive hat maßgeblich an der Steigerung der Leistung und an der Verbesserung der Schätzungen beigetragen.
• Eingriffe und Verunsicherungen des Product Owners erforderten neue Ausrichtung des Teams und störten somit die Effizienz. Die Rolle des Scrum Masters, der die Aufgabe hat, das Team vor äußeren Einflüssen zu schützen, war nicht besetzt.
• Alle Mitspieler hatten eine gemeinsame Verantwortung am Ergebnis (selbstorganisierendes Team).
• Jedes System hat eine natürliche Produktivität (Velocity), die nur durch größere Änderungen gesteigert werden kann.

Fazit

Die nachfolgenden Diskussionen und Übungen zielten darauf ab, bestimmte agile Praktiken (User Stories, Features, Test First, Test-Automatisierung, Continuous Integration usw.) auf die BPM-Welt zu übertragen. Dies war nicht immer einfach und man erkannte, dass es für einige Praktiken durchaus möglich ist, sie in bestimmten BPM-Projekten anzuwenden, man sich bei anderen aber noch mehr Gedanken machen muss, wie eine Übertragung praktisch aussehen kann.