Bei der Einführung von Scrum in einer Organisation ist nicht nur die IT-Abteilung von der Veränderung betroffen. Auch Vertreter anderer Abteilungen müssen die Funktionsweise der Methode verstehen, damit der Software-Entwicklungsprozess produktiv eingesetzt werden kann. So ist es z.B. wichtig, dass Mitarbeiter anderer Fachbereiche ihre Rolle als Product Owner kennen. Abteilungen, wie z.B. der Systembetrieb, das Marketing oder der Vertrieb, sollten das Prinzip des iterativen Vorgehens kennen, um sich auf regelmäßig neue Produktversionen einstellen zu können.
Dieser zweiteilige Beitrag zeigt, worauf man bei der Einführung von Scrum in einer Organisation achten sollte. Der erste Teil behandelt die Einführung "von oben", bei der das gesamte Unternehmen über die Veränderung informiert ist und die Geschäftsführung dabei als treibende Kraft fungiert. Dieser zweite und abschließende Teil beschreibt, wie die Einführung "von unten" im Unternehmen realisiert werden kann.
Die Einführung "von unten"
Die Einführung "von unten" beschränkt sich ausschließlich auf die IT-Abteilung eines Unternehmens; das Change-Projekt sowie die Pilotprojekte werden nur in dieser Abteilung initiiert und durchgeführt. Die restliche Organisation wird dabei nicht über die Veränderung informiert, wodurch sich auch der Erfolgsdruck auf das Change-Projekt deutlich reduzieren lässt. Mit der Beschränkung auf nur einen Teil des Unternehmens besteht jedoch das Risiko, dass bei einem späteren "richtigen" Projekt in der Gesamtorganisation Probleme auftreten, die vorher nicht berücksichtigt wurden. Dadurch kann es passieren, dass zunächst eine Scheinsicherheit hinsichtlich der Durchführbarkeit von Scrum-Projekten entsteht.
Häufig kommt direkt aus der Entwicklungsmannschaft der Impuls, agile Methoden einzuführen. IT-Mitarbeiter lernen agile Vorgehensweisen über Bücher, Zeitschriften oder durch Berichte aus anderen Unternehmen kennen und es entsteht der Wunsch, in den eigenen Projekten ebenfalls so vorzugehen.
Kurze Analyse
Wie auch bei der Einführung "von oben" steht am Anfang eine kurze Analysephase. Dabei liegt der Fokus nicht darauf, alle denkbaren Probleme im Vorfeld zu lösen, sondern sich auf das neue Verfahren einzulassen. Da die Erfahrung zeigt, dass die wesentlichen Probleme erst bei der konkreten Durchführung auftreten, empfiehlt es sich, die Analyse kurz zu halten und möglichst schnell mit dem ersten Pilotprojekt zu starten. Die Analysephase sollte daher nicht länger als vier Wochen dauern. Im Wesentlichen werden in dieser Phase nur das erste Pilotprojekt und die dafür benötigten Rollen festgelegt. Die nachfolgende Pilotphase endet jedoch nicht zwingend mit dem Schluss des ersten Pilotprojekts, sondern kann noch weitere Pilotprojekte nach sich ziehen.
Bei der Einführung "von unten" sollte aber nicht nur das agil durchgeführte Software-Projekt im Mittelpunkt stehen; ebenfalls notwendig ist es, ein internes Change-Projekt voranzutreiben. Ziel sollte es sein, während der Projektlaufzeit möglichst viel über das agile Vorgehen im eigenen Unternehmen zu lernen und Hindernisse aus dem Weg zu räumen.
