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

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

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.

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.

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.

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

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?

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.

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?