Direkt zum Hauptbereich

Lean Coffee Frankfurt/Karlsruhe, Nachschau zum Termin 63

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

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

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.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

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.

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?

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Welches Motto für den Scrum Day 2025 würde Eure Arbeit am besten unterstützen?

Die Organisator:innen planen den nächsten Scrum Day. Wir wollen bei der nächsten Ausgabe ein paar neue Dinge ausprobieren. Wir haben uns Gedanken zu ein paar Themen gemacht. Welche haben den höchsten Nutzen für die Besucher:innen des Scrum Days 2025? Wir brauchen Feedback.