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

Energieball-Fabrik
Energieball-Fabrik

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.

 

Thomas Schneider

Ich leite derzeit das Business Process Management (BPM) bei Anschütz in Kiel, zuvor das Prozessmanagement im Engineering, bis 2008 in einem deutsch-japanischen Jointventure im Bosch-Konzern. Ich bin diplomierter Informatiker und begeistere mich neben den klassischen Prozessmanagement-Themen für Software-Tools und Digitalisierung.

2 Kommentare

  1. Mh, müsste ich mal prüfen. Aber es gibt ja jetzt schließlich auch schon IE9. Da kann man doch mal wechseln, falls der Aufwand des Change Management nicht zu hoch ist ;-)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Schaltfläche "Zurück zum Anfang"