1) Die Diskussion BPM + SCRUM finde sehr spannend. Danke für die vielen Anregungen bis hier hin!

2) Ich bin der Meinung, dass das größte Potential BPM und SCRUM zu kombinieren in genau einer Phase des BPM-Kreislaufs liegt: Prozessumsetzung. Hier denke ich vor allem an IT-Umsetzung. Folgende Argumente veranlassen mich zu dieser These:

- BPM liefert keine Antwort darauf, nach welchem Vorgehen in der IT die Anforderungen aus BPM-Projekten umsetzen soll. SCRUM liefert diese Antwort.

- SCRUM liefert keine Antwort darauf, wie man die Zusammenhänge komplexer Anforderungen darstellt. BPM nutzt hierfür erfolgreich die Prozessmodelle.

Das scheinen mir die “Low-Hanging-Fruits” bei der Kombination der beiden Themen zu sein (um ein weiteres Buzzword zu verwenden ).

Daran schließt sich die spannende Frage, wie und welche Prozessmodelle als Anforderungen im SCRUM verwendet werden können. Und werden User Stories dadurch überflüssich oder ergänzt?

Viele Grüße aus einem SCRUM-Projekt
Robert

das ist die Gefahr bei solchen agilen Projekten. Um diese Gefahr zu minimieren ist unser Ansatz, dass man den BPM-Kreislauf heranzieht um das große Ganze nicht aus dem Auge zu verlieren. Wir haben hierbei in unser Diskussion auch schon festgestellt, das so ein Kreislauf verdächtig nach Wasserfall oder (um im agilen zu bleiben) nach Kanban “riecht”. Das ist auch nicht schlimm. Wie suchen nach einer sinnvollen Lösung, dass heißt nicht, dass man sich zu 100% auf Scrum einschießt. Vielleicht heißt es auch hier: “Die Mischung macht’s!”
Daher vielen Dank für deine Kritik.

Schöne Grüße
Martin (W.)

da geb ich dir Recht. Leider verleitet SCRUM dazu, dass man das Große-Ganze aus dem Auge verliert und zu agil reagiert. Also gerade die Sache auf den Punkt zu kommen, einen “Workflow” zu testen, anzuwenden und ihn dann weiterentwicklen, verliert sich sehr schnell.

Gruß,
Daniel

der Unterschied zwischen Kanban und Scrum ist nicht sehr groß (siehe hierzu den Vergleich auf http://de.wikipedia.org/wiki/Kanban_in_der_IT ). Ich finde aber grade zwei Punkte von Scrum interessant. Durch die feste Sprintlänge muss versucht werden die Arbeitspakete möglichst klein zu halten. Dadurch wird meiner Meinung nach die Agilität durch die Methode stärker gefordert als bei Kanban, da dort die Pakete beliebig groß sind. Natürlich kann es hier zu dem Problem kommen, dass man keine vernünftigen Arbeitspakete schneiden kann die zu einem “auslieferbaren und lauffähigen Produkt” führen wie Scrum es fordert. Wenn man aber den großen Nicht-IT Teil in BPM Projekten betrachtet ist diese Forderung des Scrum eh hinfällig. Man kann bei Bedarf Scrum und Kanban kombinieren und eine Userstory in mehreren Sprints von Konzeption bis zur Umsetzung durchführen (jede klassische Projektphase in einem Sprint, wie bei Kanban). Hierbei wird aber die Agilität reduziert. Außerdem fehlen mir bei Kanban eine Definition der Rollen der Projektbeteiligten und es gibt keine zwingende Priorisierung der Anforderungen.

Schöne Grüße
Martin Wieschollek

Das BPM agil werden muss sieht er unter anderem an seiner Zukunft: er sieht wie Gartner (oder sieht Gartner wie er?) das dynamic BPM bzw. Case Management. Also auch das Thema, was ich schon in Bezug auf das Prozessverständnis im BPM-Netzwerk andiskutiert. Hier sind entstehen die Prozessstrukturen erst unterwegs, ähnlich der Evolution. Und gerade in diesem Kontext meint er, dass agile Methoden auch BPM-Projekten zu Gute kommen: in kleinen Schritten ändern. Und da wären wir auch gleich bei einer unserer Fragen im Workshop: halten die Anwender es aus, wenn immer wieder kleine Änderungen im Prozess gemacht werden? Ist es besser viele kleine Änderungen zu machen als eine große?

Als ein sehr großer Vorteil der Iterationen in SCRUM wird immer wieder hervorgehoben, dass die Motivation durch schnelle Ergebnisse (potentiell lieferbar) hoch gehalten wird. Und da wir ja nach Probleme gesucht haben, die beim Big-Bang-BPM-Projekt auftreten und daher SCRUM helfen könnte, kann man auch anders formulieren: Das warten auf Godot ist entnervend. Besonders wenn am Ende festgestellt wird, dass auf Grund von 10% fehlenden Funktionen noch eine weitere Ehrenrunde gedreht werden muss.

Das einzige, was ich auf Anhieb sehe, ist dass eine kontinuierliche Entwicklung sein muss. Sonst sitze ich nur an der Konzeption und fange nie. Das man BPMN auch sehr theoretisch betrachten kann, kennt ihr alle.

Ich bin gespannt auf weitere Ideen. ( derzeit ist es eher ein Marketing Gag )

Martin W. hat, ausgehend von Sebastians Einwand, natürlich recht. Bislang existiert nur das “dumpfe” Bauchgefühl, dass BPM + Scrum = Mehrwert ist. Wobei ich es persönlich aber auch total offensichtlich finde, muss ich gestehen: Die meisten BPM-Engagements werden als Projekte abgewickelt, und Scrum ist ein bewährter Ansatz zur Abwicklung von Projekten, der sich von klassischem Projektmanagement erheblich unterscheidet. Also ich finde es spontan völlig klar, dass man BPM und Scrum kombinieren sollte.

Aber vielleicht wäre das ja gleich eine sinnvolle erste Diskussion auf BPM-Netzwerk.de?

Viele Grüße, Jakob

Hallo Sebastian,
Ich arbeite seit 18 Jahren im Kontext des Prozessmanagements in den unterschiedlichsten Rollen, auch als Projektmanager. Derzeit bin ich Produktmanager und nehme dabei seit 2 Jahren die SCRUM-Rolle des Product Owners wahr. Da ich hier erfahren konnte, wie sinnvoll es ist, einen riesigen Berg (Backlog) an Funktionen in überschaubaren Zyklen (SCRUM-Iteration) im Entwicklugnsteam abzuarbeiten, kam mir die Idee, dass das doch auch gut in BPM-Projekten möglich sein muss, sozusagen agiles BPM. Und wie Jakob darstellte, gibt es hier mehrere Ansätze.
Wenn ich beginne, geht es mehr um die Erfassung aller Informationen, was sich häufig als schwierig und aufwändig herstellt. Vom Ist zum Soll heißt das viel zu diskutieren. Anschließend die Umsetzung, egal ob mit oder ohne Technik. Und wenn alles läuft, komme ich in die schnelleren Zyklen der Optimierung auf Basis gesammelter Daten. Auch das kann in Iterationen erfolgen.
SCRUM ist defintiv kein Buzzword, zumal man sich nicht sklavisch an alles halten muss, dass gepredigt wird. Auch BPM ist kein Buzzword, wenn es richtig gemacht wird. Allerdings gebe ich zu, dass hier noch viel Bedarf besteht, da die wenigsten Firmen hiermit angefangen haben. Aber wir sind auf einem guten Weg, siehe z.B. die Ausbildungen durch die BPM Akademie, inzwischen ja auch druch die camunda und der Zertifizierung zum BPM Experten durch die EABPM. Das sind keine Marketing-Wollken mehr. Hier kommt Struktur rein.
Viele Grüße, Martin