Ich erinnere mich, wie ich einmal bei einer Kundin war, die gerade ein Buch über Scrum gelesen hatte und nun der Meinung war, dass mit diesem neuen Projektvorgehen alle Probleme gelöst seien. „Wir müssen bis Mitte nächsten Jahres das Produkt liefern, daher will ich, dass wir nun Scrum machen!“ rief sie aus. „Ich kann Ihnen versprechen, dass wir mit Scrum bis zu dem Zeitpunkt liefern – ich kann Ihnen nur nicht sagen, was“, war meine, zugegebenermaßen nicht sehr diplomatische, Antwort.
Leider erlebe ich es häufig, dass Kunden, aber auch Manager und Projektleiter der Meinung sind, mit Scrum asl Vorgehen seien alle Projekt-Probleme gelöst. Meiner Meinung nach ist das ziemlich falsch, obwohl ich von Scrum sehr viel halte. Scrum wird die meisten Probleme nicht lösen. Im Gegenteil: Scrum macht viele Projekt-Probleme so schmerzhaft, dass man diese endlich lösen möchte.
Hat der Kunde gar nicht die Zeit, sich dem Projekterfolg zu widmen? Während das bei Dokumenten-Reviews vielleicht kaum auffällt, die der Kunde zusagte, wird es offensichtlich, wenn Reviews immer ohne Stakeholder stattfinden. Gibt es keine wirkliche Sicht darauf, was die zentralen Ziele des Projektes sind? Ein Backlog, der ständig über den Haufen geworfen wird, zeigt dies deutlich. Ist die Technologie, auf der aufgebaut werden soll, risikobehafteter, als man im Elfenbeinturm der Architekturdokumentation noch dachte? Wenn kein Sprint-Ziel gehalten werden kann, dann ist das nicht mehr zu leugnen.
Als diese Probleme werden durch Scrum nicht gelöst. Nur noch unangenehmer als im „klassischem“ Projektvorgehen. Lösen müssen die Beteilgten diese Probleme dann selbst, das kann kein Vorgehensmodell übernehmen.