Direkt zum Hauptbereich

Lean Coffee Karlsruhe/Frankfurt, Nachschau zum Termin 74

Wie man die besten Betonschuhe und Arbeit von rechts nach links in Einklang bringt und wie man gegebener Komplexität begegnen sollte (eigentlich die Sache mit dem Elefanten in Scheiben, Ihr wisst schon...).

Dies und noch viel mehr erfährst Du in unseren Lean Coffees, Anmeldung zu unseren Gruppen hier:

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

 
Unser heutiges Lean Coffee-Treffen steht ganz unter dem Einfluss mafiöser Strukturen. Wir bekommen einen Bericht von Luigi, dem Macher der besten Betonschuhe weit und breit, und einige kichern schon - offenbar haben sie noch kein Schuhwerk von ihm erhalten. Sofort gehen die Spekulationen los, wem man "Luigi" empfehlen könnte/sollte...
 

Erfahrung mit Product Backlog-Unterstützung als Scrum Master (Verlängerung)

Die Themengeberin hat keinen konkreten Fall und keine eigene Erfahrung in diesem Bereich, möchte aber gerne wissen, wie andere sich diesem Thema nähern. Im Geiste hat man ggf. die Berichte von unerfahrenen POs, die weit ausladende Product Backlogs ohne erkennbare Struktur (und ggf. mit lückenhafter Priorisierung) entweder selbst erstellt oder von Vorgänger:innen übernommen haben und nun nicht wissen, wie sie damit arbeiten sollen, sich im guten Fall mit flehentlichem Blick an den Scrum Master wenden, damit diese Person das "Impediment" beseitigen helfe.

Wozu das ganze Produkt?

Ein Silberrücken grinst schelmisch, wir wissen schon, dass gleich eine Revoluzzer-Bemerkung kommen wird: "Den PO auswechseln." (Etwa zeitgleicher Kommentar im Chat: "Wird der PO noch gebraucht? Igor. Nicht mehr gebraucht? Luigi.") Hier nun die übrigen Empfehlungen aus dem heutigen Lean Coffee: Zuerst ein klares Bild über den Business Value schaffen (bereits bei dieser Aufgabe straucheln lt. dem impulsgeber bereits einige), den PO seine Produktvision überarbeiten lassen. Ein Backlog auf Sicht hilft, PO und Team sollten gemeinsam an den User Stories arbeiten.

Schatten der Vergangenheit und Vertrauen

Das Vertrauen zum Scrum Master ist hilfreich, wenn der PO (meist ein Rollenträger mit einer gewissen Fachkarriere) "die Hosen runterlassen" und um Hilfe bitten soll. Man sole in einen Dialog auf Augenhöhe einsteigen und gemeinsam (PO und SCM) das Backlog durchgehen.

Ein Bild, das Wichtigste und User Story Mapping

Jemand bemerkt, dass man ja auch prüfen könne, ob es sich tatsächlich um ein Backlog oder um eine "Wunschliste" handelt. Als sehr hilfreich habe sich erwiesen, auf einem Bild klar zu machen, welche Zusammenhänge bestehen, was das Produkt erfolgreich macht, welches seine wichtigsten Features sind. Wenn das Team weiß, welches die wichtigsten Aufgaben sind, die es erledigen muss, kann es damit zu den Stakeholdern gehen. Auch ein User Story Mapping kann angewendet werden. Danach lässt sich auch häufig eine Priorisierung (besser) vornehmen.

Komplexität als Herausforderung: Microservices und/oder Produkt-Splitting?

Eine interessante Diskussion entspinnt sich an einem geschilderten Setting eines Riesenproduktes, bei dem mindestens 80% der Anforderungen hätten umgesetzt werden müssten, damit das Produkt stabil arbeiten und die grundsätzlichen Anforderungen erfüllen konnte. Allein die Bearbeitung der relevanten Prozesse, die für das Produkt nötig seien, erlaube es nicht, ein schlankes MVP auf den Markt zu bringen. Jemand erwidert, er kenne ehrere Kunden, die z. B. global SAP-Systeme einführen wollten. Es müssten erst die Grundlagen geschaffen werden, um das Produkt umsetzen zu können. Häufig verschanzten sich Personen hinter dem Argument der Komplexität, tatsächlich gehe es aber darum, einen Weg zu finden, um mit einer gegebenen Komplexität umzugehen, andernfalls ergehe es einem wie den beschriebenen Kunden, diese nämlich "... haben sich ins Knie geschossen", sie seien für Jahre unbeweglich geworden und hätten zudem viel Geld für externe Beratung ausgegeben. (Kommentar im Chat etwa zu dieser Zeit: "Luigi macht auch Hausbesuche." ;-)) Möglichkeiten des Umgangs wären beispielsweise eine Umsetzung über Microservices oder eine sinnvolle Splittung des Produktes. Als Beispiel für eine solche Arbeitsweise wird SpaceX genannt (siehe a. Literaturhinweise).

Das Ganze vom finalen Produktbild aus aufrollen

Jemand empfiehlt, sich (prozessual gesehen) "von rechts nach links" dem Thema zu nähern. Ganz rechts steht das Produkt mit der Überschrift, für wen es gebaut wurde, was diese Zielgruppe damit tun möchte, welches Problem also mit dem Produkt gelöst werden soll. Nach Erfahrung dieses Gastes helfe dieses Aufrollen von rechts nach links und die damit einhergehende klarere Sicht bereits signifikant dabei, dass das Team von alleine Unnötiges auszufiltern beginne.

Agiles Requirement Engineering

Einige Unterschiede zwischen klassischem und agilem Anforderungsmanagement werden zunächst herausgearbeitet: "agil" bedeutet Transparenz im Umfeld, ständiges Verhandeln bzw. permanenten Dialog, Entscheidungen unter Berücksichtigung verschiedener Sichten nach teamübergreifender Priorisierung, zügigere Umsetzung bei Anforderungsänderungen. Ein Gast fasst einen tieferliegenden Aspekt bei letzterem gut zusammen: Im klassischen Umfeld sind keine Änderungen während der Umsetzung erwünscht, im Gegensatz zum agilen Arbeiten, wo sie willkommen sind und man aus diesen Änderungen zügig lernen und Verbesserungen daraus ableiten möchte. Auch hier kommt während des Austauschs die Empfehlung, von rechts nach links zu arbeiten, denn dann könne z. B. erkannt werden, wenn Anforderungen nicht ausreichend ausgearbeitet sind. Weiterer Unterschied: Im klassischen Umfeld finden wir Silos, im agilen Umfeld sind die Teams komplett eingebunden.

Weg von der extremen Konzentration auf Tools, selektiverer Einsatz von Werkzeugen

Erst dann fragt jemand aufmerksam, was das „Engineering“ in Requirement Engineering denn sei? Das, was bisher besprochen wurde, sei doch eher Requirement Management als "Engineering". (Anforderungsanalyse vs. Anforderungsmanagement, siehe z. B. dict.cc - die Red.) Die Runde stimmt murmelnd zu. Ein anderer hebt die Diskussion wieder auf eine gemeinsame Grudlage: "Was wollen wir erreichen?" Ein gleiches Verständnis der Anforderung solle erreicht werden, und dabei seien bereits in der Diskussion erwähnte "klassische" Diagramme Gold wert (z. B. ein Domänenmodell). Diese Techniken sollten nach der Empfehlng dieses agilen Silberrückens nur selektiver eingesetzt werden, früher sei man häufig mehr mit den Modellen als mit der eigentlichen Arbeit beschäftigt gewesen. 

Nachweispflichten für Features und Dokumentationsmöglichkeiten

Als Themen am Rand von Anforderungsbehandlung streifen wir noch die Tatsache, dass einige Unternehmen verpflichtet seien, nachzuweisen, wo ein Feature herkomme (z. b. im Produkt "Herzschrittmacher"). Hierfür würden Tools wie "DOORS", wo diese Anforderungen dokumentiert werden können. Unterstützend kann auch infrastructure as a code eingesetzt werden. "Je mehr im Code dokumentiert sei, umso schneller sei alles nachvollziehbar. Der Gast würde auch Dokumentation dort (in DOORS?) platzieren. (Wir erörterten nicht, auf welche Art dies gescehen könne.). "Wenn wir Systeme entkoppeln, z. B. über Continuous Delivery-Techniken, können wir schneller ausprobieren." (Sehe dazu auch die Literaturhinweise.)

(Vertrauens-)Probleme im Team


Das Setting ist wie folgt: Ein Team entwickelt einfach weiter vor sich hin, fragt nicht mehr so richtig beim PO nach. Man möchte auch nicht nachfragen - weil man sich nicht traut oder ggf. nicht abgewatscht werden möchte, so die Vermutung. Der PO nimmt seine Rolle nicht so wahr wie er es sollte (siehe dezenter Hinweis auf "Business-Chef"-Verhalten). Was tun?

In welchem Umfeld bewegen wir uns?

Ein findiger Gast mit Coaching-Hintergrund und Blick auf die gesamte Organisation fragt danach, was von oben vorgelebt wird. Wie verhalten sich die Führungskräfte? Das Team ist kein eigenes des Themengebers, aber die Vermutung lautet, dass es sich um eine klassische hierarchische Unternehmung handelt, die erste Projekte in Richtung Agilität  auf den Weg gebracht hat - vermuteterweise, weil es als "cool" gesehen wird, die Unternehmung verstehe aber sehr wahrscheinlich nicht, was diese Umstellung wirklich bedeutet.

Ansätze aus dem Publikum

Weitere Vorschläge: Den  PO im 1:1-Gespräch interviewen und nac seiner Sicht fragen, wie die Zusammenarbeit funktioniere, ihn auch fragen, welches sein Verständnis von Agilität sei und was er sich mit bestimmten Handlungen/Verhaltensweisen für Ergebnisse verspreche, dann einzelne Teammitglieder im 1:1 sprechen und versuchen, sich ein Bild vzu erschaffen. Wenn kein Mandat vorhanden sei und/oder die Geschäftsführung die Besetzung bestimme und dabei bleibe, auch wenn sich der Kandidat als wirklich unpassend erweise, dann würde es schwierig. Wegen des "klassischen" Umfelds solle man berücksichtigen, dass Personen mit Sicherheit Angst haben, sich zu öffnen.

Liberating Structures, Hoffnung und viel Geduld

Ein anderer Gast berichtet von einem Team, in dem die PO zwar wusste, dass etwas nicht rund läuft, aber nicht, wie sie aus der Situation herauskommen sollte. Hier wurde mit Liberating Structures gearbeitet, mit kleinen Häppchen angefagen. Die Maßnahmen trugen über Monate hinweg erst Frühte. Die beteiligten Personen waren vorgeprägft und gewöhnt, "alles vorgekaut zu kriegen", sie mussten in einem mühevollen Prozess umlernen und Vertrauen darin aufbauen, dass sie für ihre Entscheidungen nicht abgestraft werden.

Es muss immer noch geliefert werden...

Ein erfahrener Gast wendet ein, dass man in manchen Situationen (z. B. in Wirtschaftsunternehmen mit einer gewissen time to market und einem Wettbewerbsdruck) nicht warten könne. Wenn es keine Lieferfähigkeit gebe, müsse man die Situation transparent machen und zeigen, dass z. B. ein PO keine Ergebnisse aus dem Team erhält oder selbst keine erzeugt. "Wenn der PO nicht spurt, finde ich es legitim, dass das Team meutert." Aus seinen Coachings von Führungskräften erhielt der Teilnehmer wertvolle Einblicke.

Die Überforderung der Führungskräfte (und die fehlende Geduld)

Führungskräfte seien häufig überfordert. Eine typische Situation: Die Führungskraft hat Freiheiten gegeben, aber "es kam nichts dabei heraus", sodass bei der Führungskraft der dringende Eindruck entsteht, doch "wieder die Zügel anziehen" zu müssen. Ggf. wurde hier einfach einmal das Falsche ausprobiert, vermutet der Gast. (Passender Kommentar aus dem Chat: “frei nach B. Brecht: Das Volk hat das Vertrauen der Regierung verscherzt. Wäre es da nicht doch einfacher, die Regierung löste das Volk auf und wählte ein anderes?”)

Gemeinsame Regeln - wenn es noch etwas zu regeln gibt

Ein anderer Gast berichtet, er habe in einem Team einmal ein Canvas durcharbeiten lassen, um ein gemeinsames Regelwerk vom Team für das Team zu erstellen. Dies funktioniere aber nur, "wenn der Zug noch nicht abgefahren" sei. Sei jemand bereits "verbrannt", habe es keinen Sinn mehr, mit den einzelnen Beteiligten zu sprechen.

Fehlendes Mandat des PO

Am Rande wird noch tiefer gegraben, gegen Ende der Diskussion fragt eine Teinehmerin, welchen Auftrag der PO denn in seiner Unternehmung überhaupt habe. Hierauf gibt es keine offizielle Information, die Runde hegt aber die Vermutung, dass die beschriebene Person gar nicht das Mandat als PO hat (ein leider nahezu klassisches Setting in klassischen Unternehmen, die sich sogenannte "Proxy-POs" leisten - die Red.).

Verwendung von Planungstools

Jemand sagt, dass er früher gerne "Zettel an die Wand geklebt" habe. Jetzt, da dies seit geraumer Zeit nicht mehr machbar sei, nutze er ein Whiteboard. "Meine Präferenz: simpel;." Man könne erstaunlich viel damit machen.
Zum Denken seien Whiteboards immer gut, wirft ein anderer ein, sie sollten aber zwischendurch immer wieder einmal weggeworfen werden.

No oder low code

Er bevorzuge no-code- oder low-code-Anwendungen, meint der Teilnehmer, z. b. Airtable. Hier könne man z. B. eine Datenbank mit einem Webfrontend bedienen, Verknüpfungen je nach Zweck selbst erstellen und seine Anwendung mit sinnvollen Automatisierungen versehen (etwa "Wenn x passiert, dann automatisch Eintrag in Datenbank Y.") Es wird aus der Diskussionsrunde heraus bekräftigt, dass man in einem komplexen Arbeitsumfeld nicht auch noch komplexe Software bedienen müssen sollte. Als Beispiel nennt ein Gast Planview als Pflichtsoftware in einem seiner Projekte. Für die Erstellung eines Statusberichtes habe er jeden Monat aufs Neue die Dokumentation lesen müssen, weil er nicht mehr gewusst habe, wie die Software zu bedienen ist.

Die Klassiker und der ganze übrige Anwendungszoo

Andere erwähnen Confluence und JIRA, für Retrospektven ein einfaches Tool wie z. B. Metro Retro oder für kleine(re) Projekte Trello als abgespeckte Version von JIRA. Weitere Impulse: Notion (Mehrfachnennung), für den Fokus auf Initiativen die Software ProdPad, last but not least Asana. Jemand bemerkt noch, dass es immer schwierig sei, wenn man in seinem Arbeitsumfeld einen "Anwendungszoo" habe und beispielsweise für benötigte Information in einer Reihe von verschiedenen Tools suchen müsse. in solchen Fällen sei ein initiales und übergreifendes Konzept hilfreich.


Eingereichte Themen im Ãœberblick



Aufmerksame Betrachter:innen stellen vielleicht fest, dass eine Diskussion über das Thema "Teammitglied lästert und droht" hier überhaupt nicht auftaucht - die themengebende Person musste unser schönes Beisammensein leider spontan vorzeitig verlassen, weswegen wir zugunsten der nachfolgenden Themen umdisponierten.

Literaturhinweise

The software stack – from monolith to microservices: https://stackoverflow.blog/2021/05/13/building-the-software-that-helps-build-spacex/

Agiles Requirements Engineering https://t2informatik.de/blog/softwareentwicklung/agiles-requirements-engineering/ 

https://dpunkt.de/produkt/right-to-left/

Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation: https://www.amazon.de/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/

Get started with Jupyter Notebooks in less than 4 minutes: https://www.youtube.com/watch?v=h1sAzPojKMg 

https://www.airtable.com/

https://seatable.io/

https://www.prodpad.com/

https://inopai.com/page/

https://metroretro.io/ (nicht aus der Veranstaltung, nachgetragen - die Red.)

https://de.wikipedia.org/wiki/DOORS (nicht aus der Veranstaltung, nachgetragen - die Red.)


Wer gerne bei der nächsten "mafiösen" Gesprächsrunde dabeisein möchte, ist herzlich zu uns eingeladen. Wir beißen nicht (jedenfalls dienstags nicht) und freuen uns über Interessierte mit frischen Ideen und neuen Impulsen für unsere vertraute Runde.

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 . 

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.

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.

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.

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?

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.

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? 

"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.

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.