Fünf vermeintliche Argumente gegen Scrum und für das Vorgehen mit Lasten-/Pflichtenheft – und warum sie nicht stimmen!

1. "Scrum Projekte dauern länger, da in Sprints gearbeitet wird. Man kann Releases nicht planen. Ich habe den Zeitplan nicht in der Hand."

Diese Angst entsteht häufig in Unternehmen, die in traditionelleren Strukturen und Hierarchien aufgebaut sind und üblicherweise auf Basis eines Lastenheft arbeiten. Klassisch geben hier Vorgesetzte oder Auftraggebende von Beginn an ein Veröffentlichungsdatum vor und wiegen sich mit diesem Datum in Sicherheit. Doch ein vordefinierter Release-Termin bedeutet nicht zwingend, dass eine Anwendung auch an diesem Tag veröffentlicht werden kann und so passiert es häufig das am Ende die Seifenblase platzt.

Projekte nach Scrum verlaufen genau durch die definierten Sprintlängen sehr viel strukturierter ab. Das große Ziel wird dabei in viele kleinere Ziele unterteilt, wodurch das Team einen deutlich genaueren Überblick bekommt und den eingeschlagenen Kurs bei Bedarf auch korrigieren kann. Releases werden direkt innerhalb dieser Sprints eingeplant, was natürlich eine organisatorische Arbeit voraussetzt, die das gesamte Team zuvor erbringen muss. Die Planung der Veröffentlichung wird also “von oben” direkt ins entwickelnde Team verlagert, was für viele Unternehmen ungewohnt ist.

2. "Nach Scrum fallen viel zu hohe Kosten für Kommunikation an."

Ja, wenn ein Projekt nach Scrum läuft, wird viel kommuniziert. Das gewisse Maß zu finden, ist hier sehr wichtig. Genau für diese Aufgabe gibt es die Rolle des Scrum Masters, welche:r ein Auge auf das Ausmaß und den Wert der Kommunikation hat. Die "Mehraufwände", die für Kommunikation anfallen, gleichen sich jedoch durch die deutlich gesteigerte Produktivität des Teams wieder aus. Wenn die Scrum Events sinnvoll eingesetzt werden, gibt es im eigentlichen Entwicklungsprozess keine offenen Fragen mehr und Aufgaben können effizient abgearbeitet werden. Mithilfe der Scrum Reviews können Auftraggebende sogar nach jedem Sprint alle Ergebnisse gemeinsam mit dem Team prüfen und reflektieren. Durch diese wertvolle Kommunikation werden Missverständnisse vermieden und die Qualität des Produktes gesteigert.

Das ist ganz anders, wenn ein Projekt ausschließlich klassisch mit Lastenheft läuft und wenig bis keine Kommunikation stattfindet: Das Team rennt dann oft mit wagen Informationen los und hofft, dass es alles richtig verstanden hat. Auftraggebende sehen das Endprodukt häufig erst kurz vor definierten Release-Termin oder erhalten die Information, dass der Zeitplan nicht eingehalten werden kann. Dadurch entsteht Unzufriedenheit auf allen Seiten. Oft wird erst zum Ende des Projektes klar, dass Anforderungen falsch verstanden wurden. Diese nachträglichen Anpassungen kosten viel mehr Zeit, als die sinnvoll eingesetzte und von vorne herein im Scrum-Vorgehen strukturiert eingeplante Kommunikation.

3. "Scrum Projekte können ein Fass ohne Boden werden. Sie sind einfach zu teuer."

Klassische Projekte nach Lastenheft werden in Ausschreibung zugegeben oft zu sehr niedrigen Preisen vergeben. Mitbewerbende drücken sich gegenseitig im Preis und Auftraggebende bekommen zumindest zum Projektstart ein sehr günstiges Angebot. Doch im Nachgang müssen viele Auftragnehmende die Mehrkosten in Rechnung stellen, da die Projekte durch das unrealistisch niedrige Angebot nicht wirtschaftlich sind.

Zudem sollten Auftraggebende auch einkalkulieren, ob sie ein Projekt auf lange Sicht in guten Händen wissen möchten. Eine faire Bezahlung mit maximaler Transparenz, wie es nach der agilen Vorgehensweise möglich ist, schafft eine gute Arbeitsatmosphäre im Team. Durch Vertrauen, Transparenz und Spaß im Team kann die höchste Qualität erzeugt werden. Was nützt ein Produkt mit technischen Schulden, die sich aufgrund von mangelnder Finanzierung eingeschlichen haben?

4. "Scrum macht uns Auftraggebenden viel zu viel Arbeit!"

Viele Unternehmen berufen sich auf das Argument: "Wenn ich ein Projekt klassisch nach Lastenheft starte, habe ich weniger Aufwand auf meiner Seite, da das Entwicklungs-Team das schon macht." Die Aussage stimmt aber nicht unbedingt. Natürlich können sich Kund:innen für die Projektlaufzeit "zurücklehnen" und auf das fertige Produkt warten, doch wissen wir mittlerweile, dass die dadurch entstehenden technischen und konzeptionellen Schulden früher oder später an die Oberfläche kommen.

Im agilen Prozess werden Auftraggebende von Anfang bis Ende in den Prozess einbezogen. Natürlich wird dadurch während der Projektlaufzeit mehr Zeit investiert, doch dafür gibt es auch kein "böses Erwachen". Kund:innen kennen zu jeder Zeit den Stand des Produktes, den Zeitplan und können sich so während des gesamten Projektablauf von der Qualität des Produktes überzeugen.

5. "Ein Lastenheft ist meine Absicherung, damit ich auch das erhalte, was ich erwarte."

Das wäre zwar schön, aber leider sind auch Lastenhefte nicht "wasserdicht". Viel zu viele Anforderungen sind zu komplex, um sie in wenigen Sätzen in einem Lastenheft festzuhalten. Wir müssen bedenken, dass sich Software stetig verändert und weiterentwickelt. Das Lastenheft wird gerade für Software-Entwicklungs-Projekte “zum falschen Zeitpunkt” erstellt, nämlich vor der Entwicklung und bildet dadurch per se während der Entwicklung tendenziell eher die Vergangenheit ab.

In Projekten nach Scrum gibt es dafür extra das Event "Refinement": ein wöchentlicher oder zweiwöchentlicher Termin, in dem die nächsten Anforderungen noch einmal gemeinsam besprochen werden. Ein Lastenheft kann dabei durchaus als Fahrplan dienen, um über geplanten Features sprechen zu können. Es sollte allerdings niemals als verpflichtendes Dokument genutzt werden, welches starr an vor Monaten definierten Anforderungen festhält.

Aus Erfahrung kann ich sagen, dass agiles Arbeiten nach Scrum dem gesamten Team (im besten Fall besteht es aus Mitarbeitenden der Auftraggebenden und Mitarbeitenden der PROJEKTIONISTEN auf Augenhöhe) gut tut, die Qualität des Produkts steigert und somit für jeden Auftraggebenden wertvoll ist. Falls Ihr Interesse geweckt wurde, überzeugen wir Sie gerne!