Bei der Einführung agiler Vorgehensweisen in größeren Projekten sehen sich Scrum- Experten häufig mit einer Problematik konfrontiert, die aus einem Widerspruch zwischen der reinen Lehre und der Unternehmensrealität resultiert.
Scrum-Teams sollten zwischen drei und zehn Mitglieder haben. Doch wie geht ein Scrum-Manager mit größeren Projektvorhaben um? Die einfachste Lösung, hier auf die Anwendung von Scrum zu verzichten, geht aufgrund der Vielzahl von Unternehmen, deren Geschäftsmodell auf dem Verkauf komplexer Produkte basiert, an der Realität vorbei. Zahlreiche Experten stehen daher vor der Fragestellung, ob, und vor allem auf welche Weise, Scrum optimal skaliert werden kann.
Scrum-Entwickler Ken Schwaber sagt hierzu:
„...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...“
Bei komplexen Vorhaben lässt sich jedoch häufig genau diese Zerlegung in orthogonale Teilprojekte nicht vornehmen.
Wäre es eine Lösung, ein wenig von der reinen Lehre abzukommen, und auf Scrum-Teams mit beispielsweise 50 Mitarbeitern zurückzugreifen? Es ist nur wenig Phantasie vonnöten, um festzustellen, dass allein der Abstimmungsaufwand beim täglichen Scrum-Meeting jedem effektiven Arbeiten im Wege stünde. Die Begrenzung der Teamgröße ist eine unabdingbare Voraussetzung.
Lösungsansatz Nummer zwei: Wäre ein Rückgriff auf die alte Vorgehensweise, Projekte mittels Hierarchien zu steuern, eine denkbare Alternative? Dies würde zwar nicht mehr der Philosophie agiler Methoden entsprechen, doch es könnte ein Weg sein, um die Komplexität des Vorhabens handhabbar zu machen. Scrum- Vertreter haben in diesem Zusammenhang den „Scrum of Scrums“ entwickelt.
Dieser ist nicht eindeutig definiert. Viele verstehen darunter ein Meeting wie das Daily Scrum, bei dem 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. Eine Alternative, die allerdings erfordert, dem „Stille-Post-Effekt“ - der Verfälschung des Informationsinhaltes durch mehrfache informelle Weitergabe – entgegenzuwirken.
Auch wenn das ein kleines Abrücken von der Scrum-Philosophie bedeutet: Eine gute Dokumentation kann genau jenes Erfordernis erfüllen und somit auch größere Projekte mittels eines agilen Vorgehensmodells handhabbar machen. Nicht dessen Skalierung, sondern der sinnvolle Einbau von Scrum in die bewährten Prozesse stellt somit die Lösung dar.
Tools, die diese Vorgehensweise unterstützen, sind bereits vorhanden. Die Scrum-Software und Projektmanagement Software Track+ unterstützt sowohl agile Vorgehensweisen wie auch die bewährten Vorgehensmodelle.
Scrum-Teams sollten zwischen drei und zehn Mitglieder haben. Doch wie geht ein Scrum-Manager mit größeren Projektvorhaben um? Die einfachste Lösung, hier auf die Anwendung von Scrum zu verzichten, geht aufgrund der Vielzahl von Unternehmen, deren Geschäftsmodell auf dem Verkauf komplexer Produkte basiert, an der Realität vorbei. Zahlreiche Experten stehen daher vor der Fragestellung, ob, und vor allem auf welche Weise, Scrum optimal skaliert werden kann.
Scrum-Entwickler Ken Schwaber sagt hierzu:
„...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...“
Bei komplexen Vorhaben lässt sich jedoch häufig genau diese Zerlegung in orthogonale Teilprojekte nicht vornehmen.
Wäre es eine Lösung, ein wenig von der reinen Lehre abzukommen, und auf Scrum-Teams mit beispielsweise 50 Mitarbeitern zurückzugreifen? Es ist nur wenig Phantasie vonnöten, um festzustellen, dass allein der Abstimmungsaufwand beim täglichen Scrum-Meeting jedem effektiven Arbeiten im Wege stünde. Die Begrenzung der Teamgröße ist eine unabdingbare Voraussetzung.
Lösungsansatz Nummer zwei: Wäre ein Rückgriff auf die alte Vorgehensweise, Projekte mittels Hierarchien zu steuern, eine denkbare Alternative? Dies würde zwar nicht mehr der Philosophie agiler Methoden entsprechen, doch es könnte ein Weg sein, um die Komplexität des Vorhabens handhabbar zu machen. Scrum- Vertreter haben in diesem Zusammenhang den „Scrum of Scrums“ entwickelt.
Dieser ist nicht eindeutig definiert. Viele verstehen darunter ein Meeting wie das Daily Scrum, bei dem 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. Eine Alternative, die allerdings erfordert, dem „Stille-Post-Effekt“ - der Verfälschung des Informationsinhaltes durch mehrfache informelle Weitergabe – entgegenzuwirken.
Auch wenn das ein kleines Abrücken von der Scrum-Philosophie bedeutet: Eine gute Dokumentation kann genau jenes Erfordernis erfüllen und somit auch größere Projekte mittels eines agilen Vorgehensmodells handhabbar machen. Nicht dessen Skalierung, sondern der sinnvolle Einbau von Scrum in die bewährten Prozesse stellt somit die Lösung dar.
Tools, die diese Vorgehensweise unterstützen, sind bereits vorhanden. Die Scrum-Software und Projektmanagement Software Track+ unterstützt sowohl agile Vorgehensweisen wie auch die bewährten Vorgehensmodelle.
