Direkt zum Hauptbereich

Lean Coffee Frankfurt/Karlsruhe, Nachschau zum Termin 79

Wir sind eine kleine, feine und natürlich für alle neuen Gäste offene Community - wir sind Menschen von nebenan, die sich untereinander austauschen und vertrauensvoll jede Frage stellen, die ihnen zu Themen rund um Agilität im Allgemeinen oder Individuellen unter den Nägeln brennt.

Komm doch gerne auch einmal dazu und vergiss den Kaffee nicht: Wir treffen uns dienstags um acht Uhr (morgens! ;-)). Hier sind unsere Joint-Venture-Gruppen, über die Du immer auf dem neuesten Stand unserer Veranstaltungen bleibst:

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


Keine Stakeholder im Review...

Stellt Euch vor, Ihr arbeitet in einem Team, das ein Produkt herstellt, und im Review sitzen keine Stakeholder, Ihr starrt Eure Kolleg:innen oder die Wand gegenüber an... wie kann es zu dieser Situation kommen? Die Diskussionsrunde bringt folgende Ideen auf: "Man hat das Gefühl, einen roten Teppich ausrollen zu müssen, immer muss es eine Extraeinladung geben, obwohl es sich um einen Regeltermin handelt", "Die Stakeholder sollten das einfordern und vor der Tür stehen, im eigenen Interesse das Inkrement ausprobieren wollen", "Was ist die Aufgabe eines Stakeholders? Ich würde als erstes die Rolle schärfen, reingehen und forschen, ob der Stakeholder um seine Aufgabe weiß", "Es kann schwierig sein, an Stakeholder heranzukommen, denn es ist in großen Unternehmen nicht Usus, den Teams zu helfen: Alle sind unter Wasser, man muss sich gezielt überlegen, wer sinnvolles Feedback geben kann".

Welches Feedback, und von wem, und wie vorbereiten?

Diese Rückmeldungen könnten z. B. benötigt werden, weil es z. b. unterschiedliche Ideen darüber gibt, wie das Produkt weiterentwickelt werden kann, entsprechend muss ein Review gut vom PO vorbereitet werden. Jemand wirft ein, dass die Stakeholder, wenn gut in diese Richtung "erzogen", idealerweise irgendwann (nach 2 Jahren, so der Kommentar) von alleine kommen.

Ist es (noch) das richtige Produkt?

Ein Gast mokiert sich, dass manchmal auch nach einer gewissen Zeit immer noch niemand da ist, noch nicht einmal das Management. Er habe es daraufhin einmal gewagt und gefragt, ob das Team (noch) das richtige Produkt entwickle, woraufhin es einen großen Aufschrei gegeben habe. Nach Sicht dieses Teilnehmers tritt das Problem des minderbestückten Reviews häufig dann auf, wenn der Endabnehmer, den das Produkt wirklich interessiert, vom umsetzenden Team weit entfernt ist.
 

Weche Fragen sollten gestellt und beantwortet werden?

Eine Teilnehmerin, in mehreren agilen Rollen zuhause, ruft uns gute Imulse aus einem just vorausgegangenen Lean Coffee ins Gedächtnis, man solle sich fragen, was z. B. passieren muss, damit man als Team nicht nacharbeiten muss: "Ich brauche jemanden, der mir den Kontext erzählt, der berichtet, was gerade auf dem Markt los ist, was die Konkurrenz tut, wie sich die aktuelle Situation im Unternehmen darstellt usw.". Nach ihrer Sicht schadet es nicht, klar zu machen, dass eine Einladung zu einem Review bedeutet: „Hier hast du was zu schaffen“, und dass, wenn das im Review nicht passiert, "ein Haufen Geld in den Gully geht".

Anzahl progressiver Führungskräfte steigern (Verlängerung)

In Anlehnung an die auf dem diesjährigen Scrum-Day von Bob Emiliani gehaltene Keynote bringt ein erfahrener Teilnehmer das Thema auf, dass kreative Ideen benötigt würden, damit mehr progressive Scrum Master, POs, Lean Supervisors etc. ausgebildet werden könnten, um damit wiederum zu erreichen, was auch das Motto des diesjährigen Scrum-Days war: "Moving the Scrum Downfield". Die Diskussionsrunde wird nach ihren Gedanken dazu befragt. 

Command & control, Autoselektion und Abstimmung mit den Füßen

Unsere Ideen: Oft wird in Zeiten von Stress nach Command & Control gerufen, Menschen verfallen dann wieder in diesen Mechanismus, wir dagegen benötigen Personen, die "nein" sagen und uns bewusst machen, wenn gerade wieder versucht wird, etwas über den alten Mechanismus "Kontrolle" zu steuern. Jemand ergänzt, dass im Rahmen des sogenannten Autoselektionsprozesses immer die Art von Menschen eingestellt wird, die man bereits kennt. Erfahrung eines Teilnehmers: Gute Leute gehen weg, wenn die falschen Köpfe und Strukturen schon da sind, denn beides kann man nicht so schnell auswechseln. Ein Gast schlägt vor, sich im Unternehmen zu fragen, warum ggf. ein progressives Vorgehen dort nicht funktioniert, und wie man dagegen vorgehen könnte. Dieser Ansatz wirke nur lokal, lasse sich nicht potenzieren, es sei aber ein Anfang. Eine Teilnehmerin wirft ein, dass bereits heute mit den Füßen abgestimmt werde und gute Leute häufig ihre Unternehmen verließen, die Frage sei aber, wohin sie gingen. Am Rande wird noch erwähnt, dass viele gar nicht erst ins Managment einer Firma möchten, da der Umgang miteinander in diesen Ebenen alles andere als schön sei.

Neue Firmen mit "gewünschten" Strukturen müssen her

Eine andere Teilnehmerin kommt dabei auf die Idee, dass man flächendeckend "andere" Firmen, die nach ihrer Erfahrung bisher eher ein Nischendasein fristeten, gründen könnte, damit diejenigen, die aufgrund fehlender Flexibilität und nicht erfüllten eigenen Wünschen von agilen Prinzipien bei der Arbeit von ihren Firmen weggehen,auch irgendwohin gehen können. Die Firmen könnten dann mit der zeit zu Konzernen anwachsen, in denen die gewünschten Prinzipien etwas gelten. Ein anderer Gast beschreibt die in seinem Unternehmen bereits geltende Praxis, als Unternehmen darauf zu achten, was die Menschen brauchen, und ihnen ein höchstmögliches Maß an Flexibilität bei ihrer Arbeit zu bieten.

Paradebeispiel "Freiwillige Feuerwehr" und wieder Bauhof Herrenberg

Jemand berichtet, dass freiwillige Feuerwehren bereits nach agilen Prinzipien der Selbstorganisation und fehlender ausgeübter Hierarchie funktionierten, man könne einmal zugucken, wie die arbeiteten. Es gebe dort "kein Geschrei, keine Kommandohierarchie", der Job in der Berufsfeuerwehr sei eher bescheiden bezahlt, bei der freiwilligen Feuerwehr beruhe er sogar auf Ehrenamt mit vielen abgeleisteten Stunden. "Die machen irgendwas richtig", so das Fazit. Auch der Bauhof Herrenberg, der schon einmal Thema im Lean Coffee war, wird ins Spiel gebracht, es gebe dort lauter Initiativbewerbungen, obwohl auch hier die Arbeit "mies bezahlt" sei, wie generell bei Bauhöfen. Die machen also auch etwas richtig, wird in unserer Runde schlussgefolgert. Als Führungsebene muss man Veränderungen lostreten und auch konsequent mittragen, wird von jemandem herausgestellt. ("Der Fisch..." und so weiter.) Am Rande darf man sich auch einmal nach der eigenen Definition von "Management" fragen. (Sicherlich stellt sich hierbei ebenfalls heraus, dass es ganz und gar kein einheitliches Verständnis darüber gibt - Spekulation der Red., kein Beitrag in der Diskussion.)

Alternativen zu SAFe (Verlängerung)

Fast hätten wir für obiges Thema noch eine zweite Verlängerung anberaumen können, wenn man von den noch vorhandenen Handmeldungen ausgeht. Aber es muss gerecht zugehen, und ein bisschen Prozess schadet nicht. Eröffnungsbemerkung des Themas: "Wenn wir es geschickt anstellen, können wir das Thema von eben hier weiterdiskutieren..."

Was brauchen wir, um Unternehmen zu "agilisieren"?

Ideen aus dem Plenum: "Wir brauchen kleine crossfunktionale Teams; wenn etwas nicht im Kleinen funktioniert, kannst du den Überbau darüber auch vergessen, sprich, wenn etwas nicht im Kleinen funktioniert, geht’s erst recht nicht im Großen", was benötigt wird, sei Scrum of scrums, EATs (Executive ction Teams), "Value streams sind auch noch cool..."

Ohne Spezialisten keine sinnvolle Struktur

Was bei der Diskussion in SAFe auffiele, sei, dass alles gleichzeitig gemacht werden solle, Unternehmen ihre Arbeitsweise nicht ändern wollen. Häufig hört man das Argument, dass für die cross-funktionalen Teams die Spezialisten fehlten. "Wir cross-trainieren andere, um aus diesem Mist herauszukommen!" Wenn keine Spezialisten da sind, können die Strukturen gar nicht erst aufgebaut werden: Es muss massiv in Training investiert werden, bevor die Strukturen geändert werden können.
Ein Lean- und Kanban-Verfechter empfiehlt, gemäß Kanban Änderungen Stück für Stück herbeizuführen und nicht gleich den großen Wurf zu versuchen. Die einzige Möglichkeit bestehe darin, mit einem Team anzufangen, qualifiziertes Training anzubieten und alles Stück für Stück aufzubauen.
Eine Teilnehmerin berichtet aus eigener Erfahrung, dass tatsächlich häufig die Kapazitätszuteilung so gestaltet sei, dass man keine geschlossenen Teams bilden könne. Aktuell sieht sie in Transformationen, dass viele einzene Themen an vielen Ecken schon einmal dagewesen seien, aber nur als Stückwerk, und gescheitert sei alles, weil die Finanzierung über ein Gremium gegangen sei, "das jährlich Reports sehen will". Es gehe um eine gemeinsame Sprache, stellt sie heraus, und "wenn SAFe eine gemeinsame Sprache mit dem Kunden ist, nehme ich auch SAFe".

Das Problem mit der Abhängigkeit

(An dieser Stelle wollen wir auch die humoristischen Kommentare im Chat nicht vorenthalten, in ungeschnittener Reihenfolge: "SAFE - Brot und Spiele für das Arbeitsvolk :D" - "Eher Opium fürs Volk." - "ne, fürs Management" - "SAFe ist was für Reiche")
Ein anderer Gast bemüht noch einmal das Bild der Feuerwehr, er hat beobachtet, dass in skalierten Initiativen nicht ein Team einen Brand löschen könne, es bedürfe dafür immer noch 500 anderer zusätzlicher Teams (so viel zum Thema autark und möglichst ohne Abhängigkeiten von anderen arbeiten können - die Red.)

Hierarchische Organisationen, die funktionieren - der gemeinsame Auftrag macht's...

Jemand ruft uns ins Bewusstsein, dass sowohl Feuerwehr als auch Bundeswehr hoch hierarchische Systeme seien, trotzdem funktionierten diese Organisationen. Folgender Grund wird in unserer Runde gefunden: Das Überleben der Teams in diesen zwei genannten Organisationen hängen davon ab, dass die gesamte Struktur, "das System" funktioniert. "Wenn alle dasselbe Verständnis teilen, bekommt man einen Feuerwehr-Mechanismus hin." Jemand ergänzt, dass das gemeinsame Ziel, der gemeinsame Auftrag zusammenschweißten. "Retten, bergen, löschen, schützen - wenn du die nachts um drei aus dem Tiefschlaf weckst, können alle dieses Commitment herunterbeten" (hier nicht negativ gemeint, sondern als "in Fleisch und Blut übergegangen" - die Red.).

Wo ist denn unser gemeinsames Verständnis über den Auftrag?

Schnell wird auch ein Grundproblem bei "agil" identifiziert: das häufig fehlende gemeinsame Grundverständnis darüber, was unser Auftrag ist. Häufig steht in Unternehmen nirgends etwas sinnvolles über dieses Thema. Wenn diese Inhalte nicht immer wieder abgestimmt und kommuniziert werden, so ein Fazit aus der Diskussionsrunde, dann funktioniert besonders SAFe als strukturen- und nicht commitmentfixiertes Konstrukt nicht.

Der Themengeber sieht nach der Diskussion einige Punkte klarer und nimmt für sich mit: (kleine) Teams stärken, dass sie ausliefern können, Systems Engineering Teams zur Sicherstellung der Lieferfähigkeit einsetzen, Lieferfähigkeit auch durch Automatisierung fördern bzw. sicherstellen, und nicht zuletzt: Ausbildung und fundiertes Training.

Themen im Überblick

 

 (Heute mal im Querformat - guter Test auf benötigte Lesebrille ;-))

 Literaturliste zum Schmökern

https://www.scrum.org/resources/blog/5-konkrete-anzeichen-dafur-dass-dein-team-die-scrum-werte-nicht-lebt

Customer Distance: https://medium.com/the-liberators/zombie-scrum-the-curious-case-of-stakeholder-distance-6dc3488042ae

https://www.youtube.com/watch?v=5Ula8GliQek

https://www.linkedin.com/posts/activity-6935516945056186368-bmck?utm_source=linkedin_share&utm_medium=member_desktop_web

https://de.wikipedia.org/wiki/Mondrag%C3%B3n_Corporaci%C3%B3n_Cooperativa

Film A New Economy: https://vimeo.com/ondemand/aneweconomy/353618187

Die agilen Borg = SAFe … [https://medium.com/serious-scrum/safe-is-like-the-borg-2f2048e7f504](https://medium.com/serious-scrum/safe-is-like-the-borg-2f2048e7f504)
    
Dave Snowden: 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/
    
Funfact: https://pbs.twimg.com/media/FWQLgrUUcAAddec?fo

Die Feuerwehr hat viel vom Militär übernommen: https://de.wikipedia.org/wiki/Dienstgrade_der_Feuerwehr_in_Niedersachsen

Und hier noch einmal etwas Werbung in eigener Sache, und zwar für unseren tollen Lean-Coffee-Spezialtermin am morgigen Mittwoch, 06.07.2022: https://www.xing.com/events/lean-coffee-spezial-kollegiale-fallberatung-4014965


An dieser Stelle wieder ein großes Dankeschön für Eure Ideen, Euer Vertrauen, Eure Treue und nicht zuletzt für Euren Humor!

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.

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.

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.

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.

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.

Tooling #6: Take It To The Team

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich  hier   im Blog schon vorgestellt. Heute stelle ich mein Schweizer Taschenmesser für erfolgreiche Zusammenarbeit vor: Take it to the team!

Warum Workflows so viel versprechen. Und warum sie fast nichts davon erfüllen.

Es gibt zunehmend Unternehmen und öffentliche Einrichtungen, die Dokumentenmanagementsysteme einführen. Die "DMS" sind längst aus ihrem Namen herausgewachsen - die guten Produkte unter ihnen "managen" nicht nur Dokumente, sondern Unternehmensinformationen aller Art. Und vor allem strukturieren sie sie so, dass sie auch die Vielzahl von Prozessen, Kontakten, Vorgängen, Notizen überschaubar halten. Es gab Vorschläge, die Bezeichnungen entsprechend zu ändern - ECM ("Enterprise Content Management") oder EIM ("Enterprise Information Management"). Aber keine hat sich so richtig durchgesetzt. Bleiben wir also bei DMS. Tendenziell ersetzt ein DMS Windows als allgegenwärtige Arbeitsoberfläche (oder besser: Arbeitsuntergrund). Bei der Einführung von DMS spielen aber falsche Erwartungen der Entscheidungsträger eine große Rolle. Es werden große Hoffnungen gesetzt in Features, über die DMS nicht verfügen. Und auf der anderen Seite werden Dinge, die uns das Le

Some simple questions to generate more value with Scrum

Scrum becomes more mainstream. I also see many implementations of Scrum, where key elements are missing. With this confusion the name Scrum is burnt, because the faulty implementation of the framework is causing more harm and does not bring the desired benefits. I see the root causes of this problem in strong biases and sticky working habits. But also in Scrum training sessions, in which participants struggle to understand how Scrum works and why it is different to their existing ways of working. In these cases, I see trainers becoming defensive and trying to convince participants of the superiority of Scrum. In this blog post I’d like to help with couple of questions, that could help new Scrum teams define useful Product Goals & Product Increments figure out small incremental steps to improve their way of working – either in their team or outside their team in the organization. They could also help trainers to flip the situation: Instead of trying to convince their audience they c