In letzter Zeit habe ich mich mit einer Reihe von Leuten unterhalten, die an der Einführung agiler Vorgehensweisen in größeren Projekten beteiligt sind. Eine Aussage habe ich dabei immer wieder gehört:

„Wir haben noch nicht herausgefunden, wie wir Scrum optimal skalieren können.“

Diese Experten sind keine Scrum-Skeptiker. Im Gegenteil ist es bewundernswert, mit welchem Optimismus sie das neue Mantra willkommen heißen, obwohl es sie in mancher Hinsicht entmachtet.

Scrum-Teams sollten zwischen drei und zehn Mitgliedern haben. Alles was man mit 10 Teammitgliedern entwickeln kann, ist also Scrum-tauglich. Dem Philosoph Johann Gottfried Fichte wurde einmal vorgeworfen, dass seine Philosphie etwas realitätsfern sei. Er ist daraufhin in sich gegangen und kam nach kurzer Zeit mit einem Lösungsvorschlag: Man müsse die Realität halt anpassen. Welch ein Genius!

Vielleicht haben wir noch nicht verstanden, wie wir die Realität an Scrum anpassen können. Dabei sind einige Lösungswege recht offensichtlich. Das einfachste wäre, wir entwickeln nichts, was mehr als zehn Leute erfordert. Das wäre eine echte Scrum-Lösung, wir brauchten zum Scrum-Evangelium nichts hinzu tun und nichts davon wegnehmen.

Diese einfache Lösung passt leider nicht zu jedem Geschäftsmodell. Es gibt Firmen, die verdienen ihr Geld mit dem Verkauf komplexer Produkte. Wie geht man hier Scrum-gemäß vor?

Lassen wir den Propheten selbst zu Wort kommen:

Bevor ein Projekt offiziell beginnt, verteilen die Planer die Arbeiten so auf die Teams, dass die Abhängigkeiten minimiert werden. Die Teams arbeiten dann jeweils an Teilen der Projektarchitektur, die orthogonal zueinander sind. Dieser Koordinationsmechanismus ist allerdings nur wirksam, wenn die Verkopplungen oder gegenseitigen  Abhängigkeiten unerheblich sind. (Ken Schwaber)

Ein beeindruckender Lösungsvorschlag, der leider außer acht lässt, dass komplexe Projekte deshalb komplex sind, weil sie nicht in zueinander orthogonale Teilprojekte zerlegbar sind.

Damit sind wir gezwungen, die Scrum-Lehrsätze zu hinterfragen und uns auf die Häretiker zuzubewegen. Fragen wir uns also: Warum kann ein Scrum-Team nicht aus 50 Leuten bestehen? Das wird recht schnell klar, wenn man sich vorstellt, wie 50 Leute jeden Morgen vor einer Tafel stehen und sich über dort angeheftete Zettel austauschen. Welch ein Gedränge. Und wenn nur jeder mit jedem fünften eine Minute redet, ist der Vormittag rum. Die Begrenzung der Teamgröße  ist also durchaus sinnvoll und kann nicht ausgesetzt werden.

In einem älteren Evangelium heißt es, wer seine Hand an den Pflug legt und dabei zurückblickt, der ist nicht geeignet für die neue Welt. Wir missachten respektlos diesen Hinweis und blicken mal zurück. Wie wurden in der Vergangenheit komplexe Systeme beherrschbar gemacht? Ach ja, durch Hierarchien! Aber das wäre ja „Old School“, Scrum hat doch gerade das Hierarchie-Prinzip abgeschafft. Jetzt brauchen wir es doch wieder? Im Prinzip ja, aber damit es sich neu anhört, geben wir ihm einen anderen Namen. Statt „Hierarchie“ nennen wir es „Scrum of Scrums“, und schwups, sind wir wieder voll agil.

Der Scrum of Scrums ist nicht eindeutig definiert; viele verstehen darunter ein Meeting wie das Daily Scrum, wo sich jeweils ein Vertreter aus jedem Entwicklungsteam mit den Vertretern der anderen Teams trifft, um offene Fragen zu klären und eventuelle Hindernisse zu beseitigen. Das hört sich gut an, wenn da nicht der „Stille Post“-Effekt wäre. Vielleicht kennen Sie dieses lustige Gesellschaftsspiel: Der Erste flüstert dem Zweiten einen Satz ins Ohr, der diesen dem Dritten ins Ohr flüstert, und so weiter. In der Regel genügen vier Stationen, um den ursprünglichen Satz nicht mehr wiederzuerkennen.

Ein altes Hausmittel gegen derlei Missverständnisse ist eine gute Dokumentation. Damit entfernen wir uns jedoch ein Stückchen vom reinen Scrum, aber warum eigentlich nicht? Scrum bietet einige Vorteile, aber es ist wenig geeignet für eine Skalierung. Warum akzeptieren wir das nicht und bauen Scrum in unsere bewährten Prozesse dort ein, wo es wirklich nützt? Wer nur einen Hammer hat, für den sieht jedes  Problem aus wie ein Nagel.

Die Scrum-Software und Projektmanagement-Software Track+ unterstützt sowohl agile Vorgehensweisen wie auch die bewährten Vorgehensmodelle. Probieren Sie es aus.

 

 

Bitte folgen Sie uns:
Scrum für große Vorhaben: Die Scrum-Lösungen
Markiert in:        

Schreibe einen Kommentar

Social media & sharing icons powered by UltimatelySocial