Sich als Angestellter teil-selbständig machen, aber wie? Frag Deine kleine, feine Community! Wir beantworten auch Fragen rund um die "agilen" Themen, die Dich persönlich beschäftigen. Wir treffen einander sogar wieder im echten Leben in kleinen Runden oder Tandems. Sei Teil dieser Community und melde Dich gerne in Deiner Gruppe an:
https://www.xing.com/communities/groups/lean-coffee-frankfurt-am-main-99d1-1139176/about
https://www.xing.com/communities/groups/lean-coffee-karlsruhe-99d1-1139173/about
Am vergangenen Dienstagmorgen war wieder eine motivierte Runde versammelt, um den Tag gemeinsam zu starten. Wir hatten auch wieder einen neuen Teilnehmer zu Gast, worüber wir uns sehr freuen. Wir denken, dass er wiederkommen könnte, nachdem er sich im Chat gegen Ende der Veranstaltung schon auf unsere nächste Veranstaltung freute...
Als erstes ergeht der Aufruf an die Anwesenden, dass für den kommenden ScrumDay gerne Vorträge eingereicht werden könnten (offizieller Link: siehe Literaturliste am Ende des Artikels)..
Bei Ansicht der ersten Themenkarten auf Scrumlr fällt den schon wacheren Gästen auf, dass nicht alle Themen neu sind, sondern bereits beim letzten Mal eingereicht wurden. Verhaltenes Kichern hier und da, à la „jemand versucht es immer wieder…“. Das macht auch überhaupt nichts, da wir manchmal viele interessante Themen haben und dann eben nicht wissen, aus welchem Sack Hafer wir, bildlich gesprochen, fressen sollen. (Riecht hier jemand den Weihrauch des Eigenlobs?.. Nee, oder?)
Eine Teilnehmerin berichtet, wie es in ihrer Vergangenheit bei Dauerbrennerthemen in Projekten immer genervte Reaktionen gab („nicht schon wieder“), und fragt augenzwinkernd, ob man im Scrumlr-Board bei der Themenwahl auch Minuspunkte vergeben könne.
Handling von QM in Scrum
Ein Teilnehmer zitiert unser aller Abgott Jeff Sutherland, laut dem Scrum dafür sorge, dass man mit der Qualitätsmanagement-Dokumentation arbeiten könne, auf ein vernünftiges Maß komme es an, und in manchen Fällen gehöre die Doku zum Produkt. Er empfiehlt, sich als erstes das Produkt anzusehen und die Rückmeldungen der wichtigsten Stakeholder dazu einzuholen, beispielsweise in einer Bank die Revisionisten. Anschließend gehe es darum, eine definition of done zu finden und Automatisierung zu installieren, um manuelle Fehlerquellen zu eliminieren und alle weiteren Vorteile dieses Vorgehens genießen zu können.
Über gesetzliche Vorgaben und hardening sprints...
Jemand wirft ein, dass gesetzliche Vorgaben eingehalten werden müssten, und zitiert Behörden und Ämter als Beispiele. Nach Releases sorgte in Projekten dieses Teilnehmers ein sogenannter „hardening sprint“ dafür, dass alle Prozessschritte nochmals durchgetestet werden konnten, damit „sich alles setzt“ und letzte Stolpersteine ausgeräumt werden konnten, gerne mit Testautomation getestet. Eine Teilnehmerin berichtet ergänzend, dass sie in ihrem Projekt verschiedene Baustellen hätten, und wenn sie eine davon angingen, sei noch vieles im Fluss, es handele sich um eine „lebende“, sprich, sich noch verändernde Dokumentation. Konfigurationen könnten sich noch schnell ändern, und Tests und Dokumentation würden mit angepasst werden. Erst gegen Ende der Baustelle ginge es an die Integrationstests. Sie fügt hinzu, dass es sich um ein komplexes Produkt handele und die Schnittstellen noch nicht genügend automatisiert seien.
Die Tücken der Testautomation
Eine andere Teilnehmerin berichtet, dass in einem der Projekte, an denen sie mitwirkte, die Einführung einer Testautomatisierung nie statgefunden habe, da das dafür installierte Team fast ein Jahr lang keine Ergebnisse vorzeigen konnte und dass aufgrund keiner ganz akuten Gefährdungslage wie einem direkt vor der Tür stehenden Release dieses Thema von vielen Beteiligten einfach immer weiter in die Zukunft geschoben worden sei.
Spätestens an den Schnittstellen, lässt sich ein erfahrener Teilnehmer hören, hinge es. Als Grund führt er Systemzoos an, die viele Schnittstellen mit sich brächten und damit schnell unendlich viele Variationen von Testfällen, die über Testautomatisierung nur sehr schwierig abzudecken seien. Sie hätten sich damals im Projekt immer nur auf die wahrscheinlichen Fälle konzentriert. (Die Frage ist im Nachhinein nur, ob das überhaupt etwas mit Scrum zu tun hat… - die Red.)
Was tun mit (zu) dominanten Teammitgliedern?
Die Teilnehmerin berichtet von einem neuen Team und einem Mitglied, das bereits als recht dominant in dem Team aufgefallen sei. Es handelt sich um eine externe Person, die nach dem Gefühl der Themengeberin einerseits das Team treibe, im gleichen Atemzug wurde sie aber von einem anderen Teammitglied schon darauf angesprochen, ob es in Scrum denn einen „Teamlead“ gebe.
Einen Gang zurückschalten lassen...
Als Ideen aus der Runde werden genannt: Prüfen, ob es sich beim Teammitglied um einen „Inselwissenden“ handelt, der dann möglichst in einen Know-how-Transfer eingebunden werden sollte, gleichzeitig solle die Leistung der Person wertgeschätzt und deren Motivation zur Mitarbeit natürlich erhalten werden. Die Themengeberin solle das Teammitglied „als Experiment“ einmal einen Gang zurückzuschalten lassen, um anderen im Team eine Chance zu geben. Man könne auch dominante Personen zu Verbündeten machen, mit ihnen Gespräche führen und sie in die Ideen einbinden, wie sich die anderen besser einbringen können, sie fragen, wie man andere einladen könne. Grundsätzlich sei es vorteilhaft, Personen dazu zu bringen, dass sie mehr Fragen stellen.
Lass (im Experiment) doch mal die anderen ran
Ein Teilnehmer ist der Ansicht, man solle transparent machen, dass Person x zu x Prozent im Daily redet, fast immer als erstes in Aktion tritt. Dieser Teilnehmer weiß, dass die Meinungsstarken oft die sind, die auch viel in der Softwareentwicklung tun. Auch hier wird wieder empfohlen, den Wissensaustausch explizit zu fördern. Man könne im Daily verkünden, dass der dominante Mitarbeiter das Problem y jetzt mal nicht löse, die anderen Teammitglieder das Problem lösen müssten, während der Mitarbeiter ihnen lediglich (auf Anfrage?) helfe. Ein guter Kniff sei auch, darauf zu achten, was passiert, wenn diese Person einmal im Urlaub sei, oder man könne sie ggf. auch aus dem Daily „ausladen“, ein Experiment mit ihm als Verbündetem machen, à la: „Ich möchte mal gucken, was das Team macht, wenn du nicht da bist…“
Sicht intern vs. extern / weitere Lösungsansätze
Ein anderer Teilnehmer kommt auf die Kombination „dominant“ und „extern“ zurück und berichtet, dass es in seinem Unternehmen Externe gegeben habe, die aufgrund ihrer jahrzehntelangen (!) Beschäftigung im Unternehmen bereits eine Art Internen-Status besessen hätten, dies sei aber unterm Strich nicht förderlich für das Unternehmen (sofern der Status „extern“ bestehen bleibt), und er denkt laut darüber nach, dass man Externe am besten nicht länger als zwei Jahre am Stück im selben Unternehmen beschäftigen solle (paralleler Kommentar eines anderen aus dem Chat zu den Ausführungen: „Das ist ja wie in der Gastronomie. Dort werden alle paar Jahre die Kellner gekündigt, damit die nicht zu großspurig werden.“).
Weitere hilfreiche Hinweise: Erste Annahme treffen, dass die Person helfen will, ihr aber die Dynamik im Team aufzeigen. Und hier wieder das Thema >mehr Fragen stellen<: Jemand fragt noch, wie denn das Team diese Dominanz empfinde… (als Antwort kommt, dass sie zumindest bei dem Teammitglied, das nach der Existenz eines Teamleads in Scrum gefragt hat, wohl nicht so gut ankommt…)
Agiles Mindset fördern
Ja, auch der Begriff "mindset" ist bereits überstrapaziert und schon verbrannt, trotzdem nutzen wir ihn, weil in unserer Runde, man kann das aus den Beiträgen ablesen, allen einigermaßen klar ist, was damit angeprochen wird. (Ein Kontakt des Artikelschreibers erlitt in einer Online-Veranstaltung ob dieses Begriffs und der mit der Bearbeitung des "agilen mindsets" assoziierten Maßnahmen einmal eine Art Wutattacke und schimpfte sinngemäß "Hände weg von meinem mindset", man solle die Finger von den Köpfen der Menschen lassen.)
Spiele spielen
Ideen aus der Diskussionsrunde: Das Team fragen, warum es agil sein /werden will. Wenn herauskommt, dass nur die Firma es will, nicht unbedingt aber die Protagonisten im Team, ein paar Spiele spielen, z. B. zum Thema Fokus halten – da werde schnell klar, warum man sich fokussieren wolle. Oder: Unabhängig von Agilität fragen, wann Projekte und Zusammenarbeit gut funktioniert hätten, erfragen, was das Ausschlaggebende gewesen sei, und bei den Antworten sei dann in aller Regel viel dabei, was sich in den Kontext Agilität einordnen ließe.
Positive task-force-Erfahrungen ohne den damit einhergehenden Stress wiederholen
Weiterer Vorschlag: Fragen, wann das Team gerne zur Arbeit gekommen sei (häufig höre man dann Geschichten von z. B. einer task force, innerhalb derer ein Team erfolgreich an einem Strang zog. Solche Erfahrungen könne fast jede Organisaton berichten, „da wollen wir hin, aber ohne den Stress, den wir in der Situation dieser speziellen Aufgabe hatten“).
Being agile - Modell-Lernen
Selbst agile Reaktionen zeigen, sozusagen Modelllernen ermöglichen, z. B. auf Verbesserungsideen anderer antworten mit: „Interessant - was brauchst du von mir, um das auszuprobieren?“ Spiele spielen lassen, die Spaß machen, das Verhalten als Scrum Master und damit Förderer des Teams an das jeweilige Setting (z. B. gewisses unveränderbares Korsett für alle Beteiligten) anpassen. Erfahrungen machen lassen, die das Team gemeinsam wieder erleben möchte. Personen aus der klassischen Welt an das Thema heranführen, ohne dieses an die große Glocke zu hängen.
Rückschau der Telnehmer auf geeignete Rückschauen – Projekt-/Release-Retrospektiven
Da dieses Thema schon das dritte von ein und derselben Teilnehmerin ist, wird gewitzelt, sie sei bei Auswahl der Themen offenbar zu dominant, und jemand schlägt scherzhaft ein WIP-Limit für die Teilnehmerin vor. Ein anderer bläst frech in den Raum, neun von zehn Personen hätten kein Problem mit Mobbing, Mobbing lebe vom Mitmachen…
Der erste Teilnehmer mit potentiell ernstzunehmendem Vorschlag wartet, bis er die Aufmerksamkeit der Runde hat, und sagt dann lakonisch (als Antwort darauf, was zu beachten sei): „Möglichst lange warten, nachdem das Projekt zuende ist.“ Ratlose Pause. Eine ganze Weile, dann endlich Lachen. Der Teilnehmer grinst zufrieden – die Groschen sind gefallen.
Klare Fragen mit konkreten Arbeitsaufträgen verbinden
Ein Silberrücken gibt allen den Tipp, dass die Ergebnisse bei Retrospektiven oft ein bisschen dünn seien, und bei einer Release-Retrospektive bestehe zudem die Gefahr, dass man mit der gegebenen Kombination (Kunde, Technik,…) nie wieder zusammenkomme. Es sei besser, klare Fragen zu stellen: wie können wir mit deutlich weniger Fehlern (in %?) produzieren, wie können wir Kosten um den Faktor x reduzieren, wie können wir in der Hälfte der Zeit liefern? Ein konkreter Arbeitsauftrag sollte sich mit der klaren Frage verbinden lassen, sonst hieße es: „Man müsste mal den Dachboden aufräumen…“ „Oh, ja, das ist wirklich wichtig.“, aber keiner kümmere sich dann konkret darum.
Befreiende Strukturen (Liberating Structures)
Der Tipp eines anderen lautet: In breakout-rooms arbeiten lassen. Dem Teilnehmer ist der genaue Name der Liberating Structure entfallen. Er lässt einfach etwas ähnliches in den Raum, und sofort kommt von irgendwoher „one, two, four, all“. Der Teilnehmer grinst breit: „Wenn du was wissen willst, sag es auf jeden Fall falsch, und du wirst korrigiert.“ Man solle Paare aus Team- und Management-Mitgliedern bilden und Ergebnisse vorstellen lassen.
Teamübergreifende Themen, gute Vorbereitung und chronologische Fieberkurve
Weitere Fragmente: Nur teamübergreifende Themen betrachten (Retro in der Größenordnung eines big room plannings) und die relevanten davon festlegen (z. b. Sprintdauer ändern, Aufstocken von Bottleneck-Teams,…), deployment experts aller Teams nach einem Release zu einem Lessons Learned-Workshp/ einer gemeinsamen Retrospektive bitten, Vorbereitung tut not, da die Player häufig kein Gesamtbild haben und sich immer nur punktuell um die Themen kümmern und einige Stakeholder das Setting sowie das Format „Retrospektive“ nicht kennen. Chronologische Fieberkurve erstellen, auf der die Teilnehmenden ihre Ereignisse, „als es richtig gut/schlecht klappte“, markieren - dies seien die wichtigsten Meilensteine für eine Retrospektive.
Es wird noch ein 2-min-Video empfohlen, das man vor der ersten Retrospektive zeigen könne. Interessierte finden den Link in den Literaturhinweisen aus dem Chat.
Was für ein Murcs
Ein witziger Hinweis, der offenbar nicht nur dem Schreiberling dieses Artikels noch nicht aufgefallen ist: Irgendjemand murmelt etwas von Murks… im Chat findet sich der passende Hinweis eines gewitzten Teilnehmers. Dann kommt von irgendwem der klare mündliche Hinweis, dass das Scrum rückwärts sei. (Ja, probiert's ruhig mal aus, das ist die schlimme Wahrheit! 😉)
Zum schönen Schluss bedankt sich ein Teilnehmer, der sich im diesem Jahr als Hybrid zwischen Angestelltem und Freelancer positioniert, bei den Anwesenden, er habe viel Input aus der Community für den Schritt in die Teil-Selbständigkeit erhalten, und wir freuen uns darüber. Handfeste Unterstützung untereinander - so muss das sein!
Übersicht über die eingereichten Themen
Literaturlinks aus der Veranstaltung
https://www.scrum-day.de/call-for-papers.html
Für Doku gibt es ein Buch von Andreas Rüping: https://www.amazon.de/Agile-Documentation-Producing-Lightweigth-Lightweight/dp/0470856173/
https://erfolgreich-projekte-leiten.de/multitasking/
Karen Eilers hat übrigens mal Agiles Mindset wissenschaftlich untersucht: https://iwi.unisg.ch/news/agiles-mindset-nebelkerze-oder-erleuchtung/
https://www.researchgate.net/publication/351099957_Why_the_Agile_Mindset_Matters
https://www.youtube.com/watch?v=MFLvQXMNrO8
https://www.amazon.de/Retrospektiven-Praxis-Ver%C3%A4nderungsprozesse-Unternehmen-begleiten/dp/3864901448/
https://www.xing.com/events/innovation-kreativitat-ideenschutzengel-3763561 (Vorsicht - Lean-Coffee-Eigenwerbung!)
... und nach Verlassen der Sitzung durch die meisten Teilnehmer:innen:
Obsidian: https://obsidian.md/ (Tipp für den eigenen Werkzeugkasten fürs Wissensmanagement)
https://agile-verwaltung.org/2021/06/14/wissen-sammeln/ (als Vorbereitung auf den 25.01.2022, für diejenigen, die mitmachen möchten)
Kommentare
Kommentar veröffentlichen