Direkt zum Hauptbereich

Lean Coffee Frankfurt/Karlsruhe, Nachschau zum Termin #31

Die agile Szene trifft sich in verschiedenen Stammtischen und Meetups. Hier ist ein Bericht vom 31. Lean Coffee Frankfurt/Karlsruhe bzw. Karlsruhe/Frankfurt.

Es ist gut, wenn sich die agile Szene untereinander vernetzt und sich gegenseitig hilft. Dazu dient dieses Lean Coffee, dessen Mitglieder sich dienstagmorgens von 8 - 9 Uhr treffen. Wer dazukommen möchte, darf sich gern in einer der entsprechenden Xing-Gruppen anmelden:

Foto von Nathan Dumlao auf Unsplash

Nach einem üblichen lockeren Vorgeplänkel startete die Veranstaltung pünktlich um 08:00h. Im Wesentlichen hatte sich der harte Kern von ca. 10 Personen eingefunden. Teilweise war eine gewisse Fahrigkeit zu spüren: Die Moderation verzettelte sich wie schon öfters zwischen Notizen für diesen Text (nur noch WORD vor der Nase) und Beobachtung, welche Hand der Beitragenden sich zuerst für einen Beitrag hebt - wir sind da wirklich ziemlich diszipliniert. Aus dem Maschinenraum wurde dafür einmal vergessen, die Zeit zu starten.

Während der Themensammlung auf Scrumlr summte ein Teilnehmer leise und versonnen vor sich hin, rügte sich dann aber selbst, man dürfe ja nicht singen. Nach dem lachenden Vorschlag aus der Moderation, dass das doch eine angenehme Hintergrundmusik statt Stille sei, schaltete der Maschinenraum sofort, und da wir – wie es der Zufall wollte – heute „Freddy Mercury“ als Gast auf dem Scrumlr-Board hatten, erschollen sogleich die ersten Takte der „Bohemian Rhapsody“ als Untermalungsmusik (wahrscheinlich auf ca. 90 dB eingestellt, denn trotz der Zoom-Rauschunterdrückung und Abwesenheit von „Umgehungs“-Tools war die Musik gut vernehmbar). Passender Liedtext, wenn man an größere agile Initiativen denkt: „Is this the real life? Is this just fantasy? Caught in a landslide, no escape from reality...“ 😊

Folgende Themen brachten wir an diesem Morgen durch:

Wie skaliert man POs?

Ein Teilnehmer beschrieb den üblichen Aufbau: Ein Team besteht aus PO und Scrum Master sowie Entwicklern. Die Skalierung findet nicht nur für die Rolle des PO, sondern gesamthaft statt: Auf der nächsthöheren Ebene treffen sich POs, SCMs und Entwickler aus den verschiedenen Teams zu neuen Kreisen des Austauschs. Um in Patt-Situationen eine endgültige Entscheidung herbeiführen zu können, wird eine Person mit besonderer Entscheidungsgewalt ausgestattet.

Ein Teilnehmer drehte die Frage für die Diskussion noch einmal um: Wie schafft man es, die Skalierung zu vermeiden? Wie kann es gelingen, Teams so aufzustellen, dass sie zwar einen hervorragenden Austausch miteinander haben, aber gänzlich ohne Skalierung, d. h. so unabhängig wie möglich, nahezu isoliert voneinander, arbeiten? Eine ganz konkrete Antwort fanden wir in unserem Gespräch leider nicht. Ein anderer Teilnehmer hielt ein Buch in die Zoom-Kamera, das ihm geholfen habe, ein dritter wiederum warnte eindringlich, dass „der Schaden, den solche Methodenbücher verursachen“, enorm sei, da überwiegend die Methoden eingeführt würden, ohne den Sinn dahinter zu verstehen (eine Analogie zum Einsatz von Scrum in wahrscheinlich vielen Konzernen drängt sich hier diskret auf). Der zweite Teilnehmer lachte und bemerkte, er ziehe den - bereits in den Chat gestellten – Link zum Buch wieder zurück.

(Teil-)Auflösung des Teams: Was tut Ihr, wenn sich Kollegen verabschieden?

Die Moderation mengte sich ein und berichtete vom Abschied für ein Team nicht von einer Person, sondern von einem gemeinsam erarbeiteten Produkt (für das es, man höre und staune, keinen PO gab, da es sich um die Weiterentwicklung eines Prototypen handelte, den aber niemand adoptieren wollte). Es wurde ein retrospektiven-artiger Rahmen für den Abschied vorgeschlagen, als eine Möglichkeit, um danke zu sagen, wurde ein Gutschein als Geschenk, wie auch bei Geburtstagen üblich, genannt. Eine andere Teilnehmerin stimmte zu und empfahl, in jedem Fall eine Verabschiedungszeremonie durchzuführen. 

Hier wurden am Rand noch Geschichten aus dem Nähkästchen berichtet, bei denen das nicht möglich gewesen wäre, da manche Personen von einem auf den anderen Tag ihre Mitarbeit im Team aufgekündigt hätten und nicht mehr erschienen seien (es handelt sich hier, wie die geneigte Leserschaft erahnen kann, um zwischenmenschliche Konflikte). Weiterhin schlug die Teilnehmerin vor, dass im Team gemeinsam erarbeitet werden sollte, möglicherweise auch bereits im Vorfeld mit der scheidenden Person, was dem Team nach dem Weggang an Kompetenz und Kapazität fehlt, um sich mit Blick in die Zukunft entsprechend neu aufzustellen, Ersatz zu suchen.

Chef, sage mir, was ich tun soll - agiles Mindset

Der Themengeber arbeitet als Teamlead im Bereich Betriebsführung und damit auch Service-Level-Management, einem eher weniger agilen Bereich, in dem man aber viel über Anwenderprobleme lernt und häufig bereits im Vorfeld einschätzen kann, dass die Bearbeitung und Lösung mancher Themen mehrere Tage dauern wird. Laut dem Teilnehmer hätte das in diesem Umfeld arbeitende, nur aus drei weiteren Mitgliedern bestehende Team durchaus Gelegenheit, sich in puncto Arbeitsaufteilung selbst zu organisieren, denn von ihm bekommt es hier freie Hand. Stattdessen möchten aber die Mitglieder ihre Aufträge einzeln erhalten, und die Frage besteht darin, wie sie zur Selbstorganisation geführt werden können.

Nachdem geklärt wurde, dass das Team in keine hierarchische Struktur eingebunden ist (die eigenständiges Denken nicht unbedingt fördert), dass es ein externer Dienstleister ist, der alle Freiheiten hat, so lange die Arbeit zur Zufriedenheit aller erledigt wird, wurde aus den Reihen der Diskussionsgäste vorgeschlagen, einen Workshop mit dem Team, dem Vorgesetzten und 1 – 2 weiteren wichtigen Personen, die z. B. zuliefern, einzuplanen. Hierfür könnte möglicherweise jemand drittes als Moderation beauftragt werden, führte der Teilnehmer weiter aus und schob mit raunender Stimme ein: „jemanden aus unseren Reihen z. B.“, woraufhin ein anderer lachte: „Gut gemacht!“, im Workshop gehe es dann um Aufgaben mit Selbstbeteiligung aller, z. B. das beliebte online und offline durchführbare Post-It-Kleben zu bestimmten Themen. Für etwa die darauffolgende Woche könne dann ein Folgeworkshop für einen vollen Tag angesetzt werden.

Der Themengeber selbst hatte sich bereits überlegt, dass das Team, zusammengesetzt in der Cororna-Zeit Anfang 2021, d. h. bisher ohne persönlichen Kontakt in der realen Welt, für zwei Tage zusammengeholt werden sollte. Ein weiterer Teilnehmer empfahl einen offenen Erfahrungsaustausch mit jemandem, der einen ähnlichen Werdegang durchlebt bzw. ähnliche Erfahrungen gemacht hat. Der Mensch lerne am leichtesten am konkreten Beispiel, und durch die Überschaubarkeit des Teams biete sich ein solcher Austausch mit anschließendem „learning by doing“ an.
Das Team wurde zum Objekt dieses Lean Coffees, da es mehrfach SLAs „gerissen“ hatte und nun nach einer Möglichkeit gesucht wurde, die gemeinsame Arbeit zu verbessern und den Administrationsaufwand („sag mir, was ich tun soll“) zu reduzieren. Ein weiterer Teilnehmer stellte die rhetorische Frage, warum sich jemand überhaupt so verstecke: „Die Katze muss am nächsten Tag zum Tierarzt, und das spürt sie.“ Psychologische Sicherheit bei der Arbeit sei wichtig, ein Team entstehe erst bei einem gemeinsamen Ziel. Erst, wenn dieses feststehe, habe es auch Sinn, gemeinsame Ideen zu entwickeln.

Irgendwann zwischen zwei Themen (der Schreiberling war leider gerade in diesem Augenblick wieder mit „Senfen“ beschäftigt und sah nix) ertönte ein begeistertes Hallo aus den Reihen der Teilnehmerschaft, und einer der Gäste, dessen Bild wohl elegant hin- und hergezoomt war, ohne dass er selbst sich sichtbar bewegt hätte, bekannte, dass dies eine neue Kamera sei, die das Bild ein- und auszoomen könne. Dazu hielt er die Hand hoch und machte Fingerzeichen, die die Kamera steuern sollten (ob das ein Witz war, bleibt dem Technik-DAU verschlossen). Kurz darauf rollte ein anderer ehrenwerter Teilnehmer (der zudem bekannt hatte, dass ihm ein Kunde einmal ein Skateboard mit Unterschriften der Kollegen geschenkt habe. Frage aus der Runde: „Wie oft hast du das benutzt?“ – Laut lachend: „Noch nie!“) auf seinem Bürostuhl engagiert nach links und rechts und nach hinten und nach vorne, hin zur integrierten Kamera seines Rechners, machte ebenfalls Fingerzeichen in die Luft und imitierte zur großen Freude der übrigen Gäste den Zoom-Effekt der beschriebenen Kamera.

TRIZ als Tool

Nachdem orthografische Spitzfindigkeiten geklärt waren (es kam zu einem kleinen déja-vù, dass wir ja in einem frühen Lean-Coffee-Termin schon einmal erörtert hatten, woher der Begriff „TRIZ“ stammt), differenzierte ein Teilnehmer, es komme auf den Kontext des Einsatzes von TRIZ an: In eingefahrenen Situationen sei das Tool gut nutzbar, beispielsweise, wenn sich im Team die Sicht verfestigt habe, dass alles Böse nur von außen komme und man intern nichts mehr verbessern könne bzw. wenn ein Zustand der Unzufriedenheit herrsche.

Ein zweiter Teilnehmer empfahl die Osborn-Checkliste (siehe Literaturhinweise weiter unten): Dinge anpassen, größer oder kleiner machen, beobachten. Auch hier spielt wieder das konkrete Ziel der Retrospektive eine wichtige Rolle, als Beispiel „Durchlaufzeit der Tickets halbieren“. Der Teilnehmer bemerkte noch trocken, es sei schwierig, ohne konkretes Ziel etwas verbessern zu wollen: „Hm, ich könnte mal den Dachboden aufräumen…“ (Lachen). Bei TRIZ gehe es darum, kreative Lösungen passend zu einem Ziel zu finden. Erwähnt wurde in diesem Kontext auch die Fragestellung, was man tun müsse, um den kommenden Sprint komplett in den Sand zu setzen. Auf die zweifelnde Frage einer Teilnehmerin, ob da überhaupt etwas Brauchbareres als „Wir machen nix mehr!“ käme, wurde von einer weiteren Teilnehmerin an Vertrauen in das Team appelliert, der vormalige Teilnehmer (Sprint in den Sand setzen) bekannte, dass die Lust an der Zerstörung teilweise sehr witzig sei, er selbst bringe in jeder Retrospektive mindestens eine solche Übung unter: „Bitte macht’s möglichst schnell kaputt/Sorgt dafür, das hier gar nichts mehr geht“, das Ganze kann dann unterfüttert werden mit einer zweiten Runde, z. B.: „Wir gehen nicht mehr ans Telefon.“ – „Wie machen wir das, einfach nicht mehr ans Telefon gehen?“  Die Idee mit dem meisten Zerstörungspotential wird auf diese Weise weiter zerlegt.
Ein weiterer Teilnehmer gab der Runde den Hinweis auf das Tool Azure Devops mit: Dieses sei ein sehr mächtiges Tool, in dem u. a. auch Retrospektiven abgebildet und aus diesen heraus Aufgaben für die verschiedenen Rollen/Personen erstellt werden können. Auf der Hand liegender Vorteil neben den gegebenen Möglichkeiten des Tools selbst: Systemsprünge werden vermieden, „alles ist an einer Stelle“. Allerdings erfordert die Nutzung einige Einarbeitungszeit.

Im Anschluss wie üblich der Bildschirmabdruck mit den eingebrachten Themen und die Hinweise zum Nachlesen aus dem Veranstaltungschat.
Wir freuen uns wieder auf die nächste Runde, denn mit Euch macht die Veranstaltung einfach Spaß!

Literaturtipps:

 

Kommentare

Beliebte Posts aus diesem Blog

Wie starte ich ganz konkret mit einem neuen Scrum Team?

Ich habe den Eindruck, dass manche Agilisten damit überfordert sind, schnell ein Scrum-Team aufzusetzen. Sie haben ein Seminar nach dem anderen besucht und kennen so viele Techniken und Methoden, dass sie am Ende gar nichts davon anwenden. Das war nicht der Sinn des Scrum Guides. Hier ist mein Vorschlag für einen Teamstart.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.