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

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.

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.

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.

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.

Tooling #5: Die gute alte Systemtheorie

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich hier im Blog bereits vorgestellt (und zwar  hier ). Heute möchte ich über ein weiteres, vielleicht sogar DAS entscheidende Basiswerkzeug sprechen: Die gute alte Systemtheorie.

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.

Ich bin ganz oben (mit Kanban und Outlook)

Mit einem Kommentar zu einem lesenswerten Artikel von Thomas Mauch /1/ habe ich es an die Spitze der Trefferliste bei Google geschafft. Suchen Sie mal nach „Kanban Outlook“. Kanban ist eine alte Idee, aber immer noch der Renner unter den Produktivitätswerkzeugen. (There is an English version of this post.)

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

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.