Scrumbug: Auslegung mit Methode … oder so

Nur wo Scrum draufsteht, sollte auch Scrum drin sein -echt.

Alles andere ist Humbug. Hier dazu eine passende Fallstudie.

Ein Erfahrungsbericht mit überraschender Wendung

Erinnern Sie sich an das Gefühl totaler Erschöpfung? In einem Projekt? Ich schon. Nach der Einführung eines neuesten Bezahlprodukts vor einem gefühlten Jahrhundert – tatsächlich war es nur ein Monat – herrschte das blanke Chaos. Das Produkt? Ein Desaster – hübsch verpackt im Print Backlog, instabil wie ein Kartenhaus im Wind. Die Reaktion der Nutzer fiel entsprechend ‚mager‘ aus, was uns, das Team und mich, ehrlich gesagt, nicht wirklich überraschte.

Die globale Ausrichtung des Unternehmens, wo ich tätig war, verschärfte die Situation noch. Störungen kannten keine Zeitzonen und verlangten sofortige Intervention, was zu einem permanenten Zustand von Schlafmangel und deutlichem Stress führte. Inmitten einer unserer obligatorischen Retrospektiven platzte Michael, dem Projektleiter (war schon interessant: „Projektleiter …“) der Kragen: „So geht es nicht weiter! Wem wollen wir hier eigentlich etwas vormachen?“

Die Kehrtwende

Michael sprach die echte Wahrheit aus. Eine Veränderung, also die Notwendigkeit dazu, war unausweichlich. Unsere „Lösung“? Wir beendeten die Ära von Scrum als unser primäres Projektmanagement-Framework. Und siehe da, eine neue Welt tat sich auf! Eine Entscheidung, die ich jedem in einer ähnlichen Lage nur wärmstens empfehlen kann.
Erste Erkenntnis: Nicht überall, wo Scrum draufsteht, ist auch Scrum drin, oder passt Scrum. Da helfen auch keine Skalierungen. Die skalieren das Unpassende, nicht Scrum.

Scrum lockt mit verheißungsvollen Versprechen, einer Beschreibung um die 20 Seiten, genauso wie der berühmte Ausspruch von Jeff Sutherland, einem der Väter der Methode: „Doppelt so viel Arbeit in der Hälfte der Zeit“. Den hat er später revidiert. In unserer, also dieser Realität führte Scrum jedoch eher zu einem zähem Stillstand. Es war höchste Zeit, dieses klebrige, vermeintliche Allheilmittel kritisch zu hinterfragen. Der Ruf nach Aceton wurde laut.

Eine kleine Vorwarnung: Was nun folgt, könnte für eingefleischte Scrum-Verfechter ungemütlich werden. Nützt aber nichts, denn es gibt Realitäten. In diesem(!) Fall dieses(!) Unternehmen mit dieser(!) Sachlage.

Die Sprintplanung: Der heisse Sch…s

Betrachten ich rückblickend und exemplarisch die Sprintplanung des 14. ten Sprints. Die Wahl dieses Sprints ist willkürlich, da jede Planungsphase in diesem Projekt auf erschreckende Weise ähnlich ablief. Unsere Scrum Master präsentierten uns die Aufgabenliste, die direkt aus dem minutiös gepflegten Gantt-Diagramm unseres Projektmanagers stammte. Schon komisch: Oben Gantt und Wasserfall, unten Scrum … und das stringent.

Ursprünglich trugen wir, ich als Coach, natürlich auch etwas von der Verantwortung für die gesamte Arbeit, die zur Fertigstellung dieses Projekts erforderlich war. Das war allerdings in einer fernen Vergangenheit, als unsere naive Einschätzung der Komplexität noch ungetrübt war. Die (Innen-) Realität holte uns schnell wegen der (Aussen-) Realität ein. Die Aufgaben erwiesen sich als ungleich schwieriger als angenommen. Folglich hinkten wir im seit dem t. ten Sprint meilenweit hinterher und versuchten krampfhaft, verlorene „Zeit zurückzugewinnen“.

Schon mal darüber nachgedacht, dass Zeit eine physikalische Konstante ist und nicht, gar nicht, wieder eingeholt werden kann (zumindest nach dem jetzigen Stand der Physik.)? Was weg ist, ist weg. Punkt.

Darüber hinaus fühlte sich unsere anfängliche Einschätzung der notwendigen Schritte mittlerweile völlig überholt an. Das Feedback aus dem Vertrieb deutete auf weitere, dringende Nutzerbedürfnisse hin. Und diese waren schon 10 Wochen alt. Diese sollten jedoch geduldig auf Phase 2 des Projekts warten – falls diese überhaupt jemals das Licht der Welt erblicken würde. Währenddessen kämpften wir uns durch Phase 1 und waren uns der Tatsache schmerzlich bewusst, dass der angestrebte Mehrwert wohl eher eine Wunschvorstellung bleiben würde. Die Motivation stieg kontinuierlich – von unten gegen Null.

Unsere Handlungsfreiheit war begrenzt. Ein Plan war einmal in Stein gemeißelt, und diesen zu ändern, schien ein Ding der Unmöglichkeit, so der Projektmanager. „Der Lenkungsausschuss hätte dies niemals gebilligt.“ – zitierte er letztlich.

Ehrlich gesagt, wir konnten uns glücklich schätzen, dass wir „nur“ ein Projekt zu bearbeiten hatten. Das Reporting-Team jonglierte parallel mit vier Projekten gleichzeitig – und das je nach Dringlichkeit. Die Prioritäten wurden dort nach dem Prinzip von Eskalation (-sstufe) und dem Einfluss der jeweiligen (Projekt-)Manager (Anzahl Sterne am Revers) festgelegt. Solche direktiven „Anpassungen“ konnten auch mitten im Sprint erfolgen. Trauriger Vergleich: Ist eine Rakete abgefeuert, kommt sie auch irgendwo wieder runter … Diese Teams verdiente wirklich mein tiefstes Mitgefühl.

Das einzig Positive an den Planungssitzungen? Ihre Kürze. Wie lange braucht man, um Anweisungen für die nächsten zwei Wochen entgegenzunehmen? In der Regel kaum 45 min. (Ich verrate Ihnen was aus der Kommunikation, das geht auch in 20 min.)

Das Daily Stand-up: Eine Farce in fünf Minuten

Das Daily Stand-up war zwar das kürzeste, aber auch das ermüdendste Meeting des Tages. Fünf Minuten waren je Teilnehmer vorgesehen, in denen wir aus unserer eigentlichen Arbeit gerissen wurden, um zu verkünden, was wir am Vortag fabriziert hatten und was wir uns für den aktuellen Tag vorgenommen hatten. 2 x in Monaten wurde es geschafft, diesen Zeitslot ungefähr einzuhalten. In der Regel waren es immer um die 7-10 min. Wurde da wirklich wichtiges transportiert? Nimand ist auf die alles entscheidende Frage gekommen. Die lernen Sie meinen Coachings. Ich verspreche, aus der Farce wird ein Smile-Face – für jeden.

Und dann die obligatorische Frage nach Hindernissen. Als ob diese jemals tatsächlich beseitigt würden. Ein typisches Beispiel aus meiner persönlichen Hölle: Susanne arbeitete gewissenhaft an dem Code, der ihr in der Planung zugewiesen worden war, wurde aber ständig von Karin aus dem QA-Scrum-Team unterbrochen. Sie hatte Fehler gefunden, die Susanne umgehend beheben sollte. Das Problem? Susanne wurde rausgerissen aus ihrem Denken und musste sich um den neuen Code kümmern. Trotzdem nagte es an sichtlich an Susanne, dass ihr Code aus dem vorherigen Sprint Fehler enthielt.

Was blieb mir anderes übrig, als das Hindernis zu eskalieren? Es landete auf der berüchtigten „Hindernisspur“, wo es in aller Stille vor sich hinschimmelte, bis ich es erneut zur Sprache brachte. Sehr verhaltener Jubel. Irgendwann gab ich es auf, Hindernisse überhaupt noch zu melden. Im Grunde wiederholte jeder aus den Teams die gleiche Litanei, und nach fünf Minuten (eher 10) durften sie sich wieder ihrer eigentlichen Arbeit widmen. Allerdings kostete es weitere dreißig Minuten, bis wir sich jeder (!) wieder in seinen Workflow eingegroovt hatte.

Das Reporting-Team hingegen durfte sich jeden Tag eine ganze Stunde lang im Stand-up austauschen. Die ständigen Änderungen, Anforderungen und Eskalationen während des Sprints erforderten wohl diese ausufernde Zeiteinteilung. Ein aussichtsloses Unterfangen, wie sich herausstellte.

Die Demo: Eine schöne Zeremonie – wegen der Zeremonie

Demos. Eine weitere sinnlose Übung in unserer ohnehin schon ineffizienten Routine. Meistens hatten die Teams nicht wirklich was vorzuweisen, also wurde oft Demos kurzerhand abgesagt. Ich hatte „Hals“, manchmal bis öfter. Mitunter gelang es uns tatsächlich, funktionierenden Code zu produzieren, den wir dann stolz dem Projektmanager präsentierten. Die eigentliche Frage ist: Warum wirklich? Ihn interessierte lediglich der Fortschritt des gesamten Projektes. Er zeigte sich oft enttäuscht über die mageren, sichtbaren Ergebnisse von zwei Wochen harter Arbeit. Fazit: Die Demos waren schlichtweg wertlos. Aber der Ansatz war zu erkennen: Der Manager wollte sowas wie Wertschöpfung sehen. Sehen, nicht nur wissen.

Die Retrospektive: echtes Ventil oder endlos falsche Schleife?

Die Retrospektive war oft das unterhaltsamste Meeting, da wir hier endlich unseren Frust ablassen konnten. Die Scrum Master haben viel Zeit und Aufwand in die Vorbereitungen gesteckt, damit diese interessant blieben. Wir konnten uns in den jeweiligen Formaten alles von der Seele reden – es sei denn, der Projektmanager war anwesend. Schon komisch, wie eine ungeschriebene Dominanz (besser UM-geschriebene) samt singulärem Gestaltungsanspruch eine Tonation, einen Impact und/oder auch eine Motivation beeinflussen kann. Das mit der Anwesenheit kam glücklicherweise selten vor, meist nur, wenn er Kritik oder eine Abreibung verteilen wollte. Das Tragische an den Retrospektiven war ihre repetitive Natur. Wir diskutierten immer wieder die gleichen Probleme, ohne dass sich jemals etwas änderte. Und die eigentliche Probleme wie Mikromanagement, fehlende Selbstbestimmung etc. schimmelten weiter vor sich hin.

Crunch-Time: Wenn alle Dämme (Kunden?) weg- brechen

Jedes Projekt kennt diese kritische Phase: die Wochen oder Monate vor der Auslieferung, in denen Überstunden zur Norm werden und man sich mit den unweigerlichen Folgen instabiler Software samt erheblicher technischer Schulden und unzufriedener Nutzer auseinandersetzen muss. In diesen Wochen warf wir Scrum – notgedrungen – mehr oder weniger über Bord. Wir hatten Not und waren wendig (notwendig): Bei Arbeitszeiten von regelmäßig über 80 Stunden pro Woche hatten wir schlichtweg keine Zeit mehr für Firlefanz, Gekuschel und Rituale. Da hieß es: Genug ist genug!
Kaum war die Situation wieder halbwegs eingefangen, hiess es: Zurück zu Scrum. Hat mir das gefallen? Weniger.

Schon mal darüber nachgedacht, dass man (Prozess-) Götzen huldigt und die Belegschaft ’sauer‘ fährt? Ein NoGO im Ressourcenmanagement.

Der Ausruf: „Schluss mit diesem Scrum-Projektmanagement!“

Die Situation spitze sich weiter zu und wurde un-(er)-tragbar. Wir, Ich, mussten handeln. Radikale Veränderungen waren notwendig, und die Abkehr von Scrum als unserem Projektmanagement-Ansatz, die sich als moderne Prozess-Knechtschaft herausgestellt hatte, war die einzig logische Konsequenz. Rückwirkend betrachtet war es die beste Entscheidung, die die Teams mit meiner Hilfe je getroffen haben. 3 entscheidende Fragen haben eine radikale Erkenntnis gebracht – und auch Überlegungen, noch weiter mit SAFe, NEXUS oder SoS zu skalieren, also noch mehr vom „Korsett“, hatten sich mit einem Knall aufgelöst. Jedoch: Die Gedanken waren a) da und ausgesprochen, b) klebten auf dem Tisch und c) gemeiner Trick: Nicht mehr zu löschen oder zu tilgen. Hier sind die Gründe dafür:

Der Griff zur roten Pille: Ein Paradigmenwechsel

Wir wussten, dass wir uns ändern mussten, um zu überleben. Das Wachstum unseres Unternehmens war zum Erliegen gekommen. Wir steckten in einer tiefen Krise. Also begannen wir, unsere Rahmenbedingungen zu analysieren, um den besten Weg nach vorn zu finden. Ich reden von den Rahmenbedingungen des Unternehmens, nicht die von Scrum oder irgendwelchen Blaupausen.

Unsere Produktumgebung: Unvorhersehbar und komplex

Wir erkannten, dass unsere Produktumgebung alles andere als vorhersehbar war. Detaillierte Pläne für Monate im Voraus zu erstellen, erwies sich als illusorisch, da sich die Rahmenbedingungen ständig änderten. Neue Erkenntnisse zur Problemlösung, Learnings aus bereits entwickelter Software, Marktentwicklungen – unsere Produktumgebung war schlichtweg komplex. Also musste alles reduziert und kleiner, modularer werden.

Kleine Schritte: Iteration als Schlüssel zum Erfolg

Nachdem wir die Komplexität unserer Produktumgebung verstanden hatten, beschlossen wir, nur noch in kleinen Schritten vorzugehen, die Ergebnisse zu bewerten und dann das weitere Vorgehen festzulegen. Wir entschieden uns für einen iterativen Ansatz. Die Iterationslänge variierte zwischen einem Tag und einem Monat, je nachdem, was das Team für optimal hielt. Und darüber wurde nicht gepokert, sondern machmal einfach und pragmatisch entscheiden.

Vom Projekt zum Produkt: Eine neue Denkweise

Wir verabschiedeten uns von der Vorstellung von Projekten mit fest definiertem Umfang, Budget und Zeitrahmen. Stattdessen verschrieben wir uns einer Produktvision und näherten uns deren Umsetzung iterativ. Hört sich das schon wieder wie Scrum an? Nur wenig, weil wir eins eingebaut haben: Schriftliches Committment. Dies machte bestimmte Rollen und Meetings wie den Projektmanager und den Lenkungsausschuss überflüssig. Für die betroffenen Personen fanden wir oft andere Aufgaben, die sich jedoch an die neue Arbeitsweise und den damit verbundenen Kulturwandel anpassen mussten. Anders gesagt: Wir beerdigten das Micromanagement.

Alle Fähigkeiten in einem Team: Autonomie und Verantwortung

Wir entschieden, dass wir alle notwendigen Kompetenzen zur Entwicklung eines funktionierenden Produkts in einem Team vereinen mussten. Ein Team, ein Thema. Ein anderes Team: Ein anderes Thema. Separate Business-Analyse-, Entwicklungs- und QA-Teams gehörten der Vergangenheit an. Die benötigten Fähigkeiten sollten nun je nach Bedarf der Produktiteration in einem Team vorhanden sein. Warum soll ein Entwickler nicht auch mal Tester sein? Natürlich nur anderen Code, nicht seinen eigenen.

Eine klare Priorisierung: Der Product Owner, der das Product besitzt

Unser Team hatte das Glück, einen Projektmanager gehabt zu haben, während andere Teams diese Unterstützung vermissten. Wir entwickelten die Idee weiter, dass eine einzelne Person für die Priorisierung des Produkt-Backlogs verantwortlich sein sollte. Achtung: Klare Abgrenzung: Nur das Team kann wissen und abschätzen, was gebraucht wird. Das Team ist für das Product-Backlog verantwortlich. Der Produkt-Besitzer ist verantwortlich, wann was gemacht wird. Dies half den Teams, die Orientierung zu behalten und sich wieder auf das Wesentliche zu konzentrieren: Entwickeln. Und bei der Gelegenheit standen auch die fetten Projektmanagement-Tools, also die üblichen Verdächtigen, auf dem Prüfstand. Muss es der „Bentley“ sein oder reicht auch robuster „Jeep“?

Ziele für jede Iteration: Fokus und Zusammenarbeit

Wir legten fest, dass jede kleine (!) Iteration ein klares Ziel haben sollte und dass die dem Iterationsplan hinzugefügten Stories so ausgewählt werden sollten, dass sie zur Erreichung dieses Ziels samt Unterziele beitragen. Ein Ziel half dem Team, sich auf die anstehenden Aufgaben zu konzentrieren und förderte die Zusammenarbeit. Ein Beispiel für ein Ziel könnte sein: „Entwicklung der ersten vollständigen End-to-End-Funktionalität, um daraus zu lernen und unseren Stakeholdern deren Umfang sowie nutzvolle Ableitungen zu demonstrieren.“ Und an dieser Stelle habe wir gleich noch die Verbindlichkeit mit doppeltem Boden eingebaut. Natürlich kann ein Kollege mal ausfallen. Dann schaffen 2 andere Kollegen die Arbeit. Und niemals einen Kollegen mit über 85% auslasten. Grüße vom Ressourcenmanagement.

Selbstbestimmung der Teams: Verantwortung für Umfang und Vorgehen

Wir beendeten die Situation, in der andere dem Team vorschrieben, wie viel Arbeit es zu erledigen hatte. Wir haben massiv entflochen. Wir erkannten, dass die Teammitglieder selbst am besten einschätzen können, welche Arbeitslast sie bewältigen können. Als Experten konnten sie am besten vorhersagen, was realistisch erreichbar ist. Darüber hinaus stellten wir fest, dass Teams ihren eigenen Weg finden können, um das Iterationsziel zu erreichen. Niemand sollte ihnen mehr vorschreiben, wie sie ihre Arbeit zu erledigen haben.

Tägliche Diskussion über das Ziel: Das neue Stand-up

Unsere Stand-ups veränderten sich grundlegend. Zunächst einmal konnten die Teams selbst entscheiden, ob sie an den Stand-ups teilnehmen wollten oder nicht. Noch wichtiger war jedoch, dass sich die Stand-ups auf den Fortschritt in Richtung des Iterationsziels konzentrierten und somit zu einer echten Teamaufgabe wurden. Da sich alle diesem Ziel verpflichtet fühlten, waren die Stories plötzlich nicht mehr in Stein gemeißelt. Neue Erkenntnisse konnten zu Änderungen im Backlog führen, überflüssige Stories entfernen und neue hinzufügen, die zur Zielerreichung beitrugen. Und eine neue Frage, die in die Runden gestellt wird, hatte deutliche Auswirkungen.

Demos mit Mehrwert: Strategische Diskussionen statt reiner Präsentation

Auch die Demos entwickelten sich weiter. Sie wurden zu interaktiven Sitzungen, in denen wir zeigten, was wir entwickelt hatten, aber auch das Ziel der Iteration und unsere Maßnahmen zur Zielerreichung diskutierten. Wir begannen auch, mit den Stakeholdern über die nächsten Schritte zu sprechen, da diese nicht mehr vorab festgelegt waren. Die Demo wurde zu einem Meeting, in dem strategische Diskussionen stattfanden. Neue Erkenntnisse konnten jederzeit zu einer Umstrukturierung des Backlogs führen und somit die nächste Iteration beeinflussen.

Retrospektiven als Motor für Verbesserungen: Vom Jammern zum Handeln

Unsere Retrospektiven entwickelten sich ebenfalls. Wir nutzten sie nicht mehr nur zum Frustabbau. Der Begriff „Jammer-Meeting“ verschwand samt Inhalt des Jammerns. Stattdessen diskutierten wir, wie wir die Zusammenarbeit im Team verbessern können. Dabei wurden alle möglichen Aspekte berücksichtigt: von der Teaminteraktion über die Unternehmenskultur, die das Team beeinflusst, bis hin zu Programmierstandards auf Teamebene und Unternehmensrichtlinien. Alles, was zur Verbesserung des Teams beitragen konnte, wurde besprochen, und die dringendsten Themen wurden jetzt auch vom Team selbst angegangen. Selbstverantwortung und Selbssteuerung in Reinkultur samt Ermächtigung.

Wichtige Erkenntnisse: Der Weg zum Erfolg

Indem wir unsere alte Arbeitsweise hinter uns ließen und einen deutlich iterativeren Ansatz verfolgten, konnten wir den Stillstand überwinden. Wir konnten mehr Funktionen bereitstellen als zuvor, die für unsere Stakeholder einen weitaus größeren Wert darstellten als alles, was wir zuvor geliefert hatten. Geht doch mit der Wertschöpfung! Wir haben die Kunst gemeistert, gefühlt mehr echte Arbeit in der Hälfte der Zeit zu erledigen – und das mit deutlich zufriedeneren Nutzern, Teams und Management. Wir waren wieder im Spiel! Diese Umstellungen haben ca. 3 Monate gedauert, aber auch nur, weil alle Beteiligten die Notwendigkeit erkannt haben.

Der beste Versuch ever: Analysieren Sie Ihre Produktumgebung und prüfen Sie unvoreingenommen, ob eine Anpassung Ihres Ansatzes – ergebnisoffen – zur Produktbereitstellung sinnvoll ist. Ich garantiere Die Ergebnisse werden Sie überzeugen und ggfls. begeistern!

Abschließende Bemerkung: Die Krux mit der Definition

Ich gebe zu: Unsere ursprüngliche Arbeitsweise nannten wir „Scrum“. Wir dachten, wir hätten den passenden Geschäftsprozess dafür implementiert. Aber unser aller Verständnis von Scrum ‚as it is“ war schlichtweg falsch. Deshalb wechselten wir zu einer anderen, individuellen Arbeitsweise, die dem eigentlichen Geist von Scrum viel näherkam. Scrum kann funktionieren. Und wenn nur Elemente davon genommen werden und besser funktionieren: Was ist besser? Wir haben sie dann am Ende anders genannt. Nicht Scrumbug.