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