DeutschEnglish

Scrum ist ganz heißer Methoden-Shit

25.05.2017

Seit dem Bau der Pyramiden hat die Menschheit so manches Projekt erfolgreich abgewickelt. Zumindest insofern, als dass die Bauwerke oder Produkte sichtbar fertig geworden sind. Wie es am Ende um die Finanzen und Terminvorstellungen der Auftraggeber bestellt war, ist nicht immer bekannt, vermutlich aus gutem Grund. Und da Projekte mitunter sehr herausfordernd sein können, gibt es immer wieder Diskussionen um die "richtige" Methode, frei nach der Vermutung, dass der Projekterfolg nur eine Frage der Wahl der richtigen Methode sei, schlimmer noch der Wahl "moderner" Methoden.

Aktuell ist "Scrum" die heißeste Nummer auf dem Methoden-Cat-Walk und wir werden oft darauf angesprochen. Andere Methoden werden schon einmal schnell verworfen, allein weil sie schon älter sind. Womit "älter" mit demselben Zungenschlag benutzt wird wie im Satz "Dein Nokia 6310 ist aber schon älter, oder?" Dabei wurde Scrum bereits 1995 erstmals erwähnt und 2001 in einem Buch beschrieben. Im Internetzeitalter ist das Lichtjahre her. Und dennoch ist Scrum erst jetzt mitten im Mainstream angekommen und wird als Allheilmittel für erfolgreiches Projektmanagement gehandelt.

Knapp beschrieben ist Scrum ein übersichtliches Set von Regeln und Rollen, das in der Softwareentwicklung entstanden ist und von möglichst vielseitigen Teams von bis zu neun Personen angewendet wird, um sich selbst, das Vorgehen und die Anforderungen an die (Zwischen-) Ergebnisse eines Projektes zu organisieren. Entgegen klassischer Vorgehensweisen wird die umfassende Projektplanung zum Projektstart durch ein inkrementelles, etappenweises Vorgehen mit Abschnitten von 2-4 Wochen Dauer („Sprints“) ersetzt und damit auf eine im Projektverlauf zunehmende Konkretisierung gesetzt. Aufgaben werden innerhalb eines Sprints so weit zerlegt, dass sie mit Arbeitsinhalten von etwa einem Tag recht genau beschrieben werden können, womit die Transparenz innerhalb des jeweiligen Sprints sehr hoch ist und regelmäßig Ergebnisse bzw. Fortschritte erzielt werden können. Die Vorgehensweise des Teams ist insoweit iterativ, als dass es sich im Projektverlauf stetig hinterfragt und von den jeweiligen Erfahrungen zu lernen versucht.

Aus dieser Beschreibung werden die Grenzen der reinrassigen Anwendung von Scrum offensichtlich, bzw. werden außerhalb der Kernanwendung der Softwareentwicklung schnell Modifikationen der Methodik erforderlich: Aufgrund der unterschiedlichen Rollen im Team ist es für Kleinst- oder Einzelprojekte nicht geeignet. Eine Rückwärtsterminierung, die sich am Gesamtendtermin orientiert, ist nicht möglich, wenn wir uns von Etappe zu Etappe vorwärts hangeln. Auch kompliziertere Projektstrukturen sind so nicht abbildbar, sei es in Form großer Gesamtteams oder mehrerer Teams, die zusammenwirken, sei es durch Interdependenz von Aktivitäten im Projektverlauf bzw. langlaufenden Aktivitäten, die frühzeitig initiiert werden müssen und sich mitunter nur erkennen lassen, wenn wir uns bereits zum Projektbeginn die Zusammenhänge über den gesamten Projektverlauf anschauen. Auch wird es schwierig, Werkvertragsprojekte mit klaren Kundenvorstellungen wie gefordert zu erfüllen, da Scrum bewusst von Unschärfen und hoher Eigenständigkeit des Projektteams ausgeht.

Trotz der Grenzen nutzt Scrum ganz wesentliche Bausteine, die eine erfolgreiche Projektabwicklung unterstützen: Die Methode geht davon aus, dass Projekte mit Überraschungen verbunden sind, die im Projektverlauf Anpassungen erforderlich machen. Klassische Methoden nehmen an, man könnte Überraschungen mit höherer Planungsintensität und -präzision bekämpfen, was erwiesenermaßen eine Fehlannahme ist. Besser ist es, Unwägbarkeiten als projektimmanent zu akzeptieren und gegebenenfalls die Planung, das Vorgehen oder das Team im Projektverlauf anzupassen und dafür Puffer vorzusehen. Deshalb ist es auch grundsätzlich sinnvoll, dass sich Projektteams regelmäßig zum review treffen, um den Projektverlauf zu reflektieren.

Scrum fokussiert jeweils auf die Aufgaben des aktuellen Sprints, während klassische Projektpläne bewusst mit Detaillierung und Vollständigkeit glänzen, weshalb gerne mal lesbare Schriftgrade und der Gesamtüberblick verloren gehen.

Scrum geht von selbstgesteuerten cross-funktionalen Teams aus, innerhalb derer jeder wechselnde Aufgaben übernimmt. Diese Sichtweise stellt Teamarbeit in den Vordergrund und verhindert ein autistisches Durchschleppen durch Abteilungen, wie es in traditionell prozessorganisierten Firmen der Fall ist. Jeweils alle relevanten Aufgaben einer Projektphase transparent zu führen, den Arbeitsbedarf einzuschätzen und den Status täglich zu besprechen, ist in jedem Fall hilfreich, Fehleinschätzungen, Irritationen und Blindleistung vorzubeugen.

Und: Mit dem Scrum Master gibt es im Projekt explizit eine Rolle, die sich auf Abwicklungsdisziplin und Einhaltung der vereinbarten Projektregeln konzentriert. Das ist sehr wertvoll und verhindert, dass gerade in kritischen Projektphasen unbemerkt die Projektstrukturen verloren gehen.

In Summe lebt Scrum von der Kraft eigenorganisierter, intensiv kommunizierender Teams, die sich stetig verbessern und mit hoher Transparenz über den Projektfortschritt dafür sorgen, dass ihre aktuellen Aufgaben im Fluss bleiben. Das ist im Kern lean und nicht neu und kein Grund unsere bisherigen Methoden über Bord zu werfen. Aber vielleicht können wir sie ja noch ein Stück weit verbessern.

Kontakt

einfach.effizient. GmbH&Co. KG
Marie-Curie-Str. 1
26129 Oldenburg (Oldb.)

Tel:      + 49 441 36116210
Fax:     + 49 441 36116214
Mob:    + 49 1525 6799349