Einige Menschen in der Welt der Scrum Master / Teamcoaches / Wegbegleiter:innen / Berater:innen (etc. pp.) empfehlen, zur besseren Strukturierung der eigenen Arbeit ein berufliches Tagebuch zu führen, um einen Überblick darüber herzustellen, welche Ansätze mit welchem Ergebnis verfolgt wurden, und um seine Arbeit auf gewisse Ziele auszurichten. Ich mache das hier einmal mit einer - natürlich subversiven und subjektiven - Auswahl von Themen, die mir in meinem Berufsleben als Scrum Master / Teamcoach begegneten und die sich anders entwickelten, als ich dachte.
Ein planloses Planning
In einem Konzern war ich einem Querschnittsteam zugeordnet worden: bestehend aus mehreren Teil-Teams, die nur wenig Berührungspunkte miteinander haben, ergo nicht crossfunktional aufgestellt sind. In jedem Bereich gibt es stattdessen mindestens einen Silberrücken (m/w/d), der ganz allein das umfassende Wissen und die jahrzehntelange Erfahrung besitzt - aber eben nur für seinen Teilbereich. In der Planung der Arbeit können immer nur wenige ihre Spezialthemen einschätzen, die anderen gucken und hören vorwiegend zu. Es mangelt an einem greifbaren gemeinsamen Ziel, und bis auf wenige Ausnahmen, nämlich interne Tools, wird auch kein "Produkt" hergestellt, das einem ein Kunde begeistert aus der Hand reißen möchte. Natürlich gibt es, wie auch in anderen Teams und sogar (vielen?) anderen Unternehmen, immer zu wenig qualifizierte Leute, weswegen Nasen von außen eingekauft werden, die dann aber immer nur auf Zeit bleiben (und im schlimmsten Fall, wenn man als Konzern gepennt hat, das ganze angehäufte Wissen wieder mitnehmen).
Planning ohne jegliche Auswirkungen
Der gravierendste Stein des Anstoßes war für mich kurz nach meiner Ankunft das "Planning" des Teams. Aufgaben wurden in einem ungeeigneten Tool dargestellt, in dem sie nicht ordentlich gepflegt und auf dem aktuellen Stand gehalten werden konnten, zudem fehlte es an Dokumentation, was für die jeweiligen Aufgaben bereits getan wurde und was noch ausstand - von einem Arbeitsüberblick, der dem PO sehr geholfen hätte, ganz zu schweigen. Es handelte sich also eigentlich um gar keine "Planung" der Aufgaben. Wurden diese nicht fertiggestellt, schob man sie zudem ohne weitere Analyse einfach in den nächsten Entwicklungszeitraum weiter, und offenbar niemand störte sich daran. Viele Aufgaben waren angefangen, konnten aber nicht fertiggestellt werden, weil ein Signal von außen fehlte oder weil der Bereich (bzw. dessen CPOs - ja, Chief Product Owner, die dann das letzte Wort haben sollen, wenn sich die POs im Bereich nicht einigen können) zwischenzeitlich andere Themen höher priorisiert hatte.
Ein Teufelskreis durch intransparente Priorisierung
In einer Retrospektive hatten sich zudem einzelne Teammitlieder darüber geäußert, dass sie die Priorisierung der vielen Themen, die leider nicht selten von außen hereinspülten, intransparent fänden. Dieser Effekt verstärkte ihren eigenen Beitrag zu der Herausforderung auch noch: Aufgrund einer zumindest in ihrer Vorstellung fehlenden oder mangelhaften Priorisierung suchten sie sich nämlich auch häufig inoffiziell, d. h. nicht offiziell im Team abgesprochen und eingeplant, diejenigen Themen aus, die ihnen Spaß machten, was wiederum zu einer noch schlechteren und intransparenteren Priorisierung führte.
Was tun im Dickicht? Vom Aushändigen einer Machete
Da ich selbst noch keinen Plan von den zahlreichen Epics hatte, die allein für dieses Team kursierten (und die, wie mir
schien, nach unterschiedlichen Kriterien erstellt wurden), holte ich mir Rat von einer erfahrenen Person, die mir
sagen könnte, welche Schritte ich am besten als nächstes angehen sollte (danke, Jan, noch mal ;-)). Ich hatte die Aufgaben "Priorisierungsregeln bzw. Priorisierungsmix finden" (anteilig Aufräumen, Bugfixing, Entwicklung etc.), "mehr als 50% Verbesserung für die internen Tätigkeiten" (was auch immer das sei bzw. welche Kennzahl man dafür verwenden will), sowie "Lieferung der Ergebnisse schneller und hochwertiger" auf meinem neuen Zettel.
Priorisierungsmix finden
Nach meiner Einschätzung gab es im Team wenig Rework, es war ja auch kein Entwicklungs-, sondern ein Querschnittsteam, das infrastrukturelle Dinge für eine Reihe von technisch aneinandergeketteten Teams zur Verfügung stellte. Aufgrund von Ressourcenengpässen kam es aber auch bei uns z. B. zu längeren Wegen für Fertigstellungen, weil Reviews ausstanden, die die überlasteten Kolleg:innen aber gerade nicht durchführen konnten. Der kleine Anteil an Programmierung fand in enger Abstimmung und in pair programming statt, hier wurden Reviews meist implizit im 4-Augen-Prinzip schon durchgeführt. Idee war nun, den Priorisierungsmix mit dem PO abzustimmen und auch abzustimmen, wie das Thema ins Team zu tragen sei (Erwartungshaltung, Umgang mit Deltas etc.).
Guckt da nachher überhaupt noch einer rein?
Das Team hatte mir auf eine meiner ersten Fragen, wer denn außerhalb des "Plannings" auf die Ergebnisse des Termins sehe, ganz offen geantwortet, dass die "Aufgabenzettel", die von Zeitraum zu Zeitraum weitergeschoben wurden, "keine Bedeutung" hätten. Immerhin schien die psychologische Sicherheit im Team gut zu sein, und ich freute mich, dass man so offen zu mir war. Mit solchen Angaben kann man schließlich direkt weiterarbeiten. Interessanterweise hatte das Team sogar bereits vor meiner Einstellung schon vereinbart, wieder auf ein bekanntes Tool umzusteigen, mit dem wohl früher schon einmal gearbeitet wurde, aber offenbar konnte/wollte sich dann zwischenzeitlich niemand aus dem Team mehr daran erinnern.
Standardtätigkeiten statt Priorisierungsmix
Einen Priorisierungsmix gab es sehr lange nicht, dafür hatte das Team schon recht bald seine Standardtätigkeiten für die Berücksichtigung in den Plannings geschätzt, ein Impuls aus dem Team. Es zeigte sich häufig, dass nach Berechnung der Kapazität in den einzelnen Teil-Teams für den kommenden Entwicklungszeitraum nur äußerst wenige Tage oder auch mal gar keine für ein Teil-Team übrigblieben. Also null Puffer oder sogar Negativzeit. Das war eine klare Aussage, die uns auf andere Art genauso wichtig war wie ein Priorisierungsmix.
Das höhere Ziel bewusst machen
Im gleichen Team erhielt die Umgestaltung des Plannings eine gewisse Eigendynamik, an die ich im Traum nicht gedacht hätte. Es war wie ein Erdrutsch: Durch die Bewegung der ersten Schichten kamen weitere Schichten in Bewegung. Seitens PO kam die Idee, die Themen aus dem "Programm-Inkrement" des Bereiches, ein Zeitraum von drei Monaten, ins Planning hineinzunehmen, um die Fokussierung des Teams auf die anstehenden Ziele für das Quartal zu verbessern. Zudem konnten wir dadurch noch deutlicher sehen, an wieviele Themen auch auf höherer Ebene gleichzeitig gearbeitet wurde - und teilweise aus externen Gegebenheiten heraus gearbeitet werden musste. Abgesehen davon, dass das Team immer wieder durch hineingrätschende 3rd-Level-Support-Themen (ja, das auch noch!) von seinen Zielen abgelenkt wurde, konnten wir durch die Maßnahmen bereits besser sehen, wer an welchen Aufgaben saß, welchen Status diese hatten, und ob sie auf unserem Kanban-Board schon länger offen waren. Durch die höhere Transparenz der Aufgaben jedes Teammitglieds konnte auch gegenseitige Unterstützung gezielter angeboten werden ("ich mache Dir ein Review, ich empfehle Dir das, ich konnte dank Deines Tests dies umsetzen").
Umstrukturierung nach Kaizen
Insgesamt war meine Erwartung gewesen, dass das Planning entweder nach den ersten Maßnahmen insgesamt viel schneller umgestellt werden kann oder aber überhaupt nicht, weil man an liebgewordenen Gewohnheiten festklammert und sich nicht reinreden lassen möchte. Letzteres war zum Glück nicht der Fall, aber die Veränderungen zogen sich über eine ganze Reihe von Monaten hin, da immer wieder Zeit für Absprachen zur Umsetzung von Maßnahmen fehlte oder nur ich als Teamcoach eine gewisse Dringlichkeit bei bestimmten Themen sah. (Immerin entspannt es, wenn man sein Angebot gemacht hat, die andere Seite das Ansinnen auch versteht, aber aktuell nicht darauf anspringt.) Die Verbindung zu einer später eingeführten EPIC-Ownership hatte ich zunächst gar nicht gesehen, diese dürfte jedoch die Lage stets verbessern, da sie eine bessere Verteilung der Aufgaben bewirkt und außerdem dem PO dezidierte Ansprechpartner zur Verfügung stellt, die ihre Teil-Themen vorantreiben müssen und auch für deren Darstellung nach außen sowie deren Aufbereitung für das Planning und etwaige Refinements verantwortlich sind.
Ins Rollen kommende Steine
Was ich auch nicht erwartet hätte, war, dass der PO des Teams in puncto Verbesserungsideen für das Planning nach und nach "aufblühte" und immer mehr neue Ansätze entwickelte. Vielleicht wurde das Planning auch dadurch zu einem "Fokusthema", dass ich selbst immer mal wieder Impulse zu dem Thema gesetzt, eigene Vorschläge eingebracht und dem PO den Rücken zu stärken versucht hatte. Auch hier zeigt sich: Nicht immer gleich besitzergreifend das Steuer an sich reißen, sondern hier und da ein bisschen ankurbeln und gucken, was aus dem Team-Wald herausschallt.
Moving Motivators
In einem Team, ebenfalls bestehend aus Teilteams, kam ich einmal auf die grandiose Idee, die Retrospektive nach dem Format "Moving Motivators" durchzuführen. Ich wollte das schon immer einmal gemacht haben, investierte auch Zeit in eine gute Vorbereitung und hoffte, dass sich die Teammitglieder untereinander besser kennenlernen könnten. Weit gefehlt: Während die Beschreibungen im Internet von tollen Diskussionen zwischen den Mitgliedern faselten, die sich im Team angeblich entspinnen sollten, war es bei meinem Team völlig anders: Alle machten mit, brachten brav ihre Motivatoren in eine Reihenfolge, guckten dann, was die anderen für eine Reihenfolge gelegt hatten, nickten zufrieden, lächelten teils ein wenig, wenn sie das Ergebnis ihrer drekten Teilteam-Kolleg:innen sahen, und sagten nur: "Ja - passt."
"Goldene Wasserhähne programmieren" als Teamcoach
Vielleicht hätte ich mir vorher überlegen sollen, dass sich die Leute innerhalb ihrer kleinen Teil-Teams so gut kennen, dass die Moving Motivators keine Überraschung darstellen. Außerhalb der kleinen Teil-Teams gab es dagegen offenbar so wenig Berührungspunkte, dass man die Reihungen der anderen einfach hinnahm, bestenfalls mit einem interessierten "Aha, so, so!" Daran änderten auch Fragen nichts, die ich in den Raum stellte, um noch einen Austausch in Gang zu bringen (wie sich das schon anhört, man sieht es förmlich vor sich: Der Teamcoach hat sich etwas in den Kopf gesetzt und versucht z. B., eine tonnenschwere Maschine unter Schweißausbrüchen anzuschieben, bewegt sie aber eigentlich keinen Millimeter vom Fleck). Vielleicht waren es die falschen Fragen... Immerhin, so bemerkte eine Gästin fidel, wären ja keine Motivationsdurchhänger sichtbar - was dem ratlosen Teamcoach dann auch noch die Grundlage für Verbesserungsmaßnahmen aus dieser Retrospektive entzog. Vor dem Team bekannte ich offen, dass die Aktion ganz anders geplant war, und dass das wohl nix gewesen sei. Macht auch mal nix.
Marie Kondo kehrt JIRA
In nicht nur einem Team hatte ich die undankbare Aufgabe, die ich auch noch selbst angeboten hatte, dass ich mich um ewig offene Tickets (Stories, Fehler, Anforderungen usf.) kümmern würde. Zuhause mag ich es auch nicht, wenn zu viel herumsteht und den Weg auf die wichtigen Dinge versperrt, wenn überall Zeug herumliegt. In Wohnungen oder Häusern mancher Leute sind alle Wände vollgehängt und steht auf jeder Fensterbank irgendein Geraffel, sodass man nicht einmal mehr problemlos und spontan das Fenster öffnen kann. Angst vor freien, aufgeräumten Flächen. So ähnlich ist es auch in manchen JIRAs dieser Welt, übertragen gesprochen. Ich dachte, wenn ich ein paarmal genervt habe und wir besprochen haben, was für die einzelnen Aufgaben zu tun ist, dann sind die Aufgaben auch wieder präsent, und die Menschen werden sie schon selbst aus dem Kreuz haben wollen. Hahaha. War aber nicht so.
Immer wieder dieselbe Fliese fegen
Nachdem ich mich für viele Wochen immer wieder mit den einzelnen Personen zusammengesetzt und gefühlt immer wieder an den gleichen Punkten aufgesetzt hatte ("noch nichts gemacht", "müssen immer noch warten auf xyz", "ach, ja, stimmt ja, das da.." etc.), wurde mir klar, dass das Aufräumen so nicht klappen würde. Marie Kondo ist übrigens eine zeitgenössische Aufräum-Queen aus Japan, die natürlich auch Bücher über ihre Arbeit geschrieben hat /1/. Aber das ist eine andere Geschichte. Mir kam natürlich zuerst der Gedanke, dass all die Aufgaben, wenn sie all die vielen Wochen lang nicht erledigt werden ja so wichtig nicht sein können (bis auf Ausnahmen, die die Regel bestätigen mögen).
Mit dem JIRA-Besen ins Rampenlicht
Der zweite Gedanke war dann, nicht nur einzelne Leute zum JIRA-Putzen zu bitten, sondern mit dem gesamten Team zu prüfen, welche Aufgaben einfach geschlossen werden können. Ich hoffte, dass sich in größerer Gruppe eine Dynamik entwickeln würde, die z. B. ewigen Sammlern zu Leibe rücken und sie davon überzeugen würde, dass eine alte offene Aufgabe nicht mehr weltverändernd sein würde. Diese Rechnung ging zumindest auf. Freund bildlicher Titel nannte ich die Veranstaltung "Sack zu", und das Team entschied gemeinsam, dass für einige Aufgaben nur noch ein winziger Schritt notwendig sei, um sie guten Gewissens schließen zu können, andere Tickets konnten erfolgreich sofort dichtgemacht werden. Auch hier gilt wieder der Rat "Take it to the team".
Verbesserung der internen Tätigkeiten - aber wie?
Mein Plan, interne Arbeitsprozesse in einem Team zu verbessern, sollte auf ganz oben genannte "mehr als 50% Verbesserung für die internen Tätigkeiten" einzahlen. Dass mir nicht klar war, wie ich die Messpunkte dafür setzen sollte, machte nichts, denn es dauerte unglaublich lange, bis ich - teils über Umwege - an diese internen Arbeitsprozesse überhaupt erst mal herankam. Der Workshop zum Ticket-Bearbeitungsprozess brachte viel weniger Erkenntnisse als erhofft, auch der darin gemeinsam visualisierte Prozess mit diversen Entscheidungspunkten nahm sich regelrecht popelig aus.
Manuelle Arbeit verringern
Einem anderen Team hetzte ich Fragen nach möglichen Maßnahmen zur Reduktion manueller Arbeit auf den Hals, letztere mache nach meinem Eindruck einen nicht unbeträchtlichen Teil ihres Tagesgeschäfts aus. Darauf versicherte man mir, dass es schwierig sei, manuelle Arbeit noch weiter zu verringern, und dass man das Thema vor einiger Zeit bereits aufgerollt und Prozesse optimiert habe. (Das sind dann immer die Momente, in denen man sich als geisteswissenschaftlich geprägter Scrum Master oder Teamcoach wünscht, der Mega-Techie zu sein, um solche Aussagen bewerten zu können. Oder man muss Geduld haben und darauf warten, dass jemandem der Kragen platzt, der dieses technische Wissen mitbringt...)
Wie wäre es mit... Testautomatisierung?
Als ich bei obigen Themen zunächst auf der Stelle trat, entschied ich, mit einem Fachmann das Thema "Testautomatisierung" zu besprechen. Fazit: Es gab keine (und dieser Konzern war nicht der einzige, dem dieses tragische Schicksal beschieden war - in einem anderen Unternehmen hatte man Jahre mit Diskutiererei zugebracht und konnte sich aus unerfindlichen Gründen nicht mal auf ein Test-Tool einigen).
Irgendwer hat doch bestimmt schon was gemacht
Ich hatte gehofft, mich an dem Thema entlanghangeln zu können à la: Was wurde bisher gemacht, wer hat sich damit bereits beschäftigt, welche Tools wurden von der Test-Truppe bereits ausprobiert und mit welchen Ergebnissen, welchen Rhythmus gibt es für wenigstens Teil-Automatisierungen, welche automatisierten Testfälle werden bereits benutzt etc.? Dann hätte ich gehofft, mich von Kolleg:innen mit passendem technischen Hintergrund aufschlauen zu lassen. Gut sind ja auch immer Rechnungen in Euro und Cent à la "wenn du das 100 mal durchklickst, ist so viel Zeit weg, die kostet bei deinem Gehalt xyz, und dazu noch ist das Risiko manueller Fehler gegeben. Wenn du das automatisierst, hast du einen Initialaufwand von x und immer wieder leichten Wartungsaufwand von y, aber dafür bei allen Deployments eine enorme Zeitersparnis, ein geringes Fehlerrisiko und ein leichteres Aufsetzen von Regressionstests, was sich in Euronen folgendermaßen ausdrückt...".
Wieder ein dickes altes Brett zu bohren
Stattdessen bekam ich von einem Kollegen die Aussage, dass das Thema Testautomatisierung so alt wie das Unternehmen selbst sei. Und dieses hatte vermutlich schon viele Menschen kommen und gehen sehen, die durchaus mehr von dem Thema verstehen als ich. Ich will ganz offen sein: Der Prozess des Versuchs der Verbesserung interner Tätigkeiten läuft immer noch, vermutlich noch lang, wenn man mich lässt. Ich kann nur beten, wie Reinhold Niebuhr es der Welt gezeigt hat: "Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann, den Mut, Dinge zu ändern, die ich ändern kann, und die Weisheit, das eine vom anderen zu unterscheiden." /2/
Synchronisierung von Kalenderblockern
Ich kam als externe Arbeitskraft in eine Unternehmung, wie so viele, die gefühlt fast ständig kommen und gehen, immer ein bisschen Spuren hinterlassen, aber stets auch einiges Wissen wieder mitnehmen. Verbindungen in Communities sind gekappt, müssen mit zunächst fremden Menschen neu aufgebaut werden. Manche guten Ansätze bleiben wahrscheinlich liegen, weil sich kein anderer mit ihnen identfizieren kann. Ich sah das Bild eines Konzerns, der die gleichen Probleme hat wie andere, wenn er versucht, Scrum oder die vermeintlichen Rosinen daraus zu skalieren. Inzwischen kenne ich mindestens ein toxisches Arbeitsumfeld in einem großen schein-agilen Programm, und ich kenne auch aus mehreren Beispielen von Initiativen die Flut an Terminen, weil sich niemand von Beginn an Gedanken darüber gemacht hat, wer mit wem in welchen Formaten reden muss.
Exponentielle Kommunikationskanalanzahlkurve
Stattdessen reden gefühlt alle mit allen, vorsichtshalber, und das Ergebnis der Formel für die Anzahl an Kommunikationspfaden je Anzahl beteiligter Personen (N(n-1))/2 explodiert /3/. Ich erwartete, dass auch in diesem Umfeld daran nicht zu rütteln war und dieses Thema eine Nummer zu groß (bzw. zu "zäh") für mich oder irgendwelche anderen Einzelpersonen war.
Eines Tages sprach ich in der Teamcoach-Community über das Thema "Terminflut" in unserem gemeinsamen Bereich (eine Krankheit, die wohl jeder kennt, ich war allerdings jüngst zum ersten Mal in einer kleinen Arbeitsgruppe gelandet, die versuchte, sich des Themas anzunehmen und bereichsweite Termine "auszulichten" statt neue ins System hineinzupumpen). In den letzten Monaten waren nach und nach neue Teamcoaches hinzugekommen, andere waren zuvor gegangen, es kam also frischer Wind durch die Tür hinein.
"Betriebsgeheimnis" lüften kann Brücken bauen
Mit einem Augenzwinkern und charmanter Offenheit bekannte einer beinahe beiläufig, dass sich sein Team Kalenderblocker einstelle, um zwischendurch endlich einmal konzentriert arbeiten zu können. Diese Blocker würden dann sehr wichtig betitelt, etwa "lateraler Strategie-Workshop" oder ähnliches. Nachdem der Damm gebrochen war, bestätigten auch andere Teamcoaches ähnliche Vorgehensweisen aus ihren Teams. Am Schluss wurde noch die Idee in den Raum geworfen, dass man doch eventuell bereichsweite Blocker vereinbaren könne - an bestimmten Tagen zu bestimmten Zeiten -, in denen dann ALLE konzentriert arbeiten können, ohne ein schlechtes Gewissen haben zu müssen.
Wir können alle an einem Strang (in der gleichen Richtung) ziehen!
Am Schluss der Veranstaltung machte ich allen bewusst, dass wir durch unsere Transparenz die einmalige Chance erhalten hätten, sinnvoll an diesem gemeinsamen Thema zu arbeiten, und bedankte mich bei dem betreffenden Teamcoach für sein Vertrauen und seine Offenheit. Der Prozess (ja, auch dieser) dauert natürlich zu lange, als dass man sein Ergebnis schon in den Händen hielte, aber Konsensfindung und erste gemeinsame Arbeit am Thema sind vielversprechend.
Tja, wie soll ich diesen Artikel beenden? Am besten mit einem passenden Zitat anderer: "Wenn wir unsere Erwartungen verringern, werden wir Zufriedenheit erfahren." /4/ (Das soll der Dalai Lama gesagt haben.)
Anmerkungen
/1/ https://de.wikipedia.org/wiki/Marie_Kond%C5%8D
/2/ https://de.wikipedia.org/wiki/Gelassenheitsgebet
/3/ https://www.projektmagazin.de/artikel/skalierung_grundprinzipien
/4/ https://www.aphorismen.de/suche?f_thema=Erwartung&seite=2
Kommentare
Kommentar veröffentlichen