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
Kommentar veröffentlichen