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
Kommentar veröffentlichen