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

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.

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.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Leitlinien-Werkstatt für Microsoft-Teams

Mittlerweile hat Microsoft Teams in sehr vielen Unternehmen einen Platz gefunden. Es bedient den Wunsch nach schneller Kommunikation und gemeinsamer Datei-Bearbeitung. Und spart damit Zeit und unnötige Prozessschleifen. Oder? 

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Die Krankheit des Besser-Wissens! Drei powervolle Fragetechniken und eine Haltung zur Heilung.

Kennst Du das: Du betrittst einen Raum und bist Teil einer Situation, hörst eine Problembeschreibung, siehst eine Aufgabe oder liest eine Anfrage. Auf jeden Fall weisst Du mit einem Blick, einem Satz, einem Augenzwinkern sofort Bescheid. Du weisst: um was es geht was das Problem ist wieso das passiert ist was als Nächstes passiert und oft auch was dann (nicht) zu tun ist So wie mit dem Video hier: Ziemlich klar oder? Was für Gedanken gehen Dir durch den Kopf? Vielleicht sowas wie Oh weh!, Unfall!,  gibts Verletzte?  Oder Gehts denen gut? Wo ist das passiert? Viel Spass beim Flottmachen! Etc, etc... Auf jeden Fall aber: Was für ein Malheur! - oder irgend etwas Anderes in der Art. oder? Anderes Beispiel. Schau Dir mal folgendes Bild an und les im Geiste die beiden Reihen vor: A-B-C 12-13-14 oder? Unser Geist beruft sich auf sein Wissen und gibt uns in sekundenschnelle seine Annahme, seine Interpretation, seine Projektion der Wirklichkeit ein. Und die ist in dem Video oben nunmal ein ve

Nur was sichtbar ist, kann gemanagt werden

Ihr steckt fest? Langsam wird’s brenzlig? Ihr wisst nicht so recht, was tun? Kleiner Tipp: Nur was sichtbar ist, kann gemanagt werden.