zu c) fällt mir im Zusammenhang mit dem camunda BPMN Framework ein, dass man die Prozess nicht nur “der Länge nach” teilen kann (also in diverse Teil-Prozesse), sondern man könnte in einzelnen Sprints auch die jeweils einzelnen Prozessbeteiligten betrachten, da nach dem Framework ja versucht werden soll jedem beteiligten einen eigenen Pool zu widmen. Das würde auch die Komplexität reduzieren, da nach der Erfassung des strategischen Modells, das operative Modell mit jedem Prozessbeteiligtem separat besprochen werden kann (zumindest in großen Teilen).

Beim Improvment Cycle würde ich nicht unbedingt auf längere Sprints setzen. Ich würde evtl. in Regel mäßigen Abständen Mini-Projekte mit Scrum durchführen. Der erste Sprint würde sich dann mit der Analyse und Auswertung der gesammelten Informationen befassen, im Anschluss danach kann überlegt werden, ob in weiteren Sprints der Prozess optimiert werden kann/soll oder nicht. Ein anderer Punkt wäre das “Daily Business”, also z.B. das Monitoren der Prozesse. Hier weiß ich nicht genau, wie man hier gezielt Scum einsetzen könnte. Ich finde Scrum macht mehr Sinn im Projekt-Umfeld.

Noch ganz kurz zwei Sätze zur Rollenverteilung Ich würde eher den Process Owner als Scrum Product Owner einsetzen. Als Scrum Master einen x-beliebigen Mitarbeiter, da dieser “nur” die Scrum Formalia überwacht. Welche Scrum Rolle besetzt dann der Prozess-Analyst? Braucht man weitere Scrum-Rollen? Quasi ein BPM-Add-on?

Schöne Grüße
Martin Wieschollek

PS: Danke für den Hinweis mit dem Link. Ist jetzt korrigiert. Aber ich sehe grade, dass ich das Template auch noch anpassen muss, damit meine Antwort direkt unter Ihrem Kommentar steht.

Ich sehe es sehr ähnlich wie Martin (Bartonitz): Nicht jedes Release am Sprint-Ende wird ausgeliefert. Es muss “nur” lauffähig und theoretisch auslieferbar sein.

Dieser kleine Unterschied liefert einem aber denke ich genügend Möglichkeiten, Aufgaben sowie Inhalte entsprechend zu schneiden und in verschiedene Sprints zu packen. Das würde ja so oder so im Projekt passieren, da man seine eigene Arbeit auch innerhalb der Sprints strukturieren muss (spätestens das Team oder der Mitarbeiter).

Oder meinst du nicht? Ach ja: Und wenn das Tool dieses Vorgehen nicht zulassen sollte, hat man vermutlich das falsche Tool ) Aber ernsthaft: Das wird dann ja auch an anderen Stellen vermutlich zu starr sein…

Schöne Grüße
Bernd