Direkt zum Hauptbereich

Lean Coffee Karlsruhe/Frankfurt, Nachschau zum Termin 62

Wer sich in geselliger (noch) kleiner Runde am Dienstagmorgen über Themen rund um agiles Arbeiten (und beiläufig auch manchmal den ganzen Rest) austauschen möchte, kann sich gerne in einer unserer Gruppen anmelden, um stets auf dem Laufenden über unsere Regelevents und abendlichen Spezialtermine 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

Die abendlichen Veranstaltungen sind übrigens fast immer Resultat aus Themen, die in einem morgendlichen Lean Coffee mit besonderem Interesse diskutiert wurden - auch hier haben unsere Gäste also Mitgestaltungsfreiräume.

 


Technische Schulden

Insbesondere wird über die Haltung von Führungskräften gegenüber dieser speziellen Art von Verpflichtung gesprochen, da der Verdacht im Raum steht, dass das mittlere Management diesen Aspekt gerne lediglich "verwaltet" (lapidare Ansagen à la: "Ach ja, irgendwann müssen wir's halt mal zurückzahlen...") und auch das obere Management den Ernst der Lage nicht erkennt ("... müssen bilanziert werden... müssen wir uns mal drum kümmern, wenn wir Zeit haben...").

Produkt auf technischem Sand gebaut

Ein Gast mit offenkundigem Entwicklungshintergrund beschreibt das Setting sehr treffend und eindringlich: "Die Geschwindigkeit zu liefern wird damit mittelfristig gemindert. Unübersichtliche Programmierung mit Abkürzungen und falschen Aspekten führt dazu, dass sich neue Entwickler:innen nicht trauen, etwas am Code zu ändern." Die Software/Architektur sei dann wie ein Gebäude, bei dem das Fundament immer noch wacklig ist. Eine weitere Schwierigkeit, die man gerne vergisst: Man vergisst auch mit der Zeit, was das eigentliche Problem war, wenn die technischen Schulden stets mitgeschleift werden...

Die Definition von "Wert"

Jemand erwähnt einen anderen Lean Coffee, bei dem gefragt wurde, ob ein Product Backlog Item auch einmal keinen Wert haben darf (etwa, weil technische Schulden abgebaut werden). Antwort aus der Runde: "Wenn man technische Schulden abarbeitet, hat das einen Wert." Globaler betrachtet, kommt es auch darauf an, wie man "Wert" definiert. (Man denke an die Diskussionen, dass Bugs keine Story Points erhalten sollten, da sie lediglich eine schlechte Entwicklung umkehren, aber nicht eigenen zusätzlichen Wert generieren; diese Diskussion wurde hier aber nicht geführt - die Red.) Im Chat hinterlegt ein stillerer Teilnehmer den Hinweis: " 5 S auf die Softwareentwicklung übertragen - wirkt technischen Schulden entgegen. Wenn man es regelmäßig macht"

Von Zeitpunkt und Sinn technischer Schulden

Ein Silberrücken unter den Gästen wirft ein, dass bestimmte Maßnahmen tote Invests seien, Code, der zwar noch eingebaut werde, sich nach einiger Zeit aber als überflüssig erweise, weil beispielsweise ein Standard diese Funktionalitäten in einer neueren Version irgendwann liefert. Der Teilnehmer erinnert uns daran, dass Software nicht ewig lebt, er habe es in seinem Konzern selten erlebt, dass Applikationen 15 Jahre oder älter wurden. Man müsse prüfen, ab wann sich ein Invest in technische Schulden überhaupt noch lohnt, und hinterfragen, ob manche technischen Schulden überhaupt noch etwas bringen, etwa mehr Verträge oder eine höhere Marge.

Zeitlicher Bumerang und Klassifizierungsmöglichkeiten

Ein anderer Gast bekundet, dass in vielen Fällen die Haltung bestehe "Es geht ja erst mal gut!" (= "wir schaffen erst mal das nächste Release"), der zu erwartende Knall, beispielsweise zwei Jahre später (die aufmerksame Leserschaft nimmt wahr, dass auch hier die technischen Schulden offenkundig lange nicht bereinigt werden), würde dabei aber verdrängt.
Technische Schulden, als weiterer interessanter Blickwinkel aus der Diskussionsrunde, sind auch nicht kalkulierbar, aber diese Tatsache bleibt wohl bisher nur schwerlich im Bewusstsein der Beteiligten haften. Es fällt der plastische Ausdruck von Software, die "verrottet", durch technische Schulden immer langsamer und schlechter wird. Die interessante Frage einer Gästin, ob es für Nicht-Entwickler:innen eine (Risiko-)Klassifizierung von technischen Schulden gebe, konnte nicht beatwortet werden.

Arbeitet der PO strategisch oder koordinativ? (Verlängerung)

In den meisten Situationen im realen Leben arbeiten POs nach der Erfahrung der versammelten Teilnehmenden eher koordinativ. Es sei die Frage, ob die POs das volle Mandat über das Produkt hätten, und selbst dann, wenn man äußerlich befugt sei, strategische Entscheidungen zu treffen, bliebe immer noch die Frage, ob man als PO eine "strategische Marionette" im Unternehmen sei (der berühmte und geschmähte "Proxy-PO", der nur Entscheidungen trifft, die gewissen Personen im Unternehmen in den Kram passen).

Der PO nur als Übersetzungsmaschine?

Der PO ist (auch) für den Wissenstransfer von Kunde/Stakeholdern zum Entwicklungsteam zuständig ("Übersetzungsarbeit"), er müsse auch Kundenfragen beantworten können. Ohne Strategie gehe es in dieser Rolle nicht, so eine Teilnehmerin.
Jemand echauffiert sich ein wenig, wofür man denn einen PO habe. "Fürs Händchenhalten brauche ich ihn nicht, der Fokus besteht darin, business value zu schaffen. Das ist seine Hauptaufgabe." Wenn der PO frisch einsteige, so eine Teilnehmerin (mit eigenem PO-Hintergrund), fange dieser in der Regel allerdings nicht mit hochstrategischen Arbeiten an. Eine Schwierigkeit bestehe weiterhin darin, dass es in vielen Unternehmen an Leadership-Kenntnis mangele.

Mit dem Pfund des PO wuchten

Ein wirklicher PO mit vollem Mandat, so die obige Teilnehmerin eindringlich, sei "ein großes Pfund", man wolle so jemanden haben und entwickeln. Ein Proxy-PO wird in der Runde nur als Schuld-Übernehmer im Unternehmen identifiziert. Am Rande, um die Wertigkeit der Arbeit eines "echten" PO zu unterstreichen, kommt die Frage aus einem länger vergangenen Lean Coffee wieder auf, in dem diskutiert wurde, welches Gehalt eines POs würdig wäre, denn es war im damaligen Termin die Aussage aufgetaucht, dass die POs unserer Welt eigentlich alle gnadenlos unterbezahlt wären. In jenem Lean Coffee, so erinnern sich dunkel Teilnehmende, wurde von Wissenden von einem niedrigen sechsstelligen Jahressalär als eigentlich angemessen gesprochen (ja, auch solche interessanten Themen kommen hier auf, danach können einige ggf. direkt in Gehaltsverhandlungen mit ihrem Unternehmen einsteigen; die Quellen sind noch bekannt und können für Details bei Bedarf angezapft werden).

PO-Erfahrungslevel vs. Kanban Maturity Model

Zur Frage, was einen Junior-, Normal- und Senior-PO voneinander unterscheide, wirft jemand ein, dass ein wahrer PO ein Unternehmer im Unternehmen sei, der sein Produkt profitabel leite. Ein anderer ist von diesem Modell (wahsch. Scrum-Framework - die Red.) genervt, weil es so personenbezogen sei. Das Kanban-Maturity-Modell dagegen mache alles an der Organisation selbst fest statt an Rollen/Personen. In Unternehmen eines hohen Reifegrades denken danach alle Mitarbeiter:innen strategisch mit, nicht nur die Personen, die explizit als "Strateg:innen" ausgewiesen sind.

Was macht einen guten PO aus?

Und hier haben wir gleich den fließenden Übergang zum vorausgegangenen Thema, das schon intensiv diskutiert wurde. Der Einfachheit halber verwenden wir hier die männliche Form, auch wenn natürlich auch Frauen als PO arbeiten. (Dieser Umstand ist wahrscheinlich dem - im Englischen vermutlich genus-freien - Ursprungswort geschuldet: Product OwnER -> viele Wörter, die im Deutschen auf -er enden, sind männlich, z. B. der ManagER, der VerkäufER etc.) Nach diesem sprachlichen Exkurs wieder zurück zur Sache.

Was muss ein PO alles können?

Auszüge: Der PO muss strategisch denken (Einwand eines Teilnehmers, siehe auch oben: "Es müssen alle strategisch denken!"). Er muss visionär sein. Muss ein PO auch sales-versiert sein? Man ist sich einig, dass Menschen in dieser Rolle gut kommunizieren können müssen, da ihre Position viel Abstimmung zwischen Stakeholdern und Team mit sich bringt. POs benötigen ein tiefes Produktverständnis, auch Regularien bzw. gesetzliche Anforderungen gehören dazu, damit der Rahmen der Produktentwicklung adäquat abgesteckt werden kann. Der PO, so die Erfahrung einer Teilnehmerin, muss das Produkt kennen, "Wenn nicht der PO das Produkt kennt, wer dann?", jedoch nicht die nötige Entwicklung im Detail, denn dafür gibt es Expert:innen im Development-Team. Jemand anderes bekräftigt, dass es die Glaubwürdigkeit und das Vertrauen in diese Rolle schmälert, wenn die ausfüllende Person beispielsweise die Basisdaten des Produkts nicht kennt.

Der PO als Integrator

Als PO muss man zwar sicherstellen, dass man das Produkt gut verkaufen kann, man kann aber nicht alle Wissensgebiete selbst vollumfänglich abdecken (Produktkenntnis, Entwicklung, Marketing, Sales, Jura,...) En PO kann nicht alles gleichzeitig bieten, sollte aber in der Lage dazu sein, alles Wissen zusammenzuführen.

Virtuell vs. physisch - wie veganes Rührei

Während der Themensammlung kam das Thema "Frühstück" auf und die Frage, wie man mit Essensresten umgehe. Der Kommentar, älteres Essen z. B. noch durch ein gekleppertes Ei zu adeln (alles in die Pfanne, nicht roh), inspirierte die Themengeberin offensichtlich zu ihrer Formulierung, die kurz danach auf dem Scrumlr-Board erschien. Zur Erklärung: Es handelt sich hier um Berliner Flair. - Ja, wir haben inzwischen ganz schön Reichweite! - In Berlin, so die Themengeberin, gebe es ein veganes Rührei.

Fofu-Matsch mit Schwefelsalz und die Analogie...

Es handele sich dabei um eine Art Tofu-Matsch, gewürzt mit einem Schwefelsalz, das komisch rieche, sowie Kräutern (und ggf. weiteren Zutaten, die der Schreiberling vergessen hat - die Red.).
Analogiebildung: Das vegane Rührei ist ein Produkt wie virtuelle Meetings - man versucht, Sachen nachzuahmen, die es im physischen Bereich gibt, dies gelingt aber nicht richtig. Analogiesprung zurück: Wenn man das vegane Rührei schmecke, denke man etwas wie, "ja, man kann's essen", sei dann aber doch leicht enttäuscht.

Was passiert zum kalendarischen Frühlingsbeginn?

Das Datum 20.03.2022 wird in den Zoom-Raum gestellt, gemeinsam mit der Frage, wie es sein könnte, wenn wir zu Hybrid-Veranstaltungen und wieder Treffen vor Ort schwenken. "Soll man sich überlegen, welche Vorteile es im virtuellen Raum gibt?" bzw. "Sollte man nicht mal etwas voranbringen, anstatt zu heulen, dass Präsenz gerade nicht geht?"
Ein sehr richtiger und wichtiger Einwurf lautet, dass wir alle mit Präsenz unseren schönen Lean Coffee um 8 Uhr morgens nie schaffen würden, zumal wir in verschiedenen Städten ansässig sind. Da es im Lean Coffee auch bereits wieder Präsenzveranstaltungen gibt, könnte man sich aus beiden Varianten einen Mix bauen, "die Formate sind unterschiedlich."

Durchgängig online - nein, danke. Aber ab und zu

Manche schätzen inzwischen auch online, obwohl das persönliche Gespräch nach wie vor durch nichts wirklich zu ersetzen ist. Online ohne Reisezeit sei eine Chance, so jemand, und virtuelles Arbeiten sei laut einem anderen die einzige Chance gegen den Verkehrsinfarkt und weitere Klimaschädigung (siehe hierzu die Literaturliste unten mit dem passenden Eigenwerbungs-Beitrag im Chat), was durch eine teilnehmerin bestätigt wird, die ein geringeres Schmutzwäsche-Aufkommen durch verringerte Schmutzpartikelmenge in ihrer Stadt hat.

Anpassung an "online": Gute Moderation tut not

Guter Impuls aus dem Chat: Für Online-Veranstaltungen ist es vonnöten, gut in diesem Umfeld moderieren zu lernen (auch hier sind selbstverständlich Anpassungen notwendig; jede/r kennt diese Notwendigkeit z. B. durch Versuche, manche Übungen, die im realen Leben wunderbar klappen, in die Online-Welt zu übersetzen).

Zusammenfassung

Jemand findet ein schönes Schlusswort: Es tut sich etwas in der Online-Welt, aber es dauert noch, bis sich durchgesetzt hat, wo es Vorteile gibt und wo z. B. etwas online nur ein künstlich aufgeblähes Produkt ist, das Zusammenarbeit nur suggeriert. Die guten Praktiken werden sich noch herauskristallisieren.


Themenüberblick

 

 

(Übersichtliche) Literaturliste

https://agile-verwaltung.org/2021/04/15/die-10-prinzipien-der-kaizen-philosophie/

(Herzhafter Begleitkommentar: "Ich greife da ja immer zum Tacker und nagele die 10 Kaizen Prinzipien auf die Stirn der Manager. Hilft auch)

https://de.wikipedia.org/wiki/5S (NICHT aus der Veranstaltung, Hintergrundinformation der Red. für das im Chat erwähnte 5s)

https://de.wikipedia.org/wiki/Technische_Schulden (NICHT aus der Veranstaltung, erste Recherche der Red. zur Klassifikation technischer Schulden im Anschluss an die Veranstaltung, wenig Information: SonarQube dient immerhin der Errechnung des Aufwands für den Abbau technischer Schulden, siehe Quelle Fußnote 10)

https://www.xing.com/events/fr-agile-earth-action-sammen-scrummen-1-5-grad-3723813 oder https://www.linkedin.com/events/fr-agileearthaction-z-sammenscr6872284808505040896/about/ (das ist die Eigenwerbung...)


Danksagung

So machen es doch auch Autor:innen und Illustrator:innen auf den ersten Seiten ihres Produktes... wir machen es sozusagen ganz unten, am Fuß der letzten (und einzigen) Seite:

Danke, dass Ihr da wart, es hat wieder Spaß gemacht, und besonders freuen wir uns über noch Neue, aber schon "Wiederholungstäter:innen", die unserer gemeinsamen Gruppe frischen Wind in die Segel pusten.



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.