Ist Scrum das richtige Framework für unser Projekt?

Scrum” ist ein Wort das man derzeit recht häufig in vielen Entwicklungsbüros und Chefetagen hört. Endlich gibt es eine Methode um komplexe Software oder Produkte zu entwickeln ohne das Risiko des Misserfolgs, weil Deadlines nicht eingehalten werden können oder weil Probleme durch falsche Konzeption enstehen die das komplette Endprodukt gefährden. Mit Scrum kann man also ab sofort nichts mehr falsch machen! Das hochqualitative Endprodukt wird schneller und mit weniger Aufwand fertig. Und weil das noch nicht reicht: Auch die Kosten werden niedriger ausfallen. Warum ist da eigentlich vorher noch keiner drauf gekommen?

Das Framework für agile Software-/Produktentwicklung taucht erstmals in einem Buch von Ken Schwaber und Mike Beedle auf. Seit dem zieht Scrum immer mehr in Teams, Unternehmen und mittlerweile sogar in Konzernen als Wundermittel ein.

Dabei steht schon in den ersten Büchern, dass Scrum Probleme nicht lösen kann, sehr wohl aber diese aufzudecken und zu lokalisieren vermag.

Wie, Scrum löst keine Probleme sondern macht welche? Das wurde wohl bei den meisten Präsentationen von Vertrieblern, Projektmanagern und anderen Scrum-Infizierten vergessen zu erwähnen. Ich wiederhohle noch mal: Scrum deckt Probleme auf! – Jetzt fragen sich einige: “Was für Probleme, wir haben doch garkeine!” – Dann komme ich mal mit der Gegenfrage: “Warum dann überhaupt etwas ändern? Dann bleibt doch bei eurem alten Wasserfallmodell wenn alles so problemlos ist!”

Zehntausende von verstrichenen Deadlines oder nie fertig gestellten Produkten und Millionen von Überstunden sprechen leider eine andere Sprache. Die Wahrheit ist: Die Projekte werden immer komplexer, die Anforderungen immer kurzlebiger. Das ist mit konventionellen Methoden nicht mehr kontrolliert abbildbar. Oft landen ganze Projekte auf dem Müll, weil sich die Welt nach der eigentlich Konzeptionsphase schon x-mal um sich selbst gedreht hat und das fertig Konzeptionierte noch vor Beginn der Entwicklung nicht mehr aktuell ist. Und da kommt jetzt Scrum herbei und verspricht eben diese Probleme unter Kontrolle zu bringen – entschuldigung, ich meine natürlich: diese Probleme aufzuzeigen. Ich sag es noch mal: AUFZUZEIGEN!

Aber was soll jetzt diesen “Aufzeigen” bringen? Ganz einfach: Es soll dem Team ermöglichen strukturiert an Problemlösungen zu arbeiten. Und mit Team meine ich nicht nur die Programmierer die das Produkt oder die Software erstellen. Zu einem Scrum-Team gehört auch der Kunde, bzw. Product Owner wie er in Scrum-Teams genannt wird. Auch er ist ein Produktentwickler. Daraus ziehe ich den Schluss:

Totale Transparenz. Keine Hierarchie.

Das muss jedem der in einem Scrum-Team arbeitet bewusst sein. Mitdenken, Verantwortung, Teilen. Wen das einer nicht kann oder will, ist das Scrum-Team gefährdet. In der Praxis sieht es häufig so aus, dass der Auftragnehmer Teams stellen kann, die dazu in der Lage sind. Aber was ist mit dem Auftraggeber? Auftraggeber sind es gewohnt, einen Wunsch in form eines Pflichtenhefts zu äußern, der dann auch umgesetzt wird. Dafür bezahlt man ja Geld, oder nicht? In einem Scrum-Projekt ist das nicht ganz so. Hier wird davon ausgegangen, dass der Auftraggeber (Produkt Owner) seinen “Wunsch” Stück für Stück mit dem Team über einen großen Zeitraum erarbeitet. Und in dem Wort “erarbeitet” liegt häufig das Problem. Man erteilt ja einen Auftrag um eben Zeit für andere Arbeit zu haben. In Scrum-Teams ist es jetzt aber so, dass der Product Owner ein Glied in der Kette ist dessen Arbeitskraft genauso gefragt ist wie jedes anderen Teammembers. Nur wenn das gegeben ist, wird ein Scrum-Projekt zum Erfolg führen! Um Enttäuschungen vorzubeugen und Entscheidern eine Hilfe zu geben ob Scrum das richtige Framework für deren Projekt ist kommentiere ich anschließend ein paar Zitate über Scrum die ich im Netz gefunden habe:

“Scrum kann keine Erfolgsgarantie bieten.”

Wie schon bereits oben erwähnt: Scrum zeigt Probleme auf. Lösungen müssen vom Team erarbeitet werden.

 

“Wer Scrum macht, muss sich darauf einstellen, dass seine Erwartungen permanent enttäuscht werden.”

Scrum ist dazu da so schnell wie möglich die Abweichungen vom Soll-Zustand aufzuzeigen um schnell darauf reagieren zu können.

 

“Der Erfolg hängt davon ab was das Team aus den gewonnen Erkenntnissen macht.”

Das Team ist dazu angehalten auf aktuelle Probleme zu reagieren. Und mit Team ist jeder einzelne gleichermaßen gemeint.

 

“Die Selbstorganisation im Entwicklungsteam beinhaltet den Grundsatz, dass es im Team keine permanente Hierarchie geben darf.”

Mitglieder die nicht bereit sind ihren bisherigen Status aufzugeben führen zu Konflikten.

 

“Von Scrum wird gefordert, dass prinzipiell alle Teammitglieder alle Aufgaben eines Sprints bearbeiten können.”

Jedes Mitglied soll die Rolle von jedem anderen einnehmen können. Jeder ist Architekt, Programmierer, Tester, …

 

Wenn nach dem Artikel Zweifel aufkommen, dass Scrum vielleicht nicht das richtige Framework für das Projekt ist gibt es zwei Möglichkeiten.

  1. Scrum ist nicht die richtige Mehtode für das Projekt.
  2. Du bist nicht die richtige Person für das Projekt.
Wem das Aufzeigen von Problemen nicht reicht und sich doch für eine konventionelle Methode entscheidet, hat eben genau dieses “Aufzeigen” auch noch verloren.
Scrum ist ehrlich und transparent. Und Transparenz und Ehrlichkeit ist im politischen Umfeld von Konzernen nicht immer so einfach umsetzbar oder manchmal auch einfach nicht erwünscht.