Henne oder Ei?
Im ersten Teil dieser Artikelserie habe ich die Überlegungen vorgestellt, welche hinter dem Wandel von der Agentur hin zum modernen Technologie-Unternehmen stecken. Ich habe erläutert, weshalb wir SCRUM als Prozess einführen, sowie welche Chancen und Risiken damit verknüpft sind. In diesem Teil der Serie gehe ich nun auf die Suche nach der richtigen Vorgehensweise zur Implementierung ein.
Die Einführung ist mit diversen Fallstricken versehen, die es zu umschiffen gilt.
Ist die Entscheidung zu Gunsten von SCRUM gefallen, ist die Einführung mit diversen Fallstricken versehen, die es zu umschiffen gilt. Unter anderem ist der richtige Zeitpunkt bzw. die richtige Reihenfolge der Einführung von SCRUM essentiell. Im Falle von DI UNTERNEHMER zeigte sich, dass die Teams intern noch „agenturig“ arbeiteten: Die Prozesse und die Zusammensetzung der Teams in Bezug auf die Disziplinen der Teammitglieder waren noch nicht auf Software-Entwicklung abgestimmt.
So stellte sich die Herausforderung, die Teamzusammensetzungen anzupassen, die Disziplinen zu schärfen und den Prozess umzustellen. Doch in welcher Reihenfolge sollte man dabei vorgehen? Zuerst den Prozess umstellen und die Strukturen nachziehen? Oder wäre es besser, erst neue Strukturen zu schaffen und danach den Prozess aufzusetzen? Möglicherweise wäre eine gleichzeitige Umstellung von Strukturen und Prozess am besten?
Jede der drei Möglichkeiten hat ihre Vor- und Nachteile, welche ich nachfolgend erörtern möchte.
Wenn der Schwanz mit dem Hund wedelt
Beginnt man mit der Umstellung der Teamstrukturen bzw der darin abgebildeten Disziplinen, bleibt ein schlecht funktionierendes Gebilde zurück: Die eingespielten und funktionierenden Teams sind zu neuen, noch nicht funktionierenden Haufen zusammengesetzt. Da diese Haufen nach einer bestimmten Vorstellung geformt sind, um alle für Software-Entwicklung benötigten Disziplinen abzudecken, funktioniert der alte Prozess nicht länger, da die klassischen Projektmanager plötzlich kein Team mehr haben bzw. ihr altes Team auf mehrere Teams verteilt wurde. Gleichzeitig fehlt der neue Prozess, der ein reibungsloses Zusammenspiel ermöglicht.
Insofern passt das Bild eines Schwanzes, der mit dem Hund wedelt, sehr gut: Da der Prozess die Team-Zusammensetzung beeinflusst und es nicht umgekehrt sein sollte, funktioniert die Zusammensetzung nicht ohne Prozess und sollte demnach auch nicht vorab eingeführt werden.
Big Bang Theory
Sauberer klingt es, alle Voraussetzungen auf einmal zu schaffen: Die Team-Zusammensetzungen anzupassen, die Disziplinen zu schärfen und den entsprechenden Prozess gleich noch mit einzuführen.
Was sich in der Theorie durchaus erstrebenswert anhört, stellt sich in der Praxis als schwierig bis unmöglich heraus.
Was in der Theorie durchaus erstrebenswert klingt, stellt sich in der Praxis als schwierig bis unmöglich heraus: Die im Prozess noch ungeübten Teammitglieder arbeiten in noch nicht eingespielten Teams ohne festgelegten Prozess. Das hört sich nicht nur chaotisch an, es wäre auch genau das! Und somit liegt klar auf der Hand, dass dieser vermeintlich optimale Weg nicht der Richtige sein kann: Zu groß wäre das Risiko, das laufende Geschäft nicht länger erfolgreich abzuwickeln und somit den wirtschaftlichen Erfolg der Firma zu gefährden.
Somit bleibt noch der Weg, SCRUM ohne optimale Voraussetzungen einzuführen.
ScrumBut
SCRUM erfordert, dass jedes Projekt ein dediziertes Team hat. Wechselnde Mitglieder sind nicht nur der Effizienz-Killer schlechthin sondern erschweren auch jede Metrik ungemein. Sind benötigte Disziplinen nicht vom Team abgedeckt, müssen sie als externe Abhängigkeiten berücksichtigt und bei Verzögerungen als Impediments abgebildet werden. All das erschwert das reibungslose Arbeiten und sollte daher vermieden werden.
Da sich nun aber die anderen Optionen aber als nachweislich nicht gangbar entpuppt haben, muss SCRUM in einem Umfeld eingeführt werden, in dem die Teams (noch) nicht optimal zusammengesetzt sind. Dies bedeutet aber gleichzeitig, dass der SCRUM-Prozess nicht 100% sauber eingehalten werden kann.
Abweichungen vom Idealprozess werden als ScrumBut bezeichnet.
„STOP!“ werden jetzt einige rufen, SCRUM nur teilweise einzuführen sei ein großer Fehler! In der Tat bin auch ich überzeugt davon, dass SCRUM nur dann seine Stärken entfaltet, wenn man sich möglichst nah am Idealprozess hält. Abweichungen davon werden als ScrumBut bezeichnet (im Sinne von „Wir nutzen zwar SCRUM, aber…„). Allerdings erfolgen die Abweichungen wissentlich unter der Prämisse, dass diese nur temporär sind bis die Teamstrukturen nachgezogen sind. Da wir also von einer Übergangsphase sprechen, sind die damit einhergehenden Nachteile akzeptabel um das Henne/Ei Problem zu losen.
So haben wir bei DI UNTERNEHMER zuerst SCRUM als Prozess etabliert bevor die Teams entsprechend strukturiert und die Disziplinen geschärft wurden.
Ausblick
Ich hoffe mit diesem Artikel den ein oder anderen Leser bei der Einführung von SCRUM zu unterstützen, indem ich meine Entscheidungsprozesse erörtert habe. Im nächsten Teil der Serie gehe ich auf die Teamstrukturen und Disziplinen ein, welche bei DI UNTERNEHMER geschaffen wurden und beleuchte die Tools, mit deren Hilfe wir SCRUM abbilden.