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" 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.
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.
Generell ist natürlich darauf zu achten, wer im Unternehmen die Entscheidung treffen darf, ein neues Vorgehensmodell einzuführen. Wenn es möglich ist, ein Veränderungsprojekt vollständig innerhalb eines kleinen Teams abzuwickeln, dann kann die Entscheidung des Teamleiters für die Einführung ausreichend sein, sofern dieser dazu berechtigt ist. Andernfalls muss eine Person diese Entscheidung treffen, die aufgrund ihrer Position in der Hierarchie dazu berechtigt ist.
Wichtig ist, dass diese Instanz gegenüber denjenigen Mitarbeitern, die an der Scrum-Einführung beteiligt sind, entscheidungsbefugt ist. Tauchen Probleme auf, welche die Einführung von Scrum stören könnten, muss diese Führungskraft ihren Mitarbeitern "den Rücken freihalten" und die notwenigen Entscheidungen treffen, damit sich die Beteiligten ganz auf die Einführung konzentrieren können.
Wie bei den Pilot-Projekten empfiehlt es sich, auch das Change-Projekt iterativ und nach agilen Prinzipien durchzuführen. So kann das Team regelmäßig den Verlauf des Change-Projekts überprüfen, Störungen und Probleme identifizieren und sich über Verbesserungspotenziale austauschen. Das Backlog des Change-Projekts setzt sich dabei zusammen aus den notwendigen organisatorischen Änderungen, die für eine erfolgreiche Einführung wesentlich sind sowie aus den Problemen (Impediments), auf die das Change-Projekt im Laufe der Zeit stößt.
Es empfiehlt sich, für das Projekt eine Rolle ähnlich der des Scrum Masters zu etablieren. Der Inhaber dieser Rolle stellt eine direkte Verbindung zwischen den Projekten, in denen die Probleme auftreten, und dem Change-Projekt her und achtet darauf, dass die auftretenden Hindernisse priorisiert und die jeweils wichtigsten Punkte auch gelöst werden. Damit alle Beteiligten des Change-Projekts die notwendigen Änderungen mittragen, sollte das Team die Entscheidungen möglichst einvernehmlich treffen. Lässt sich kein Konsens finden, muss eine Möglichkeit bestehen, dennoch eine Entscheidung herbeizuführen, z.B. in dem die Entscheidung an die nächsthöhere Führungsebene weitergegeben wird.
…
