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

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.

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.

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.

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.

Raus! Aus! Dem! Stress! Die Burnout-Uhr

Menschen geraten oft in Stress und in Schieflage, weil sie überengagiert sind. Wie kommt das? Was ist zu tun, um das zu verhindern? Was, um in einer guten professionellen, gesunden und leistungsfördernden Verfassung zu bleiben? 

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.

Wie geht es nach einem Scrum-Training weiter?

Scrum-Trainings können eine Menge Energie und Hoffnung freisetzen. Einige Menschen sagen auch schnell: „Ich verstehe, was mit Scrum gemeint ist. Aber ich weiß nicht, wie ich das in dieser Organisation umsetzen kann.“ Vielleicht ist das der falsche Anspruch. Ich gebe meist eine andere Antwort.

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.