ProjektmanagementScrum oder Wasserfall-Modell?

Ein agiles Vorgehen, wie zum Beispiel Scrum im Projektmanagement, ist im Zusammenhang mit der Digitalisierung nicht mehr wegzudenken. Unternehmen setzen zunehmend auf dieses Mindset, um mit den immer schnelllebigeren Bedingungen und flexibleren Startups mithalten zu können. So werden beispielweise Scrum Squads eingerichtet, Agilität in den Zielen verankert oder auch Scrum Master zertifiziert. Die Erwartungshaltung an Scrum ist hoch, und doch hat das Topmanagement oftmals nur eine oberflächliche Vorstellung über die Voraussetzungen und Konsequenzen eines agilen Vorgehens.

Doch ist die agile Vorgehensweise wirklich das Maß aller Dinge und in allen Unternehmen oder Projekten einsetzbar? Sind die bisher bekannten und bewährten Vorgehensweisen und Methoden im Wasserfall-Modell falsch oder nicht mehr zeitgemäß? Die Antwort auf beide Fragen lautet nein. Je nach Unternehmen und Projekt sollte differenziert werden, ob agil oder nicht agil vorgegangen wird. Ein zweistufiges Modell mit jeweils einem Fragenkatalog hilft dabei, die Entscheidung für die richtige Vorgehensweise zu treffen.

Zunächst sollten Unternehmen die grundsätzlichen Voraussetzungen für ein Arbeiten mit Scrum klären:

Prüfung vorhandener Ressourcen

Besitzen wir genügend Ressourcen im Produktmanagement beziehungsweise Vertrieb für die zeitintensive Abstimmung mit der Entwicklung?

Beispielsweise sind Vertriebsabteilungen am Jahresanfang meist weniger ausgelastet und haben Zeit für ein klassisches Fachkonzept. Unter dem Jahr aber wird die Zeit knapp, um permanent in agilen Sprints als Product Owner teilzunehmen.

Prüfung vorhandener Kompetenzen

Sind die Methoden-Kompetenzen im Projektteam vorhanden?

Häufig ist der IT Bereich geschult, aber nicht die beteiligten Fachbereiche, wie Produktmanagement und Vertrieb.

Prüfung der sozialen Kompetenzen

Sind die sozialen Kompetenzen für selbstorganisierte, interdisziplinäre Teams vorhanden?

Feedbackkultur und Führung sind in agilen Projekten unterschiedlich (zum Beispiel permanentes Feedback anstelle jährlicher Mitarbeitergespräche oder Coaching statt Führung). Dazu gehört auch, mit dem hohen sozialen Druck durch tägliches Tracking, wie beispielsweise im Daily Scrum umgehen zu können.

Akzeptanz von weniger Transparenz?

Akzeptieren wir, und insbesondere das Management, weniger Transparenz bezogen auf die gesamte Projektstrecke, aber mehr Transparenz bezogen auf die Teilstrecken (Sprints)?

Vertrauen in Mitarbeiterinnen und Mitarbeiter vorhanden?

Vertraut das Management seinen Mitarbeiterinnen und Mitarbeiter beziehungsweise Teams?

Bei Scum etwa ist ein Eingriff durch das Management in einen laufenden Sprint mit veränderten Anforderungen tabu. Greift das Management dennoch ein, wird die geplante Agilität ad absurdum geführt – was in der Praxis häufig vorkommt.

Erst wenn diese Voraussetzungen erfüllt sind, kommt agiles Vorgehen überhaupt in Frage. Ansonsten müssen die prozessualen und organisatorischen Voraussetzungen mit Hilfe von geeigneten Change-Management-Maßnahmen geschaffen werden.

Ziele von Change-Management-Maßnahmen für das Management sind:

• Vor- und Nachteile agiler und klassischer Methoden sowie deren bevorzugte Einsatzgebiete kennen.
• Tiefergehende Kenntisse agiler Prozesse erwerben, diese auf das Unternehmen übertragen, um und anschließend daraus die erforderlichen organisatorischen Maßnahmen, wie die Bereitstellung von dedizierten Ressourcen für agile Projekte ableiten zu können.
• Weniger Transparenz über die gesamte Projektstrecke, aber mehr Transparenz über die jeweilige Teilstrecke bejahen.
• Geringere Eingriffsmöglichkeiten akzeptieren und den agilen Teams vertrauen.
  

Ziele von Change-Management-Maßnahmen für die geplanten agilen Teams sind:

• Vor- und Nachteile agiler und klassischer Methoden sowie deren bevorzugte Einsatzgebiete verstehen und einsetzen.
• Tiefgehende Kenntisse in agilen Methodiken, damit alle Beteiligten das gleiche Verständnis haben und diese anwenden können.
• Herausforderungen in selbstorganisierten, interdisziplinären Teams kennen und die notwendigen sozialen Kompetenzen erwerben. Wichtig ist besonders der konstruktive Umgang mit Konflikten und dem Gruppendruck sowie die Fähigkeit, Feedback anzunehmen und zu geben.

• Wie hoch ist der Unsicherheitsgrad? Falls die Anforderungen, die zugrundeliegende Technologie und Rahmenbedingungen nicht einem ständigen Wechsel unterzogen sind, spricht das für das Wasserfall-Modell. Das ist beispielweise oft bei IT-Migrationen der Fall.
• Ist das Projekt groß genug? Ein Scrum Team setzt normalerweise fünf bis zehn Vollzeitarbeitskräfte voraus.
• Handelt es sich um ein Großprojekt? Falls ja, gibt es die dafür notwendigen Kompetenzen, um diese beispielsweise mit einem skalierten Scrum-Ansatz zu beherrschen?
• Wie stark sind die Abhängigkeiten zu anderen Systemen beziehungsweise Produkten? Agilität eignet sich am besten, wenn keine oder nur minimale Abhängigkeiten vorhanden sind, wie etwa bei der Gestaltung von Web-Oberflächen.

Nehmen wir ein so genanntes Jahr-2000-Problem (Millennium-Bug oder auch „Y2K“-Bug genannt) bei einem großen Finanzdienstleister als Beispiel zur Klärung der projektindividuellen Fragen. Das Unternehmen musste im Jahr 1999 sicherstellen, dass die Prozesse und Systeme auch mit den Folgejahren umgehen können. Wir nehmen zusätzlich an, dass die Grundvoraussetzungen für agiles Vorgehen im Unternehmen vorhanden sind und auch Großprojekte agil abgewickelt werden können.

Unsicherheitsfaktor

Der Unsicherheitsfaktor ist gering. Die Anforderungen, die notwendige Technik und Rahmenbedingungen für dieses Projekt sind von Anfang an klar und werden sich nicht ändern.

Größe des Projekts

Da alle Prozesse und Systeme des Unternehmens gescannt werden müssen, ist das Projekt groß genug für agile Projektteams. Zusätzlich handelt es sich um ein Großprojekt, so dass mehrere Teams gebildet werden müssen.

Abhängigkeiten

Die Abhängigkeiten sind hoch, da viele Schnittstellen vorhanden sind.

Unter den vorausgesetzten Annahmen lässt die Größe des Projekts agile und nicht agile Vorgehensweisen zu. Entscheidend ist hier der geringe Unsicherheitsgrad, der keine sich wiederholenden Abstimmungszyklen mit der permanenten Einbindung der Fachbereiche erfordert. Eine einmalige, ressourcenschonendere Einbindung im Rahmen der Erstellung eines Fachkonzepts und einmaliger Tests für die Umsetzung ist deshalb sinnvoller. Die hohe Abhängigkeit von anderen Systemen spricht ebenfalls nicht für agile Methoden beziehungsweise Scum. Daher lautet die Empfehlung, nicht agil vorzugehen und das klassische Wasserfall-Modell zu nutzen.

Nicht nur die grundsätzlichen Voraussetzungen für ein agiles Vorgehen im Projekt mit Scrum müssen erst einmal geschaffen werden. Zudem sollten Unternehmen anhand und zu Beginn jedes einzelnen Projekts klären, ob sich ein agiles Vorgehen oder die klassische Wasserfall-Methode besser eignet.