Scrum ist KEIN Prozess

Veröffentlicht von

This post is also available in: English (Englisch)

Ich hatte mal das Vergnügen in einem Unternehmen zu arbeiten, dass es sich zur Aufgabe gemacht hat, die Entwicklungsprozesse global zu vereinheitlichen. Heraus kam ein globaler Entwicklungsprozess, der weltweit an allen Standorten für jede Art von Produktentwicklung eingesetzt wurde. Er galt sowohl für die Entwicklung eines Werkzeuges ohne jegliche Elektronik, bis hin zu komplexen Softwareprojekten. One size fits all. Natürlich konnte man den Prozess bis zu einem gewissen Anteil an die jeweilige Produktentwicklung anpassen, aber im Endeffekt musste der Prozess zu etwa 90% befolgt werden. Dies führte dazu, das selbst die kleinsten Projekte über 6 und mehr Monate liefen, da der Prozess einen riesigen Overhead verursacht hat. Ausserdem wurde die erhöhte Komplexität in Softwareprojekten komplett ignoriert. Wie man vielleicht schon heraus gehört hat, halte ich das für eine sehr schlechte Idee. Jeder Prozess, der den jeweiligen Kontext aus Acht lässt, ist meiner Meinung nach zum Scheitern verurteilt.

Schön, dass Scrum KEIN Prozess ist, sondern ein Rahmenwerk, auch wenn mit man den Begriff Scrum-Prozess einige Tausend Treffer bei Google hat. Scrum definiert zwar Rollen, Regeln und Artefakte, aber wie man das ganze umsetzen soll wird nur oberflächlich erklärt. Natürlich gibt es hier auch ein paar Ausnahmen, wie z.B. die genaue Abfolge der einzelnen Scrum Meetings (beispielsweise erfolgt das Sprint Review am Ende des Sprints). Und genau deshalb ist Scrum auch „Schwierig zu meistern“, wie man im deutschen Scrum Guide nachlesen kann. Scrum definiert das WAS; das WIE obliegt dem Team, welches Scrum implementiert. Das ist zum einen eine Chance, aber eben oft auch die Hauptursache, warum Scrum fehlschlägt. Nur weil man alle Scrum Meetings durchexerziert und alle definierten Artefakte erstellt, hat man noch lange nicht den Benefit, den man sich vielleicht von Scrum erhofft.

Nutze die Chance und mache Scrum zu Deinem Prozess. Nimm das Rahmenwerk, dass Scrum vorgibt und passe die Inhalte an Deinen Kontext an. Probiere aus und passe Deinen Prozess auf der Basis empirischer Daten regelmäßig an. Life is an experiment. Wenn Du dabei die 12 Prinzipien des agilen Manifest im Hinterkopf behälst, bist Du schon auf einem guten Weg. Und mache niemals den Fehler, Prozesse eins zu eins auf einen neuen Kontext zu kopieren, das hat noch nie funktioniert.

[mc4wp_form]

  • …sehe ich auch so, Marc. Ich war erst neulich mit Prozessen in unserem Unternehmen beschäftigt und mich hat es auch gestört, dass Scrum in die große Prozesskiste neben Release, Deployment, Desaster etc. gesteckt wurde. Das konnten wir intern zum Glück schnell klären und auch auf das Framework, das Scrum bieten will und soll, hinweisen. Grüße aus Hamburg, Robert