Annahme: “Backlog? Brauchen wir nicht — das können wir uns merken”

Wer versucht gesprochene Sprache zu transkribieren wird feststellen, dass die kognitiven Fähigkeiten von Menschen erstaunlich sind. Grammatik-befreites Kauderwelsch in sinnhafte Aussagen zu transformieren, stellt vermutlich eine der größten Leistungen des menschlichen Gehirns dar.
Nichtsdestotrotz können sich die wenigsten Menschen auf Anhieb einen Backlog mit 200 Items samt allen Akzeptanzkriterien, Querverweisen, Fristen, Projektzusammenhängen, Business-Bedürfnissen, Prioritäten und Anforderungen merken. Dies war auch hier der Fall, deshalb gab es eine Gedächtnishilfe: Eine Textdatei mit Stichpunkten.

Wenn ein Task abgeschlossen war, musste erstmal besprochen werden, was als nächstes zu tun ist. Daraufhin hat das Team zusammen in die Textdatei geschaut und basierend auf empfundener Dringlichkeit entschieden, welche Aufgabe das Mitglied als nächstes erledigen soll.

Häufig entstanden dabei Diskussionen darüber, was als nützlicher oder dringlicher empfunden wurde, zusätzlich entstanden Unstimmigkeiten darüber, was die einzelnen Stichpunkte eigentlich bedeuten. Zu allem Überfluss wurden diese Gespräche mehrfach geführt, da man sich jedes mal aufs neue zusammenreimen musste, was ein Stichpunkt denn nun bedeutet. Wie man sich sicherlich vorstellen kann, werden Gespräche dieser Art nicht immer mit der notwendigen Sachlichkeit geführt.

Bei einer dieser Situationen habe ich meine Kollegen darauf aufmerksam gemacht, dass aufreibende Gespräche dieser Art mit einem sauberen Backlog vermieden werden. Man spart sich die Zeit zur Rekonstruktion der Items, hat alle Informationen an einer Stelle vereint, begeht weniger Fehler durch falsche Interpretationen und hat eine klar vorgegebene Priorisierung für die nächsten Aufgaben.

Das Team ist meinem Vorschlag gefolgt. Ich habe die Stichpunktliste in Tickets überführt und in Zusammenarbeit mit dem Team haben wir gemeinsam Akzeptanzkriterien, Fristen, Business Value und Abhängigkeiten definiert. Dabei priorisierte ich die Items im Backlog nach Business Value. Womit wir auch schon beim nächsten Problem wären.

Annahme: Der Product Owner weiß nicht, worum es geht

Bei einer nach Innen gerichteten Sichtweise drängt sich diese Annahme zwangsläufig auf. Da kommt eine Person, die keine fachlichen Kompetenzen aufweist und fängt an zu entscheiden, welche Aufgaben wichtiger als andere sind.

Wieso sollte ein Außenstehender, der kein technisches Verständnis von der Thematik besitzt, besser einschätzen können, was als nächstes zu tun ist? Und auf welcher Grundlage trifft er seine Entscheidungen?

Die Priorisierung der Items erfolgt anhand von Business Value und dem dazugehörigen Aufwand für die Implementierung. Als Product Owner liegt mir der Business Value der einzelnen Items aus den Abteilungen vor. Diese Informationen laufen bei mir zusammen und es ist meine Aufgabe, diese Informationen zu besorgen. Was mir für eine angemessene Priorisierung fehlt, sind die Aufwände für die Implementierung. Diese Information kann mir das Team liefern. Daher ist der Product Owner die einzige Person, die alle notwendigen Informationen besitzt um über eine angemessene Priorisierung zu entscheiden.

Als Außenstehender unterliege ich einer gewissen Emotionslosigkeit im Bezug auf den Backlog, was es mir leichter macht rationale Entscheidungen zu treffen. Versteht mich nicht falsch: Jedes Teammitglied tut zu jedem Zeitpunkt immer das, was es für richtig hält und gibt immer 100 Prozent, aber die Handlungsabsichten von Individuen sind nicht immer transparent.

So kommt es natürlich vor, dass spannende Tickets zuerst bearbeitet werden. Natürlich ist es super, dass wir interessant finden, was wir tun — Faszination ist unsere wichtigste Motivationsquelle. Trotzdem gehört es genauso zu unserem Brotverdienst, ungeliebte Tasks hinter uns zu bringen. Da ich die Arbeiten selber nicht durchführen muss, bin ich von diesen Emotionen befreit und kann mich auf den Business Value konzentrieren.

Der Product Owner ist auch nur ein Mensch mit dem man reden kann und sollte. Unstimmigkeiten in der Priorisierung können im Gespräch geklärt werden. Gleichzeitig schärft sich beim Product Owner im Gespräch mit den Entwicklern das Verständnis für die Thematik. Die Entwickler verstehen ihrerseits die Ziele der Stakeholder dadurch besser. Das heißt: Je häufiger man das Gespräch sucht, desto klarer versteht das Team die Bedürfnisse der Stakeholder und der Product Owner arbeitet sich dabei in die Thematik ein.

Zu guter letzt vertritt der Product Owner die Interessen des Produkts. In unserem Fall ist das Team selber auch ein Stakeholder und bringt Vorschläge zur Weiterentwicklung ein, aber sie sind eben nur einer der Stakeholder und repräsentieren nur eine der Perspektiven. Durch Gespräche mit verschiedenen Stakeholdern — und da ist das Team natürlich eingeschlossen — bekam ich das notwendige Know-How um den Business Value angemessen beurteilen zu können.

Annahme: Wir brauchen keine Fokussierung

Es kann schnell sehr eintönig werden über mehrere Wochen hinweg an einem Thema zu arbeiten. Ungeliebte Aufgaben erzürnen mich persönlich bereits nach wenigen Stunden. Menschen begegnen dem Problem häufig mit Ablenkung: Was gibt es denn sonst noch zu tun? Leider bringt der ständige Wechsel der Fokussierung einige unschöne Effekte mit sich.

Bei uns schlug sich der Fokuswechsel im Bereich der internen Testabdeckung nieder. Es gab für das Aufsetzen unserer CI-Cluster Tests, aber die Testabdeckung war bei weitem nicht so flächendeckend, wie wir es gerne hätten.

Da an dem Thema nicht kontinuierlich gearbeitet wurde, waren einige Komponenten getestet, andere nur zum Teil und wieder andere gar nicht. Eine denkbar unschöne Ausgangslage, da man sich eigentlich niemals sicher sein konnte, ob man beim Update einer Komponenten nicht versehentlich das ganze Cluster zerstört.

Abgesehen von den inhaltlichen Nachteilen fehlender Testabdeckung, gibt es auch noch eine psychologische Komponente: man schließt niemals etwas vollständig ab. Es bleibt das Gefühl von Unvollständigkeit, das auf Dauer ermüdend ist.

Das Team hat diesen Umstand eingesehen. Ich beschloss eine Wunschliste zu erheben. Die Items der Liste wurden geclustert. Wir konnten uns zusammen auf ein Thema einigen, das aus interner Sicht den höchsten Business Value liefert und auch einen beachtlichen Mehrwert für die Arbeit der anderen Teams liefert. Natürlich müssen wir noch weiterhin Zuarbeiten leisten und den Geschäftsbetrieb aufrecht erhalten, aber wenn wir Zeit haben, fokussieren wir uns auf unser gemeinsames Ziel.

Annahme: Wir brauchen nicht für jede Aufgabe ein Ticket

Manchmal sieht man ein kleines Problem, das man gerne schnell beheben würde und ist sich sicher, dieses schnell beheben zu können. Wozu sollte man ein Ticket für eine Sache schreiben, bei der die Erstellung des Tickets länger dauert als die eigentliche Behebung? Es ist doch nur eine kleine Änderung…
Die Haltung ist nachvollziehbar, aber sie wirft drei Probleme auf.

Erstens: Was ist ein kleines Problem? Wann wird ein „kleines“ Problem zu einem, das ein Ticket benötigt? Und was ist eigentlich eine „kleine Änderung“?
Diese Fragen lassen sich nicht mit Hilfe von messbaren Größen beantworten. Folglich würde es im Ermessen eines einzelnen Teammitglieds liegen zu entscheiden, ob ein Problem behoben werden soll oder nicht. Jedoch obliegt diese Entscheidungshoheit nicht den Teammitgliedern, sondern einzig und allein dem Product Owner.

Zweitens: Wenn ich ohne Ticket Änderungen durchführe, wie wird der Rest des Teams und der Product Owner darüber informiert, dass ich diese Änderungen durchgeführt habe? Natürlich kann man hoffen, dass die Person sich am nächsten Tag noch an all die kleinen Änderungen erinnert und es beim Daily wiedergibt. Allerdings erachte ich Hoffnung nicht als adäquates Mittel für die Steuerung von Projekten.

Drittens: Selbst die Aufwendung von 15 Minuten für ein unbedeutendes Problem fehlen an anderer Stelle. Wieso sollte man also an einem kleinen, unbedeutenden Problem arbeiten, wenn im Backlog noch viele Items mit höherem Business Value sind? Wir sind dabei verblieben, dass jede Tätigkeit ein Ticket benötigt. Dies hat die Transparenz innerhalb des Teams merklich gesteigert.

Annahme: Unsere Arbeit ist nicht planbar

Wie bereits eingangs erwähnt, lässt sich die Arbeit des Teams in planbare Arbeiten und spontan entstehende Arbeiten unterteilen. Falls es einen Ausfall an einem bestehenden System gibt, muss das Team reagieren — ja, dieser Teil der Arbeit ist nicht planbar.

Aber der andere und weitaus größere Teil der Arbeit lässt sich sehr wohl planen: Welche Weiterentwicklungen wollen wir an unseren Tools vornehmen? Welche Teams brauchen bald eine CI-Pipeline oder ein Deployment? Welche Updates müssen wir bald durchführen? In welchen Projektphasen befinden sich die anderen Teams und wo wird unsere Unterstützung notwendig sein? Welche Infrastruktur wollen wir als nächstes erneuern? Dieser Teil unserer Arbeit ist vorhersehbar und kann in Sprints eingetaktet werden.

Den Vorwurf der Unplanbarkeit bekam ich nicht nur vom eigenen Team, sondern auch von anderen Teams: “Was passiert denn, wenn wir sofort etwas brauchen — müssen wir dann einen ganzen Sprint abwarten bis ihr uns helft?” oder “Wir können unseren Kunden Antwortzeiten von einer Woche nicht vermitteln!” bekam ich recht häufig zu hören.

Viele Leute fühlten sich des Rechts beraubt, in unseren Raum zu stürmen und uns Kommandos zu erteilen. Mithilfe von einigen einfachen Gesprächen konnten die Wogen geglättet werden: Natürlich lassen wir niemanden im Stich und wenn’s gerade brennt, werden wir das Feuer löschen — aber nicht jedes umgefallene Teelicht erfordert, dass die Feuerwehr ausrückt.

So führten wir einwöchige Sprints ein. Das Team hat nach einigen Sprints akzeptiert, dass ein gewisser Aspekt ihrer Arbeit — oder wie ich gerne sage: die weitaus größere Hälfte — sehr wohl planbar ist.

Die Aufregung der Teams, denen wir zuarbeiten, legte sich schnell. Sie erkannten, dass wir dinglichen Anfragen weiterhin zügig nachgehen.
Gleichzeitig hat unser Anspruch auf Planbarkeit auch in den anderen Teams zu einer besseren Organisation geführt. Andere POs haben sich häufiger gefragt, ob die Arbeit sofort erledigt werden muss oder ob es zum nächsten Sprint ausreicht. So hat unsere Prozesstreue auch zu einer Disziplinierung in anderen Teams geführt und sich somit unternehmensweit positiv ausgewirkt.

Lirum larum, Summa summarum

Das Team sieht den Backlog als wichtiges Hilfsmittel an und zeigt reges Interesse an der Ticket-Qualität und an der Priorisierung des Backlogs. Sie versuchen häufig Akzeptanzkriterien zu erweitern oder informieren mich, falls ich etwas übersehen haben sollte. Tickets, die unklar formuliert sind, werden von ihnen bemängelt oder abgelehnt. Dies gilt auch für Tickets aus anderen Teams, was wiederum die Ticket-Qualität in den anderen Teams verbessert.

Die Fokussierung auf ein Thema hat den Zusammenhalt gestärkt, da wir das Gefühl haben, an einem gemeinsamen Ziel zu arbeiten. Der stetige Fortschritt an unserem aktuellen Projekt macht ihre geleistete Arbeit sichtbar und sorgt für gute Stimmung. Voller Vorfreude waren wir darauf, das Feature auszurollen.
Supportanfragen von anderen Teams werden zurückgewiesen, wenn kein Ticket dafür angelegt wurde. Wir ermahnen uns regelmäßig, falls jemand versucht ohne Ticket zu arbeiten und sogar die größten Sturköpfe haben eingesehen, dass sich eine gewisse Befriedigung im Brustkorb breit macht, wenn man nach zwei Tagen fokussierter Arbeit ein Ticket in die Done-Spalte verschieben kann. Jedes Mitglied hat verinnerlicht, dass Tickets zur Transparenz innerhalb des Teams führen und den Wissensaustausch vorantreiben.

Ich habe kurz nach dem Antritt meiner Tätigkeit eine anonyme Umfrage im Team durchgeführt um die Situation festzuhalten. Diese Umfrage habe ich 3 Monate später wiederholt.

Das Ergebnis war eindeutig: Das Team hat das Gefühl, dass die Arbeit besser planbar geworden ist. Ob das einzig und allein an den durch mich herbeigeführten Änderungen liegt, lässt sich zwar nicht eindeutig klären, aber es liegt nahe, dass sie zumindest zur Verbesserung der Situation beigetragen haben.

Das Team hat sich mit dem Prozess vertraut gemacht und ihn angenommen. Mittlerweile schlagen sie eigenständig Änderungen am Prozess vor und versuchen dadurch ihre Arbeit angenehmer zu gestalten. Dies kann man definitiv als gutes Signal interpretieren. Das Team Arbeitet seit vier Monaten in Sprints. Alles in allem kann man sagen, dass das Team, obwohl es viele Vorurteile hatte, mit dem Prozess und den Tools sehr zufrieden ist.

Epilog

Ob Scrum als Vorgehensmodell die richtige Entscheidung war, kann man gewiss anzweifeln. Allerdings bietet Scrum genug Freiraum um auch unter schwierigen Umständen zu funktionieren. Vermutlich wären mit anderen agilen Ansätzen ähnliche Erfolge erzielt worden. Die meisten Annahmen richteten sich nicht gegen Scrum, sondern gegen jede Form von Management. Die Quintessenz bleibt jedoch die gleiche:

Ja, man kann unplanbar erscheinende Aufgaben zu einem gewissen Teil planbar machen. Wenig Planung ist schließlich besser als keine Planung. Ja, man kann mit sehr wenig Ordnung und ein bisschen Disziplin viel Transparenz herstellen, wovon alle Beteiligten profitieren.