Wenn Du Dich regelmäßig in vertrauensvoller Atmosphäre zu Deinen Fragen rund um agiles Arbeiten austauschen und Teil unserer kleinen Community werden möchtest, melde Dich gerne in einer der folgenden Gruppen an, um immer auf dem Laufenden über unsere Termine zu bleiben:
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
An diesem Morgen war Walter A. Shewhart als VIP bei uns zu Gast (für Interessierte: https://de.wikipedia.org/wiki/Walter_A._Shewhart; das "war ein..." im ersten Satz ist demnach natürlich ein Tippfehler...;-)). Wir steigen dieses Mal gleich ein in die besprochenen Themen.
Muss-Ausbildung von POs? Was fehlt ggf. in den Kursen?
Soft Skills werden oft nicht beachtet: Teamgefühl und Zugehörigkeit müssen wahrgenommen und beachtet werden können. Ein PO muss Themen so ins Team bringen können, dass dieses gut damit arbeiten kann. Scrum bekannt zu machen, ist nicht nur Aufgabe des Scrum Masters, sondern auch zum PO gehörig.
Themen adäquat ins Team tragen
Der PO muss z. B. verständlich machen können, warum eine Priorisierung so ist wie sie ist. Häufig wird unterschätzt, dass für einen PO nicht nur nein sagen können wichtig ist, sondern auch die Fähigkeit, die Gründe für das Nein adäquat zu platzieren. Dies zu moderieren, sodass Wert resultiert, ein Werteverständnis ins Team und nach außen zu tragen, das sind Aufgaben eines PO, die in Kursen weitgehend nicht auftauchen.
Empathie kann man nicht immer dazulernen, immer aber Praxiserfahrung sammeln
Einwand: Vorhandene oder nicht vorhandene Empathie ist ureigene Veranlagung, an der eventuell nicht viel gerüttelt werden kann. Es ist wichtig, nach der ersten Ausbildungsstufe in die Praxis zu gehen, dort zu lernen und sich austauschen (Beispiele: product tank, Austausch mit anderen PO, in die Community gehen für seinen speziellen Fachbereich, da Fachaustausch gute fachliche Entscheidungen ermöglicht, advanced POs auf diesem Weg unterstützen,...). Weitere identifizierte Bedarfe für künftige PO-Kurse: OKR, Möglichkeiten der Priorisierung (z. B. MoSCoW), Vermittlung, wie man als PO erkennt, was der Markt wünscht und wie man ein Gespür dafür bekommt. Bei Arbeit in einem stabilen Umfeld (eine Firma, ähnliches Umfeld, z. b. SAP): sich mit der Technologie auseinandersetzen, damit man versteht, was das Team leistet oder was ggf. nicht möglich ist oder zu großen Aufwand bedeutet.
PO als Psychologe/Psychologin, Entwickler:in, Übersetzer:in
Zu beachten ist dabei allerdings: Was logisch ist, ist nicht immer psychologisch (Zitat Vera F. Birkenbihl).
Refactoring und Key Code-Prinzipien sollten bekannt sein, der PO muss diese in seinen Businessbereich übersetzen können und die Prinzipien anschließend auch zum Tem transportieren können.
Ein Produkt hat einen Lebenszyklus, seine Pflege geht während des laufenden Zyklus nie zuende, es wird beständig gewartet. Ein Verständnis darüber ist wichtig, ab wann Refactoting und andere Maßnahmen noch durchgeführt werden sollten. Ebenso ist die Denkweise in deadlines gefährlich, man sollte keinen fixen Termin vor Augen haben.
Unterschied zwischen Internen und Externen?
Hier einige Impulse aus unserer Diskussionsrunde: Externe sind im Zweifel schneller "draußen" als Interne, manche Dinge dürfen aber nur Interne machen. Toleranz, Geduld und Akzeptanz sind unter Menschen auf gleichem Level durchaus gegeben.
Auch Externe sind manchmal Wissensträger:innen ("Die wissen, wie sie an die Information kommen."). Wenn man also wissen möchte, wie etwas geht, kann man seine Externen fragen.
Mit einem Bein immer schon weg
Externe sind - abgesehen von Langläufer-Engagements (einer berichtete von Externen, die über zehn Jahre lang zu ihrem Tagessatz in seinem Unternehmen engagiert gewesen waren) - meist mit einem Bein immer schon weg, stehen häufig im Hintergrund, gehören nie riczig dazu, ob als Freelancer oder in ANÜ. Man sollte die möglicherweise vom "Mainstream" abweichenden Sichtweisen der Externen nutzen, sie haben eine "andere Uhr", gehen Themen anders an, und Interne könnten davon profitieren (Stichwort "unabhängigerer Spirit").
Vergabe der Rollen mit großer Umsicht
Es wird wiederholt gemahnt, dass bestimmte Rollen auf keinen Fall mit Externen besetzt werden sollten, z. b. die Position des PO, als "DNA des Unternehmens", es müsse eine maximale Beschäftigungsdauer eingerichtet werden. Ferner muss sich ein Unternehmen permanent dem Thema Skill-Trasfer widmen - ein mühseliges Geschäft, das nicht gerade dadurch erleichtert wird, dass sich - nach Erfahrung einiger - viele Interne auch hinter den externen Kolleginnen und Kollegen verstecken.
Auslastung vs. Wertgenerierung
Endlich ist dieses Thema einmal durchgekommen (es war schon mehrfach auf der Liste), und die Diskussion dazu war sehr interessant. Zu Beginn sagt jemand, dass maximale Auslastung zwar auch mehr Wert generieren kann, aber nicht zwingenderweise muss. Diese Sicht wird vielmehr infrage gestellt.
Die Frage wird gestelt: "Was meinst du mit Wertgenerierung? Für den Endkunden, fürs Team,...?" Auch hier muss also differenziert werden, wie wir später noch sehen werden.
Beschäftigungstherapie bringt nichts
Die Frage wird erst später mittelbar beantwortet, zunächst sagt jemand, dass Wertgenerierung wichtiger als Auslastung sei. Beschäftungungstherapie bringe nichts, dies würden aber viele machen. Ein Team aber wächst auch mit Erfahrungsgewinn, mit Austausch untereinander etc., all diese Aktivitäten bringen jedoch keinen sichtbaren direkten Output.
Nur eine ständig tippende Ressource ist eine gute Ressource?
Ein erfahrener Teilnehmer, der auch Trainings hält, bestätigt: "Leute haben das Gefühl: Wenn ich nix tue, bin ich kein guter Mitarbeiter. Die Menschen kommen nicht aus dieser Denkweise heraus." Stattdessen gehe es auch um kontinuierliche Verbesserung, Aufräumarbeiten, konzeptuelle Vorarbeit, die Bearbeitung von Abhängigkeiten. "Wenn sich alle zu 100 Prozent auslasten, wird alles langsamer, das klappt nicht." Nicht Auslastung ist das eigentliche Thema, sondern die Erzeugung von Gewinnen durch neue Werte.
Fachliche Auslastung ist nicht alles, es geht auch um menschliche Werte
Jemand ergänzt, dass eine Vollauslastung auch schnell in Überlastung umschlagen kann. Sei eine Auslastung mal nicht für alle Teammitglieder gegeben, solle man Menschen trotzdem im Team lassen (und nicht gleich abziehen?), da sie z. b. ausgleichend auf das Team wirken, das Team insgesamt glücklicher sein lassen, vielleicht eine Quelle der Inspiration für andere sind.
Bei einmal mangelnder fachlicher Auslastung könne sich auch um Themen wie Qualitätssicherung gekümmert werden, jede/r könne eingebunden werden, wenn man sich nicht rein auf "fachliche Auslastung" bezieht. Nach althergebrachtem Verständnis ist "Auslastung" immer sichtbar (jemand aus dem Netzwerk des Schreiberlings zitierte einmal leicht sarkastisch: "Nur ein tippender Entwickler ist ein guter Entwickler."), wie bereits erwähnt, haben unzählige Menschen noch immer das Gefühl, man muss die Aktivität, die "Auslastung", immer von außen sehen. Es kommt die Erinnerung an einen Lean Coffee vor Monaten, in dem es darum ging, dass auch Langweile wichtig ist, dass Pausen dazu führen, dass man wieder auf neue Ideen kommt, dass sich Kreativität gerade in dieser Pause entfalten kann und dass, we ständig unter Strom steht, diesen Raum für Kreativität offenkundig nicht hat. Als Ergänzung berichtet jemand von einer Umfrage des VDI, nach der Produktentwickler häufig keine Zeit haben, um kreativ zu sein. Von diesem Teilnemer ergeht der Appell in unser virtuelles Wohnzimmer, dass, wenn Langweile da ist, man dieses Tor zu Kreativität nutzen sollte. Am Schluss kommt noch der Impuls des "death by jira": Mit diesem Werkzeug kann man zwar die Auslastung von Menschen messen, so die Teilnehmerin, aber den Wert der verrichteten Arbeit leider nicht.
Vorarbeiten während eines Sprints?
Aufgehängt wurde das Thema an einem Team, bestehend aus Frontend- und Backend-Entwickler:innen, die temporär unterschiedlich ausgelastet sind, an Stories arbeiten und immer wieder erleben, dass die eine Fraktion noch zu tun hat, während die andere mit irem Pensum bereits fertig ist und vor Langeweile Däumchen dreht. Um nicht die nächsten Stories, die Backend-Anteile haben, bereits "anzukknabbern", was die teils überausgelasteten Backend-Personen überlasten würde, steht immer wieder die Frage im Raum, ob nicht andere Dinge vorbereitet werden könnten, die in den kommenden Stories benötigt werden, wie z. B. das Design bestimmter Knöpfe.
Ein permanenter Spagat im Team
Eine Teilnehmerin benennt klar, dass das Team aus voneinander weitgehend getrennten Teilgruppen besteht, sie selbst würde versuchen, eine Verbindung herzustellen. Einzelne Teammitglieder könnten vielleicht einmal etwas anderes machen, ggf. auch einmal mit Testen beginnen. Auch wenn man am Anfang länger brauche für eine "Umarbeitung", es ist nach ihrem Dafürhalten besser, wenn jemand etwas vielleicht auch anfangs noch langsam fertigstellt, als wenn diese Person sich etwas neues suchen würde. Ein anderer schlägt vor, dass Teammitglieder sich mit Refactoring beschäftigen könnten. Um das eigentliche Problem, die inhaltliche Trennung der Arbeiten der zwei Teilteams, zu verringern, empfiehlt ein Dritter, man solle die Kapazität des Backend-Teilteams durch Annäherung T-shape-Qualifikation der Teammitglieder zu erhöhen suchen. Wenn diese Trennung permanent auftrete, würde sie jedenfalls zum Flaschenhals.
Zusammenhang zwischen Frontend und Backend und Springer-Pool
Die Frage eines Entwicklungslaien, ob die Frotend- und Backend-Themen denn immer solchermaßen zusammenhingen, oder ob man sie anders aussteuern könne, wird vom Fach abschlägig beantwortet. Es wird von anderer Seite aber vorgeschlagen, einen Pool an Springern einzurichten, Personen also, die in beiden Themengebieten zuhause sind und je nach Bedarf unterstützend entwickeln können.
Grenzen von "t-shaped"
Der Themengeber bekennt, dass alle Teammitglieder bis zu einem gewissen Grad eine t-förmige Qualifikation besitzen, dass dies aber seine Grenzen habe. Auch an anderer Stelle wird bestätigt, dass häufig Frontend-Entwickler:innen gerne nur Frontend-Entwicklung machen möchten, sich quasi bewusst so spezialisiert haben, gleiches gilt für viele Backend-Entwickler:innen.
Vorarbeit birgt viele Gefahren...
Als Quintessensz kommt die Runde zu dem Schluss, dass Vorarbeit gefährlich ist, nicht zuletzt deswegen, weil möglicherweise Dinge, die bereits vorgearbeitet wurden, bei der kommenden Sprintplanung aus welchen Gründen auch immer gecancelt werden und somit Blindleistung erbracht wurde, oder auch, weil Vorarbeiten ggf. Architeturänderungen mit sich bringen, ggf. erst zuendegebracht werden müssen. bevor sinnvoll weitergearbeitet werden kann. Als bessere Alternative werden zusätzlich zu den bereits vorgeschlagenen Maßnahmen wie z. B. Refactoring auch Know-How-Transfer (sehr zeitintensiv!) und Weiterbildung sowie teambildende Maßnahmen vorgeschlagen.
Themen im Überblick
Knappe Literaturhinweise aus der Veranstaltung
https://www.amazon.de/Mustang-Designer-Schmued-Smithsonian-Aviation/dp/1560989947/
Und hier kommt schon die Werbung in eigener Sache (allerdings freundlicherweise eingestellt von jemandem, der besser vorbereitet war als wir selbst): https://www.xing.com/events/design-thinking-workshop-widerstand-agilitat-3827837?cce=em61f5ab16.%3ALov9JKd7CoP8n24P-4szAD
Wir freuen uns auf alle, die am kommenden Dienstagmorgen Fragen, Impulse und Gedanken mit uns teilen und sich dazu mit uns in unserem Zoom-Wohnzimmer treffen möchten! Sei doch auch mit dabei.
Kommentare
Kommentar veröffentlichen