Rudolf "Ruedi" Gysi
Liebt Produkte welche Kunden begeistern und Forscher zum Thema Iterative Produktentwicklung.
Versucht Work-Systems und Social-Systems nachhaltig miteinander zu verbinden damit wertvolle Arbeitswelten entstehen.
In den letzten Jahren haben sehr viele Firmen Agile Initiativen gestartet. Es wurde offensichtlich das es einen Wandel in der Arbeitswelt braucht. Agile Firmen hatten Vorteile auf dem Markt. Die Budgets zum Einführen Agiler Methoden, Werkzeuge und Infrastruktur wuchsen in die Höhe. Jeder Projektleitende wurde zum Scrum Master zertifiziert. Wir haben mehr Product Owner ausgebildet als die Firma jemals Produkte auf den Markt werfen kann. Die ganze Infrastruktur wurde ebenso grosszügig aufgewertet. In jedem Pausenraum gibt es nun Tischfussball oder andere Gruppenspiele. Die flauschigen Teppiche dürfen auch nicht fehlen. Das quitschfarbige Sofa steht natürlich prominent da wo auch jeder Besucher oder Bewerber es sehen kann. Ob die Rolleninhaber oder Teams wollten oder nicht, es wurden Heerscharen von Beratern und Coaches engagiert um den Teams zu zeigen wie „Agilität“ jetzt zu funktionieren hat.
Viele Verantwortliche schauen nun auf das Erreichte. Sind wir die coole Firma geworden bei der jedes Talent arbeiten will? Haben wir die Wettbewerbsvorteile der agilen Produktentwicklung erreicht? Warum sehe ich nun das Mindset nicht bei den Mitarbeitenden von dem alle Coaches gesprochen haben? All die investierte Kohle und was habe ich nun davon? Habe ich richtig investiert?
Wir können auf die Unternehmung schauen und erkennen relative schnell die offensichtlichen Zeichen des Arbeits-Systems (Work System). Dazu gehören Methoden wie Scrum, Kanban, Design Thinking, Itertaion Zero und die vielen bunten Boards. Ja, auch das quitschige Sofa gehört dazu.
Es gibt auch ein anderes System. Dieses ist nicht so einfach zu sehen. Es ist das Soziale-System (Social-System). Natürlich erkennen wir die Menschen. Wir sehen sie. Wir erkennen auch was sie im Work-System tun und wie sie sich verhalten. Das sind genau die, welche das agile Mindset noch nicht adaptiert haben. Das sind diejenigen die dauernd über dieses mühsame Scrum jammern. Die sind so undankbar. Sie dürfen jetzt ihre eigenen Geräte bringen, dürfen Homeoffice machen und es ist jeder Tag Casual Friday.
Wer die Vorteile des agilen Work-Systems wirklich nutzen will braucht Menschen mit dem richtigen Mindset (heisst es doch). Menschen die den Wechsel von „knowing Agile“ zu „being Agile“ gemeistert haben. Und genau da fängt das Social-System an. Was brauchen den die motivierten Mitarbeitenden damit es klappt? Sie müssen in einem Team arbeiten können. Gestern noch im Einzelbüro mit verstellbarem Eichenholz Tisch und einem eigenen kleinen Königreich, nun in einem crossfunktionalen Team. Was hat der Coach gesagt? Ich muss jetzt meine T-Shape Skills entwickeln? WTF wollen die von mir? Ich muss im Team Entscheide fällen? Wir reden doch gar nicht über Strategie? Warum habe ich jetzt keine Macht mehr über meine Mitarbeitenden?
Wir haben in den Unternehmen in das Work-Sytem investiert und Methoden, Werkzeuge, Praktiken und Infrastrukturen aufgebaut. Was haben wir in das Scocial-System investiert? Wieviel wurde ausgegeben um den Mitarbeitenden zu zeigen wie man Meetings moderiert. Wer hat ihnen geholfen zu verstehen was es mit dieser emotionalen Intelligenz auf sich hat? Working out loud? Was soll dieser Baumumarmungs-Scheiss? Warum soll ich jemanden als Mentor zur Verfügung stehen? Wie geht eine Retrospektive wirklich? Muss ich 13 Sprints hintereinander immer die gleiche Methode wie aus dem Training anwenden?
Wer den Nutzen aus den agilen Initiativen wirklich realisieren will muss in die Entwicklung jedes einzelnen Mitarbeitenden investieren. Ja, genau in die Entwicklung jedes Einzelnen. Agiles Arbeiten benötigt persönliche Skills der Teammitglieder. Die Fähigkeit zu Reflektieren, wissen wie man mit Kritik umgehen kann. Wie gehen wir im Team mit Konflikt um? Arbeiten im Team und Co-Creation verursacht ein gerütteltes Mass an Teamdynamik und braucht Vertrauen.
Ja, wir haben in die richtigen Dinge investiert, aber etwas einseitig. Es ist Zeit den Focus vom Work-System auf das Social-System zu schwenken. Der Invest in die Mitarbeitenden und die Entwicklung der persönlichen Fähigkeiten anzuschieben. Agilität braucht Teamplayer. Der Weg vom Einzelkämpfer im Silo zum Teamplayer ist weit und beschwerlich. Wir sollten uns bald auf den Weg machen.
Wir organisieren die Scrum User Gruppen Bern und Zürich und sind Co-Organisatoren der Scrum User Gruppe Zentralschweiz. Bisher haben wir unsere Events in kleineren Gruppen an coolen Orten durchgeführt. Der Austausch und die Gespräche unter den Teilnehmenden nach dem Event waren uns immer wichtig.
Nun haben wir gefühlt 100 Events online organisiert, geplant, gehostet und moderiert. Dabei ist immer wieder der Wunsch an uns herangetragen worden das wir die Events aufzeichnen und veröffentlichen sollten.
Wir haben die Speaker gefragt, alle sind einverstanden. 🙂 Das bedeutet das es nun einen Youtube Kanal gibt auf dem die aufgezeichneten Events verfügbar sind.
Alle zukünftigen Online Events der Scrum User Gruppe Bern, Zürich und die Kanban User Gruppen Schweiz werden auf diesem Kanal verfübar sein.
Seit März 2020 haben sich sehr viele Rahmenbedingungen in der Arbeitswelt verändert. Teams wurden auseinander gerissen, die Menschen arbeiten aus dem Homeoffice. Wenn es die Technik überhaupt erlaubt. In fast allen Medien und Communities wurde nach Tools und Methoden gesucht um wieder zusammen arbeiten zu können. Dieses Problem wurde von den meisten Teams und den Unternehmen irgendwie gelöst.
Ok, die Menschen können wieder zusammen reden, sehen sich in virtuellen Kaffees und besuchen Meetings und Trainings online. Alles wieder gut?
Im April hörten wir plötzlich andere Fragen. Wir möchten ein Projekt starten. Wie kommt das neue Team zusammen? Ich kriege einen neuen Mitarbeiter. Wie integriere ich den in mein Team? Wir haben Leute im Online Meeting die andere nicht zu Wort kommen lassen. Was kann ich da tun?
Ganz nach dem Agilen Manifesto sind die Interessen wieder dahin gerückt wo sie sein sollten. Von Prozessen und Tools sind wieder Menschen und Interaktionen wichtig geworden. Das Manifest stimmt also auch in den schwierigen Zeiten. Bin ich froh! 🙂
Aber… wie soll ich als Scrum Master oder Coach nun Teamdynamik beurteilen, unterstützen oder meine Fähigkeiten im dem Teambuilding einsetzen? Sehr viel was uns als soziales Wesen definiert ist online gar nicht möglich. Die Kommunikation ist eingeschränkt. In Zeit und Qualität. Wir können nicht zusammen Neues kreieren, zusammen um die gute Lösung streiten oder mal einen verrückten Plan aushecken.
Wie steht es nun mit der Teamentwicklung und der Teamdynamik? Braucht es das tatsächlich? War das eine sozialromatische Spinnerei vor der Kriese? Die Leute sind doch am arbeiten. Diese Frage hat zu einem sehr inspirierenden Gespräch mit Olaf Geramanis geführt.
Teams welche eine gute Teamentwicklung hatten und viel investiert haben in Selbstorganisation sind sehr schnell aus der Schreckensstarre erwacht.Sie haben zeitnah Lösungen entwickelt um die Probleme zu meistern. Unternehmen mit einer guten agilem Maturität sind den Umständen entsprechend relative rasch in ein neues Arbeitsmodell gerutscht und konnten weiter produzieren. Feedback der Teams war dahingehend das es nicht super ist, aber wir kommen vorwärts und lösen zusammen unsere Aufgaben.
Fast alle Scrum Master haben aber das selbe Thema; Wie entwickle ich das Team nun weiter? Wie integriere ich neue Mitarbeitende? Wie bringe ich ein neues Team zusammen?
Neue Teams mit den aktuellen Arbeitsmitteln und den verteilten Arbeitsplätzen aufzubauen ist sehr schwer bis unmöglich. Die ganzen Teambildungs Ereignisse und die notwendigen Aushandlungen von Teamregeln und das aufbauen von soliden, tragfähigen Vertrauens-Strukturen ist in diesem Umfeld kaum, oder zumindest sehr aufwändig möglich.
Das führt zu unser Hypothese das es sowas wie „Soziales Kapital“ geben muss. Teams und Unternehmen welche in das Soziale Kapital investiert haben sind nun in der Lage von dem „Ersparten“ zu zehren. Die Teams können eine Zeit lang die Zusammenarbeit aufrecht erhalten und sind trotz der Umstände Leistungsfähig. Es gelingt komplexe Aufgaben zu lösen da alle sozialen Strukturen im Team schon da sind. Dazu kommt auch das die Meisten Arbeits-Systeme mit Arbeit überladen sind. Wir können endlich das Backlog abbarbeiten.
Spannend ist es nun zu beobachten ob diese Investitionen lange halten. Wenn wir davon ausgehen das jedes Neue Teammember wieder einen Teamdynamischen Prozess auslöst… naja dann können wir vom ersparten Sozielan Kapital leben bis sich das Team ändert.
Diejenigen Firmen welche nicht in Teams und die Selbstorganisation (Being Agile) investiert haben konnten zwar einen schnelleren Produktions-Zyklus realisieren. Dabei sind vermutlich aber Technische Exellenz und das Soziale Kapital zu kurz gekommen. Diese „Schulden“ wiegen in der aktuellen Zeit schwer.
Product Owner, RTE’s , und Produktverantwortliche sollten sich in Zukunft gut überlegen in was sie investieren wollen. Investieren wir nur in Epics und Features, egal wie die technische Qualität aussieht? Diese Strategie führt zu erheblichen technischen Schulden. Irgendwann, spätestens im Betrieb werden wir da bezahlen müssen.
Neu sollten wir uns auch überlegen wie viel wir in das „Soziale Kapital“ der Teams investieren wollen. Wenn wir das zu wenig berücksichtigen wird das Team nicht die nötigen Strukturen aufbauen um auch in schweren Situationen angemessen zu reagieren und resilient gegen äussere Störungen zu werden. Wir bauen „soziale Schulden“ auf.
Wenn wir als Investoren Glück haben wird das Team nie in eine knifflige Situation kommen und wir haben Geld gespart. Aber was wenn das Team mal unter Druck kommt? Und das braucht keine Pandemie damit ein Team zeigt das es unter Druck das Preisschild der Sozialen Schuld schreibt.
Spätestens seit der Corona Krise ist das Thema Homeoffice flächendeckend bekannt. Mit diesem Beitrag möchten wir dir helfen möglichst gute Erfahrungen mit Online Konferenzen oder Trainings zu erhalten.
Als Coaches und Trainer sind wir viel mit den Tools unterwegs und darum beschreiben wir hier einige unserer Erfahrungen.
Gute Moderatoren sind ein Garant für erfolgreiche Online Sessionen
Wenn du ein Meeting planst, dann sei dir bewusst das du die Gesprächsführung haben wirst. Du wirst auch aus der technischen Sicht Dinge organisieren müssen und der Gruppe helfen, damit das Meeting ein Erfolg wird.
Die technische Sicht
Wir verwenden fast ausschliesslich http://zoom.us für unsere Meetings und Trainings. Es gibt viele gute Tools. Viele sind gratis und sehr leicht zugänglich. Wenn du Meetings online moderieren willst, dann musst du den anderen Teilnehmenden helfen können, wenn sie Probleme haben an der Session teilzunehmen oder mit der Steuerung nicht zurecht kommen. Wenn du viele Tools im Einsatz hast, musst du viel Technik Wissen mitbringen und zwar für jedes Tool. Es gibt nichts ärgerlicheres, als wenn der Moderator und ein Teilnehmer versuchen ein technisches Problem zu lösen, während alle anderen dabei zusehen und warten müssen. Daher fokussiere dich auf 1-2 Lösungen und arbeite dich da ein.
Unsere Empfehlung ist folgende: Wenn du die Teilnehmenden einlädst, schicke ihnen im Einladungs-Mail die Links zum Tool und den Schulung-Videos mit. Bitte sie darum vor dem Meeting die Software für die Konferenz und die Technik des PC’s oder Notebook zu testen.
Hier geht es zu einem Test-Meeting: https://zoom.us/test Da kann jeder alles ausprobieren.
Struktur des Meetings
Im echten Leben treffen wir uns im Konferenzraum, plaudern, holen Kaffee und suchen uns einen Platz am Tisch. Wir nehmen wahr, wenn der Moderator beginnen will und langsam wird es still im Raum, die Teilnehmenden schenken der sprechenden Person ihre Aufmerksamkeit. Alle dies nonverbalen Signale werden im Online Meeting größtenteils wegfallen. Daher ist es wichtig, dass die moderierende Person klare Strukturen und Regeln vorgibt und Sorge trägt das die Regeln eingehalten werden und gegebenenfalls angepasst werden. Zuerst einige Gedanken zu der Struktur
Check In Das Check In dient dazu das die Leute ankommen, ihre Technik noch anpassen können, und sich auf das Meeting vorbereiten. Es sind auch nicht immer alle gleich da. Einige werden noch von der Nachbarin an der Türe aufgehalten, bei anderen musste der Hund noch schnell vor die Tür, etc. Gib dem Check In genügend Zeit.
Was macht man im Check In?
Nachdem die Teilnehmenden alle in der Haupt-Session versammelt sind, ist es am Moderator zu fragen, ob ihn alle verstehen. Die Feedbacks kann man verstärken wenn man bspw nach einem “Daumen hoch” Zeichen frägt. Dann ist schon mal sicher, das dich alle sehen. Ob nun alle auch was sagen können ist noch nicht sicher. Daher ist es ein guter Zeitpunkt den TN zu erklären was “Breakout-Sessions” sind und was Timeboxen sind. Als Moderator schickt man anschliessend die TN in kleinen Gruppen in die Breakout-Sessions. Das sind temporäre Meetings in kleineren Gruppen. Wenn die Timebox abgelaufen ist, kommen alle wieder automatisch in die Haupt-Session zurück. Das sollte mindestens einmal geübt werden.
Die erste Breakout Session sollte eher kurz sein. Wir empfehlen 3-4 Minuten. Wir wissen nun, ob bei allen die Technik funktioniert und bei wem es noch ein Problem gibt. Du kannst jetzt die Leute mit technischen Problemen in eine Breakout Session nehmen und gezielt ihre Probleme lösen lassen. (Der Moderator kann in die Session hinein und auch wieder hinaus gehen)
Tipp: Wenn es einige TN gibt mit Problemen, wieder in Breakout Sessions gehen und sie gegenseitig helfen lassen. Als Moderator von Gruppe zu Gruppe gehen bis alles läuft. Diejenigen welche alles am Laufen haben sollen miteinander plaudern oder sich noch einen Kaffee holen.
==> Break Out Sessions; Timeboxed die Technik prüfen und gegenseitig kennen lernen
In das Check In gehört auch die Bekanntgabe der Regeln in der Gruppe. Wir haben mit folgenden Regeln gute Erfahrungen gemacht:
Wir verabreden ein Handzeichen wenn jemand nicht zu verstehen ist
Wir halten uns an die Timeboxen
In jeder Breakout Session moderiert jemand temporär (dazu gehört auch das Timekeeping)
Wir arbeiten alle mit Videomodus
Wir verwenden eine klare, möglichst präzise Sprache
Wir lassen andere Ausreden und halten auch unseren Beitrag kurz
Andere Anwendungen auf dem Gerät sind während der Konferenz geschlossen (Sie fressen Bandbreite und geben eventuell störende Geräusche ab)
….
Konferenz oder Haupt-Session
Jetzt geht es zum eigentlichen Inhalt des Meetings. Sei dies Training oder ein Business Meeting. Je nach Thema und Dynamik bietet es sich auch wieder an das Breakout-Sessions gemacht werden. Nach jeder Breakout-Session müssen die Ergebnisse zusammengefasst und den anderen mitgeteilt werden.
Dadurch das die Technik funktioniert hat und alle sich an die Regeln gehalten haben sollte die Haupt-Session das gewünschte Resultat liefern.
Als Moderator solltest du dir Gedanken machen wie du die Ergebnisse aufnimmst und visualisierst. Du kannst deinen Bildschirm mit deinen Notizen teilen, ein virtuelles Board pflegen oder alle haben Zugang zu einem Tool, welches das ganze Team nutzen kann. Auch hier; teste die Software und die Tools vor dem Meeting.
Zusammenfassung und was kommt als nächstes
Bevor wir die Haupt-Session abschließen, sollte die Moderation die Ergebnisse zusammenfassen oder zusammenfassen lassen. Gegebenenfalls klären wo Notizen oder Ergebnisse gefunden werden können und wer wem was noch zusenden will. Wir klären, ob für alle die nächsten Schritte oder Aufgaben klar sind.
Check out
Jetzt bleibt uns als Moderator nur noch die Aufgabe die Feedback-Schleife zu schliessen. Wir fragen die TN ob alles geklappt hat und ob sie sich Änderungen am Check In oder an den Regeln wünschen. Wenn alles bearbeitet wurde, allen einen schönen Tag wünschen und mit einem ByeBye Winken verabschieden. Als Moderator kannst/musst du alle aus der Session kicken und das Meeting abschliessen.
Arbeiten mit Timeboxen
Die Online Meetings sind anspruchsvoll was das zuhören und verstehen der Inhalte anbelangt. Als Moderator sollte man auch daran denken das nicht alle Teilnehmenden Profi Ausrüstung zur Verfügung haben. Es kann gut sein das ein Headset nach 40 Minuten auf die Ohren drückt, die Tonqualität so schlecht ist das man ganz erschöpft vom aktiven zuhören ist. Aus diesen Gründen empfiehlt es sich die Session in mehrer Abschnitte zu unterteilen.
Handzeichen und Visualisierungen
Es gibt viele Störungen welche an einem Online-Meeting auftreten können. Für die Wichtigsten sollten Handzeichen alternative Lösungen oder Visualisierungen vorbereitet sein.
Handzeichen sind sehr einfach und haben einen schnellen Erfolg. Wenn zum Beispiel die Tonqualität plötzlich schlechter wird, können die Teilnehmenden das mit einem Zeichen angeben. (Bsp Hand hinter das Ohr) Wenn jemand etwas sagen möchte kann dies mit erhobener Hand signalisiert werden, die Moderation sorgt für eine gerechte Redezeit. Oft muss jemand aus der Gruppe früher gehen. Dies sollte beim Check In angekündet werden und wenn die Zeit gekommen ist, in die Kamera lächeln und Good Bye winken und aus der Session rausgehen. Die Verbleibenden winken zurück, aber der Dialog wird nicht unterbrochen.
Visualisierungen sind bei Online Konferenzen immer eine Herausforderung. Natürlich kann jeder, je nach genutztem Tool, seinen Bildschirm freigeben und etwas zeigen. Regelmäßig findet man dann den Knopf nicht um die Präsentation zu beenden, oder es sind im Browser so viele Fenster offen, dass die Teilnehmenden nicht genau wissen, was jetzt gezeigt werden soll. Wenn du mit einem Flipchart oder einem Whiteboard arbeiten möchtest, dann gibt es Möglichkeiten damit dies gut gelingt. Du brauchst dazu möglicherweise zusätzliche Technik. Damit White-Boards nicht spiegeln ist die Beleuchtung wichtig. Wenn du im Raum herumgehst, solltest du ein entsprechendes Headset oder ein gutes Mikrofon haben. Wenn du an Flipcharts arbeiten möchtest, kommst du um eine zusätzliche Kamera fast nicht herum. Diese Kamera ist auf den Flip gerichtet und das Mikrofon ist auf “Mute”.
Privatsphäre und Datenschutz
Die Teilnehmenden sind oft zuhause oder in Räumlichkeiten welche Hinweise auf ihre Privatsphäre geben könnten. Wenn du dich auf die Moderation vorbereitest und gegebenenfalls die Webcam testest, dann schau dir mal den Hintergrund genauer an. Ist nur das zu sehen was du auch von dir preisgeben willst? Schaffe eine Umgebung welche einem Trainingsraum ähnelt. Das selbe gilt für deinen “Dresscode”. Natürlich sind wir alle zuhause in unserem Homeoffice. Aber wir gehen ja auch nicht im Sportdress zu Meeting. Ziehe dich an als ob du ein Training vor Ort geben würdest.
Aller Anfang ist schwer. Das wissen wir alle. Du kommst als Scrum Master zum neuen Team. Auftragsklärung war gut, Mission ist klar. Beim ersten Planning üben sich die Teammembers in Zurückhaltung. Kaum jemand sagt was. Einizig der Lead-Architekt weiss ganz genau was zu tun ist.
Da fange ich als Scrum Master an etwas nervös zu werden. Haben wir hier im Team ein Hirn und der Rest sind Finger und Füsse? Warum hat niemand vom Team eine andere Meinung als der Architekt? Wenn alles klar ist, ja dann… könnten wir auch klassisch entwickeln. Der PO meinte im Vorfeld ganz klar: Es ist was komplexes, wir wissen noch nicht wie wir das machen werden.
Ok, es scheint an der Zeit zu sein als Scrum Master über eine Team-Intervention nachzudenken. Problem; es spricht nur einer. Alle andern sagen nichts, schauen weg, oder beantworten Mails auf dem Notebook. Ich sehe nicht alle Synapsen bei der Arbeit, mindstens nicht bei der gemeinsamen Arbeit.
Neues Team beim Planning
Hypothese als Coach: Die anderen sagen nichts weil keiner den anderen kennt und keiner weiss was die anderen Denken und wissen oder gar was sie können. Eine Vorstellungsrunde wird da nicht reichen. Wir müssen wissen wer hier welche Skills mit in das Team bringt.
Intervention: Ich unterbreche den Redefluss des Leadarchitekten mit der Frage ob sie schon einmal zusammen gearbeitet haben und sich daher als Fachleute schon kennen. Die Team-Members kennen sich als Menschen, aber haben noch nie zusammen gearbeitet. OK. Mein Vorschlag ist nun das wir uns alle 5 Minuten Zeit nehmen und jeder schreibt aus seiner Sicht auf, welche Skills in diesem Team notwendig sind um erfolgreich liefern zu können. Nachdem die Timebox abgelaufen ist tauschen sich immer 2 zu den Skills aus, welche sie für relevant halten. Doppelte Beiträge werden zusammengefasst. Ev kommt ja noch was anderes zum Vorschein. So ca nach Ablauf von 5 Minuten stellen nun diese Paare die „Soll Skills“ aus ihrer Sicht vor. Das Ergebnis: Wir haben einen aktuellen Stand was das Team denkt was es braucht um die Aufgabe zu stemmen.
Im zweiten Schritt legen wir alle Skill Karten in die Mitte des Tisches. Jeder zieht sich das Kärtchen wo das Teammember glaubt Fähigkeiten zu haben. Jedes Teammember legt die Karten offen vor sich auf den Tisch. (Transparenz der Skills)
Nun entsteht meistens ein anderes Problem. Es liegen noch Kärtchen auf dem Tisch. Ups. Im dritten Schritt schauen wir uns als Team an, wer sich um welches Skill Kärtchen kümmern möchte. Optionen sind; selber schlau machen oder jemanden suchen der diese „missing skills“ hat.
Ev ist die Zeit für das Planning nun schon rum. Kein Problem. Neuen Termin machen. Die Teammember bringen ihre Skill Karten zum Planning mit und legen diese vor sich hin. Wenn wir nun über das Produkt reden weiss jeder wozu seine Meinung gefragt ist und wo sogar erwartet wird das dieses Teammember was dazu sagt.
Das nächste Planning sollte nun viel lebhafter und intensiver sein.
Wenn nicht… dann war die Coaching Hypothese wohl nicht zutreffend. Dann schauen wir dem Team nochmal zu und stellen eine nächste These und planen die nächste Intervention. Das sehen wir dann in der nächsten Episode. Wenn es heisst; A Scrum Master’s Life!“
Ich habe einen interessanten Beitrag zur Agilen Transition bei der Bank ING gefunden. Der Artikel ist eine Übersicht und Zusammenfassung zur Geschichte der Transformation der Bank.
Wer kennt es nicht? Wir arbeiten Sprint für Sprint als Scrum Master oder als Coach mit dem Team. Es stellen sich gute Erfolge ein. Die Kunden geben Feedback das ermuntert, wir gehen den Weg weiter. Der PO hat ein zufriedenes Lächeln an den Meetings.
Trotzdem beschleicht uns von Sprint zu Sprint ein Gefühl der Leere. Ist das überhaupt noch sinnvoll was ich hier mit dem Team tue? Bringte ich das Team als Scrum Master noch weiter? Jeden Tag gehen wir zum Daily oder zu einem anderen Meeting und haben das Gefühl Hauptdarsteller im Film „täglich grüsst das Murmeltier“ zu sein.
Ich nenne diesen Zustand „Die Einzelgänger Lethargie“. Duden definiert Lethargie folgendermassen: Zustand körperlicher und psychischer Trägheit, in dem das Interesse ermüdet ist. Dabei werden folgende Eigenschaften beschrieben: gleichgültig, träge, langweilig, schwerfällig, desinteressiert, schlapp, teilnahmslos und viele weitere Worte die nicht sehr inspirierend sind. Im Internet gibt es viele Definitionen oder Synonyme dazu.
Ich konnte diese Phänomene auch bei mir schon beobachten. Denn ich wusste von mir das diese Attribute eigentlich gar nicht so zu mir gehören oder passen. Trotzdem hat es mich enorme Mühen gekostet in der Arbeit gegen die Symptome anzukämpfen. Ich habe lange gebraucht um den Ursachen auf die Schliche zu kommen.
Ich habe angefangen acht zu geben, wann diese Trägheit auftritt und wann sie wieder weg ist. Auffallend oft hatte ich das Gefühl lethargisch zu sein, wenn ich lange und alleine in meiner Rolle oder Aufgabe unterwegs war. Ich konnte mich mit niemandem wirklich über die Herausforderungen und die Probleme meiner Mandate austauschen. Ich war völlig uninspiriert und habe den Team nicht das gegeben was ich als Scrum Master oder als Coach eigentlich geben möchte. Selbst Retrospektiven, etwas was ich eigentlich sehr gerne mache, waren plötzlich eine Last und ich habe den Weg des geringsten Widerstands gewählt und irgendwas genacht was mich wenig Energie gekostet hat.
Es gab aber auch andere Momente. Zum Beispiel wenn ich an einer Scrum User Group war. Da habe ich viele Menschen getroffen die ähnliche Aufgaben zu lösen hatten. Die neue Ideen schilderten und von Erfolgen in ihren Teams erzählten. Ich konnte da auch andere nach ihrer Meinung fragen. Oder wenn ich in einer Firma in der Agilen Gilde oder in der Gilde der Coaches oder Scrum Master besucht habe. Der Austausch hat inspiriert und Lust gemacht Neues auszuprobieren. Auch der Besuch von Konferenzen hat geholfen neue Ideen zu sammeln und Energie zu tanken um neue Aufgaben anzupacken.
Agilität lebt davon das man in einem Team arbeitet und sich austauscht. Aber die Arbeit in einem Team ist nur ein Aspekt von Agilität. Denn wir sind auch Teil einer Gruppe die sich für gewisse Fachthemen interessiert, ausserhalb meines Entwicklungs-Teams. Dort kann ich über meine spezielen Skills reden, lernen und reflektieren. Diese speziellen Skills bringe ich in in meiner Rolle als Coach oder Scrum Master wieder in mein Team. Aber wo kann ich diesen Tank meiner Skills wieder füllen? Wer hilft mir besser zu werden in meiner Rolle? Das Team, in dem ich normalerweise arbeite kann diese Aufghabe nicht unbedingt erfüllen. Die „verbrauchen“ ja meine Ideen und Fähigkeiten. Daher muss ich die Energiequelle anderswo finden.
Immer wenn ich fühle das die „Einzelgänger Lethargie“ sich langsam aufbaut überlege ich mir wo ich wieder Energie herkriege. Wo kann ich mich mit Menschen austauschen welche meine Interessen teilen? Mit diesem Ziel habe ich eine ganze Reihe von Möglichkeiten gefunden meine Inspiration wieder mit Energie zu versorgen. Ich gehe regelmässig zu Scrum User Groups um mich fachlich mit Kollegen zu unterhalten. Ich besuche regelmässig Konferenzen. Dort erhoffe ich mir immer neue Methoden und Ideen zu erlernen und neue, spannende Menschen kennen zu lernen. Dann gibt es noch eine Möglichkeit sich zu regenerieren. Ich treffe mich regelmässig mit Coaches und Scrum Mastern die in einer ähnlichen Arbeitssituation sind. Wir nennen das „Coach Treffen“ Da verbringen wir die Zeit mit „Kollegialer Fallberatung“ Es tut doch immer wieder gut zu sehen das man mit seinen Themen nicht alleine auf der Welt ist. Dieser Perspektivenwechsel bringt sehr viele neue Ansatzpunkte für die Arbeit.
Und sonst…. da gehe ich einfach mal mit anderen Kollegen einen Kaffi trinken und wir erzählen einander wie schwer wir es doch haben und welch grossartigen Heldentaten wir in der letzten Zeit vollbracht haben.
in aller Kürze: Verlasst euer eigenes Silo, geht raus und trefft und redet mit Kollegen und tauscht Ideen und auch mal Sorgen aus. Sucht euch einen Club der euch wieder Inspiration und Energie gibt. Ihr werdet sehen das die Schwere und Müdigkeit des Alltages plötzlich viel weiter weg ist und das Team wieder einen Coach oder Scrum Master hat der inspiriert und von innen heraus wieder leuchtet. das was wir uns doch alle so sehr wünschen… oder? 😉
Es war einmal ein Team, das hat den ganzen Sprint hindurch nur gemotzt und an allem rumkritisiert hat. Das war als Scrum Master jeden Tag eine Tortur mit diesem Team zu arbeiten. Doch die Quälerei hat ja auch was Gutes. Wir können am Tag der Retrospektive ganz viel besprechen.
Der Tag kommt…. und dem Team fällt überhaupt nichts ein, worüber man reden kann und wo es sich lohnen könnte zusammen besser zu werden.
Aus dieser Situation hinaus habe ich mir folgende Retrospektiven Merthode ausgedacht.
Die Methode beginnt am Ende der Retrospektive, wenn mal wieder nichts besprochen wurde. Ich verteile allen in Team einen Block Post-Its. Alle haben die selbe Farbe. In der Mitte des Raumes stelle ich einen Papierkorb oder ein anderes geeignetes Gefäss hin. Der Auftrag an das Team lautet folgendermassen: Jedes Mal, wenn ihr euch aufregt, oder über Dinge ärgert; schreibt es auf eines der Post-It’s, zerknüllt es und werft es in den Papierkorb.
Am Ende des Sprints wird der Papierkorb in die Mitte des Tisches entleert. Wir sortieren die Zettelchen und bilden Themengruppen. Danach bestimmen wir welche Themengruppe es wert ist näher besprochen zu werden und unterhalten uns darüber. Wenn das team dann einen Verbesserungsvorschlag dazu macht, super!
Alternativen in der Durchführung: Jeder sucht sich eine Farbe aus. Damit ist am Ende vom Sprint klar wer, welche Zettel geschrieben hat. Oder jeder macht ein Kürzel auf den Zettel. Es ist nicht anzunehmen das jeder ab dem ersten Tag des Sprints Zettelchen schreibt. Als Scrum Master nehme ich den Papierkorb mit zum Daily und frage aktiv nach ob es schon Zettelchen gibt.
Ich werde mich freuen wenn andere Scrum Master die Methode ausprobieren und in den Kommentaren Feedback geben würden.
Wer im Internet nach dem Begriff „Produkt Dekomposition“ sucht wird im Moment nicht sehr viele Treffer landen. Jedenfalls nicht im dem Zusammenhang wie er in der Agile Produktentwicklung verwendet wird.
Im wesentlichen geht es darum, das sich ein Product Owner (PO) sich damit auseinandersetzt wie er sein Produkt an den Markt bringen möchte. Natürlich gibt es dazu in den entsprechenden Foren und Medien sehr viele Praktiken und Prinzipien die helfen sollen das Produkt gut zu schneiden.
Schauen wir hier einmal die Produkt Dekomposition an. Ausgehend von der Definition zerlegen wir das Produkt in Teilfunktionen. Das ist schon mal sehr gut, da damit klar ist das wir uns überlegen sollten aus welchen Features das Produkt besteht. Damit geraten wir als PO weniger in die Versuchung das Produkt in Komponenten zu zerlegen.
In den Planning Sessions überlegen nun der PO und das Entwicklerteam wie sie das Produkt produzieren und ausliefern sollen. Dabei werden die Funktionen zerlegt und geschätzt. Die entstandenen Backlog Items (PBI) werden dann auch noch sauber im Product Backlog (PBL) nach Wert oder Komplexität eingeordnet. Wir sind bereit für den Sprint.
Je mehr Sprints vergehen kommt das Gefühl auf, das die Produktentwicklung wenig zielgerichtet ist. Was ist jetzt wichtig? Haben wir die richtigen Dinge priorisiert? Warum kriegen wir diese User Story (US) nicht fertig? Werden wir das Minimal Viable Product (MVP) auch wirklich hinkriegen? Das Team diskutiert und schätzt und ordnet. Das Gefühl von Unsicherheit wird nicht kleiner.
Diese Teamszenen kann man als Coach fast jeden Tag in einem Team erleben. Der PO hat den Top Stakeholder versprochen zu liefern, das Team will seine Zusagen einhalten. Die Dialoge in den Plannings und Refinements werden hitziger. PO und Team verlieren sich immer wieder in den Flughöhen bei den PBI Besprechungen. Einmal diskutiert man auf dem atomaren Niveau einer Funktion. Danach prägen Philosophische Exkurse den Dialog im Team. Das Meeting geht zu Ende und man einigt sich hurtig auf die Reihenfolge im PBL und die Schätzungen. Natürlich verläuft der nächste Sprint nicht besser. Natürlich müssen wir besser planen, schätzen und priorisieren. Die Definition of Done (DoD) war ja eigentlich auch nicht so klar. Hat jemand die Akzeptanzkriterien der Story gelesen?
Warum passieren diese Szenen in fast jedem Team? Ich vermute das der Fokus fehlt und sich das Team mit dem PO zu wenig um die Planungsaspekte der Agilen Produktentwicklung kümmert. Das Bewusstsein, wie sich das Produkt zusammensetzt, in welcher zeitlichen Abfolge Was geliefert werden sollte und die Grösse der Produktfunktionen ist oft nicht klar. Es ist möglich, das einzelne Teammitglieder dieses Produktbewusstsein erlangt haben. Es ist jedoch fraglich ob diese Produktinformation vom ganzen Team geteilt wird.
Hier kommt die Idee der Produkt Dekomposition in das Spiel. Das ganze Team muss verstehen was von dem Produkt zu welchem Zeitpunkt geliefert werden muss. Um diesen Dialog möglichst fokussiert und zielgerichtet führen zu können muss das ganze Team verstanden haben wie das Produkt zerlegt wird.
Übersicht Produkt Dekomposition
Dabei wird das Produkt auf verschiedenen Stufen zerlegt. Zuoberst stehen die „Investitions Themen“. Ich Nenne die so, da auf dieser Flughöhe vor allem Stakeholder miteinander sprechen die von der Technologie oder den Details nicht so viel wissen. Das müssen sie auch nicht. Es geht um eine langfristige Ausrichtung und um strategische Themen. Diese Gruppe beschäftigt sich sehr stark mit dem „WAS“ und dem Markt. Dabei ist der Fokus auch auf finanzielle Themen gerichtet. Folgende Fragen interessieren: Wie lange können wir am Markt mit dem MVP operieren? Wann muss mindestens 1000 Kunden auf dem Produkt gebucht sein? Wie messen wir den Erfolg? Wann geht uns das Geld aus? Wann müssen wir skalieren? Diese Themen werden in einem Startup natürlich auch vom Team geführt. Da passiert dieser Dialog von selber. In grösseren Unternehmen sind an diesem Themenbereich meistens Menschen beteiligt die mit der Umsetzung direkt nichts zu tun haben.
Jahresplanung mit Investitions Themen
Eine Ebene darunter befinden sich die Epics. Wenn das Team die Investition Themen gut geordnet hat ist nun der PO mit dem Entwicklungsteam dran. Aus was bestehen die Investition Themen. Wie liefern wir den versprochenen Wert? Aus der Investitionsplanung ist ersichtlich bis wann welches Produktelement geliefert werden sollte. Die Epics werden den Investition Themen zugeordnet und in die Reihenfolge gebracht welche das Team glaubt sei die richtige. Wenn wir uns die Grösse eines Epics anschauen sind das Arbeitselemente welche in 1 bis 3 Monaten geliefert sein sollten. Das Team erkenn, wenn mehrere Epics zu einem Investition Thema gehören und der gewünschte Release gefährdet wird. Das ist nun der richtige Zeitpunkt um mit dem PO zu reden und zu klären ob wirklich so viel geliefert werden soll. Der PO hat mit seinem Team zusammen gelernt und trägt die Informationen nun zu seinem Stakeholder und bearbeitet die neue Situation. Die Klärungen helfen dabei das PBL richtig zu priorisieren und gegebenenfalls die Grösse eines Investition Themas oder dessen Liefertermin anzupassen.
Quartalsplanung mit Epics
Die Ebene unter den Epics nenne ich die User Stories oder Product Backlog Items. Diese Arbeitsstücke sind einigermassen definiert. Das sind Elemente welche innerhalb eines Sprints geliefert werden sollen. Das heisst die maximale Aufwandschätzung sollte 4 Wochen nicht übersteigen. Sogar wenn das Team Kanban verwendet bin ich der Meinung das diese Produktelemente nicht grösser sein sollten. Ab hier macht eine Sprintplanung absolut Sinn. Hier muss auch Klarheit über das „WIE“ liefern wir diese Produktfunktion herrschen. Wenn der PO Epics zum Planning mitbringt sind die Basis-Philosophischen Dialoge schon ziemlich gut geführt. Das Team weiss WAS der PO den Stakeholdern verprochen hat. Der Fokus der Dialoge liegt aus dem WIE liefern wir dieses Produktinkrement? Wenn das Team mit dem PO diskutiert warum das gebaut werden soll, dann ist es vermutlich besser den Sprint nicht mit einem Produktinkrement zu planen von dem nicht sicher ist das der Wert vom Team verstanden wurde.
Sprintplanung mit Product BAcklog Items (User Stories)
Die unterste Ebene in der Produkt-Dekomposition wird durch die Tasks beschrieben. Das sind Arbeitselemente die zu einem Epic zählen und vom Aufwand 1 bis 3 Tage gross sein sollten. Diese Tasks sollte das Team unabhängig eines Stakeholder oder des PO beschreiben und umsetzen können.
Sprint Board
Mit verschiedenen Teams habe ich bereits versucht mit dieser Methode mehr Fokus in die Plannings und Refinements zu bringen. Bisher habe ich sehr gute Erfahrungen damit gemacht. Wenn ein Team diese Strukturen legt, wird oft klar, das die Dialoge mit den unterschiedlichen Stakeholdern nicht gut geführt wurden. Das Erwartungen an Information und Produkt nicht geklärt wurden. Für mich ist dies eines der wichtigsten Lernelemente eines Teams. Klärt die Kommunikations-Strukturen. Werdet euch bewusst mit wem ihr über was sprechen müsst. Speziell für Teams in grösseren Unternehmens Strukturen ist dies wichtig.
Ein sehr guter Nebeneffekt sind die Fragen welche das Team nach oben in das Portfolio richtet. Muss das Investitions Thema wirklich so gross sein? Was gehört wirklich dazu? Es werden Verzichtsdialoge geführt um den tatsächlichen Wert des Produkt-inkrements zu klären.
Probiert die Idee der Produkt Dekomposition mal in euren Teams aus. Über Feedback oder Erfahrungen würden wir uns sehr freuen!
