Direkt zum Hauptbereich

Lean Coffee Frankfurt/Karlsruhe, Nachschau zum Termin #71

Wir haben in unserem Joint Venture mehrere harte Kerne und eine Reihe Wiederkehrer:innen sowie immer wieder auch neue Gesichter (die dann auch gerne ab und zu wieder bei uns vorbeischauen). Man sieht immer mal wieder neue Leute, bekommt frische Gedanken, aber man ist auch in vertrauter Umgebung, mit Menschen, bei denen es sich so anfühlt, als würde man sie wirklich kennen (auch wenn man sie nur online gesehen hat). Und manche kennen einander im wirklichen Leben, weil wir auch Lean Coffee offline können (hauptsächlich bisher allerdings Karlsruhe). Werde Teil dieser Community und vernetze Dich mit uns:

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

 

Wie strukturiert man Teams? (Verlängerung)

Dieses interessante Thema hätte natürlich noch länger diskutiert werden können, auch an der Verlängerung sieht man den Bedarf an Zeit. Als erster Hiweis wurden "äußere Merkmale" genannt, an denen man sich orientieren könnte: IT-Systeme, Prozesse, Skills, Aufteilung nach Wertstrom, nach SW-Entwicklungstechnologien,…
Der Themengeber möchte wissen, wie Teams in einem größeren gemeinsamen Kontext zusammengestellt werden können, damit sie gut zusammenarbeiten können. Es gibt ein einziges logisches Produkt, einzelne Aufgaben sind in unterschiedlichen logischen Systemen verortet. Nach welchen Kriterien solten Teams in einem solchen Umfeld geschnitten werden?

Das sagt die Schwarmintelligenz zu dieser Frage

Ideen aus der Runde: Es dem Team überlassen: "Wir werden zu träge, lasst uns zwei Teams bilden", man soll es den Teams selbst überlassen, sich zu finden. (Auf die Frage hin, ob das denn auch wenig erfahrene Teams schaffen, berichtet jemand aus eigener reichhaltiger Erfahrung, man könne eine Retrospektive durchführen und einen ganzen Tag für einen Open Space einplanen, um sich zu organisieren.)

Orientierung am Scrumbook

Verwiesen wird auch auf das Scrumbook unter scrumbook.org, das uns bestimmte Muster auflistet: Teams müssen bestimmte Dinge tun können/erfüllen. Oft werde die "Mitgliedschaft" in einem Team abgelehnt mit der Begründung, dass bestimmte Skills nicht vorhanden seien. In diesem Fall könne es helfen, ein bestimmtes Zeitkontingent pro Woche in die Aus- und Weiterbildung von Teammitgliedern zu stecken (auch: Mitglieder schulen andere Mitglieder). Natürich wird auch in dieser Runde festgestellt, dass dieser Ansatz je nach Setting seine Grenzen hat und es manchmal einfach nicht gelingt, aus einem Frontend- einen backendentwickler zu machen.

Orientierung an der Wertschöpfungskette? An den Aufgaben (Zielen)?

Eine Teilnehmerin bekundet, dass ihr Team zu groß geworden sei (siehe obige erwähnte Trägheit und Schwerfälligkeit) und selbst beschlossen habe, sich unter Moderation von außen in zwei Teams aufzuteilen. Der Themengeber selbst wirft ein, dass man Teams auch an der Wertschöpfungskette ausrichten könne, mit einer groben Anordnung der beteiligten Systeme (und den erforderlichen Skills für deren Nutzung). Wieder ein anderer steuert bei, dass Teams in seiner Welt aufgabenbezogen zusammengesetzt würden, jedes Team habe ein Ziel, eine Aufgabe, und danach entscheidet sich noch über (temporäre und ggf. externe) Mitgliedschaften im Team

Vorbereitung einer Aufteilung

Auf die Frage „Wie können wir uns organisieren, damit wir möglichst autonom handeln können?“, die man der sich zu formierenden Belegschaft stellen sollte, kann es die Antwort geben, dass möglicherweise fehlende Skills über ein ganzes Jahr hinweg aufgebat werden müssen, bevor eine sinnvolle Aufteilung möglich ist.

Die Bedeutung von "crossfunktional"

Der Themengeber fragt, was in einem großen Projekt „crossfunktional“ bedeutet, ob gemeint sei, innerhalb der kompletten Produktentwicklung? Antwort aus der Diskussionsrunde: ja. Auf den Einwand des Themengebers hin, dass man einen "5 Kilometer langen" Prozess habe, der gestaltet werden muss und nicht in einem einzigen Team abgebildet werden könne, schlägt jemand vor: Die Abhängigkeiten möglichst gering halten, Schnitt in einzelne Prozessschritte, innerhalb derer kann das Team dann crossfunktional sein. Nachdem auch die Zeit der Verlängerung herum war, merkte man, dass das Thema am heutigen Morgen immer noch nicht ausgeschöpft war. Vielleicht bieten wir vom Lean Coffee eines Tages einen Spezialtermin dazu an...

Als Team zusammengehen, sich als Team teilen: Wann und warum?

Amnesie im Daily

Als erstes lebhaftes Beispiel berichtet uns eine Teilnehmerin von schwierigen Umständen in früheren Standups, die dazu geführt hatten, dass sich das Team schließlich selbst aufteilte:"Wir haben uns damals geteilt, weil wir im Daily am Ende, wenn der letzte gesprochen hatte, vergessen hatten, was der erste gesagt hatte...", die Teammitglieder wussten dann nicht (mehr), mit wem sie sich absprechen möchten. Das neunköpfige Team habe sich daher aufgeteilt. Zwar hätten beide Teams noch in derselben Code-Basis gearbeitet, aber entweder an unterschiedlichen Stellen oder aber sehr eng zusammenarbeitend. Für diesen Fall stieg natürlich der Aufwand für die Team-Synchronisation. Inzwischen, so die Teilnehmerin, stehe durch Personalschwund wieder die umgekehrte Bewegung an.

Wer ist der PO, und wenn ja, wieviele?

Auf die Frage aus der Runde antwortet die Teilnehmerin, dass es weiterhin einen gemeinsamen PO
gebe, es gebe sogar noch mehr Teams, die auch alle denselben PO hätten. Dieser sei in Dailys (natürlich) nicht mehr dabei, für Sprintwechseltermine habe man alles so gelegt, dass er nur einmal anreist und viele untereinander abgestimmte Termine hintereinander hat.
Als Stirnrunzeln ob der Belastung des PO im Publikum spürbar wird, wirft ein Silberrücken ein, dass Toyotas Chefkonstrukteur (als Äquivalent eines PO) Personenanzahlen im dreistelligen Bereich bedient habe, "Das muss gehen!" Wenn man einem PO nur ein einziges Team oder maximal zwei zugestehe, würde man die Arbeit des PO (oder den PO selbst?) unterschätzen, die Rolle sich nicht voll entfalten lassen. 

Der PO als Flaschenhals und WIP-Limitierung seiner Arbeit

Jemand macht darauf aufmerksam, dass es manchmal "links vom PO hängt" (vermutlich prozessual bzw. vom Wertstrom her betrachtet), sodass dessen Arbeit überläuft und der PO zum Flaschenhals wird.
Auf die Frage an den Themengeber, was genau hinter seiner Fragestellung steckt (als Situation aus dem wahren Leben) antwortet dieser, dass gerade zwei Teams zusammengehen (sollen?), die auch von außen als ein Team gesehen werden, sich selbst jedoch als zwei disjunkte Teams wahrnehmen. In anderen Settings sei als Kriterium für die Aufteilung "nach Linienaufgabe" im Gespräch gewesen (Linie = häufig ähnliche Skills)... Von mehr oder weniger wahrnehmbarem Kopfschütteln aus der Runde begleitet, äußert eine Teilnehmerin, selbst leicht irritiert, dass sie immer nach Produkten aufteilen würde. Ausrichtung auf das Produkt (und natürlich auf den Kunden, der es abnehmen soll) kann ja schon mal nicht schaden... ;-)

Scrum vs. Kanban

Wann nehme ich Scrum, wann Kanban? Man höre zu dieser Fragestellung viel Unsinn, so der Themengeber. (Deswegen wollte er auch noch unseren dazu hören... ;-))
Die Idee, die der Themengeber im Kopf hat: Kanban ist evolutionär und ein Change Management-Werkzeug, Scrum dagegen ist disruptiv, wird dann genutzt, wenn etwas komplett Neues entstehen muss und man mit der üblichen Arbeitsweise nicht weiterkommt, aber schnell dazulernen muss.

Nicht nach einem Tool oder Fraework fragen, sondern nach einem Problem

Ein Teilnehmer echauffiert sich ein wenig: "Die Frage ist schon falsch! Welches Problem willst du denn lösen?" Er bekennt, dass er, wann immer diese Frage auftauche, leicht allergisch darauf reagiere. Der Themengeber kommt nicht aus der Ruhe, sie werde aber dauernd gestellt, erwidert er, und man müsse wissen, was man darauf antworte.

Scrum in wenig disruptiven Umfeldern gesichtet

Ein anderer Gast leitet seinen Kommentar mit den schönen Worten ein: "Ja, ich weiß, Erfahrung is‘ 'n Arschloch…" Er selbst habe immer nur Entwicklung gesehen, bei der immer mal ein bisschen was neues dabeiwar, aber Change und disruptiv sei ganz selten erkennbar gewesen, das Erlebte hätte nur kleine Bausteine davon gehabt. Die Teams, die er gesehen habe, hätten immer in kleinen Schritten von dort aus, wo sie waren, weiterentwickelt. Der Gast sieht darin nichts Disruptives, obwohl die beobachteten Teamarbeiten offenbar unter dem Namen "Scrum" liefen. (Was so alles unter dem Namen "Scrum" läuft, aber das ist wieder eine andere Geschichte...)

Hier riecht es nach Scrumbut

Ein anderer Teilnehmer hat auch Teams gesehen, die einen Mix verfolgen, sich also an eigenen Vorgehensweisen orientieren, mit denen sie am schnellsten zum Ziel kommen. (Dies setzt natürlich voraus, dass das Team seine Ziele kennt...) Details wurden leider nicht bekannt, da die Zeit um war und keine Verlängerung zustandekam.

Externe Abenteurer im selben Code

Externe Entwickler, die an einem Team vorbeiarbeiten (wie explizit gesagt wurde), als "Abenteurer" zu bezeichnen zeugt von einem wunderbaren Humor, vielleicht Galgenhumor?!?... Die Themengeberin berichtet, dass immer wieder Konstellationen aufgesetzt wurden, in denen externe Entwickler außerhalb des Teams, aber in derselben Code-Basis arbeiteten.

Pfusch mir nicht in meinen Code oder: wie man es schafft, dass alles drunter und drüber geht

Diese Personen reden mit dem gemeinsamen PO, und nicht nur das: Sie reden auch mit dem Kunden. Eine seltsame Erwartungshaltung des Managements, dass daraus etwas Sinnvolles erwachsen könnte (Meinung der Red.). Die Führungsriege zeigte sich in der Vergangenheit laut der Themengeberin leider auch nicht lernfähig (die harten Worte des Schreiberlings...), denn obwohl die Teams laut der Themengeberin immer wieder betonten, dass sie schlechte Erfahrungen mit dieser Arbeitskonstellation gemacht hätten, möchte das betreffende Management diesen Aufbau offenbar immer wieder. Die Frage steht nun im Raum, ob dieses Setting wirklich ein Problem ist oder nicht, und wenn nicht, wie man es schaffen kann, dass es eben kein Problem ist.

Das Spielfeld einengen

Vorschläge dazu aus der Runde: festen Rahmen/feste Spielregeln entwickeln, regelmäßige Termine wahrnehmen lassen, Verpflichtung auf die DoR, Teilnahme an Refinements, Einhaltung der Kommunikationswege, …
Die Themengeberin betont auf Nachfrage, dass die Externen tatsächlich neben dem Team arbeiten, also nicht in der Teamstruktur vorhanden sind. Sie müsten aber doch, so ein anderer, den Scope und die DoR erfüllen, und ohne Prüfung der Regeln passiere viel "unterm Tisch und durcheinander". Ein anderer hat die Idee: "Einsperren? Also: Deren Spielfeld eingrenzen? Sie z. B. an einzelnen Plug-ins arbeiten lassen?"

Der wahre Grund: Ja-sagen

Erst durch Nachstochern mehrerer Teilnehmer, warum das Management denn diese Art von Setting bevorzuge, kommt für alle ans Tageslicht, dass der wahre Grund der folgende ist: Das Management will nicht nein sagen. Gespielte Empärung mit wenig Überraschung macht sich kurz breit, es wird von jemandem zusammengefasst, dass das Management also seinen Job, nämlich, passende Entscheidungen zu treffen, nicht erledige.

Lasst doch auch externes Management ran...

Die Themengeberin berichtet zum Schluss noch, dass die betreffenden Teams planen, alle Fehler und die dadurch entstehenden Kosten noch einmal genau aufzubereiten (frei nach Jeff Sutherland "so dass das Management nicht wegsehen kann" - die Red.). Ein Silberrücken kommt auf die Idee, dass man ja anstelle der nicht entscheidenden Entscheider auch externe Manager einstellen könne. Er feixt "rent a manager" und kündigt (scherzhaft?) an, diese Idee zu einem Geschäftsmodell machen zu wollen.

Themen im Überblick

Literaturhinweise aus dem Termin

Podcast Christian Müller - Ist Scrum gescheitert?: https://proagile.de/ist-scrum-gescheitert/

Podcast Ralf Kruse - Worauf müssen Scrummer bei Kanban achten? (evolutionäre vs. disruptive Umfelder) https://enablechange.de/2022/04/27/scrum-vs-kanban/

Scrum Book: http://scrumbook.org/

https://stackoverflow.blog/2021/05/13/building-the-software-that-helps-build-spacex/

https://teamtopologies.com/

Vortrag "Autonome Teams durch eine agile Architektur" (Online Scrum Community): https://youtu.be/qZTSVmjWILw

Why Limit WiP (Jim Benson): https://www.amazon.de/Why-Limit-WIP-Drowning-MemeMachine/dp/0989081230/

Why Plans Fail (Jim Benson): https://www.amazon.de/Why-Plans-Fail-Business-MemeMachine/dp/0989081222/ref=sr_1_2?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3VFPN1YR04DUK&keywords=why+plans+fail+benson&qid=1652214725&sprefix=why+plans+fail+benson%2Caps%2C62&sr=8-2


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.

Transparenz als Schlüssel zum Erfolg: 20 Reflexionsfragen für moderne Organisationen

Transparenz ist das Herzstück erfolgreicher Teams. Sie schafft Vertrauen und fördert Zusammenarbeit. Wenn alle Zugang zu den notwendigen Informationen haben, können sie fundierte Entscheidungen treffen und gemeinsam Lösungen erarbeiten. Dies führt zu höherer Effizienz, schnelleren Entscheidungsprozessen und besseren Arbeitsergebnissen. Transparenz ist mehr als ein Schlagwort – es gilt, sie greifbar zu machen, ein gemeinsames Verständnis davon zu entwickeln und es in die Praxis umzusetzen. Wie das gelingt und welche Vorteile es für Euer Team und Eure Organisation bringt, erkunden wir im Folgenden.

Die Stimmung in Deinem Team drehen? So wird’s gemacht.

Oder ähnlich. Mir gefiel der Titel. Vor ein paar Tagen hat mich jemand angesprochen und von einem, wohl etwas frustrierenden, virtuellen Teammeeting erzählt. Die Teammitglieder zogen lange Gesichter, schauten grimmig in ihre Kameras. Ich habe mich dann gefragt, was ich tun würde, wenn ich in so einer Situation wäre. In diesem Blogpost beschreibe ich ein paar Tipps mit denen Du die Stimmung in Deinem Team (und Deine eigene) verbessern kannst.

Als Team innehalten für ein neues Jahr

Es ist eine schöne Tradition, den Jahreswechsel für das persönliche Innehalten zu nutzen. Als einzelne Person blickt man zurück, reflektiert und wünscht sich etwas für das neue Jahr. Einige Menschen nehmen sich etwas für das neue Jahr vor. Aber geht es auch auf der Ebene eines Teams?

Wofür braucht man einen Aktenplan?

Es muss im Jahr 2000 gewesen sein. In meinem Job hatte ich ein breites Feld an Aufgaben und ich wollte den Überblick behalten. Ich kannte mich schon mit verschiedenen Zeitmanagementsystemen aus. Aber mein Schreibtisch und meine elektronische Ablage wurden immer unübersichtlicher. Wer könnte noch ein Problem in der Ablage haben? Die Lösung fand ich in einem Handbuch für Sekretärinnen: einen Aktenplan. Ohne ihn wäre mein Leben anders verlaufen.

Leisten! Leisten? Leisten!

Warum opfern wir so viel für den Job, selbst wenn es uns nicht wirklich weiterbringt? Ein paar blasphemische Gedanken zu einem für uns überlebenswichtigen Thema. 

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.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

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.

Tanz der Konflikte - Tipps und Tricks für Führungskräfte im Konfliktmanagement

Erinnern Sie sich, zu welcher Musik sie so richtig ausgelassen tanzen konnten? Stellen Sie sich die digitale Transformation Ihrer Organisation als eine große Tanzinszenierung vor: Unterschiedlichste Rhythmen und Stilrichtungen treffen aufeinander - die Heavy-Metal-Fans auf die Diskofox-Queens, die Raver auf die LineDancer. Diese Vielfalt führt zwangsläufig zu Konflikten. Doch was, wenn wir sie als kreative Impulse für Fortschritt nutzen? Wie Führungskräfte diese Konfliktenergie effektiv nutzen, zeigt dieser Artikel. Konflikte verstehen: Warum sie unvermeidbar und wertvoll sind Konflikte - formwandelnde Begleiter Konflikte entstehen überall. Führungskräfte erleben Konflikte häufig in Form von unklaren Verantwortlichkeiten, unterschiedlichen Erwartungen oder Widerständen gegenüber neuen Arbeitsweisen. Während einige bereit sind, neue Schritte auszuprobieren, vertrauen andere auf vertraute Abläufe. Konflikte begleiten die Tänzer:innen auf eine Reise zwischen unterschiedlichen Bühnen. Jed...