„Wir müssen skalieren!“, „Warum haben wir noch nicht skaliert?“ oder „Ich denke, eine Skalierung würde viele Probleme lösen!“
Kommen euch solche Sätze bekannt vor? Dann arbeitet ihr mit Sicherheit in einem Umfeld, in dem entweder mehrere Produkte und Features oder Teams umschlossen werden. Oft herrscht Chaos und die Leute wissen nicht, wo sie hingehören, mit wem sie reden sollen oder was am Ende als Inkrement rauskommen soll. In diesem Blog gehe ich auf die neuen Rollen und Events ein, die bevorzugt eingesetzt werden. Die Klassiker im skalierten Umfeld, die auch Herausforderungen in sich tragen.
Neue Events
Scrum bildet für mich das Herz einer Skalierung. Refinement, Daily, Retrospektive, Review und Planning, nur, dass wir in einem größeren Rahmen denken. Müssen mehrere Teams miteinander sprechen, muss dafür Raum geschaffen werden. Sitzen zwei Teams an einem brenzligen Inkrement und man konnte die Abhängigkeiten nicht vorab klären, bietet sich ein Crossteam-Refinement an. Abgesandte aus den Teams erarbeiten dort Lösungen und schreiben sie ins Backlog. Braucht man eine tägliche Abstimmung, dann ist das Scrum of Scrums die größte Chance. Selbst bei einem detaillierten Planning bietet sich ein Crossteam-Planning an, um die exakten User-Storys mit in die Sprints zu nehmen. Dies bietet nicht nur eine enge Abstimmung, sondern auch die Möglichkeit, Abhängigkeiten vorab zu klären. Am Ende steht die Review und eine Overall-Retrospektive, in dem die Teams ihre Pros und Cons aufschreiben, damit die Zusammenarbeit in dem skalierten Umfeld verfeinert wird.
Neue Rollen
Chief-Product Owner
Zu den neuen Events werden auch neue Rollen notwendig. Sind es mehrere Teams, die zu einem Produkt ihre Leistung erbringen sollen, ist es wichtig, einen Chief-Product Owner zu integrieren. Eine Person, die in der Hierarchie nicht über den anderen steht, sondern den anderen Product Ownern eine Vision, Ziele und die Möglichkeit bietet das Richtige aufzubauen. Er thront nicht über den anderen Product Ownern, sondern ist Ihr Mentor. Auch wenn andere Product Owner eine Vision erstellen, sollte sich diese nicht mit der des CPO beißen. Gesammeltes Stakeholdermanagements, Innovationen und Ideen werden im Kollektiv besprochen.
„Chief“-Scrum Master:
Als Scrum Master ist man oft auf sich allein gestellt; man bezieht Informationen aus seiner Umwelt und versucht, diese in Korrektur zu bringen, um das Beste für seine Teams zu erarbeiten. In einem skalierten Umfeld braucht es dennoch jemanden, der zwischen den Teams, gerade wenn Abhängigkeiten existieren, springt und vermittelt. Warum das „Chief“ nicht ohne Gänsefüßchen auskommt? Weil Scrum Master keinen „Chief“ benötigen, sondern hier eher das Kollektiv denjenigen bestimmt, der entweder die meiste Erfahrung, Kontakte oder eine gute Idee hat. Hier wird wieder der akephalische Ansatz wichtig. Kopfwissen bringt den Vorteil und die Vorteile für die Scrum Master. Nichtsdestotrotz sticht hier viel mehr heraus das ein Scrum Master ebenfalls eine Richtung benötigt und die kann im Kollektiv der Scrum Master erarbeitet werden. Dies hat merkliche Gleichnisse zu einer „CoP“, die in einem skalierten Umfeld nicht fehlen darf.
Was machen die anderen Rollen?
Teamleiter, Abteilungsleiter und weitere hierarchische Organe können in einem skalierten Umfeld umgeschult werden. Mentorenprogramme, die Menschen bei der Orientierung helfen und beim Herausfinden, wie viel Wissen noch benötigt wird. Es formt und lebt sich anders in einem skalierten Umfeld, das vielleicht fernab von tayloristischen Hierarchien arbeitet.
Verändertes Mindset?
Braucht ein skaliertes Umfeld ein anderes Mindset als jenes, welches sich an den Werten von Scrum anlehnt? Ich denke nicht. Mut, Offenheit, Respekt, Fokus und Selbstverpflichtung sind auch hier die Säulen von Scrum und der Mitarbeit. Was mich dazu bringt, dass bei einer Skalierung darauf geachtet werden muss, dass man nur soviel wie nötig integriert, um nicht in eine Übertaktung von Rollen oder Ereignissen gelangt. Scrum überfordert viele Menschen, eine Skalierung noch mehr. Hier ist es wichtig, dass wissende Leute darüber sprechen.
Die Skalierung schlägt fehl!
Kein Problem, nicht in Panik verfallen. Eine Skalierung braucht Zeit und viele Mittel, um sich richtig und stabil zu integrieren. Wenn es dort zu asynchronen Ereignissen kommt oder Leute ohne Wissen unterwegs sind, ist es nur wichtig, dass dies von vorneherein für alle Beteiligten sichtbar ist. Fehler passieren, aber in Scrum lernt man schnell aus diesen und richtet sich danach aus.
Fazit:
Skalierung ist Trend. Viele wollen skalieren, manche müssen nicht skalieren und machen es trotzdem. Wenn ihr euch dafür entscheidet, sollte euch bewusst sein, das, sich vieles ändert und die Leute viel Hilfe benötigen. Viel Erfolg dabei, denn eine erfolgreiche Skalierung birgt immenses Potenzial!
