Scrum ist kein Rosinen heraus picken

Funktioniert Scrum besser als die Wasserfallmethode? Oder sollte man sich aus beiden Ansätzen bedienen?

Schon seit einigen Jahren geistert gerade in der Welt der Softwareentwicklung das Buzzword „Scrum“ durch die Flure. Die meisten davon wissen zwar nicht so richtig was sich dahinter verbirgt, aber immerhin muss es verdammt trendy sein. Für die einen ein Grund es unbedingt machen zu wollen, während andere gerade deshalb demonstrativ die Finger davon lassen.

Dabei ist Scrum tatsächlich in erster Linie nur ein Modewort, das viele Dinge einfach nur zusammenpackt und dann sozusagen als alten Wein in neuen Schläuchen verkauft. Wobei man sich das Thema natürlich dennoch zu Gemüte führen kann, hält Scrum doch auch den ein oder anderen guten Ratschlag bereit.

Leider habe ich es in meiner Laufbahn oft erlebt, dass sich nicht wenige aus dem Scrum-Konzept sozusagen die Rosinen herauspicken und andere Aspekte ignorieren. Gerade im Softwarebereich ist die Gefahr groß, am Kunden vorbei zu produzieren. Im extremen Klischee ist der Programmierer ein Nerd und der Kunde ein DAU (Dümmster anzunehmender User). Auf diese Weise kommt oft Software auf den Markt, die der Kunde nicht versteht, während dem Programmierer glaubt, er hätte da etwas gezaubert, was er schon im Kindergarten hätte verstehen können. Während viele Unternehmen von diesem Detail des Konzeptes lieber die Finger lassen, auch wenn sie felsenfest behaupten, auch bei ihnen stehe der Kunde im Mittelpunkt, sind sie ganz heiß auf einen anderen Aspekt von Scrum. Das der Kunde nämlich sozusagen in die Entwicklung eingebunden wird, indem er möglichst schnell eine Lösung für sein Problem bekommt. Nehmen wir zum Beispiel an wir programmieren ein Content Management System und der Kunde möchte irgendeine zusätzliche Funktion, diese bekommt er dann auch möglichst schnell und sie funktioniert bei ihm auch. Wer an dieser Stelle aber kein ordentliches Versionsmanagement hat, und das haben selbst viele mittelgroße Softwarefirmen nicht, produziert auf diese Weise ein großes Wirrwarr an verschiedenen Versionen, bei denen Module teilweise nicht miteinander arbeiten können, die Usability widersprüchlich bis nicht vorhanden ist oder eine Dokumentation den Endanwender bestenfalls verwirrt.

Scrum wurde als Gegensatz zum sogenannten Wasserfallmodell entwickelt, bei dem zu Beginn eines Projektes ein großer Gesamtplan entwickelt wurde, der mit dem Kunden noch abzusprechen war und schließlich so umgesetzt wurde. Das hatte natürlich den Nachteil, dass man wenig flexibel war und manche Anforderungen, die am Anfang galten, bei Auslieferung schon überholt sein können. (Was meistens der Fall ist und unnötige Unzufriedenheit auf beiden Seiten produziert.)

Allerdings erleichtert Scrum den Prozess nicht nur, indem er Flexibilität und Schnelligkeit bringt, sondern macht Projekte durchaus auch komplizierter. Denn wirklich umgesetzt verlangt es zum Beispiel von Managern auch, seinen Mitarbeitern nicht ständig ins Handwerk zu pfuschen sondern die Programmierer auch mal machen zu lassen. Scrum verlegt seine Rolle vom Befehlen und Lenken deutlich hin zum organisieren. Die Programmierer unterdessen müssen aufhören sich auf ihre kleine Wissensinseln zurückziehen und sich als Teamplayer beweisen. Jeder muss nicht alles können, aber es darf im Team auch niemanden mehr geben, der nicht in Urlaub fahren darf, weil sonst der ganze Laden zusammenbricht. Teammeetings, bei denen täglich kurz gebrieft wird, was wer gerade macht, sind da nur ein Anfang.

Nur ein katastrophaler Umstieg, ist ein guter Umstieg!

Wer von einem besonders hierarchischen Prinzip auf Scrum umsteigt, wo Projekte zudem nach der Wasserfallmethode geplant wurden, geht oft mit der Erwartung heran, dass jetzt alles besser werden wird. In gewisser Weise stimmt das natürlich auch, weil einzelne Elemente ja durchaus Verbesserungen im Ablauf bringen. Der Haken an der Geschichte ist aber, das Scrum die Probleme in einem Unternehmen nicht löst, sondern nur besser sichtbar macht. Wer plötzlich anfängt tägliche Reviews und 14-tägige Gesamtbetrachtungen zu machen, wird nicht nur auf bekannte Probleme stoßen, sondern eben auch auf viele kleine Probleme, die den Prozess behindern, bisher aber nie wirklich offensichtlich wurden. (Entweder weil man sie überhaupt nicht erkannt hat, oder sie mit viel Arbeitsaufwand vertuschte.) Ist man dann von Scrum ohnehin nicht besonders überzeugt, führt das mitunter auch zu der Einstellung, dass Scrum bei einem eben nicht funktioniere.

Ob es aber am Ende tatsächlich notwendig ist von 100% Wasserfall auf 100% Scrum umzusteigen, dass darf dann doch dahingestellt sein. Beide Ansätze haben ihre Vor- aber eben auch Nachteile. Sicher wäre eine Kombination die beste Lösung, indem man sich herauspickt, was im eigenen Ablauf am besten funktioniert. Abläufe sind schließlich auch etwas, was sich einspielen muss. Allerdings hat natürlich auch dieser Ansatz seine Nachteile, wie zum Beispiel das oben beschriebene Rosinen picken.

—————-

Eine kurze Einführung in Scrum und ein Gespräch über die Vor- und Nachteile gibt es in diesem Video:

About Thomas Matterne

Thomas Matterne ist Chefredakteur des dreisprachigen Online-Magazins DenkZeit und als Online-Marketing-Manager tätig. Der ausgebildete Journalist hat ein Diplom in Wirtschaftsinformatik, und schreibt an dieser Stelle über IT-, Online-Marketing- und SEO-Themen - unteranderem.

Schreibe einen Kommentar

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