Kick-off: BPM + Scrum
February 19 2010 by Jakob Freund · 13 Comments
BPM + Scrum?
Sowohl BPM als auch Scrum werden immer beliebter. Lassen sich die beiden Disziplinen sinnvoll kombinieren? Wir glauben schon, und haben auch schon erste Versuche in diese Richtung unternommen, da wir nicht nur BPM-Experten sind, sondern auch Scrum-Expertise besitzen und das Thema entsprechend coachen. Ganz ähnlich geht es Dr. Martin Bartonitz von Saperion, und Martin Wieschollek von Seven Principles, und deshalb haben wir drei uns gestern mal bei camunda in Berlin zusammen gesetzt.
Wie man sich denken kann, ist das ein ziemlich großes Fass, das wir da aufgemacht haben. Und der gestrige Vormittag hat bei Weitem nicht gereicht, um das wieder schließen zu können. Deshalb haben wir zwei Dinge getan: Einfach mal gesammelt, welche Themen bzw. Fragen uns bei “BPM + Scrum” durch den Kopf gehen, und uns dann einfach mal welche herausgepickt und darüber diskutiert. Es wurde eine lebhafte und produktive Diskussion, und die ersten Ergebnisse kommen weiter unten.
Das Ganze ist 100% “work in progress”, aber ganz im Sinne von Scrum wollen wir nicht ewig tüfteln für die perfekte Lösung, sondern zeitnah unsere Ideen herausbringen, damit sie diskutiert und vielleicht sogar schon angewandt werden können. Für die Diskussion habe ich ein Forenbrett auf BPM-Netzwerk.de eingerichtet. Aber natürlich sind auch Diskussionen dazu im Rahmen von Events etc. denkbar, z.B. bei der Berliner BPM-Offensive. Ich werde das dort mal anregen.
Wir drei werden uns jedenfalls im März wieder treffen, um weiter zu diskutieren und die nächste Iteration unserer Ideen zu entwickeln. Die Ergebnisse werden wieder geblogged, entweder im Blog von Martin Bartonitz oder im Blog von Martin Wieschollek, je nachdem wer das nächste Mal Gastgeber und somit Moderator ist. Ich werde dann aber natürlich auch auf BPM-Guide.de darauf hinweisen.
BPM + Scrum: Ergebnisse des 1. Workshops (18.02.2010, camunda, Berlin)
Spontane Überlegung am Anfang: Prozessmodellierung ist kein Overhead
Wir sehen grundsätzlich keinen Widerspruch zwischen der Modellierung von Prozessen und dem agilen Manifest. Die zentrale Frage ist einfach, in welchem Umfang man Prozessmodellierung betreibt. Aber ganz unabhängig von User Stories etc. erspart uns ein kleines Prozessdiagramm eine umfangreiche textuelle Prozessbeschreibung, und das ist ist kein Bremser, sondern eine Hilfe für mehr Agilität.
Scope: Was betrachen wir?
Wir konzentrieren uns im ersten Schritt auf BPM-Projekte (Scrum ist ein Vorgehensmodell für Projekte), also weniger den kontinuierlichen Prozessbetrieb o.ä.. Diese Projekte können drei Ausprägungen haben:
- “Reine” IT-Projekte
- IT-Projekte mit Orga-Anteil (=> Change Management etc.)
- “Reine” Orga-Projekte
Auch wenn es die beiden Reinformen wohl kaum gibt, geht es darum, die unterschiedlichen “Ausmaße”, die der Orga- bzw. IT-Teil in einem BPM-Projekt haben kann, zu berücksichtigen.
Themen rund um BPM + Scrum
Das sind die Fragen, die wir uns spontan gestellt haben:
- Sprint und BPM-Kreislauf bzw. BPM-Projekt: Wie geht das zusammen?
- Scrum-Rollen im BPM-Projekt?
- Scrum-Artefakte im BPM-Projekt?
- Scrum-Zeremonien im BPM-Projekt?
- User Stories im BPM-Projekt?
Als estes haben wir uns der Sprint-Frage gewidmet.
Sprint und BPM-Kreislauf bzw. BPM-Projekt: Wie geht das zusammen?
camunda BPM-Kreislauf
Als Ausgangspunkt haben wir den BPM-Kreislauf von camunda genommen, der ja in ähnlicher Form von verschiedensten Firmen, Hochschulen etc. vertreten wird und noch relativ überschaubar, aber nicht marketing-mäßig trivialisiert ist.
Hier kommt schon das erste Problem: Im Kreislauf ist explizit von einer Phase der Prozesskonzeption die Rede, und danach kommt die Umsetzung. Das riecht verdächtig nach Wasserfall, und tatsächlich ist das ja auch die Denkweise, die dem allgemeinen Paradigma von Konzeption und Umsetzung zugrundeliegt: Erst entwerfe ich ein Haus, dann baue ich es. Spätere Änderungen unerwünscht. Das widerspricht Scrum. Wir sind trotzdem der Ansicht, dass die Prozesskonzeption als Phase erhalten bleiben muss. Hier subsummieren sich viele Tätigkeiten, die einer Prozessverbesserung richtigerweise vorausgehen, z.B. eine ROI-Abschätzung. In der Prozesskonzeption werden unter Umständen überhaupt erst die User Stories ermittelt, die ins Product Backlog eingehen.
Der Soll-Prozess ist nicht in Stein gemeißelt
Das heißt, wir gehen generell nicht mehr davon aus, dass die Soll-Konzeption und somit auch das Soll-Prozessmodell nach Abschluss der Konzeptionsphase fixiert ist, sondern dass es sich hierbei nur um eine Version 1.0 handelt. Diese Version 1.0 kann aber im Rahmen der Prozessumsetzung auch überarbeitet werden, dass Soll-Konzept bzw. der Soll-Prozess wird also auch während der Prozessumsetzung noch verändert (siehe Abbildung).
Das klingt jetzt irgendwie banal, aber tatsächlich schafft diese neue Prämisse einen großen Spielraum, aber auch große Herausforderungen. Allerdings genau die Herausforderungen, denen sich Scrum widmet, und für die Scrum ja auch Lösungsansätze bietet.
Nach dieser Grundsatzüberlegung kamen wir zur Gretchenfrage: Wie schneide ich meine Sprints? Ist eine Iteration im Kreislauf ein Sprint? Oder finden mehrere Kreislaufiterationen innerhalb eines Sprints statt? Oder anders herum sogar mehrere Sprints innerhalb einer jeden Phase im Kreislauf?
Die vorläufige Antwort lautet wie so oft: Es kommt drauf an 
, sprich das Ganze hängt maßgeblich von der Komplexität des Prozesses / der Prozesse bzw. des Verbesserungsvorhabens ab. Aber gehen wir mal von einem typischen “mittelschweren” Vorhaben aus, das sich locker über 6 Monate hinziehen kann. Nach einigen Versuchen, die Sprint=>Kreislauf-Frage “top-down”, also vom Groben zum Feinen, zu diskutieren, mussten wir erstmal aufgeben: Wir kamen nicht so recht weiter, auch wenn unser schönes BPMN-Framework dabei recht schnell eine zentrale Rolle spielte 
. Nein, wir entschieden uns, “bottom-up” vorzugehen, was die Diskussion sehr schnell konkret werden ließ und sich am Ende als zielführender herausstellte (wie so oft).
Sprich: Wenn wir jetzt mal nur die Phase der Prozessumsetzung anschauen, wie verhält sich diese zu einem Sprint? In einem mittelschweren Vorhaben (3-6 Monate), ist die Konsequenz ganz klar: Die Prozessumsetzung kann sich über mehrere Sprints hinweg ziehen, denn ein Sprint sollte idealerweise 3 oder 4 Wochen dauern, jedenfalls nicht 6 Monate. Diesen Grundgedanken übertrugen wir auf andere Phasen im Kreislauf:
Das Verhältnis von Kreislaufphasen zu Sprints ist häufig 1:N.
OK, spinnen wir den Gedanken für die Prozessumsetzung mal weiter, was müssen wir tun, damit das klappt? Schließlich sind Sprints eine ziemlich abgegrenzte Sache, mit jeweils eigenem Planning etc. Die erste Challenge (neben vielen weiteren) besteht also darin, die Prozessumsetzung in Sprint-fähige Phasen einzuteilen, wir müssen das Ganze “schneiden”. Das wiederum brachte uns zu einer Diskussion, die vorerst ohne Konsens beendet werden musste:
Ist es für die Akzeptanz der betroffenen Prozessbeteiligten (”Process Participants”) besser, wenn mehrere kleine Prozessänderungen erfolgen, oder ist es besser, wenn nur eine große Prozessänderung erfolgt?
Eine interessante Frage, die man vielleicht im Forum diskutieren könnte. Ja klar, es kommt mal wieder drauf an, aber ich selbst tendiere eher zu vielen kleinen Änderungen, als zu einer großen, solange es nicht die Änderungen selbst sind, die wieder geändert werden (denn das führt ja dann zum “heute hü, morgen hott”-Gefühl).
Obwohl wir hier keinen Konsens hatten, konnten wir trotzdem über mögliche “Schnittmuster” für die Prozessumsetzung diskutieren, um diese in Sprints aufzuteilen. Spontan eingefallen sind uns drei Muster:
Parallele Prozess-Stränge: Mitunter findet ein Prozess durch mehrere gleichzeitig ablaufende “Stränge” statt, sodass man die einzelnen Stränge in jeweils eigenen Sprints umsetzen könnte. Ein Beispiel, das Martin Wieschollek hierführ nennen konnte, war die Einschleusung neuer Mitarbeiter, also aus dem HR-Bereich.
Vertikal schneiden: Prozesse lassen sich oft in Phasen aufteilen, also sequentielle Teilprozesse, wenn man so möchte. Beispielsweise Bestellprozesse. Je nach Zeit und “Erlaubnis” kann ich hoffentlich bald ein Projektbeispiel hierzu bringen. Jedenfalls lassen sich diese Phasen bzw. Teilprozesse auf Sprints verteilen, wobei natürlich sicher gestellt werden muss, dass die “neuen” Teilprozesse mit den “alten” Teilprozessen gekoppelt werden können, z.B. über technische Schnittstellen.
Horizontal schneiden: Ein anderer Ansatz wäre, den Prozess end-to-end im ersten Sprint umzusetzen, aber nur für einen bestimmten organisatorischen Bereich, z.B. eine Niederlassung, oder für ganz bestimmte interne oder externe Prozessbeteiligte.
Wir haben uns vorgenommen, in den kommenden Wochen für jede dieser drei Ideen ein Beispiel zu formulieren und das Ganze auf dieser Grundlage weiter zu diskutieren. Martin Bartonitz hat heute direkt mal vorgelegt:
|
Prozessumsetzung horizontal schneiden: Beispiel von Martin Bartonitz
eBilling / elektronische Rechnung: Die Implementierung des Signierens von Ausgangsrechnung ist sehr schnell durchgeführt. In der Regel können die Ausgangsdokumente in ein Verzeichnis gespeichert werden. Hier holt sich der Signier-Service die Dokumente ab, verarbeitet sie und legt sie anschließend in ein anderes Verzeichnis ab, ggf. verschickt er die Rechnungen auch schon. Aus diesem Verzeichnis holt sich dann der Import-Service des Archivs die Dokumente ab und speichert diese zusammen mit den ebenfalls zur Verfügung gestellten Indexdaten. Wurden die Dokumente noch nicht verschickt, könnte dies nun auch das Archiv noch durchführen. Alternativ aber auch das ERP, das die Rechnungen erstellt hat. Schwieriger ist es, die Empfänger dazu zu bewegen, den Empfang auch zu akzeptieren. Denn dieser darf sich auch verweigern. Mann kann nun in mehreren Iterationen nach und nach die Empfänger einzufangen. Eine weitere Möglichkeit ist, eine kleines Unternehmen zu gründen, das die Verifikation der signierten Rechnugnen im Namen des Empfängers durchzuführen. So könnten die Empfänger für das Verfahren gewonnen werden, die aufgrund der geringen Anzahl von Rechnungen aus Kostengründen keinen Inhaus-Service einrichten wollen. Damit könnte das Schnittmuster wie folgt aussehen: Iteration #1 Implementierung Verfahren zum Signieren elektronischer Rechnungen (falls kein Archiv vorhanden: Iteration #0) papierbasierte Rechnungsverarbeitung Da der papierbasierte Prozess extrem langsam und fehleranfällig ist (verlorene Eingangsrechnugen -> Skonti verpasst), sollen sie gescannt, manuell indiziert, archiviert und über einen Workflow zur Freigabe inkl. gebracht werden. Damit könnte das Schnittmuster wie folgt aussehen: Iteration #1 bis #x Implementierung Dokumentenerfassung, Archivierung und Freigabeprozess Viele Grüße |
Scrum-Rollen im BPM-Projekt?
Danach haben wir noch kurz die Rollenfrage andiskutiert, sind aber aufgrund des Zeitlimits nicht sehr weit gekommen. Hier trotzdem mal der aktuelle Stand:
Product Board: Hier werden in Scrum die strategischen Produktentscheidungen getroffen, die der Product Owner in User Stories ausformulieren muss. Der Horizont der Entscheidungen dieses Boards liegt oft bei ca. 6 Monaten. Wenn wir ein ähnliches Gremium für einen oder mehrere Prozesse überlegen, wäre das ein Process Board, dem die Führungskräfte angehören, die den Prozess ganz oder teilweise verantworten, was mit dem Problem der Prozess-Matrixorganisation zusammenhängt. In unserem BPMN-Buch heißen diese Rollen Process Manager. Falls der Prozess nur von einem Process Manager verantwortet wird, bestünde das Board eben nur aus einer Person. Wichtig: Hier wird unter einem Process Manager also wirklich ein Entscheider verstanden, nicht bloß ein Inhouse-Consultant oder Methodenspezialist, das ist viel mehr der Process Analyst (siehe unten).
Product Owner: Die Analogie, die am ehesten zum Product Owner passt, wäre der Process Analyst, zumal dieser als Einziger in der Lage wäre, aus den Soll-Prozessmodellen die notwendigen User Stories abzuleiten.
An dieser Stelle mussten wir aus Zeitgründen einen Cut machen, obwohl sich natürlich gerade bei den Rollen zigtausend weitere Fragen auftun (z.B. Aus welchen Mitgliedern besteht das Scrum-Team, wenn die Verbesserungsmaßnahme ganz oder teilweise aus Change Management, also nicht IT-Umsetzung, besteht? Wie verändert sich die Zusammensetzung des Teams über mehrere Sprints hinweg, z.B. zuerst mehr Entwickler, später mehr Change Manager?).
Aber wie schon gesagt: Unser Anspruch ist es nicht, unangreifbare Weisheiten zu postulieren. Wir wollen einfach nur unsere Überlegungen, Ideen etc. mitteilen, evtl. Hilfestellung und Anregungen dadurch liefern, und natürlich Feedback sammeln und Diskussionen führen. Jedes Workshop-Ergebnis soll, so gut es halt geht, ein Working Increment sein, aber mit Sicherheit nicht der Weisheit letzter Schluss
Sorry, bitte nicht übel nehmen, aber Scrum und BPM zu mischen hört sich für mich einfach nach Buzzword Bingo an
2010-02-19 um 6.03 pm Uhr. Verfasst von SebastianNaja, klar sind das Buzzwords!
Genau so wie Business Rules, BPMN, SOA, Cloud, Community und weiß der Hugo alles Buzzwords sind. Deshalb ist aber keines der genannten Stichwörter perse Quatsch, bzw. macht die Kombination keinen Sinn. Im Gegenteil, was unter dem Thema SOA + BPM schon alles verbrochen wurde, mit völlig nichtssagender Phrasendrescherei, lässt BPM + Scrum ja doch sehr harmlos aussehen. Vor allem, wenn man es derart bodenständig angeht, wie wir das gerade tun.
Und ich glaube auch, dass das Verhältnis von erfolgreichen Scrum-Initiativen mit konkretem Nutzen im Vergleich zu “Scrum als Buzzword-Verblendung” um Längen besser ist, als das z.B. bei SOA und ich glaube auch leider leider BPM der Fall ist.
Und die Mischung macht m.E. erst recht Sinn. Es existiert keine einzige BPM-Quelle, die wirklich konkret beschreibt, wie ein BPM-Projekt nach modernen, sprich agilen, Maßstäben abgewickelt wird. Auch hier glaube ich: Der komplementäre Effekt ist vermutlich sogar größer als bei BPM und SOA!
2010-02-19 um 6.21 pm Uhr. Verfasst von Jakob FreundHallo Jakob,
die Zusammenfassung unserer Ergebnisse gefällt mir gut. Mein Beispiel zum schneiden paralleler Prozessstränge um Pakete für einzelne Iterationen zu haben werde ich schnellstmöglich aufbereiten
Die Anmerkung zum Buzzword Bingo von Sebastian, wirft einen sehr wesentlichen und auf jeden Fall nur zur Diskussion stehende Frage auf: Was bringt es überhaupt Scrum und BPM zu kombinieren? Bringt es überhaupt etwas? Wir sind alle mit dem Bauchgefühl und mit der Vermutung, dass wir komplementäre Effekte haben in die Diskussion eingestiegen. Evtl. kann man diese Vermutung und das Bauchgefühl konkretisieren.
Schöne Grüße
2010-02-19 um 8.19 pm Uhr. Verfasst von Martin WieschollekMartin
Hallo Jakob,
Du hast unsere Workshop Ergebnisse und auch die Überlegungen dorthin wirklich gut auf den Punkt gebracht. Ich vermisse keinen einzigen Punkt. Kein Wunder, dass Du wegen der resultierenden Länge dann Probleme mit der Technik beim Einstellen hattest
Hallo Sebastian,
und der Zertifizierung zum BPM Experten durch die EABPM. Das sind keine Marketing-Wollken mehr. Hier kommt Struktur rein.
2010-02-20 um 1.16 am Uhr. Verfasst von Martin BartonitzIch 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
Viele Grüße, Martin
Hallo zusammen,
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
2010-02-20 um 12.15 pm Uhr. Verfasst von Jakob Freund[...] kleinen Workshop bei Jakob in Berlin abgehalten. Die Ergebnisse unseres ersten Workshops können auf bpm-guide.de nachgelesen und im Forum des BPM-Netzwerk diskutiert werden. Ich bin gespannt auf das Feedback im [...]
2010-02-20 um 8.34 pm Uhr. Verfasst von Agiles BPM mit Scrum « BPM+Ihr solltet euch vielleicht lieber mit Kanban befassen. Dort sind viele Punkte, welche euch Probleme machen, oft einfach Optional. Denn ich bin gespannt, wie ihr die typischen Spielchen mit Schätzungen, Commitments, usw. umsetzen wollte. Ich glaube, dass ihr euch hier mit SCRUM evtl. nicht gerade das passende Vorgehen/Modell/Buzzword
ausgesucht habt.
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
)
2010-02-20 um 8.55 pm Uhr. Verfasst von Daniel Manzke[...] by Martin at Februar 21st, 2010 Wie im Artikel “Kick-Off: BPM + Scrum” den Jakob Freund auf bpm-guide.de veröffentlicht hat wollten wir noch Beispiele für [...]
2010-02-21 um 8.06 pm Uhr. Verfasst von Prozesse für Scrum zerlegen « BPM+In Amerika ist das Thema agiles BPM schon letztes Jahr vom Technical Commitee Chairman der WfMC, Keith Swenson, besprochen worden. Er hat hier noch ein paar neue Begriffe eingebracht, die sich auch um mein beliebtes BPM Rond-Trip Engineering drehen, die Transformation und Preservation Strategy. Seine Transformation Strategy steht für das Wasserfallmodell, was den Rückfluss des Prozessmodells aus der IT zurück in die Organisation schlecht ermöglicht. Die Preservation Strategie kommt unseren Ideen der kleinen Schritte nahe, da diese das Ping Pong zwischen Org und IT leichter macht. Siehe: http://bpmfundamentals.wordpress.com/2009/07/13/bpm-modeling-strategies-explained/
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.
2010-02-21 um 11.04 pm Uhr. Verfasst von Martin BartonitzHallo 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
2010-02-22 um 12.27 pm Uhr. Verfasst von Martin WieschollekMartin Wieschollek
Hi 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ß,
2010-02-22 um 4.38 pm Uhr. Verfasst von Daniel ManzkeDaniel
Hallo Daniel,
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
2010-02-22 um 7.16 pm Uhr. Verfasst von Martin WieschollekMartin (W.)
Hallo,
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
2010-03-01 um 7.25 pm Uhr. Verfasst von Robert GimbelRobert