Den Blick weiten wie das Team in unseren Themen "Einführung von Scrum in kleinem Entwicklungsteam" und "Inhalte von Stakeholdern im Review" - mit der Teilnahme an unseren Lean Coffees kannst Du das tun. Melde Dich gerne in Deinen zukünftigen Lieblingsgruppen an, um mitzudiskutieren und immer auf dem neuesten Stand der Gruppen zu sein:
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
Bester Zeitpunkt für Rollenwechsel
Ein Teilnehmer nutzt den Lean Coffee heute dafür, wozu er noch häufiger genutzt werden könnte: als Austauschforum auch für eigene Themen, als Community, die der einzelnen Person mit ihren Ideen und Anregungen hilft. Es geht um Fragestellungen des Jobwechsels, und neben eigenen bereits verfolgten Ansätzen werden folgende Impulse gegeben: die Frage (zum Selbst-Beantworten), was einen an aktuellem Job/Firma/persönlichem Arbeitsumfeld stört, sich Menschen suchen, die unerbittlich nachfragen ("Was hast du davon? Welches sind deine Präferenzen? Wieso möchtest du das [nicht]?"...), möglichst genau analysieren, wie die neue Position sein soll, und hinterfragen, welches die eigene Motivation ist, damit man nicht nach dem Wechsel wieder in eine Position gelangt, die einem nicht gefällt. Dabei helfen kann zusätzlich, Eindrücke von verschiedenen Personen zu sammeln und auch den eigenen Marktwert zu erfragen (Stärkung des Selbstvertrauens und realistische Einschätzung der eigenen Position). Wir kommen angesichts der aktuellen Erfahrung und Position des Gastes zu der Einschätzung, dass er nichts zu verlieren hat, wenn er sich auf neues Terrain wagt.
Was ist an SAFe so schlimm?
Der Gast, der dieses Thema einbringt, möchte eine wertfreie Diskussion anstoßen - wahrscheinlich aus Erfahrung mit uns, denn das Thema wurde zuvor schon teilweise durch den Kakao gezogen. An dieser Stelle jedenfalls dankeschön für das Zurverfügungstellen dieses Themas und die größtenteils sachliche Diskussion dazu!
Das ist alles nur geklaut
Erster Beitrag: "98% sind geklaut, abgeschrieben, nicht gekennzeichnet. Das Ganze wird teuer gekauft, zusammengemixt und teilweise ach noch falsch abgeschrieben." Es handele sich um ein blaupausenartiges Vermarktungselement, das sich der Trivialisierung bediene. Der Gast redet sich ein wenig in Rage, das Fragment "... wie die Borg alles totmachen..." fällt, und der Teilnehmer bekundet, er sei jetzt still, sonst komme er in den Berserkermodus. Ein anderer Gast kichert und schlägt vor: "Der agile Derwisch". Heiterkeit macht sich kurz breit, obwohl das Thema natürlich sehr ernst ist. ;-)
Der Weg von oben nach unten ist geklärt...
Es wird als positives Merkmal dargestellt, dass mit SAFe der Weg von "oben" (die Geschäftsführung hat Geld für eine Initiative) nach "unten" (Das Team hat etwas zu tun) geklärt sei. Leider aber werde die bestehende Komplexität lediglich durch eine andere ersetzt, anstatt Komplexität zu reduzieren. Es wird auch erwähnt, dass es Menschen, die in SAFe-Initiativen arbeiten, überwiegend nicht gut gehe. Woran kann das aber liegen?
Gekonntes Abspecken - das kann fast niemand
Hinweise aus der Runde: Man kann nie alles umsetzen, da es zu viel ist, man muss also immer einen Zuschnitt vornehmen, wenn man aber keine Ahnung hat, wie das geschehen soll, sucht man in der Regel das heraus, das den eigenen bekannten Strukturen am nächsten ist. Das Unternehmen hat zu diesem Zeitpunkt häufig noch keine Ahnung, wie der zuschnitt gemacht werden sollte. "Man muss voraussehen können, was passiert, wenn man etwas weglässt." Dieses Wissen besitzen diejenigen, die den Zuschnitt vornehmen (oder die dabei beraten) aber offenbar häufig nicht.
Fehlendes Change Management und falsche Sicherheit
Den Unternehmen wird beim Verkauf von SAFe weiterhin überwiegend
suggeriert, dass sie sich nicht grundlegend ändern müssten. Somit
bleiben sie prinzipiell in der klassischen Welt verhaftet. SAFe, so ein anderer, suggeriere falsche Sichereit, deswegen gingen Initiativen "in die Hose".
Man solle sich, so ein anderer Hinweis, die Value Streams genau ansehen (wo wird welches Geld hineingesteckt, welches Geld kommt wo heraus?). In der Implementierungsphase sollte ferner gut abgewogen bzw. geprüft werden, ob man auch wirklich den Rückhalt des Seniormanagements hat.
Über SAFe-Zertifizierungen
Jemand bringt das Thema der SAFe-Zertifizierung als Gelddruckmaschine auf: Früher habe es 100 Dollar im Jahr gekostet, um die Gültigkeit der Zertifizierung zu erhalten, inzwischen seien es 300 Dollar, was eine Frechheit sei. Es kommt heraus, dass auch andere in der Diskussionsrunde eine SAFe-Zertifizierung besitzen, und ein Silberrücken fragt in einem stillen Moment frech in den Raum: "Ja, wieso sind denn der X und der Y so blöd, sich zertifizieren zu lassen?" (Namen der Redaktion bekannt) In unserem Zoom-Wohnzimmer wird gelacht.
Neu-Einführung Scrum in kleinem Entwicklungsteam
Es wird seitens der Runde danach gefragt, ob die Einheit schon XP durchführt, wenn ja, könne man daran anknüpfen. Ähnliches gelte für Refactoring, ferner: sich ansehen, wo man einen Prozess vereinfachen könnte. Im fraglichen Unternemen gibt es bereits ein Produktmanagement, aber noch keinen PO.
Gibt es keinen PO, dann bastele dir einen
Dem Themengeber feht noch jemand, der im fachlichen Thema unterstützt und als Sparringspartner fungieren kann. Empfehlung: mit Menschen aus dem Produktmanagement Austausch-Termine vereinbaren und diese Personen als Stakeholder mit ins Boot holen. Offen im Unternehmen ansprechen, dass eine Person gesucht wird, die die eigenen Entscheidungen hinterfragt und fachlich herausfordert, und fragen, wen diese Aufgabe interessieren würde.
Sicher ist sich jemand anderes, dass es taktisch unklug wäre, sofort mit der Ankündigung "Jetzt machen wir Scrum!" ins Haus zu fallen, gerade als neuer Mitarbeiter. Vielleicht könnte das Unternehmen derartiges bereits ausprobiert und sich bewusst dagegen entschieden haben können.
Lieferfähigkeit eines Teams
Alternative: Fragen stellen, wie das Team liefert. Wie erhält das Team Feedback für das Ausgelieferte? Oft sei dies gar nicht geklärt, z. b. auch nicht, wer unbedingt mitsprechen müsse. Beim fachlicen Thema des Themengebers wird laut der Runde besonders häufig Feedback benötigt, es handele sich um kein technisches Thema, sondern darum, über schnelle Experimente Prozesse umzugestalten. Hierfür müsse der Ausliefermechanismus gut funktionieren, damit man Ideen umsetzen könne und auch wissen könne, ob sich diese auszahlen (werden). Wichtig, so dieser Gast, sei es, sich immer wieder das Mandat zu holen, wenn immer wieder auf den Auslieferungsprozess gesehen werde. Hinterher könne man offenbaren, dass das, was man gemeinsam getan hat, Scrum war. "Scrum ist eine Feedback-Maschine", daher gehe es darum, dieses Feedback gut zu organisieren.
Aufgaben, Ziele und Ansätze bei Unklarheit
Ein erfahrener Teilnehmer fragt, welches die genaue Aufgabe des Themengebers sei, an welchen Ergebnissen er sich messen lassen müsse, welches seine Ziele seien. Der Themengeber antwortet darauf, und ein anderer empfiehlt, für Fälle, in denen auch auf diese Fragen noch keine konkreten Antworten gefunden werden können, Statik aus Kanban einzusetzen, um die aktuell größten Schmerzpunkte in der Arbeit zu finden und zu analysieren, wo somit möglichst schnell etwas spürbar verbessert werden könne. Er empfiehlt generell eine ergebnisoffene und methodisch nicht festgelegte Herangehensweise.
Inhalte von Stakeholdern in Reviews
Wenn ein Team - im Beispiel in der IT-Branche - etwas ausliefert, handelt es sich nicht nur um ein Stück Software, sondern um einen ganzen Kontext um dieses Stück Software herum, der mitbetrachtet werden muss. Die Themengeberin führt aus, dass es sich ggf. um einen weiterentwickelten Kontext handele, dass ggf. Themen aus einem vormals irrelevanten Kontext plötzlich relevant geworden sein könnten, die Konkurrenz etwas Neues entwickelt haben könnte, etc. pp.
Die Themengeberin möchte wissen, ob es in den von den übrigen Teilnehmern besuchten bzw. durchgeführten Reviews derartige Aktualisierungen von Stakeholderseite an das Team gebe.
Betrachtung des Gesamtkontextes eines Stückes Software
Ein erfahrener Gast berichtet, dass in seinen Umfeldern die POs Reviews mit Blick auf den Gesamtkontext eröffnen, statt punktuell und abgegrenzt in einzelnen JIRA-Aufgaben zu stochern. Mögliche Aussagen könnten z. B. sein: "Wir wollten xyz erreichen, die Entscheidung abc ist gefallen/noch offen", man solle sich auch gemeinsam Termine ansehen und prüfen, ob und in wieweit diese noch Bestand haben. Auf diese Weise entstünde ein Zwang, über den Kontext nachzudenken und das Ausgelieferte in einem größeren Zusammenhang zu sehen. Indem Entwickler Rückmeldungen von externen Stakeholdern erhalten, können sie potentiell auch Auftrieb für ihre Arbeit erhalten, indem etwa gewürdigt wird, dass sie etwas in einem sehr kurzen Zeitraum auf die Beine gestellt haben.
Wer sind eigentlich meine Stakeholder?
Ein anderer Gast spricht von Zombie-Scrum und von der Erfahrung, dass viele Teams ihre Stakeholder gar nicht kennten. Wenn es keine Stakeholder gebe, lautet eine Idee von ihm, solle man stattdessen potentielle Stakeholder aus derselben Zielgruppe herbeiholen, einladen und einbinden. Mit Entwicklern könne man eine "Stakeholder-Safari" machen, d. h. ihren Blick weiten und von der häufig beobachteten reinen Begeisterung für Technik loslösen.
Wie kann sich das Team an die Konsument:innen des Produktes heranpirschen?
Die Themengeberin möchte wissen, wie man es schafft, den PO so "zu treten", dass nicht nur Auftraggeber:innen im Review sitzen, sondern auch die Konsument:innen des Produkts eingeladen werden und ihr Feedback geben. Dazu antwortet jemand, dass in seinem Umfeld mit hauptsächlich internen Projekten die Fachbereichskolleg:innen bereits mit in den Teams gewesen seien, was die Arbeit für POs erleichtert habe.
Vertrauen zwischen PO und Scrum Master / Stakeholdermap
Ein anderer Gast empfiehlt, zunächst das Arbeitsverhältnis zu verbessern: Wenn man einen PO bei der Arbeit spürbar unterstütze, werde er/sie einem auch zuhören. Fragen im Hinblick auf ein Review zu Beginn eines Projektes stammen aus einer zu erstellenden Stakeholdermap: Welche Stakeholder können das Projekt fördern/behindern? Was wollen wir als Team von diesen Stakeholdern, was wollen sie von uns? Wen muss man "zufällig auf dem Parkplatz" treffen, um mit ihm/ihr zu sprechen? Um den Blick auf das Große zu wahren, kann ein Team zu Beginn der Woche beispielsweise seine Stakeholdermap durchgehen.
Frei nach Bugs Bunny:
Das Publikum war heute wieder wundervoll
und traurig klingt der Schlussakkord in Moll.
Wir sagen dankeschön und auf Wiederseh' n
schaut Ihr bald wieder rein, denn etwas Show muss sein...
Themen im Überblick
Scrumlr hatte heute offensichtlich Bauchschmerzen, denn die Themen wurden aus unerfindlichen Gründen nicht nach Stimmenanzahl vorsortiert...
Literaturempfehlungen des Tages
How to land a space shuttle: https://www.youtube.com/watch?v=Jb4prVsXkZU
https://www.xing.com/events/lean-coffee-karlsruhe-offline-9-4013297
Die agilen Borg = SAFe … https://medium.com/serious-scrum/safe-is-like-the-borg-2f2048e7f504
SAFe = Infantilisierung des Managements: https://thecynefin.co/safe-the-infantilism-of-management/
Ken Schwaber: unSAFe at any speed, https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/
Maarten Dalmijn: Scaled Agile Framework (SAFe): when you don’t have the guts to do Scrum, https://medium.com/serious-scrum/scaled-agile-framework-safe-when-you-dont-have-the-guts-to-do-scrum-528f7b5643f2
Jeff Gothelf: SAFE ist not Agile, https://jeffgothelf.com/blog/safe-is-not-agile/
Blogbeitrag: Wie starte ich ganz konkret mit einem neuen Scrum Team: https://www.teamworkblog.de/2021/09/wie-starte-ich-ganz-konkret-mit-einem.html
https://hjavixcs.medium.com/statik-systems-thinking-approach-to-introduce-kanban-13996dbe414a
Kommentare
Kommentar veröffentlichen