5 Gründe, warum Scrum Projekte scheitern

5 Gründe, warum Scrum Projekte scheitern

Scrum Projekte scheiternWoran liegt es, dass Scrum Projekte scheitern? Welche Erklärungen geben die Verantwortlichen? Sind die Projektmitarbeiter nicht agil? Fehlt es am Mindset? Oder wurde ein Scrum Evangelist beauftragt, Maßnahmen herzuleiten? Nicht selten hört man Sprüche wie „Das, was ihr hier macht, ist ja auch kein echtes Scrum“. Nach dem Motto „Mehr vom Gleichen“ (aus dem Buch Anleitung zum Unglücklichsein von Paul Watzlawik) führt ein Scrum Master mehr „echtes“ Scrum ein. Hilft aber nicht unbedingt. Statt das Notwendige wird das Geglaubte getan. Es ist fast wie bei der spanischen Inquisition: Glaube ersetzt Wissen und Können. Dabei gibt uns Wissenschaft und Forschung genügend Hilfsmittel für erfolgreiche Projekte. Woran liegt es wirklich, dass Scrum Projekte scheitern?

Missverständnis über agiles Projektmanagement

Wenn ein Manager das Wort agil hört, übersetzt er agil in modern, schnell und günstig. Wenn ein Projektmitglied das Wort agil hört, übersetzt es agil in modern, spannend und flexibel. Agiles Projektmanagement ist allerdings nicht per se schneller oder günstiger als klassisches Projektmanagement. Agiles Projektmanagement liefert schneller Teilergebnisse. Ein Beispiel verdeutlicht das: Sie wollen eine Gruppenreise mit 6 Personen von Hamburg nach München durchführen.

  • Beim klassischen Projektmanagement würden Sie im Vorfeld verschiedene Angebote einholen und je nach Priorität das günstigste oder das schnellste Angebot auswählen. Es vergehen einige Stunden, bevor Sie sich auf die Reise begeben.
  • Beim agilen Projektmanagement würden Sie unter den jetzt gerade verfügbaren Angeboten eines auswählen, welchen Sie Ihrem Ziel ein Stück näher bringt. Vielleicht eine Bahnfahrt von Hamburg nach Bremen. Dann würden Sie in Bremen den nächsten Schritt planen, vielleicht mit Flixbus nach Nürnberg. Eventuell finden Sie Nürnberg so interessant, dass Sie garnicht mehr nach München reisen würden.

Sie sehen, agile Methoden sind nicht zwangsläufig schneller oder günstiger als klassische. Sie liefern schnellere Zwischenergebnisse und erlauben Ihnen, das Ziel zu verändern.

Die Methode ist dem Projektauftrag nicht angemessen

Scrum wurde erstmals 1986 in dem Artikel „The New Product Development Game“ von Takeuchi und Nonaka vorgestellt und kommt aus der Produktentwicklung. Kundenindividuelle Softwareprojekte bestehen allerdings aus mehr als aus reiner Produktentwicklung. Wenn Sie beispielsweise ein  CRM-System für 10.000 Außendienstmitarbeiter in über 50 Ländern ablösen wollen, haben Sie einen hohen Anteil an Schulung, Rollout und Support. Teile, die Sie im Vorfeld genau planen müssen. Klassisches Projektmanagement ist dazu besser geeignet als Scrum.

Der größte Unterschied zwischen agilem Projektmanagement und klassischem Projektmanagement ist die unterschiedliche Priorität von Sachziel und Terminziel (siehe auch Das magische Dreieck oder Projektmanagement beim Wochenendeinkauf). Bei agilem Projektmanagement hat die Timebox (oder der Sprint) die oberste Priorität. Das Sachziel wird ggf. verändert, um die Timebox halten zu können. Bei klassischem Projektmanagement hat das Sachziel die oberste Priorität und die Zeit (Projektdauer) wird ggf. angepasst (Terminverschiebung). Immer dann, wenn das Sachziel nicht verändert werden kann (z.B. bei einem Umzug eines Rechenzentrums oder beim Ablösen eines Altsystems), genügt Scrum alleine als Methode nicht. Nichtsdestotrotz kann es in Teilen, beispielsweise für die Programmierung des neuen Systems, eingesetzt werden. Wenn jedoch statt 7 Sprints á 3 Wochen 12 Sprints á 3 Wochen benötigt werden, verschieben sich die Benutzerschulungen, die Datenübernahme und die Einführung um 15 Wochen. Es ist mehr als offensichtlich: Wenn Scrum als Methode nicht angemessen ist, werden Scrum Projekte scheitern.

Die Selbstorganisation im Team funktioniert nicht

Sich selbst organisierende Teams stellen eine große Herausforderung an die beteiligten Teammitglieder dar. Die in Gruppen ablaufenden Prozesse sind in dem Buch „Dynamik in Gruppen“ von Eberhard Stahl hervorragend beschrieben. Forming, Storming, Norming und Performing hat jeder aus dem Projektgeschäft bereits gehört. Aber was bedeutet das ganz konkret für ein Projekt? Vereinfacht muss das Team zu Beginn eines Projekts die Rahmenbedingungen verhandeln. Also beispielsweise, welche Tools verwendet das Projektteam, wie kommunizieren das Projektteam, wie geht es mit Störungen um etc. Daraus entsteht ein erster „Gruppenvertrag“, der im weiteren Projektverlauf angepasst werden muss. Wenn dieser „Gruppenvertrag“ nicht entsteht, funktioniert die Selbstorganisation im Team nicht. Gründe für das Scheitern der Selbstorganisation sind:

  • Der Projektauftrag ist nicht aus dem Team entstanden, sondern von außerhalb festgesetzt worden. Das Team sieht den Projektauftrag deshalb nicht als eigenes Interesse.
  • Das Team benötigt zu Beginn Zeit, um einen ersten Gruppenvertrag zu verhandeln. Diese Zeit wird dem Team von Außen (z.B. in Form eines Budgets) nicht zugestanden. Es soll ja schnell gehen (siehe auch Missverständnis über agiles Projektmanagement). Im Gegensatz zu Produktentwicklungsteams benötigen Projektteams, die erstmalig zusammenarbeiten, länger um den ersten Gruppenvertrag zu verhandeln.
  • Informatiker können keine Gruppenverträge verhandeln. Alleine die Tool-Frage zur Pflege der User Stories kann schon hitzige Diskussionen auslösen.
  • Der Scrum Master gibt einen großen Teil der Rahmenbedingungen vor (User Stories, Sprints, Meetings, …). Einerseits entlastet diese Vorgabe das Team davon, die Rahmenbedingungen verhandeln zu müssen. Andererseits nimmt es den Teammitgliedern die Möglichkeit zu verhandeln. Ist die Methode dem Projektauftrag nicht angemessen, ist das Scheitern des Scrum Projekts vorprogrammiert.
  • Die Teammitglieder machen oberflächlich zwar mit (meinetwegen), unterstützen aber innerlich den Gruppenvertrag nicht. Das kann man erkennen, wenn Absprachen nicht eingehalten oder die verhandelten Tools nicht eingesetzt werden.

Die Liste gilt nicht nur für Scrum-Teams sondern generell für Projektteams. Mit einem fehlenden „Gruppenvertrag“ scheitern Scrum Projekte und alle anderen auch.

User Stories sind unzureichend

Um gute User Stories zu schreiben, benötigt man Erfahrung. Die Form einer User Story ist zwar einfach und festgelegt (siehe User Story in Wikipedia). Doch diese Einfachheit macht eine kluge Verwendung auch schwierig. Mit der User Story „Als Anwender möchte ich alle notwendigen Funktionen ausführen, um meine tägliche Arbeit zu erledigen“ können Sie jedes beliebige System beschreiben. Geschicktes Hinterfragen und aufteilen der User Stories in die richtige Größe sind absolut wichtig. Um Hunderte User Stories zu organisieren sind User Story Maps entstanden oder mehrere User Stories werden zu einem Epic zusammengefasst.

Im Kontext der Produktentwicklung (z.B. einer Webseite oder einer App) leisten User Stories gute Dienste und können als alleinige Dokumentation genügen. Führt jedoch ein Dienstleister ein Projekt für einen Kunden durch und der Kunde möchte zu einem späteren Zeitpunkt den Dienstleister wechseln, benötigt man – trotz der Aussage des agilen Manifests – zusätzliche Dokumentation. Wie ein Stadtplan von den Details einer Stadt abstrahiert und dadurch einen Überblick gibt, sollte die Dokumentation einen Überblick über das System geben. Und das besser grafisch als textuell. Hilfreiche zusätzliche Dokumentationsformen sind:

Außerdem gibt es Bereiche, in denen es bessere Formen der Anforderungsanalyse als User Stories gibt (z.B. Schnittstellen, Datenübernahmen oder beim Reengineering).

Wenn es auch anders geschrieben steht: Anwender denken nicht in User Stories. Aus der Psychologie ist bekannt, dass die meisten Menschen Informationen überwiegend visuell verarbeiten. Deshalb sind Prozessmodelle und Wireframes eine hervorragende Bereicherung von User Stories. Leider werden diese oft aus dogmatischen Gründen abgelehnt. Getreu dem Motto: Wer als Werkzeug nur einen Hammer hat, für den ist jedes Problem ein Nagel.

Mangelnde Professionalität des Projektteams

In der Informatik ist es wie im Fußball. Es gibt Profis und es gibt Amateure. Zwischen Profis und Amateuren liegen Welten. Leider gaukelt uns die öffentliche Diskussion vor, dass alle Informatiker mit etwas wahrem Scrum, einem Spritzer Kanban und 100 Gramm Agilität ebenfalls zu Profis werden. Das ist ungefähr so, als würde man Jogi Löws Trainingsmethoden auf eine beliebige Hobbymannschaft anwenden und sich ernsthaft Hoffnungen auf einen Titel bei der nächsten WM machen. Absurd!

Profis und Amateure kann man leicht unterscheiden. Ein Profi wird die „Selbstverständlichkeiten“ von sich aus berücksichtigen. Beispielsweise, dass man Desktop-Anwendungen auch mit der Tastatur bedienen kann. Ein Amateur wird bemängeln, dass die User Stories oder Testfälle unvollständig sind. Ein Profi hat so etwas ähnliches schon mal gemacht. Ein Amateur beginnt fast bei Null. Einem Amateur muss man genau vorgeben, was er tun soll. Einem Profi muss man nur das Ergebnis beschreiben, er findet seinen Weg selbst. Ein Profi kann sich in die Situation von Anderen hineinversetzen, sei das der Anwender oder der Systembetrieb. Ein Amateur argumentiert, warum er Recht hat und die Anderen falsch liegen.

Wenn ein Projekt für einen Implementierungspartner nicht wichtig ist, werden oft Amateure geschickt. Das treibt die Aufwände für die Anforderungsanalyse, die Implementierung und den Test exponentiell nach oben. So kann aus einem kleinen Projekt schnell ein Großes und Teures werden. Nicht selten würden Profis das gleiche Projekt für ein Viertel der Kosten realisieren. Allerdings wird das durch die agile Vorgehensweise selten transparent. Für mich ist allerdings auch das ein Grund dafür, dass Scrum Projekte scheitern.

Fazit

Einer der wichtigsten Gründe, warum Scrum Projekte scheitern ist das dogmatische Festhalten der Evangelisten am Scrum Prozess. Einerseits wird dem Team die Möglichkeit genommen, einen eigenen – vielleicht besseren – Gruppenvertrag auszuarbeiten. Andererseits kann die Methode unzureichend oder unangemessen sein. Außerdem trägt mangelnde Professionalität dazu bei, dass Scrum Projekte scheitern.

Weitere Beiträge zum Thema:

5 Gründe, warum Scrum Projekte scheitern

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.