Die größten Befürworter von Scrum sind gleichzeitig die größten Blockierer

Jan: Eine agile Organisation hat zwei Dinge gelernt: 1. Sie kann schnell entscheiden bzw. schnell auf Veränderungen reagieren. 2. Lernen ist in ihre Prozesse “eingebaut”. Diese Themen sind mit Scrum gut gelöst.

Die Rolle Product Owner hat einen klaren Entscheidungsrahmen in allen Fragen des Produktes. Das heißt nicht, dass diese Person machen kann, was sie will. Eine gute Product Ownerin ist eine gute Kommunikatorin. Sie ist mit vielen Stakeholdern in Kontakt. Die Entwickerler:innen im Scrum-Team haben einen klaren Entscheidungsrahmen in allen Fragen der Umsetzung. Darüber hinaus sind alle POs in einem engen Austausch mit der Geschäftsführung. Vertreter:innen aus allen Scrum-Team klären die fachlichen Standards.

Lernen finden wir bei Scrum in der Arbeit des POs und in den Arbeitsstrukturen der Entwickerler:innen wieder. Eine gute Product Ownerin lässt nicht einfach Dinge abarbeiten. Sie definiert die Wissenslücken und setzt mit Sprint- und Releasezielen Lernschwerpunkte. Die Entwickler:innen nehmen sich Zeit, einander wichtige Kompetenzen beizubringen. Mit jedem Daily Scrum wird eine kleine Verbesserungsidee ausprobiert, mit jeder Sprint Retrospektive eine große.

Ich würde eher fragen: Wie wird eine Organisation agiler? Scrum ist ein toller Arbeitsrahmen. Ich habe viel von Jeff Sutherland und den Kolleg:innen von der scrum.org gelernt. Ich halte es aber für den falschen Weg, “Scrum zu implementieren”. Stattdessen würde ich Fragen stellen:

● Was sind unsere Ziele als Organisation?

● Wie gut erreichen wir gerade diese Ziele? Woran merken wir, dass wir besser werden?

● Wie finanzieren wir unsere Arbeit? Wie viele zahlende Kunden brauchen wir?

● Was sollten wir lernen, um erfolgreich zu sein?

● Welche Werte sind uns im Umgang wichtig? Dürfen wir diese Werte einfordern?

● Was ist hier kaputt und muss dringend repariert werden?

Wenn die ersten Antworten vorliegen, können wir mit einem Scrum-Team starten. Ich bin dagegen, alle im Unternehmen gleichzeitig verrückt zu machen. Ich verfolge eher die Strategie: mein Haus, meine Straße, meine Stadt. Dann werden nämlich aus den Beratergeschichten die eigenen Geschichten.

Paradoxerweise sind die größten Befürworter von Scrum gleichzeitig die größten Blockierer. Sie verstehen die vertraute und die neue, agile Welt und versuchen sie übereinander zu legen. Das funktioniert leider nicht. Es reicht nicht, den Scrum Guide mechanisch abzuarbeiten. Scrum sieht so einfach aus. Aber der Teufel steckt im Detail. (Bei den Details lohnt sich übrigens ein Blick in die Scrum-Muster im Scrum Book.)

Die Hindernisse kann man gut an den Rollen erkennen: Es gibt oft keine Product Ownerin, die für diese Arbeit freigestellt wurde. Es gibt meist überhaupt keine PO-Organisation, die mit der GF Ziele abstimmt. Die Produkte sind Waisenkinder. Ein PO ist kein Projektleiter.

Es gibt keine interdisziplinären Teams, die (überwiegend) an einem Produkt oder einem Service arbeiten. Es sind Gruppen von Spezialisten, deren Zusammensetzung sich immer wieder ändert. Sie haben keine gemeinsamen Ziele und sie kümmern sich überhaupt nicht um gegenseitige Wissensvermittlung. Die Teams sind falsch zusammengesetzt.

Das Verständnis der Arbeit einer Scrum Masterin ist leider auch ziemlich unterschiedlich. Wir haben einmal Stellengesuche für Scrum Master ausgewertet. In 9 von 10 Fällen dieser kleinen und nicht-repräsentativen Stichprobe kam die Idee von kontinuierlicher Verbesserung nicht rüber. Stattdessen sah man diese Rolle als Meetingmoderierer und JIRA-Administrator.

Wenn es nur ein einziges Scrum-Team gibt, kann man mit bestehenden Mitteln alles erledigen. Jeder weiß, was die Ziele sind. Jeder weiß, was die anderen können, und welche Lücken zu schließen sind. Post-Its, Flipcharts, Tafeln reichen hier aus.

Interessant wird es in größeren Organisationen. Um den Bedarf für Besprechungen zu reduzieren, würde es helfen, wenn alle auf die Ziele der verschiedenen Teams und Bereiche Zugriff hätten. Es würde helfen, wenn wir Zugriff auf die Kompetenzen der Teams hätten. Was sind die Entscheidungsbefugnisse? Ich vermisse einfache Werkzeuge, um z. B. verteilt einen Open Space zu moderieren. Wenn die Teammitglieder räumlich verteilt sind, stelle ich meine Vorbehalte zu elektronischen Werkzeugen zurück. Das kann hier schon eine Erleichterung sein.

Jan Fischbach (Xing, LinkedIn) berät seit dem Jahr 2013 große und kleine Unternehmen dabei, agiler zu werden. Er ist einer der Geschäftsführer der Common Sense Team GmbH in Karlsruhe und er ist Teil vom Scrum-Events-Netzwerk.

Foto Jan Fischbach: Anya Zuchold