Über die letzten Monate hinweg ist mir verstärkt aufgefallen, wie sehr man sich in meiner Branche doch ständig nach neuen und noch optimierteren Prozessen umsieht und wie einfach so etwas dann auch ausgenutzt werden kann. Das ist sicherlich nichts Neues und auch nicht speziell nur in der digitalen Branche der Fall. Es ist nur etwas, das mir bewusster geworden ist in letzter Zeit.
Agile Scrum-Manie
Nehmen wird Scrum oder noch etwas unspezifischer: Agile Prozesse. Überall wird mittlerweile „agiles Arbeiten“ eingefordert. Kein Projekt mehr, das sich nicht „agil“ auf die Fahne schreiben möchte. Scrum – als Synonym für agile Prozesse – wird Pflichtprogramm. Mitarbeiter, die absolut gar nichts mit dem Scrumprozess zu tun haben, werden in Scrum-Schulungen geschickt und es wird ihnen nahegelegt, zumindest das PSM I-Zertifikat (Professional Scrum Master auf Stufe 1) zu machen.
Doch wofür? Damit der Creative Lead was macht? Den Entwicklern auf die Finger schauen, damit sie auch ganz sicher ihre Daily Standups durchführen? Oder die Story Points richtig verteilen? Natürlich nicht. Es geht selbstverständlich darum, dass man nach außen hin vorzeigen kann, dass auch der Facility Manager agil arbeiten kann. Dabei wird vermutlich ausgerechnet dieser sogar agiler arbeiten als die meisten Projekte, die gezielt Scrum einsetzen wollen, um agiler zu werden. Und mal ehrlich: Was bedeutet das Zertifikat denn überhaupt? Jeder, der ein paar Sachen auswendig lernen kann und weiß mit der PDF-Suche und Google umzugehen, wird den Test bestehen. Oder man nimmt ein paar Euro in die Hand und lässt den Test von jemandem machen, der das Thema versteht. Was selbstverständlich nicht in Ordnung wäre, aber so funktioniert die Welt leider.
Nein, das Zertifikat alleine bedeutet nicht viel. Vielmehr muss man Scrum-Projekte durchführen um zu verstehen, worauf es ankommt und wo man bestimmte Stellschrauben drehen muss.
Dabei verliert Scrum oftmals seinen ursprünglichen agilen Gedanken und wird zu einem Kontrollwerkzeug. Es geht weniger um eigenverantwortliche Entwicklung eines Produkts durch ein Team, als vielmehr um die tagtägliche Kontrolle über das Team und den Projektverlauf. Die täglichen Standups werden zur Leistungskontrolle, bei denen man bestenfalls auch immer ausreichend berichten kann, was man getan hat und was man noch plant zu tun. Der Informationsaustausch unter den Teammitgliedern rückt dabei immer weiter in den Hintergrund. Ich kann euch zu dem Thema diesen Artikel hier auch wärmstens ans Herz legen: https://www.infoq.com/articles/agile-agile-blah-blah/
Agil ist dabei oft nur die Art, wie Teammitglieder ausgetauscht werden, wenn jemand über mehrere Standups hinweg keinen nennenswert sichtbaren Fortschritt vorweisen kann. Der Planungs- und Entwicklungsprozess ist meistens weit weniger agil. Kontrolle tritt dabei in den Vordergrund, da man den Teams kein Vertrauen entgegenbringt. Es stimmt schon, dass man fähige Leute braucht, damit Scrum funktioniert. Zu schnell werden ansonsten falsche Entscheidungen getroffen, die – selbst im agilen Umfeld – viel Zeit und Geld kosten können. Aber selbst mit sehr fähigen Personen werden Projekte gerne als agil verkauft und dann als klassisches Wasserfallprojekt mit zusätzlichem Chaosfaktor durchgeführt. Chaosfaktor deshalb, weil Scrum zwar umgesetzt werden soll, dann aber so wichtige Teile wie die Retrospektive nicht durchgeführt werden. Wer Scrum einsetzen will, sollte die dahinterstehende Philosophie auch verstehen (ich kann das Buch hier empfehlen, auch wenn es echt nicht spannend zu lesen ist).
Ich durfte persönlich erleben, wie sich ein Scrumteam über mehrere Sprints hinweg für eine kleine (sinnvolle!) Änderung im Prozess ausgesprochen hatte. Der Scrum Master (gleichzeitig aber auch Business Stakeholder) hatte diesen Wunsch schlichtweg abgelehnt, ohne dafür eine stimmige Erklärung abzugeben. Ein absolutes No-Go in Scrum, da das Team die Entscheidungsgewalt über solche Dinge hat. Da man die Kontrolle aber nicht abgeben wollte, wurde nun also augenscheinlich Scrum eingesetzt, dieses aber eben dann doch nicht wirklich angewendet. Solche Dinge resultieren dann in frustrierten Mitarbeitern, die genau merken, dass Scrum letztlich nur als Kontrollinstrument eingesetzt wird und eigentlich gar kein Scrum durchgeführt werden soll.
Scrum kann ein sehr sinnvolles Framework sein. Wenn das Team passt. Wenn Scrum zum Projekt passt. Wenn dem Team ausreichend Freiraum gegeben und nur die Richtung für das Team vorgegeben wird.
Trifft das nicht zu, dann sollte man vielleicht doch lieber ein Wasserfall-Projekt durchführen. Da weiß man wenigstens woran man ist.
Design Sprints als Allheilmittel
Ein weiteres Beispiel für den Missbrauch eines Hypes sind Design Sprints. Eins vorweg: ich finde Design Sprints super. Ich bin ein großer Freund dieses Prozesses, da er sehr lösungsorientiert ist und schnell greifbare Ergebnisse liefert.
Dennoch sehe ich, wie Design Sprints regelrecht glorifiziert werden. Ich befinde mich natürlich in meiner Filterblase und bin diesen Dingen extremer ausgesetzt, aber: Alles Mögliche soll jetzt mit Design Sprints gelöst werden. Ob es nun sinnvoll ist oder nicht z.B. Auswahlprozesse für Jobbewerber über Design Sprints durchzuführen…ich weiß es nicht. Ich bezweifle aber, dass wir in Zeiten von Big Data und der Selbstdarstellung per Webseite, LinkedIn, Xing, Dribble oder Behance einen doch recht zeitintensiven Prozess wie diesen benötigen. Ich kann aber natürlich komplett falsch liegen.
Mir geht es darum, dass hier ein System aufgebaut wird über ein Netzwerk von Design Sprint Moderatoren, das sich einen selbsterhaltenden Markt aufbauen will, indem suggeriert wird, Design Sprints wären das beste Mittel für alles. Je mehr Leute diese Idee aufgreifen und selbst verkaufen möchten, desto größer wird das Netzwerk und desto mehr entsteht der Eindruck, dass Design Sprints vielleicht wirklich die Lösung aller Probleme sein könnte.
Wer von Design Sprints hört und sich darüber informieren will, wird viele begeisterte Berichte darüber finden und sehen, dass dort einiges passiert. Dazu noch unzählige kostenfreie Meetups und Webinare,…letztlich alles nur Marketingmaßnahmen, die ganz automatisch durch die Anhängerschaft durchgeführt werden. Da ist es gar nicht so einfach auch mal kritische Stimmen zum Thema zu finden (die es aber natürlich schon gibt: https://www.invisionapp.com/inside-design/design-sprint-wont-work/).
Das ist jetzt auch wieder nichts Neues. Schließlich muss man der Welt einfach mal mitteilen, was sie braucht – auch wenn es es vorher auch ganz gut ohne funktioniert hat. Vielleicht rege ich mich auch umsonst darüber auf. Aber immer wenn etwas DIE eine Lösung sein soll, werde ich skeptisch.
Wieso ist das so?
Warum wir uns immer wieder nach neuen Methoden umschauen, ist mir nicht ganz klar. Ist es der ständige Erfolgsdruck? Der Druck, effizienter zu arbeiten und Abläufe immer weiter und weiter zu optimieren? Oder liegt es vielleicht auch einfach daran, dass wir uns nicht zufrieden geben wollen mit den bestehenden Prozessen? Ich weiß es nicht. Ich habe mich jetzt in der Richtung gar nicht allzu sehr eingelesen. Ich weiß aber, dass es durchaus auch anders geht und man nicht immer jeder neuen Optimierungsmöglichkeit hinterher rennen sollte.
Ein kritisches Auge haben
Wir sollten uns vielleicht einfach weniger Gedanken darüber machen, welche neuen Tools, Frameworks oder Prozesse wir ausprobieren sollten, um Arbeitsabläufe noch weiter zu optimieren. Es macht keinen Sinn, Mitarbeitern neue Prozesse aufzuzwingen, wenn diese eigentlich nicht auf das Unternehmen, die Teams oder bestehende Abläufe passen.
Vielmehr sollte Mitarbeitern die Entscheidungsfreiheit zugestanden werden, Abläufe selbst zu verbessern oder zumindest gemeinsam über Optimierungsmaßnahmen zu sprechen und diese zu entwickeln. Dabei darf man natürlich bestehende Tools oder Frameworks heranziehen. Diese sollten dann aber ggf. so angepasst werden, dass sich die Mitarbeiter auch wohl fühlen damit. Denn nichts könnte der Verbesserung der Arbeitsprozesse mehr im Weg stehen als unzufriedene Mitarbeiter.
Dass man auch mit unkonventionellen Methoden Erfolg haben kann, sieht man beispielsweise an der Art, wie Basecamp sein Unternehmen führt: https://basecamp.com/shapeup/
Hier wird auf bekannte Modelle verzichtet und stattdessen so gearbeitet, wie es zumindest aktuell am besten funktioniert – ohne dabei in einer endlosen Spirale von Optimierungsmaßnahmen zu enden. Aber auch deren Arbeitsweise lässt sich nicht einfach auf jedes andere Unternehmen übertragen. Es funktioniert für Basecamp, aber andere Firmen würden damit vielleicht komplett vor die Wand fahren.
Ich sehe es auch kritisch, wenn eigentlich gute Prozesse Gefahr laufen, einen negativen Beigeschmack zu bekommen (so wie jetzt “agile Prozesse” und “Scrum”). Zu oft geraten Dinge in Verruf, weil sie nicht richtig oder nicht richtig dosiert angewendet wurden. Aufgrund dessen, dass man bei der ständigen Suche nach neuen Optimierungswerkzeugen mitunter relativ leicht beeinflussbar wird, werden oft falsche Entscheidungen getroffen oder diese Beeinflussbarkeit auch ausgenutzt. Wenn Kunden Maßnahmen verkauft werden, die dann nicht den gewünschten Effekt erzielen, wirft das schnell ein schlechtes Licht auf eben diese Maßnahme. Als Spezialisten haben wir deshalb die Pflicht, hier kompetent zu beraten und nicht jeden Hype zu verkaufen, nur weil man schnelles Geld machen kann oder Kunden nach einem bestimmten Prozess fragen, über den sie im Internet gelesen haben. Vielmehr sollten wir nach sinnvollen Lösungen suchen – auch wenn das bedeutet, dass man gegen den Strom schwimmen muss.
Denn manchmal ist das Wasserfallmodell eben leider doch die beste Lösung für ein Projekt.
(Alle meine Artikel werden von mir persönlich geschrieben. Da schaut niemand mehr drüber, was manchmal vielleicht besser wäre. Aber dadurch bekommt man eben auch genau das zu lesen, was ich so denke und recherchiert und gelernt habe. Da bleiben ein paar Rechtschreibfehler nicht aus. Das tut mir auch echt leid, aber damit muss man dann auch einfach mal klar kommen.)