Direkt zum Hauptbereich

Lean Coffee Frankfurt/Karlsruhe, Nachschau zum Termin 69

Kurz und gut, hier findet Ihr, die Ihr auf der Suche nach Antworten oder weiteren guten Fragen seid, die Links zu Euren potenziellen neuen Lieblingsgruppen:

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 gemeinsamer Morgen beginnt mal wieder aufgeräumt: Ein Teilnehmer hat einen Hinterrund in kühlen Minttönen und mit einem modernen, minimalistischen Interior Design eingestellt, der andere Gäste an eine Arztpraxis erinnert. Es wird gefachsimpelt, ob es sich wohl um eine Zahnarztptaxis handelt, und Insider, die eine andere Diskussion um genau diesen Hintergrund bereits kennen, werfen ein, dass das Bild von Dritten jüngst als Gynäkologiepraxis identifiziert wurde. Kommentare danach in chronologischer Reihenfolge: "Es gibt Ähnlichkeiten, es wird an irgendeinem Körperende gebohrt..." (Lachen), "ja, das ist eine gute Einführung..." (Lachen), "Heute müssen Abstriche beim Niveau gemacht werden." (noch lauteres Lachen). Ein Teilnehmer empört sich scherzhaft, woraufhin eine Teilnehmerin verständnisvoll mit milder, gesenkter Stimme feststellt: "Du stehst doch drauf."

Teilhabe im Team

Fragen zum Thema "Wie seht ihr den value stream?", man kann fragen, wie Teilhabe erlebt wird und wie das Team sie erleben möchte. Assoziationen zu "Teilhabe" aus der Runde: Mitmachen (sich verwirklichen dürfen) oder etwas abbekommen (Geld), Anerkennung und Wertschätzung. Weitere Gedanken: Immer wieder ist Kunden nicht klar, wie sich das Unternehmen oder ein Bereich oder ein Team (...) optimieren kann? "Optimierung" benötigt außerdem einen Bezugspunkt. Teammitglieder sollen selbst bewerten können, ob sie gute oder schlechte Arbeit machen, wenn ein Coach (Scrum Master, Agile Coach) ihre Arbeit bewertet, ist dies nicht aussagekräfig. Kundenaussage: "Das können wir nicht sichtbar machen, unsere Produkte sind zu verzahnt miteinander...", in diesem Fall sollte das Unternehmen wenigstens dazu in der Lage sein, die Kosten insgesamt für einen Bereich darzustellen, um ermitteln zu können, ob der bereich rentabel ist (Bereich kostet das Unternehmen x EUR, spielt dafür aber y EUR wieder ein)

Das Thema mit der Richtung (und den Zielen)

Jemand bricht eine Lanze für Management über Vorbilder: "In welche Richtung wollen wir konkret gehen?" (Anknüpfungspunkte hierzu finden sich auch weiter unten bei den Transcenent Goals!) Für die Frage „Wie gut bin ich?“ könnte man zwischen internen (z. B. "sind wir schneller geworden?") und externen Referenzen (Absatz Konkurrenzprodukte am Markt; Ladezeiten; Anzahl der downloads im App-Store,…) unterscheiden.
Das Thema "Teilhabe" mutierte während der Diskussion ein wenig, aber das störte niemanden.
 

Testen in Scrum Teams (Verlängerung)

Eine Teilnehmerin bringt das Thema mit, da es in ihrem Srtting Tester in den Scrum Teams gibt, obwohl eine Rolle "Tester/in" in Scrum nicht definiert ist. Die Test-Kapazitäten (Personal) sind sehr knapp, eine Person hat gerade gekündigt, eine andere ist bereits am Limit. "Wie läuft es denn, wenn es gut läuft?"

Schwarmintelligenz zum Thema "Testen"

Vorschläge und Meldungen aus der Runde: Scrum verbietet nicht explizit Tester, das Team muss die Tests organisieren, und wenn zu wenig Tester da sind, muss das Team eine andere Lösung finden (eine bewährte Praxis hierbei: jemand anderes als die Person, die den Code geschrieben hat, erstellt den Unit Test). Auch die Umsetzung von BizDevOps (ein buzzword, juchhuu) ist im gesetzten Unternehmen nicht möglich, aber immerhin besteht lt. einer Anregung die Option, dass der Entwickler Grundkenntnisse in Operations haben muss, damit wartbarer Code generiert wird.

Kein/e Tester/in, keine Tests - und da ist ja noch die DoD

Es wird angemerkt, dass die Schwierigkeit von "separaten" Testern gerade in diesem Unternehmen erlebt wird: Fällt der Tester für das Team weg, fallen auch gleich die die Tests weg. (Es wurde natürlich auch gefragt, welche Art von Tests angesprochen ist: Eine eigens dafür abgestellte Person würde z. B. nicht Code von Entwicklern testen). Der Hinweis ergeht, dass Testen zur Definition of Done gehört. Jemand berichtet, in einem seiner Unternehmen seien eigene Testpersonen in den teams gewesen, die aus den Fachbereichen kamen und die ensprechenden Prozesse kannten, um das Team autonom/cross-funktional zu machen. Auf die aufkommende Frage, wie weit getestet wird, antwortet das Plenum, dass dies in der DoD stünde und dass mögliche Erweiterungen dieser in einer Retrospektive behandelt werden könnten.

Information hiding als hidden setting

Erst am Schluss der Diskussion tritt ein verborgenes Problem zutage: Der (verbliebene?) Tester schreibt z. B. keine Testpläne, ist überfordert, sitzt aber auf seinem Wissen und teilt dieses nicht. Jemand ruft frech, aber nachvollziehbareweise "Feuern!" rein, allein: Die genannte Person steht kurz vor der Rente und wird nach Überzeugung der themengebenden Person auch nicht mehr freigesetzt werden. 

WIP-Limit und Engelszungen

Ein anderer in der Runde berichtet von einem ähnlich gelagerten Fall, bei dem man es mit einem WIP-Limit für die beteiligte überlastete Person versuchte, weiterhin mit Vier-Augen-Gesprächen und dem Appell, die Person solle andere begleiten, da sie der Experte sei, und den anderen zeigen, wie sie diese Arbeiten übernehmen könnten. Man habe mit Engelszungen geredet, allerdings ohne Erfolg. Dies führte dann dazu, dass u. a. der Gast, der uns diesen Fall schildert, das damalige Projekt verließ (während die andere Person natürlich drinblieb...).
Ein anderer aus der Runde schlägt vor, das Team zu fragen, ob man ein Thema nur auf einer Person abladen wolle. Das Team werde sicher eine Meinung dazu haben und, so vertraut dieser Teilnehmer, auch eine Lösung finden.

Transcendent Goals

Zunächst ist eine Begriffsklärung notwendig. Einige sehen, übertragen gesprochen, ratlos nach links und rechts, der Themengeber erklärt, dass mit "transzendent" gemeint ist, dass ein Arbeitsergebnis über die Erwartung an das Team hinausgeht. Was bedeutet das aber konkret?

Einfache Ziele, normale Ziele, transzendente Ziele

Eine Teilnehmerin vermutet, dass die Grundvoraussetzung für diese Art von Zielen in Teams wahrscheinlich fehle, sie kenne kaum Teams, die auch nur ein sauber definiertes Sprintziel hätten, was es aber ihrem Verständnis nach brauche, um ein transcendent goal "draufsetzen" zu können (der Themengeber stimmt ihr zu).
Wir bekommen aus der Runde ein Beispiel für ein solches Ziel. Henry Ford wollte nie nur Autos bauen und/oder den Reichen ein neues Spielzeug an die Hand geben - sein Ziel war, autos so günstig zu machen, dass auch Bauern sich eines leisten und damit in die Stadt fahren können, es handelte sich also um ein gesellschaftiches Ziel. Auch Sakichi Toyoda habe mit seinen Webstühlen mehr erreichen wollen als nur den Bau einer Maschine, er habe das Ziel gehabt, für seine Gesellschaft etwas zu tun und für sie einen Fortschritt zu erzielen.

Die tiefere Bedeutung dessen, was wir (im Arbeitskontext) tun

Bei "Transcendent goals" geht es darum, nicht nur vordergründig einen Auftrag umzusetzen: Diese Ziele gehen darüber hinaus. Der Sinn des Entwickelten soll erfasst und gedanklich auf die Weise weiterentwickelt werden, dass das Entwickelte das damit verfolgte Ziel tatsächlich und besser umsetzt, es geht um die tiefere Bedeutung dessen, was wir tun.
Zurückkehrend zu Ford bemerkt jemand, zur Verbildlichung könne vielleicht gesagt werden, dass eine Brücke „(Was bedeutet) Mobilität“ zwischen dem Auftrag „Reichen das Spielzeg geben“ und „günstige Mobilität für alle“ geschlagen werden muss.

Richtung, Improvement Kata, Hingabe für Produkt und Team

Weitere Fragen und Stichworte aus dem Plenum: Wo fangen die transzendenten Ziele an?; das Thema hat mit dem Aspekt "Improvement Kata" zu tun: Kann ich mich an die Organisation koppeln? Gelingt die Kopplung der eigenen und der Unternehmensziele? (verdeutlichendes Beispiel: Waffenentwicklung); es geht darum, dass etwas Richtung gibt und nicht nur "larifari" ist (nach der Erkenntnis des Teilnehmers mit diesem Beitrag seien die meisten Unternehmen immer noch "larifari") es geht um Hingabe für das Produkt und/oder das Team; man sollte sich und andere fragen: "Wofür machen wir das hier eigentlich?" An dieser stelle wird in der Runde die Vermutung geäußert, dass wahrscheinlich meist nichts kommt, was ein Gast aus eigener Erfahrung bestätigt. Eines seiner Teams habe geantwortet, das sei ihnen zu kompliziert...

Und es gibt sie, Firmen mit transzendenten Zielen

Es gebe aber auch Firmen, die sich an einem solchen Nordstern, einem transzendenten Ziel ausrichten, die z. B. aus dem, was sie erreichen wollen, auch für sich selbst unbequeme Konsequenzen zögen, die auch ihre Lieferanten entsprechend diesen Zielen auswählten, Risiken eingingen und teils sogar aus Überzeugung ihr Business riskierten, so wird im Plenum berichtet. Als Exempel dieser Art von Firmen wird fritz cola genannt. (Hierzu gibt es keinen Link in den Literaturhinweisen, geneigte Leser:innen mögen bitte selbst nach geeigneten Quellen recherchieren.)

Themen im Überblick

Literaturhinweise

Vortrag über ein Jahrhundert Scrum bei der LATC22: https://leanbase.de/onlineacademy/lernmodule/uber-ein-jahrhundert-scrum-aus-der-ideengeschichte 

Erklärvideos bei der Leanbase über Lean-Persönlichkeiten: https://leanbase.de/onlineacademy/lernmodule?category=7

Scrum Day: https://www.scrum-day.de/home.html

Beispiele für DoDs: https://www.scrum.org/resources/blog/done-understanding-definition-done

https://www.youtube.com/watch?v=dTvvMhiWGeo

https://www.scruminc.com/scrum-team/#:~:text=Transcendent%3A%20They%20have%20a%20sense,what%20they're%20capable%20of

Danke für einen guten Dienstagmorgen, es hat uns wieder viel Spaß gemacht, und mit dem Thema "transcendent goals", das erst langsam anlief und dann immer facettenreicher diskutiert wurde, haben wir auch schon wieder einen Aspiranten für einen der nächsten Lean Coffe-Spezialtermine am Abend (Referent wurde gleich im Termin klargemacht).

An alle, die noch nie dabeiwaren: Kommt doch dienstagmorgens einfach mal selbst bei uns vorbei und macht mit! Damit habt Ihr auch die Möglichkeit, direkt Anregungen für abendliche Spezialveranstaltungen zu geben. :-) Wir probieren gerne Dinge aus und haben für Eure Ideen nicht nur ein offenes Ohr, sondern setzen sie auch um.


Kommentare

Beliebte Posts aus diesem Blog

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.

Selbstbewertungsfragen für den Alltag in Arbeitsgruppen aus Sicht von Mitarbeitenden

Welche Fragen können wir Mitarbeiter:innen stellen, um herauszufinden, ob agiles Arbeiten wirkt? Es gibt bereits eine Menge an Fragebögen. Aber ich bin nicht immer zufrieden damit.

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Microsoft Lists: mit Forms und Power Apps komfortabel mobil arbeiten

In meinem Kundenkreis sind viele Menschen, die den Arbeitsalltag nicht vorwiegend auf dem Bürostuhl sitzend verbringen, sondern "draußen" unterwegs sind. Vielleicht in Werkstätten oder im Facility-Management. Es ist so wichtig, dass die Schnittstellen zu den Abläufen im Büro gut abgestimmt sind. Microsoft 365 hat so einiges im Baukasten, man muss es nur finden und nutzen.  In diesem Artikel spiele ich ein Szenario durch, das auf Microsoft Lists, Forms und - für die Ambitionierteren - Power Apps setzt.

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.

Wie Agilität den Kundennutzen steigert - Einige Argumente für Berater:innen

In Zeiten wirtschaftlicher Unsicherheit fragen sich viele, ob agile Beratung noch eine Zukunft hat. Die Antwort liegt in der konsequenten Orientierung am Kundennutzen. Qualität setzt sich durch, wenn sie messbare Verbesserungen bei Umsatz, Kosten und Leistungsfähigkeit bewirkt, anstatt sich in Methoden und zirkulären Fragen zu verlieren. Dieser Artikel zeigt, wie agile Beratung nachhaltige Veränderungen in Unternehmen schafft und warum gerade jetzt gute Berater:innen gebraucht werden, um Organisationen widerstandsfähiger zu machen.

Warum eine Agile Transformation keine Reise ist

Die agile Transformation wird oft als eine Reise beschrieben. Doch dieser Vergleich kann viele Unternehmen in die Irre führen oder Bilder von unpassenden Vergleichen erzeugen. Transformationen sind keine linearen Prozesse mit einem klaren Ziel, sondern komplexe und dynamische Entwicklungen. Dieser Artikel zeigt, warum Agilität kein Weg mit einem festen Endpunkt ist.

Warum bringen Warum-Fragen so wenig?

Frust! Wieder gibt's am Ende des Meetings keine Lösungen, sondern nur Diskussionen darüber, wer was warum verbockt hat. Wieder geht nichts voran. Warum passiert uns das immer wieder? (Ha! Da ist sie wieder, die Warum-Frage.)