Revision 561: Organisationstruktur "Unfix"

Transcript

[0:00] Machst dir im dort ein blick da drauf okay was brauchen diese menschen in meiner organisation ihren job möglichst gut machen zu können so will man denn überhaupt eine organisation.
Strukturieren man könnte ja sagen beispielsweise maximale autonomie das ist wahrscheinlich das spannungsfeld das so aus autonomie und irgendwie konzertiertem vorgehen und vielleicht auch so informationsfluss aufrecht erhalten.

[0:29] Music.

[0:54] Revision 561, Diese Revision von Working Draft wird euch präsentiert von Midwald.
Midwald ist der Hoster für Agenturen und Freelancer.
Solltet ihr mehr als ein einzelnes Webprojekt zu betreuen haben, dann könnte Midwald euer Gamechanger sein. Ich erinnere mich mit Grausen an meine eigene Freelancer-Vergangenheit, als ich für 10 Kunden bei 20 verschiedenen Hostern mit 30 Logins zu jonglieren hatte. Brrrrrr.
Bei Metwald hingegen ein Login für alle Projekte.
Wahlweise für den besucherbasierten Agenturserver oder den nerdig selbstkonfigurierten Spaceserver.
Mit allen Features, die ihr euch nur wünschen könnt, vom Shop-System-Installer über SSL-Zertifikate bis hin zum ausgefuchsten Rechte- und Rollensystem.
Ihr wisst schon, für das Management eurer Projekte unter einem Dach.
Und DSGVO-konform. Und sollte es mal haken und ihr den Support anrufen, dann kriegt ihr echte Nerds ans Rohr. 24-7 an 365 Tagen im Jahr.
Das alles könnt ihr haben, wenn ihr auf mitwald.de slash workingdraft vorbeischaut. Das schreibt sich mitwald.de slash workingdraft. Alle Infos zu mitwald findet ihr natürlich auch in den Shownotes zu dieser Revision. Wir danken mitwald für die Unterstützung von dieser Revision von Working Draft.

Revision 561: Organisationstruktur "Unfix"

https://workingdraft.de/561/

[2:11] Wir sind heute zu viert. Aus dem Team hätten wir da einmal die Vanessa. Hallo. Dann den Hans.
Ja, hallo. Ich bin der Shep und das bedeutet, wir haben auch wieder einen Gast dabei, und zwar den Milan Matul. Hallo Milan.
Moin. Du warst schon zweimal oder dreimal zu Gast bei uns. Ich glaube zweimal, ne?
Du bist Tailwind-Experte auf jeden Fall, aber mehr als das, du bist auch Geschäftsführer bei einer Agentur in Hamburg, richtig?

[2:44] Genau, so ist es. Genau, also ich war zweimal hier und durfte mit euch über Tailwind CSS sprechen.

[2:53] Und eigentlich bin ich aber Managing Partner bei Victoria.
Und genau, wir sind eine Softwareagentur in weitestmössenem Sinne aus Hamburg mit einem internationalen Team. Ja, cool.
Genau, über Tailwind sprechen wir bestimmt, wenn dann die Version 4 rauskommt, nochmal mit dir, könnte ich mir vorstellen.
Genau, aber heute zapfen wir deinen Know-how als, ja, weiß ich nicht, wie man es ausdrücken soll, so Firmenvorsteher, Firmenhäuptling, Co-Häuptling an und möchten über Organisational Design sprechen.
Also eigentlich gar nicht so sehr, gar kein Entwicklerthema oder kein Programmierthema, Thema, aber ein Thema, das uns ja trotzdem irgendwie alle betrifft, wenn wir zu mehr als einer Person im Verbund Dinge machen. Genau, und du beschäftigst dich damit und hast da auch was Neues gefunden, auf das wir uns so im Verlauf dieser Revisionen hinarbeiten wollen und vielleicht, genau, können wir aber erstmal damit anfangen, so ein bisschen mit Grundlagen. Also was bedeutet es denn überhaupt eigentlich Organisational Design? Genau, vielleicht wollen wir damit mal einsteigen.

[4:19] Mhm, sehr gerne. Also das ist ein relativ großes Thema und ich glaube, es gibt auch sehr viele verschiedene Ansichten und Definitionen von, aber meine Sicht darauf ist vor allem erstmal die Frage, wie organisiert und wie strukturiert man Firmen dahingehend, wie der, Informationsfluss in einer Organisation sein kann. Also wer muss wann was wissen, damit eine Organisation ihrem Zweck entsprechen kann, dass die möglichst gut ihre Produkte, Dienstleistungen, ihre Mission verfolgen können. Aber eben halt auch dahingehend, wie tauschen die Mitarbeitenden ihr Wissen und ihre Aufgaben miteinander aus, dass sie sich auch möglichst wohl dabei fühlen, dem Auftrag gerecht zu werden. Das ist auch ein Teil davon.
Und dann, je nachdem, wie man eben da drauf guckt, also wie man da...

[5:22] Also ich im Behördenkontext drauf, da wird es dann relativ schnell dann auch so Amtsdeutsch mit so Stabsstellen und Direktiven und wie soll man das so, naja, sagen wir mal Handlungsspielräume, all solche Sachen spielen da tatsächlich auch eine Rolle.
Aber grundsätzlich geht es erstmal darum, wie baut man Organisationen auf, damit die, und strukturiert man sie, damit sie möglichst gut ihrem Zweck gerecht werden können.

[5:52] Ja und im Endeffekt hast du ja dann quasi gesagt, kann man so verschiedene, vielleicht verschiedene Schwerpunkte setzen, so was einem sozusagen da am wichtigsten ist. Also irgendwie schafft man viel oder hat man eine gute Atmosphäre für alle.
Das muss ja nicht dasselbe sein.
Also das kann ja irgendwie hierarchisch organisiert sein, sodass auch Leute vielleicht nicht ganz so happy sind.
Einfach irgendwie der Laden so läuft, wie der Chef das möchte.
Und... Also dazu kann ich noch ganz kurz dann vielleicht noch sagen, also das würde ich gar nicht erst mal so werten. Also dieses...
Also ich nehme jetzt natürlich so ein bisschen an, dass ihr alle auch in einem Software-Hintergrund arbeitet.
Und da haben sich auch gewisse Prozesse und Vorgehensweisen in den letzten Jahrzehnten auf jeden Fall etabliert.
Aber diese ganzen Detailfragen, also wie hierarchisch und wie einbindend und.

[6:53] Tatsächlich auch so, wo es dann vielleicht auch so ein bisschen eher in Richtung Unternehmenskultur und Unternehmenswerte geht.
Das ist, würde ich jetzt nicht unbedingt sagen, dass man das so direkt gegeneinander stellt.
Also ich glaube, es gibt auch Organisationen oder Kontexte, in denen das total gut funktioniert, wenn das hierarchisch organisiert ist.
Also da gibt es auch so ein, also jetzt schon die erste Klammer, die ich aufmache, aber da gibt es so ein halbwissenschaftliches Modell, Biodynamics heißt das, wo man so die unterschiedlichen Evolutions- und Kulturstufen auch von Organisationen beschreibt. Und das ist dann so ein Modell von der prähistorischen Stammeskultur, der hier entstammt, über die Familie, die Mafia, das Militär hin zur McKinsey-Matrix-Organisation und vollkommen holokratischen Organisationen, dass es so ist. Sehr großer, 100.000-jähriger Kurzfassung, wie so Organisationen auch geprägt sein können.

[7:57] Vielleicht kann man ja auch noch mal kurz erklären, für mich ist immer interessant zu erfahren, wieso will man denn überhaupt eine Organisation strukturieren? Man könnte ja sagen, beispielsweise maximale Autonomie, jeder macht schon das Beste, hat die gleichen, heeren Ziele sozusagen. Aber da geht es ja schon los. Also was sind die Ziele? Wie verfolgen wir die? Aber der Kern der Frage eigentlich, warum macht es Sinn, eine Organisationsstruktur einzuführen? Ja, das ist cool, dass du das sagst. Also ich kann es dir für uns beantworten und auch relativ einfach so aus der Praxis erzählen. Also uns gibt es jetzt sieben, acht Jahre und die ersten drei, vier sind wir eher auf so eine noch relativ easy handelbare Größe sind wir dann noch gewesen, so zehn bis zwölf. Das war noch super entspannt, total klein. Jeder kannte jeden, Man konnte irgendwie mal eben was über den Tisch werfen.

[9:03] Und es gab in dem Sinn auch nur ganz wenig Spezialisierung. Also es war wirklich, wenn du eine kleine Firma bist, dann war es häufiger auch so, dass alle irgendwie alles machen müssen und ich hier noch ein bisschen Buchhaltung und der Nächste hier irgendwie noch mit dem Kunden sprechen und so.
Also alle Sachen sind einfach noch nicht so klar festgeschrieben.
Und warum beschäftigt man sich überhaupt damit genau, wenn es darum geht.

[9:31] In größeren Zusammenhängen dann zusammenzuarbeiten. Also wir sind jetzt dann in den letzten Jahren relativ stark gewachsen und sind jetzt inzwischen so um die 50 Leute, also immer noch.

[9:42] Rechtmäßig klein, aber für uns ist es ein riesengroßer Schritt gewesen.
So einfach dahingehend, dass das schon ein Umfeld ist, wo man nicht immer täglich mit allen Leuten zu tun hat.

[9:54] Und es gibt eben halt auch eine maximale Menge an Informationslast, die so eine einzelne Person in einem Unternehmen gleichzeitig tragen kann.
Also das wird dann im Englischen immer als so Cognitive Load irgendwie bezeichnet, den du mit dir mitschleppst. Und das heißt, dahingehend willst du dann eigentlich darüber nachdenken, wie du die Informationslast und Komplexität in deinem Unternehmen reduzierst für den Einzelnen, denn so, dass die nur eine bestimmte Anzahl an Ansprechpartnern gleichzeitig haben oder nur mit einer bestimmten Anzahl von Leuten und Abteilungen sich gleichzeitig abstimmen müssen. Das ist so eins der Sachen darüber hinaus. Und dann natürlich, wenn du anfängst, in größeren Zielen zu denken, wenn es nicht mehr nur noch ist, in wie vielen Wochen wird dieses eine kleine Projekt irgendwie fertig, sondern, hört mal, Leute, wir wollen uns mit der Firma hier was komplett anderes, ganz anders aufstellen, also nicht einen anderen Marktbereich abdecken oder so. Wenn du dann Arbeit so organisieren musst, dass da nicht nur noch acht Leute, sondern eben 50 oder dann eben in richtig großen Unternehmen, dann hunderte oder tausende Leute irgendwie darauf einzahlen sollen, in der täglichen Arbeit, dann brauchst du ja ein.

[11:17] Mindestmaß an Struktur. Aber da habe ich auch ein schönes Zitat, den ich schon vorweg, ein bisschen Spoiler, eine Struktur, die der Komplexität des Marktumfeldes von deiner Firma angemessen ist. Also wenn du ein ganz einfaches Geschäftsmodell hast mit wiederholbaren Tätigkeiten, auch wenn du, Ich kann jetzt nicht sagen, dass es einfach ist, also es ist ein sehr großer Skill, aber man denkt, das ist eine Tischlerei oder so. Dann brauchst du sehr erfahrene, handwerklich begabte Mitarbeitende, aber die eigentliche Tätigkeit oder der eigentliche Prozess sozusagen ist wiederholbar. Und Software ist das meistens nicht. Da haben wir zumindest die Erfahrung gezeigt in der Vergangenheit.

[12:11] Das heißt, du würdest bezeichnen, dass unterschiedliche Probleme dann auch was, unterschiedliches sind?
Oder reden wir jetzt von einem größeren Bild? Weil ich, also das kleine Bild, ich hab ein Team, arbeitet Features ab, ist für dich dieses eine, ich stell mir nämlich gerade nur vor, wenn man Feature nach Feature macht, ob das nicht doch in irgendeiner Art und Weise das gleiche Tun ist, so wie wahrscheinlich der Tischler einmal Tisch viereckig, einmal Tisch rund macht.
Naja gut, das ist natürlich ein bisschen die Frage, auf welcher Ebene man halt das betrachtet.
Das ist halt so aus der Prozesssicht von einem Dev-Team.
Und ich sag mal so, wenn du Feature nach Feature machst, ohne zu wissen, auf welches größere Ziel das einzahlt, gibt's da so ein bisschen despektierlichen Termen so der Feature-Factory, Also dann bist du ein Dev-Team, was fließband Arbeit macht.
Also jetzt schon ein bisschen edgy, ne? Aber in einem komplexeren Arbeitsumfeld würde man auf Prozessebene dann eher tatsächlich auch mit dem Team sagen.

[13:24] Guck mal, das hier sind die Business-Ziele, die wir haben.
Wie können wir unsere Anwendung oder was auch immer gebaut wird, halt so strukturieren, dass sie dem gerecht wird und das gemeinschaftlich gestalten.
Aber das, würde ich sagen, ist sehr stark auf wie strukturiere ich den Alltag eines Dev-Teams und wie steuere ich die Arbeit da ein.
Und Organisational Design ist tatsächlich nochmal drei Nummern eigentlich größer.
Also wirklich so die Vogel-Perspektive oder Ansicht auf eine Organisation da drauf.
Und verlässt auch tatsächlich so ein bisschen die Ingenieurswissenschaften und geht eher in die Sozialwissenschaften oder Betriebswirtschaften, würde ich sagen.
Vielleicht, bevor wir so in dieses, was du jetzt gerade auch beschrieben hast, in dieses overarching Organisationsstruktur einsteigen.
Ich glaube so, womit sich jeder von uns wahrscheinlich irgendwie identifizieren kann, ist eine Arbeit in einem Team.
Also, was man ja häufig hat, ne, dann gibt es halt irgendwie reine Engineering Teams oder halt die Cross-Funktionalen Teams, die halt irgendwie da, haben ja andere Disziplinen auch noch mit auf.
Das ist doch eigentlich so die kleinste Einheit, in der man denkt, oder, also denkt man eigentlich, wenn man an eine Organisationsstruktur dann auch weiterdenkt, denkt man da gar nicht mehr in Teamstruktur oder in einem einzelnen Team?

[14:48] Naja, auf der Wertschöpfungsebene schon. Da können wir später nochmal reingehen. da ist das die sagen wir mal, kleinste Einheit, die irgendwie einen Workscreen halt herstellt. Und da ist es absolut notwendig, dass die alle, Informationen haben und alle Hindernisse aus dem Weg geräumt bekommen, dass sie möglichst gut und möglichst unterbrechungsfrei da ihre Arbeit machen können.
Genau. Und dann, der Gag ist so ein bisschen, das können wir aber später tatsächlich dann auch bei dem Modell, was ich mitgebracht habe, dann nochmal gucken, ist.

[15:26] Das kann eben ganz viele unterschiedliche Formen von Teams in einem Unternehmen geben.
Also, und nicht nur das Development Team, was eine Software baut.
Auch wenn das vielleicht aus unserer Perspektive die zentrale wertstiftende Einheit in einem Unternehmen ist, aber es gibt ja auch noch ganz viele andere Menschen, die in einem Unternehmen normalerweise arbeiten.
Und die sind auch in der Form von Teamstruktur organisiert.
Aber die sehen wir vielleicht nur nicht so häufig. Also Personalwesen, Management, Plattformteams gibt es zum Beispiel auch manchmal.
Dann gibt es manchmal Teams, die eben je nachdem, du hast es auch so schön genannt, funktionale Teams, cross-funktionelle Teams, irgendwelche Spezialistenteams, das Security-Team, die Rechtsabteilung.
Also kannst du ja wirklich vieles ausdenken, wo Menschen mit einem bestimmten Zweck zusammenkommen.
Und das ist eben das Spannende. Also idealerweise findet man eben dann eine Form, die dem Zweck am besten gerecht wird.
Das heißt, du machst dir im Dirt-Sci ein Blick darauf, okay, was brauchen diese Menschen in meiner Organisation, um ihren Job möglichst gut machen zu können?
Welche Informationen brauchen die, um möglichst...

[16:55] Und man fängt dann auch später noch an, aber um möglichst autonom ihren Job dann machen zu können, aber trotzdem an dem zu arbeiten, was die Organisation möchte.

[17:06] Ja, das ist wahrscheinlich das Spannungsfeld, ne, das so aus Autonomie und irgendwie konzertiertem Vorgehen und vielleicht auch so Informationsfluss aufrechterhalten, Nicht in einem zu hohen Maß, aber eben genug, dass irgendwie alle im Bilde sind und sich nicht abgehängt fühlen.
Und wahrscheinlich mit zunehmender Zahl Menschen wird das eben auch immer schwieriger, kennt man ja auch, dass man dann irgendwie immer weniger Ertrag hat beim Skalieren.
Und ich glaube, das will man ja auch immer schaffen, dass man da irgendwie die Verluste gering hält.
Genau, wie ist das jetzt momentan bei euch allen? Wie seid ihr denn organisiert derzeit?
Also, vielleicht können wir da hinschwenken.

[18:03] Also, bei Factorio seid ihr 50 Leute. Da ist es wahrscheinlich schon ein bisschen ausgefeilt.
Ja, also ausgefeilt ist der richtige Ausdruck. Also wir haben in den letzten zwei, drei Jahren angefangen, tatsächlich erweiterte Strukturen bei uns aufzubauen.
Wir haben da hinten auch beratende Unterstützung von extern dazu bezogen und mit dem uns gemeinsam da für ein Modell entschieden und eine Vorgehensweise und die dann aber so angepasst für uns. Und das Modell, was bei uns aktuell noch im Einsatz ist, das nennt sich VSM, Viable System Model heißt das. Da wird es auch relativ schnell so ein bisschen akademisch, aber ich versuche es nur ganz kurz zusammenzufassen. Also das ist relativ alt. Das kommt so aus der Pyranethik tatsächlich noch. Hat dann auch Einfluss auf die St. Gallener Management School gehabt in der Vergangenheit. Aber die Grundtheorie von diesem Modell ist, das Unternehmen.

[19:25] Aufgebaut werden sollten wie Organismen. Und zwar wie Organismen in ihren einzelnen Funktionen, dass die in der Lage sind, auf eine sich verändernde Umgebung reagieren zu können.
Da seht ihr auch schon die Brücke zum Agilen.
Und aber eben alle lebensnotwendigen Organe in sich bereithalten.
Und was da auch noch angelegt ist, dass sie sich eigentlich auch replizieren können.
Also du kannst einen Organismus aus verschiedenen Molekülen und Organen zusammenbauen und die haben in sich aber eigentlich dann wieder die gleichen Strukturen.
So.
Können wir das vielleicht kurz an einem praktischen Beispiel jetzt mal festmachen?
Also ich sag mal, ein Value Stream könnte ja sein, hey, ich hab hier, sag ich jetzt einfach mal meinen online shop und benutzerinnen und benutzer der klassiker sollen in dem online shop etwas kaufen oder ist das zu groß gedacht das ist nicht zu groß gedacht das ist also das wäre jetzt meinst du als hypothetisches beispiel für eine firma die so ein geschäftsmodell hat genau richtig und wie würde man dann sozusagen so einen organismus aufstellen dass er sich wie wie du ja eben sagst, selbst erhalten kann und dann diese Teile darin auch abbildet.

[20:52] Ja, also bei dem VSM, das muss ich ein bisschen verkürzen, aber da musst du dir so vorstellen, da gibt es so eine Art Blaupause für verschiedene Unternehmensbestandteile, einzelne Systeme wird das dort genannt.
Fünf Stück gibt es da im Groben.
Und das erste System da drin, das sind die wertschöpfenden Teile von einem Unternehmen.
Also das wäre dann so ein Value Stream oder ein Softwareentwicklungsteam, was Dinge bereitstellt, die die Welt braucht und die dann verkauft und vermarktet werden können.
Und die anderen Bereiche, die es da dann gibt, sind Unternehmensfunktionen.
Funktionen, die ist auch tatsächlich relativ allgemeinwürdig.
Also du kannst das für eine Softwarebude benutzen.
Das Beispiel, was uns immer da geholfen hat, war die deutsche Fußballnationalmannschaft.
Die wurde da auch immer gerne genommen.

[21:50] Das Einsatzsystem ist das Team, was auf dem Spielfeld steht und die, die in Anführungszeichen eigentliche Arbeit machen.
Und dann gibt es gibt es eben aber ganz viele andere Funktionen in einem Unternehmen darüber hinaus, die auch notwendig sind, damit dieses Team besonders gut funktionieren kann.
Genau. Und wenn wir zum Online-Shop dann zurückgehen, also dieses Team produziert Software-Features, die die Menschen brauchen, hoffentlich oder die Firma, sage ich mal, hat ein funktionierendes Geschäftsmodell und möchte ihre Software eben weiter ausbauen.
Und dann gibt es aber in der Organisation darüber hinaus Dinge, die benötigt werden. Und da...

[22:40] Was du in dem VSM, also ich, also für mich, mir fällt es ein bisschen leicht, das für meine Firma zu erzählen. Wir sind auch nicht so weit weg vom Online-Shop. Dann mach mal das.
Aber wir sind ja Agentur, also das heißt, wir haben nicht ein großes Produkt, sondern wir haben vier, fünf verschiedene Teams, die an unterschiedlichen Kunden und Projekten arbeiten.
Aber wir haben daneben eben tatsächlich jetzt auch eine.

[23:13] Abteilung ist nicht der richtige Ausdruck, aber ein System an Menschen, die sich darum kümmern, zum Beispiel so, firmenübergreifende Standardisierung zu machen in dem von unseren Dev-Teams, also alle Frontender, Backender, UXler, ProjektmanagerInnen, bei uns kommen regelmäßig zusammen in ihren Streams, um sich da auszutauschen.
Und dann ist es aber eben auch Aufgabe der fachlichen Führungskräfte, daraus so ein Destillat herzustellen.
Schaut mal, so wollen wir eigentlich unternehmensübergreifend arbeiten.
Und das dann auch occasionally zu überprüfen.
Also wir sind jetzt nicht so, dass ständig irgendwelche Checklisten gearbeitet werden müssen und dass das alles super eng geführt ist, aber es ist wichtig für uns, dass wir nach außen eine gleichbleibende Qualität oder eine gleichbleibende Kundenerfahrung sicherstellen können. Zum Beispiel, das ist ein Partner, den gibt es von uns, der nicht direkt im Team stattfindet, sondern daneben. Dann haben wir Personalwesen, Die arbeiten auch noch an anderen Ebenen, auch nochmal mit unseren Führungskräften zusammen.

[24:33] Wir haben Buchhaltung, wir haben aber auch so eine Art Management- oder Governance-System bei uns, wo wir grundlegende Richtungsentscheidungen treffen und sagen, guckt mal Leute, in die Richtung wollen wir in der Zukunft. Und das findet alles eben in unterschiedlichen Kreisen statt.
Und da können nicht immer alle gleichzeitig involviert sein, aber es ist eben wichtig, dass es trotzdem die Organisationen diffundiert und aber auch klar ist, Wer wann in welchem Bereich informiert sein muss, und wer doch Entscheidungen treffen kann, darf, soll.

[25:15] Ja, bei eurem, also genauso die, äh, hier die Verwaltung und die, äh, das Management, die, die brechen so ein bisschen, äh, so aus in ihre eigenen Welten.
Ähm, was eure Entwicklerteams angeht, hört sich das so ein bisschen ebenso tatsächlich wie so cross-funktionale Teams an, die ihr habt.

[25:34] Wahrscheinlich irgendwie die, die ihr auf bestimmte Kundenprojekte ansetzt.
Da, die bieten sich ja wahrscheinlich an, um diese Teams zu, zu schneiden.
Und dann habt ihr anscheinend eben quasi um so diese Querverbindung in den Teams zu haben und den Austausch so eine Art Gildensystem, oder? Wo ihr dann sagt so, hey, so das Team tauscht natürlich intensiv aus, aber wir haben halt dann noch die Frontender-Gilde oder die Designer-Gilden, die dann irgendwie auch so in ihrem Fachbereich zusammen Dinge weiterentwickeln und wieder zurück in ihre Teams tragen. So habt ihr dann quasi auf verschiedenen Achsen Kommunikation, aber eben auch nicht mit allen, sondern eben immer nur mit den einem am nächsten liegenden Personen. Also wahrscheinlich. Genau. Also genau bei uns heißen diese Dillen oder diese Meetings, die ja drum herum dann passieren, das sind dann Working Groups, sind das dann bei uns. Und in anderen Unternehmen heißen die auch manchmal Community of Practice oder so.
Und es gibt ja verschiedenste Namen dafür, aber die machen genau alle Ähnliches dabei.
Eine wichtige Part, die ich noch vergessen habe, ist eben der ganze.

[26:58] Strategische und zukunftsblickende Teil von einem Unternehmen. Also das ist sozusagen, also es gibt den ganzen operativen Teil, also die tatsächliche Durchführung von der täglichen Arbeit.
Und es gibt aber eben halt auch den Teil, der nach vorne blickt und zukunftsversprechende Richtungen versucht zu identifizieren.
So will ich es mal am ehesten beschreiben.
Genau, und das machen wir bei uns dann im Management zusammen.
Und dann binden wir aber eben halt auch unsere Führungsebene damit ein.
Genau. Und das refundiert dann wieder zurück in die Teams tatsächlich.

[27:45] Und Vanessa, wie seid ihr organisiert bei euch? Ihr seid ja nicht so groß, ne?
Was seid ihr, 20 oder so in der Kante?
Genau, immer noch 20. Und ich bin in die Organisation nicht in erster Linie involviert, da ich mich tatsächlich eben um die Ausführungen kümmere.
Und bin mir dementsprechend nicht sicher, welche Begriffe die richtigen wären.
Ich bin mir sicher, dass es Organisationen gibt, die sind jetzt aber nicht in dem Sinne irgendwie hingedruckt und jeder hält sich an alle Regeln, sondern die sind dann eingeflossen, sodass sie sehr natürlich wirken, sodass es mir vielleicht gar nicht auffällt, dass das jetzt eine Art und Weise Organisation dahinter ist.
Ich erinnere mich natürlich noch an die ersten Wochen, die wenigen Monate, in denen wir tatsächlich nur fünf und dann sechs Personen waren.
Ich glaube, an dieser Situation gab es tatsächlich keine Organisation und wir hatten jeden einzelnen Tag mit allen Leuten Kontakt.
Wir waren quasi ein Team.
Und seit wir da ein bisschen gewachsen sind, haben wir doch relativ schnell auch aufgehört, diese mit jeden Tag mit allen Personen Kontakt zu haben.

[29:10] Es gab relativ lang doch tatsächlich immerhin weiterhin dieses Daily für alle. Also das war auch mit ein bisschen dem Trade-off, dass man wusste, es ist jetzt nicht für jeden alles dabei.
Aber es war doch durchaus eine sehr effiziente Methode, dass wichtige Sachen, die vielleicht sonst erst Tage oder gar Wochen später aufgefallen wären, wirklich dann zur Sprache kamen, weil halt durchaus alle zuhören. Also wir sind eben wenig Leute, das heißt, da sind alle motiviert am Start und da sagt vielleicht eine Person mal was zwischen den Zeilen oder denkt, es wäre keine wichtige Information und dann springt sowas bei rum wie, ach, das können wir übrigens technisch in zehn Minuten ändern, wir wussten ja gar nicht, dass das jetzt quasi eine Sache ist und eben solche Dinge. Dennoch, ich glaube, das hat gut geklappt bis zu 14 Personen und irgendwann war es tatsächlich einfach, dass du schon weißt, es ist zu viel für die Gesamtheit.
Aber es war, wie gesagt, zumindest für mich ein sehr smoother Umorganisationierungsprozess, da ich ihn nicht so wirklich mitbekommen habe.
Speziell jetzt für die Devs und Designer und Produkt.

[30:25] Gab's tatsächlich häufigere Änderungen. Ich glaub, wir waren das mal in zwei Teams.

[30:34] Dann war die Frage, brauchen diese zwei Teams eigentlich die gleichen Arbeitsrhythmen?
Ich möcht jetzt gar nicht mal irgendwie ...
Wie heißt das bei Scrum? Ich hab's schon ganz vergessen. Ich hab schon so lange kein offizielles Scrum benutzt.
Aber da waren eben auch manchmal die Fragen, müssen wir das jetzt so machen oder müssen wir das so machen?
Und im Endeffekt waren alle Personen immer damit einverstanden, zu sagen, wir probieren das mal aus, aber wenn es uns nicht passt, dann müssen wir mal weitergucken. Und so hat sich das dann immer weiterentwickelt.
Im Moment sind wir tatsächlich bei einem Setup, dass jetzt die Entwicklungsteams, also wie gesagt, Designer und Produkt eingeschlossen, sehr klein sind.
Also wir haben es uns tatsächlich auf vier verschiedene Teams aufgeteilt.
Da sind pro Team dann teilweise nur drei bis maximal fünf Personen dabei.
Das hat natürlich auch Nachteile. Ich glaub, der größte ist klar, was ist, wenn Person X krank wird.

[31:33] Ähm, aber es war bei uns nie ein großer Nachteil. Weil immer noch die Devs, auch jetzt sind wir wieder bei der anderen Achse, die Devs und Designer untereinander wiederum ihre eigenen Gruppchen da gebildet haben, um sich da dann wieder weiterzuinformieren.
Das heißt, es passiert normalerweise nichts, wenn eine Person unerwarteterweise, ungeplanterweise nicht da ist, weil irgendeine andere Person kann einspringen.
Und im Allernotfall, das kommt sehr selten vor, im Allernotfall rennt man eben zum Chef und sagt.

[32:09] Kann man nicht splitten, Problem A oder Problem B? Und dann kommt man recht schnell an eine Antwort auch rein.
Muss eigentlich gar nicht immer von der obersten Sticht kommen, sondern dann ist tatsächlich auch ein Gespräch mit den Leuten hilfreich, die am meisten mit Kunden und Kundinnen zu tun haben.
Das kann je nachdem immer auch jemand anders sein. Aber dann weiß man tatsächlich, wo der Schuh dann am meisten drückt.
Zum Beispiel für mich ist, wenn ich einen Bug sehe, hat der für mich immer Prio 1, das ist klar.
Und irgendjemand sagt mir dann vielleicht, ja, weil das Feature kommt.
Ein Prozent der Trial User vielleicht jetzt nicht so wichtig wie, keine Ahnung, Kunde mit am meisten Usern bei uns.
Und daher bin ich gespannt auch immer wieder, wie es weitergeht.
Und ich glaube, ich werde dann auch mal ab morgen nachfragen, welche Organisation wir denn eigentlich offiziell haben, von denen ich die Begrifflichkeiten vielleicht gar nicht so bewusst wahrgenommen habe.
Ich bin mir sicher, dass was dahinter steckt, weil es irgendwie einfach funktioniert, wenn wir mal kleiner und größer werden, ohne dass es Problemchen gibt.

[33:12] Ja, wir können ja gleich noch ein paar von den Spielarten noch kurz besprechen, zumindest anreißen.
Und vielleicht findest du euch da wieder.
Aber so ein bisschen klingt's ja auch nach VSM.
Ja, tatsächlich hab ich die ganze Zeit gedacht, ah, das klingt ja sehr verdächtig und bekannt.
Ich komm tatsächlich davor, war das ja eine ganz andere Struktur, als ich noch bei der Agentur war. Da war ich aber auch bei verschiedenen Projekten und hab schon allein deswegen immer auch nicht so wirklich wahrgenommen.

[33:51] Weil es immer Personen gab, die sich quasi um mich dann gekümmert haben, um mir gesagt haben, das ist jetzt deine Rolle hier, und du machst diesen Aufgabenbereich.
Dennoch, das letzte Projekt, das ich da hatte, war dann in den letzten paar Monaten mit Save.
Und ich weiß nicht, welche Hörer oder Hörerinnen jetzt grad so innerlich ein bisschen aufgestöhnt haben.
Ich denke, bei so etwas wie Safe, und hier nehm ich's jetzt einfach nur mal kurz als, pick ich mir das als Paraderbeispiel raus, ist es oft gar nicht das Problem des Frameworks, ähm, dass den teilnehmenden Personen dann nicht so passt, sondern oft vielleicht auch eher so ne, die Organisation drumrum, oder wie das eingeführt wird, wie das erklärt wird, wissen denn eigentlich alle Personen, was es bedeutet, wird es dann auch durchgesetzt.
Genau, ich würde mal in die Runde fragen, da ich es jetzt gerade erwähnt habe.
Kann mir jemand ganz genau erklären, was SAFE eigentlich ist?

[34:55] Ich weiß nur, dass es irgendwie so ein komischer Frankenstein ist aus agilen Arbeiten und das Ganze aber in irgendwie, glaube ich, so einen Wasserfallkontext reingebaut, oder?
Ja, das ist jetzt die… Das habe ich im Hinterkopf. Ich weiß aber nicht, ob das stimmt.

[35:18] Also ich würde vielleicht, ich würde es vielleicht ein bisschen anders beschreiben, ich würde vielleicht sagen, man hat ab einer gewissen Stufe, wenn man eine gewisse Größe als Unternehmen erreicht, ja immer so die Herausforderung, okay, wie skalier ich denn etwas wie einen Scrum, ja, Scrum für ein Team funktioniert super, vielleicht auch für vier Teams funktioniert auch super, machst du noch einen Scrum of Scrums dazu und dann hast du einen guten Sync, ja.

[35:42] Wenn man jetzt aber mal vielleicht sehr viele verschiedene Teams, 20, 40 verschiedene Teams, an verschiedensten Initiativen arbeiten hat, dann ist natürlich die Frage, wie organisiere ich das, über verschiedene Management-Ebenen auch hinweg, über verschiedene Projekte hinweg, Weil ich sag mal, man arbeitet dann vielleicht nicht, also es arbeiten dann vielleicht nicht alle Leute an dem gleichen Projekt, sondern man muss auch diese ganzen Initiativen managen, die wiederum dann Stakeholder en masse haben, die auch irgendwie gemanagt werden müssen.

[36:19] Und um trotzdem ein Alignment hinzubekommen, so sehe ich jetzt so ein Safe-Modell, ein Alignment zwischen diesen, sagen wir mal, 40 Teams, die dann nochmal unterteilt sind in verschiedene Teilbereiche, ja, braucht man halt irgendeine Art Organisationsstruktur drumherum, wo man dann sagen kann, okay, ich hab jetzt hier so eine Art, keine Ahnung, ein großes Planning, ja, Big Room Planning nennt man es dann vielleicht, wo man vielleicht sagt so, hey, da versuchen wir alle zu alignen.
Und irgendjemand muss sich darum kümmern. Also gibt es da vielleicht auch noch Rollen, die es in einem Modell wie mit einem reinen Scrum, was sehr lean ist, ja, vielleicht nicht gibt. Und so sehe ich diese größeren Frameworks, die, jetzt wurde eben gesagt Frankenstein, die halt versuchen so ein Stück weit viele Projektmanagement.

[37:13] Ja methodiken übereinander zu legen ja und die zusammenzubringen um daraus ein großes ganzes zu formen was ich dann irgendwie manchmal dann doch wieder wie wasserfall anhört wenn da so ein kleines zahnrädchen team in anfangsstrichen, unter den anderen 40 zahnrädchen team funktionieren so das ist so meine meine sicht auf diese dinge aber ja milan vielleicht.
Siehst du das auch nochmal anders oder hast du auch nochmal mehr Insights?
Du hast dich ja mit dem Thema sehr intensiv, glaube ich, auch beschäftigt.

[37:45] Ich finde, du hast das gut geschrieben. Ich meine, das ist halt der Versuch, eine agile Arbeitsweise, Organisation 2, zu skalieren.
Und eben dafür zu sorgen, das ist genau das, was Hans eben meint, wenn du, desto größer deine Firma wird, also das ist dann vor allem für Produktorganisationen relevant, wie gesagt, bei uns nochmal ein bisschen anders, weil die Teams an unterschiedlichen Kunden und Projekten arbeiten, also die haben nicht so einen starken Need dafür, auf Zielebene, was die Entwicklungsziele anbelangt, allein zu werden. Aber wenn dein Startup von 20 Leuten auf 2000 Leute anwächst innerhalb von x Jahren, dann hast du diesen Need. Und du hast ein Produkt, wo es einfach ganz viel Abstimmung erforderlich ist, und die muss irgendwie organisiert werden.

[38:39] Und zu safe muss ich entweder sagen, kenne ich mich nicht genug aus, um da so richtig qualifiziert was sagen zu können, außer, also die Kritik, die mir halt bekannt ist, und das gilt aber für fast alle agilen Frameworks, mit denen ich mich so auseinandergesetzt habe, ist, dass es viel bestimmte Vorgehensweisen und Methoden vorschreibt. Also, du musst dann deine Firma oder deine Dev-Teams in einem bestimmten Prozess organisieren, um safe gerecht zu werden. Du musst in einer bestimmten Kadenz alle deine Teams dann abstimmen, damit der Informationsfluss gewährleistet ist. Du musst bestimmte Rituale und Meetings durchführen, damit das dann immer noch zu diesem Prozess gehört. Das habe ich auf Agiler Ebene oder auf Spannebene auch schon hundertmal durchlebt.

[39:47] Auch eine der größten Kritikpunkte an so agiler Arbeitsweise oder an dem, wie es eingeführt wird.
Das heißt, ich maße mir gar nicht einen über das Modell so groß zu urteilen, sondern das ist eher dieser Punkt.

[40:00] Leute, wir machen jetzt heute alles anders, aber die Leute wissen gar nicht, warum.
Also im Sinne von, wir übernehmen die Arbeitsweisen aus einem Manifest oder aus einer Verfassung, Aber wir wissen gar nicht, warum. Und das ist tatsächlich sozusagen auch dann der große Unterschied, zu dem Amphix dann angetreten ist, was ich noch mitgebracht habe, die eben halt auch im nächsten Nebensatz dann sagen, okay, wir sind für Versatile Organization Design.
Wir sind vielschichtig und anpassungsfähig.
Und dahinter steckt auch immer die These, dass Praktiken und Methoden, die kommen, sollten aus der Praxis informiert sein.
Und jede Organisation ist im Zweifel einzigartig genug, als dass sie es rechtfertigen, ihre eigenen Prozesse und Vorgehensweisen und Strukturierungen zu entwickeln.

[41:00] Und deswegen macht Unfix da auch keine klaren Vorgaben, sondern bringt dir eher, sagen wir mal, Handlungsspielräume oder Möglichkeiten, alle Bereiche deines Unternehmens zu strukturieren und je nachdem, welchen Zweck die zu verfolgen, die richtige Form oder die angemessene Form zu finden.
Das ist der Kritikpunkt, den ich oft bei Safe gehört habe.
Oder auch wenn Leute Scrum übernehmen und dann haben wir jetzt Dailies, aber trotzdem wird die Arbeit alles einfach eingekippt.
Also man übernimmt die Rituale, ohne wirklich die Arbeitsweise zu verändern.

[41:43] Das ist, was ich dazu sagen kann, zu der Kritik dabei. Aber die Bestrebung grundsätzlich, agile Arbeitsweise skalieren zu wollen, das kann ich sehr gut nachvollziehen, dass es die gibt.
Und dass es da drumherum dann so eine Zertifizierungs- und Beraterstruktur gibt, das ist so ein bisschen so eine Stilblüte.
Du hast ja gerade schon erwähnt, du hast das Anfix-Modell im Gepäck.
Das wollen wir uns gleich angucken.
Aber bevor wir das machen, wollen wir noch einmal kurz erwähnen und stichwortartig sagen, was die machen, die also so bestehende Modelle.
Also safe hatten wir. Ihr habt das Weibel System Model. Welche gibt es noch, die so praktiziert werden aktuell?

[42:34] Und wie funktionieren die? Also ich bin da total unterbelichtet, tatsächlich.
Also ich arbeite eigentlich immer in kleinen Teams. Also ich kenne Kanban und Scrum und genau, das war's dann.
Und den Rest kenne ich nur vom über den Tellerrand schauen.

[42:52] Ich glaube vielleicht, was eins der Modelle ist, was jetzt ja häufiger auch mal erwähnt wird, weil es in den vergangenen Jahren viel, ja, auch Literatur dazu gab, ist das Modell von Spotify. Spotify hat ja praktisch irgendwann mal publiziert, es gibt so ein Organisationsmodell, wo sie sich aufstellen nach gewissen Formen sozusagen. Sie sagen, okay, es gibt da sogenannte Tribes, die sich dann halt irgendwie hauptsächlich mit einem, ja, einem Produkt, sage ich jetzt mal, in einer gewissen Art und Weise beschäftigen, und darin werden dann Dinge auch weiter zerlegt. Und das ist sozusagen die vertikale Sicht der Dinge, ja, so dass du irgendwann bei einem Team ankommst und das Team ist halt kostfunktional aufgestellt.

[43:44] Und beispielsweise auf der Horizontalen gibt es dann zwischen Teams gewisse Notwendigkeiten zusammenzuarbeiten, ja. Beispielsweise wenn man jetzt mal sagt, man nimmt halt irgendwie ein Produkt, dieses Produkt hat irgendwie, ja, so eine Art Discovery-Funktion, sei es eine Suche, sei es Produkt-Detailseiten oder Articles oder whatever, ja, dann gibt es in diesen verschiedenen Teams, die ich jetzt mal so exemplarisch genannt habe, vielleicht Entwicklerinnen und Entwickler, die an der Frontend-Tätigkeit nachgehen, und dann organisiert man sich da eventuell auf, wir haben es vorhin schon angesprochen, auf, in der Gilde, wo man halt dann sagt, okay, wir sprechen viel über Frontend-Tätigkeiten.
Und genauso passiert das aber auch auf einer Ebene der...

[44:30] Product Ownerinnen und Owner, oder dann halt auch im Scrum Master und Agile Coaches Bereich, wo man auch vielleicht sich zusammentut, innerhalb dieser Organisationsstrukturen.
Das wäre vielleicht noch eine, ja, ein Modell, was halt so die verschiedenen, also einmal das Arbeiten an einem Produkt als solches, aber dann auch auf der Horizontalen, dann sozusagen eher auf dem darüber liegenden Gesamtgoal der Firma oder des Teilbereichs sozusagen arbeiten. Das finde ich, fand ich noch ganz interessant in der Vergangenheit, in so einem Modell zu arbeiten, weil es zum einen dich fokussieren lässt auf ein Produkt, aber zum anderen halt genau das, was ich eben sagte, ne, halt auch die darüber liegenden Ziele, die du gemeinschaftlich nur erreichen kannst, die auch besser zu verfolgen bietet.
Jetzt haben wir es im Vorgespräch schon gesagt, das Interessante ist ja an der Geschichte, Spotify praktiziert das Modell gar nicht, weil sie sagen, ineffizient, wenn ich mich da richtig erinnere aus der Literatur heraus.

[45:33] Ja, oder es war auf jeden Fall, es war, es war, glaube ich, ein Snapshot zu einem bestimmten Zeitpunkt in der Entwicklungsgeschichte von Spotify. Und der ist jetzt, also das Modell, es, anscheinend hat das so eine Strahlkraft und Wirkung entfaltet, dass immer noch viel drüber gesprochen wird und da findet ihr Anklang. Aber das ist – ich kenne den genauen Zeitraum nicht – aber es ist gefühlt fünf oder sechs Jahre her mindestens, dass die so gearbeitet haben.
Und wenn man da die entsprechenden Coaches verfolgt, dann sagen die auch, nee, heutzutage gibt es das alles gar nicht mehr. Was ich noch ergänzen wollte, wo die sehr gut waren in der Metapher als dieses Thema, sagen wir mal, Selbstorganisation gegen Zielalignment zu erklären. Also da gibt es mal so einen ziemlich berühmten Comic, so Autonomy vs. Alignment.
Wir müssen über diesen Fluss gehen. Hier ist der Plan oder bohrt es mir eine Brücke oder bohrt mir ein Fluss. Ihr auf der linken Seite baut die Brücke und die auf der rechten Seite bauen den Tunnel. Dann haben wir irgendwie auch was falsch gemacht und so. Also das ist schon, bin ich schön und zugänglich da auf jeden Fall erklärt für alle Beteiligten und.

[46:51] Ja, jetzt heute in der Praxis, was ich gehört habe, aber dass das Bildertören sagen, ist eigentlich eher, dass sie relativ wenig fixe Modelle und Regeln da haben.
Das ist auch so eine Theorie tatsächlich, an die ich auch glaube, dass wenn du talentierte und fähige Mitarbeitende hast, dann musst du auch gar nicht so viel Prozesse vorgeben oder so eng halten, sondern solche Mitarbeitenden, die wollen ihre eigenen Prozesse schaffen, die dem gerecht werden.

[47:31] Vielleicht muss man das ja auch so betrachten, dass man solche Strukturen erst mal zum Starten verwendet, sozusagen als Sprungbrett, damit man eben was hat, um so ein Gefühl dafür zu kriegen, was funktioniert daran gut und was nicht.
So ein bisschen so wie, dass man eben nicht den Writer's Block hat, wenn man halt schon irgendwie was hat.
Dass man einen Text hat, von dem man ausgeht, und dann fällt einem ja ganz viel ein, was man besser machen kann.
Also, dass man so ein Modell eben für diesen Zweck heranzieht.
Und dann macht das ja auch Sinn, dass Spotify das gar nicht mehr benutzt, weil das ja seinen Zweck erfüllt hat, nämlich einfach nur ein Sprungbrett zu sein in das nächste Ding, was dann wahrscheinlich wirklich nur individuell von genau diesen Mitarbeitern, die da gerade sind, entwickelt werden konnte, weil das einfach ihrem naturell entspricht.
Und wahrscheinlich ist Spotify ja auch in der Größe schon wieder ganz anders als vor fünf, sechs Jahren, als sie dieses Modell, diesen Snapshot sozusagen entwickelt haben.
Ich denke, jedes Modell ist ja auch wahrscheinlich prädestiniert für eine bestimmte Teamgröße.
Also genauso wie Safe offenbar ja eben für sehr große Organisationen ein Werkzeug sein kann, aber eben nicht für kleine zum Beispiel.

[48:59] Ja, es ist ja auch immer eine Frage von, also wie viel organisatorischen Overhead du dir auch zu welchem Zeitpunkt halt erlauben kannst oder möchtest.
Also diese ganzen Austauschformate, die werden, also wie hast du das auch beschrieben, also wenn du Scrum of Scrums und die Product Owner müssen alle miteinander sprechen, so damit man ein kohärentes Gesamtprodukt halt irgendwie erstellt, so dann ist das wichtig.
Und dann ist das auch wertvoll, da Zeit rein zu investieren.
Aber wenn du zehn Leute bist, dann ist das wahrscheinlich overkill.
Dann solltest du dich in dem Maße damit nicht auseinandersetzen, sondern dann hast du eine andere Fragestellung für dein Unternehmen.

[49:47] Ansonsten wären wir jetzt wahrscheinlich ja alle sehr gespannt drauf, das Unfix-Modell da nochmal tiefer einzusteigen.
Und wie es sich, du hast gerade schon erwähnt, es grenzt sich so ein bisschen davon ab, von den anderen, und ich bin mir nicht sicher, ob es sich vielleicht aus diesem Grund auch genau entwickelt hat, Weil eine oft genannte Kritik an Frameworks wie SAVE ist, dass es zu steif ist.
Das lasse ich jetzt auch einfach mal ganz unkommentiert so weiter stehen, sondern es ist einfach eine Kritik da dran.
Und UNFIX wäre eher etwas flexibler. Habe ich das richtig verstanden?
Ja, genau. Also, so ist es. Design, also, not another agile scaling framework, ist die Tech Line.
Und auch eine Organisationsdesign für kontinuierliche Innovation und eine bessere menschliche Erfahrung.
Und das ist schon ganz spannend dabei zu betrachten.

[50:57] Also dazu muss man vielleicht ein bisschen den Hintergrund auch nochmal erzählen.
Also wo kommt das her?
Also der Erfinder von unfix, das ist Jürgen Apelow heißt der, und der ist Management Consultant und Speaker Und der hat, ich glaube, das ist jetzt so knapp zehn Jahre her, der hat so ein relativ bekanntes Buch, auch in der agilen Community geschrieben, über die Rolle des Managements im Agilen.
Das hat einen relativ doofen Titel, das heißt Management 3.0, ist aber meines Erachtens ein sehr gutes Buch, weil der eben versucht, diesen Widerspruch aufzulösen.
Also das ist natürlich nochmal so zu der Entstehungsgeschichte.

[51:47] Viele Leute denken ja auch, okay, wenn jetzt alles agil ist, dann gibt's kein Management mehr, dann gibt's keine Regime mehr, dann gibt's keine, Entscheidungen mehr, die irgendwie über die Team-Ebene hinausgehen. Und da sagt er eben, nee, das ist nicht so. Also es muss diese Rolle trotzdem auch geben in einem Unternehmen, aber das Unternehmen muss eben anfassungsfähig sein und muss eben in der Lage sein, eine kohärente, tolle Erfahrung auch nach außen sicherzustellen.
Dafür hat er sich einen...

[52:31] Meines Erachtens ziemlich spannendes Modell ausgedacht. Wenn man, das würde ich euch vielleicht auch empfehlen, wenn man auf die Seite von unfix geht, also unfix.com und dann ein bisschen runterscrollt, dann kommt einem ganz schnell so ein, eine bunte, eine bunter Bauplan entgegen, mit ganz vielen unterschiedlichen Strukturen, ganz vielen Smilies, ganz vielen Farben und Kreisen und sonst was.
Und das wirkt erstmal vielleicht auch ein bisschen erschlagend, aber dahinter stecken meines Erachtens und ich sehr, sehr interessante Gedankengänge, wie man eben unterschiedliche Bestandteile eines Unternehmens zusammensetzen kann, mit einem bestimmten Zweck, um das optimal zu erreichen.

[53:33] Und was hat dich darauf stoßen lassen? Also ich meine euer Modell, das ihr praktiziert, das klang ja im Grunde genommen ganz plausibel und gar nicht schlecht.
Bist du dann so, hast du dann irgendwie das Gefühl gehabt, dass es irgendwie auch an seine Grenzen stößt?
Oder bist du einfach generell so sozusagen ein Dauerforschender, um zu gucken, was kann man eben besser machen, als wie es jetzt ist?
Was macht's besser als zum Beispiel das Viable System Model?
Also ich bin Dauerforscher, das stimmt, und interessiere mich für sehr viel.
Tatsächlich hat aber wirklich auch unser Organisationsberater, mit dem wir zusammenarbeiten, der hat mich auch auf das Modell aufmerksam gemacht. Da war es eben noch ganz frisch.

[54:29] Und dann habe ich mich da so ein bisschen reingefuchst und habe gesagt, ah, das ist ja interessant.
Und was es vielleicht unterscheidet, also im allergrößten ist, dass es, also das VSM, würde ich sagen, ist auf einer größeren, viel, viel größeren Abstraktionsebene.
Also das ist quasi so ein fast allgemeingültiges Modell der Wirklichkeit, was du auf jede, jedwede Form von Organisation anwenden kannst.
Und es ist schon sehr gut in der allgemeinen Strukturierung, aber es ist vielleicht ein bisschen weniger angewandt als unfix.
Also unfix gibt dir konkrete Beispiele, konkrete Zusammenhänge, in denen es Sinn ergeben könnte.
Eine Crew, das ist auch so ein Terminus, den er da einführt, mit einem bestimmten Zweck in deinem Unternehmen einzuführen.
Und da gibt dir VSM nicht so konkrete Handreichung, sondern das musst du dir eben dann selber überlegen.
Und was ich tatsächlich auch sehr gut dabei finde, ist eben, dass es ganz starken Wert darauf legt.

[55:53] Nicht diese eine Lösung dir vorzukauen, die du dann übernehmen wirst.
Also werden wir vielleicht später auch noch zukommen. Müssen wir mal gucken, wie detailliert wir jetzt tatsächlich reingehen.
Aber zum Beispiel haben wir auch immer wieder mal die Diskussion, Wir sehen uns im nächsten Video.
Wie fix sollten denn eigentlich unsere Teamstrukturen tatsächlich sein?
Also grundsätzlich ist es ja in der Anleitung gut.

[56:21] Wenn die Leute regelmäßig in einer dauerhaften Teamzusammensetzung zusammenarbeiten, also jenseits vom fachlichen Austausch, auch wenn man die Leute besser kennt, Vertrauen zueinander aufbaut und auch dadurch am Ende auch eine leistungsfähige Zusammenarbeit eben gewährleisten kann.
Laufen kann. Bei uns zum Beispiel im Agenturalltag kann es aber durchaus auch mal sein, dass ein Projekt eine Laufzeit von sechs Monaten hat und das andere von drei. Also wir sind zum Glück nicht mehr bei, das ist eine Woche und das zwei, aber trotzdem kann es eben sein, dass wir auch zeitgebunden.

[56:59] Dann ein neues Team zusammenstellen müssen. Und das erlaubt Anfix auch. Das kann man dann auch abbilden. Und dann sagt er, ah, es gibt aber unterschiedliche Arten von Teams. Und je nachdem, wie mission-critical das eben ist, kannst du unterschiedliche Verfahrensweisen finden, um dieses Team dann zusammenzustellen. Und was ich persönlich auch sehr, sehr dabei mag, ist den Dingen halt einfach auch nochmal einen Namen zu geben, damit sie besser kommunizierbar sind. Also das ist ja, wie du gesagt hast, im Alltag als Dev war mir, glaube ich, also früher, war mir, glaube ich, nicht jeden Tag bewusst, in welcher Struktur oder nach was für einem Modell ich da jetzt gerade arbeite. Ich glaube auch nicht, dass alle Unternehmen das machen, aber.

[57:55] Aber ich glaube, dass es für den Kontext oder Zusammenhang, in dem du gerade arbeitest, ist schon sehr sehr hilfreich eben zu wissen, Warum sitzt man mit den Menschen gerade an einer gemeinsamen Aufgabe und mit welchem Zweck tut man das denn eigentlich?
Und da hilft unfix doch sehr.

[58:18] Also diese Teamumstrukturierungen habe ich eigentlich generell immer nur gute Erfahrungen damit gemacht.
Das haben wir tatsächlich hin und wieder aus, ich glaube, vor allem zwei Gründen gemacht.
Das eine ist, dass einfach das, jetzt darf ich nicht wieder Englisch reden, das Wissen geteilt wird zwischen allen Personen. Das hat den, es hat natürlich am Anfang kurz den Nachteil, dass man sich ja ständig irgendwie onboarden muss an irgendwas. Aber es hat natürlich genau diesen Vorteil, wenn man jetzt wie wir, es sind sehr kleine Teams im Alltag hat, dass ich aber trotzdem den Code überall noch verstehen und lesen kann.
Oder ich weiß im Notfall zumindest, wer die richtige Ansprechperson gleich dafür ist und muss nicht irgendwie in einen, was weiß ich, Channel mit x Personen reinschreiben, ey, wer kann mir denn zu diesem Thema mal helfen, sondern ich weiß jetzt immer genau, wen ich ansprechen kann.
Das andere ist nicht nur, dass das Wissen jetzt über die Codebase oder Wissen über die Produktfeatures geteilt wird.

[59:25] Sondern auch den Input, den ich jetzt als Developer zum Beispiel an Code Reviews bekomme.
Also nur, dass wir kleine Teams haben, heißt jetzt nicht, dass wir keine Code Reviews machen, sondern dass wir, obwohl es eine Person nicht in diesem Feature-Team gerade dabei ist, werden die Code Reviews doch durchaus an alle Frontend-Apps zum Beispiel weiterverteilt.
Das heißt, da ist natürlich auch noch ein Austausch. Und hier ist das hilfreich, wenn das verschiedene Personen sind, dann bekommst du einmal, sagen wir mal, stärkeres Feedback, da, wo diese Person dann eben auch stark dafür ist.
Das kann dann ein starkes Feedback, speziell zu HTML, Accessibility und vielleicht CSS sein.
Auch bei einer anderen Person ist es stark an TypeScript.

[1:00:12] Und da, wie gesagt, diese Teams durchmischen, sehe ich immer große Vorteile da drin.
Ich habe jetzt tatsächlich noch nie ein Team erlebt, das dann nicht so funktioniert hat. Aber das ist bei uns 20 Personen, die sind natürlich auch aufeinander abgestimmt. Was mich jetzt noch interessieren würde, du hattest gerade Crews gesagt, eigentlich ist mir jetzt gerade egal, ob das jetzt Guilden, Teams, Crews, Workforces, Taskforces, Ferken-Crews sind. Aber sprechen wir dann davon, dass wenn ich Teil einer Crew bin, bin ich dann nur Teil dieser Crew oder bin ich vielleicht Teil von mehreren Crews?
Bei Unfix? Ja, kommt auch an. Also du kannst auch Teil von mehreren sein, also das ist da jetzt nicht so festgelegt.

[1:00:58] Für die meisten Mitarbeitenden und Menschen macht es mehr Sinn, den Großteil ihrer Zeit in einer Crew zu verbringen.
Also das ist einfach Stichwort, jetzt muss ich auch denken, das ist ein Komplette Float, ne?
Das ist schwierig für Menschen in vielen Gruppen gleichzeitig zu arbeiten.
Aber das heißt nicht, dass du nicht in unterschiedlichen Zusammenhängen mit unterschiedlichen Leuten auch agieren kannst.
Das ist so ein bisschen auch das, was Hans schon meinte.
Also du kannst in deinem cross-funktionalen Entwicklungsteam sitzen, kannst aber gleichzeitig dann auch noch Member...

[1:01:40] Ja, da müssen wir vielleicht mal ein bisschen in die Bedürflichkeiten gucken.
Also, ANSIX bringt da für vieles schon auch, sag ich mal, Vorschläge mit.
Und Crew begreifen die so, das ist eine Ansammlung von Menschen, die mit einem bestimmten Ziel zusammenarbeitet.
Und wenn es zum Beispiel um so Crossfunk oder so Funktionales Alignment geht, Hans beschrieben hat, mit diesen Gilden. Das heißt bei Anfix dann Forum. Also das kann ich auch gleich nochmal gucken. Aber ich glaube, die einzelnen Begriffe sind, glaube ich, nicht so wichtig. Es ist halt wichtig, dass alle wissen, was gemeint ist. Und du hast bei Anfix dann immer auch gleich noch so einen Synonym-Wörterbruch quasi daneben, was es dann auch noch heißen kann. Genau, aber über die verschiedenen Formen von Crews.
Das wäre tatsächlich nochmal spannend, vielleicht sich anzugucken, die es geben kann in so einem Unternehmen, weil wir gucken eben sehr stark auf diese Sicht des cross-funktionalen Teams, also das Entwicklungsteam plus UXler und Product Owner, aber eben in einem Unternehmen kann es eben halt auch noch.

[1:03:02] Jede Menge andere Formen von Crews geben. Da fällt mir auch das, wenn wir jetzt mal außerhalb so schauen.

[1:03:12] Sind dir bei Unfix dann speziell schon Lösungen aufgefallen, die jetzt dann mit, was könnte es denn sein, Customer Support oder sowas zusammenhängen?
Weil das ist ja normalerweise etwas, wofür diese ganzen anderen Frameworks dann da sind, damit es dafür irgendwelche Prozesse gibt, wenn irgendwas zum Beispiel mit einem Customer Support reinkommt.
Oder wenn das Error Monitoring rot schlägt. Wie wird das denn jetzt alles in einen Sprint, mir ist das Wort wieder eingefallen, wie kommt das jetzt eigentlich in einen Sprint und dafür gibt es das Daily dann etc.
Aber wenn ich jetzt zum Beispiel meine selbstorganisierten, super fixen Teams habe, und die haben alle ihren definierten.

[1:03:56] Ihr definiertes Ziel, Was passiert denn dann, wenn was von außen reinkommt?
Wie zum Beispiel, es ist jetzt, gut, Production Fix will ich jetzt nicht als Beispiel bringen, weil ich hoffe, jede mitarbeitende Person würde bei einem Production Bug mal kurz sagen, hat Prio.
Aber was ist denn jetzt, wenn irgendwas reinkommt? Wo weiß ich, an welches Team ich treten soll?
Wenn es jetzt, oh, Crew, Squad, was auch immer. Wenn es dafür keine direkten Personen gibt.
Hm. Ja, also das ist tatsächlich super, dass du das erwähnst, weil da haben die ein spezielles Konzept, wo sie eben auch meinten, einen Mangel bei bestehenden agilen Produktorganisationen entdeckt zu haben.
Weil sie eben sagen, das ist total super und klasse, dass die autonom und selbstorganisiert arbeiten, Aber was da ein bisschen aus dem Blickfeld geraten kann, ist eine.

[1:05:03] Unternehmensweite Sicht auf die Kundenerfahrung. Also der hat da, ich war auch auf der Anfix-Konferenz im letzten Jahr, und da hat er so ein Beispiel gemacht von seiner Bank da in den Niederlanden, die meinte ja, die wären total klasse und jeder individuelle Kanal mit denen sei super slick ausgearbeitet, also sprich, das, weiß ich nicht, Desktop, Online-Banking und die Mobile-App, alle richtig, richtig gut.
Aber der Moment, in dem die beiden miteinander interagieren müssen.

[1:05:40] Da wäre der komplette Medienbruch und er muss anrufen oder die Zwei-Faktoren-Authentifizierung geht nicht oder so.
Und da sagt er eben, da wäre es wirklich sinnvoll, eine unternehmensübergreifende Experience-Crew dann ins Leben zu rufen, die diese Sicht, also die Kundenperspektive, auf alle Teams verteilen können.
Also das heißt, idealerweise sitzen die eben dann an der Schnittstelle zu dem Customer Support, aber auch zum Experience-Design, was dann eben reinkommt.
Und nehmen dann auch tatsächlich Einfluss darauf, in der Koordination von den Dev-Teams, wie zusammenhängend dann auch die Entwicklungsarbeit gemacht wird.

[1:06:34] Konkrete Vorschläge, wie wichtig jetzt ein Produktionspack ist, das ist da nicht drin.
Aber das finden die bestimmt auch, und würde ich auch sagen, ist wichtig.
Aber manchmal, es gibt auch Produkte, die sagen, das ist nicht wichtig.
Wie oft tritt das denn auf?
Ist das nur bei dem so und so Web-Entwickler, der mir gerade gemailt hat, oder ist das bei ganz vielen von meinen Kunden?
Sag mir mal, wie wertvoll es ist, diesen Bug wirklich zu fixen.
Also das sind dann Produktmanagement-Entscheidungen, die uns in der Entwickler-Inniere dann vielleicht ein bisschen wehtun, aber da gibt es natürlich noch ein Geschäftsinteresse dahinter.

[1:07:26] Aber dann könnte ich doch eigentlich auch, wenn wir jetzt diese selbstorganisierten, schnellen Teams hier haben oder Crews, auch zum Beispiel sagen, das liegt vor und wir wissen, dass wir das technisch in 15 Minuten fixen können, weil, keine Ahnung, fehlt ein Semikolon.
Quatsch, Amalinta.
Aber dass wir gar nicht diese Schleife jetzt ... Weil das ist das, was ich von diesen großen Frameworks kenne und was jetzt generell mein Kritikpunkt dran wäre, ist, dass manche Sachen aufgebauscht werden.
Und ich verstehe schon auch den Sinn dahinter. Denn ich glaube nicht, dass, wenn man eine Organisation von 2.000 Personen hat, dass, wenn ständig jeder da eine Entscheidung für sich selber trifft, dass das große Ganze noch das Richtige rauskommt.
Aber jetzt so im Kleinen könnte ich dann bei Anfix auch sagen, bevor ich jetzt überhaupt 5 min eine Nachricht schreibe, entscheide ich, ich fix das in 15 min.
Ohne eben jetzt Produkt und Customer und Experience-Crews zu fragen.

[1:08:32] Ja, würde ich sagen, aber es ist ja eine Frage von, auch da eher Autonomie und Alignment.
Also das, sag ich mal so, das Anfix ist schon eng verbunden auch mit der agilen Sichtweise auf Produktentwicklung und auch so das dahinterstehende Wertesystem.
Und da geht es nicht darum, jetzt einen riesengroßen Bürokratie-Layer einzuführen in der Organisation.
Und ich würde sagen, wenn dein Team gut erleint ist und selber gut beurteilen kann, wie wichtig dieser Bugfix tatsächlich ist, dann sollen sie es selbstverständlich auch selbst entscheiden können.

[1:09:16] Aber wenn du in großen Organisationen natürlich zusammendenkst, und ich kenne das Beispiel genau, was du sagst, Also stell dir vor, der direkte Draht vom Kundensupport ins Dev-Team kommt, und du hast jetzt ein Produkt, was von hunderttausenden Leuten halt irgendwie benutzt wird, dann wirst du schon in irgendeiner Weise da einen Filter- oder Bewertungsmechanismus einführen müssen.
Und dann gibt es natürlich unterschiedliche, ich sag mal, Autonomiegrade von so einem Team auch tatsächlich.
Also Selbstorganisation heißt ja erst einmal gar nicht unbedingt, die entscheiden selber komplett, was sie machen, sondern sie entscheiden selber, wie sie es machen. Das ist so im Besonderen der erste Schritt. Und wie detailliert und wie fein gerade die Arbeit in so einem Team dann eingesteuert wird, das würde ich sagen, das ist Verhandlungssache. Ich persönlich hätte keine Lust auf so eine kleine Ebene da den Informationsfluss dann eben sicherzustellen. So und wenn das bekannt wird.

[1:10:30] Und man hat ein gutes Gefühl, das soll man machen. Aber das ist für mich jetzt nicht spezifisch zu anfällig, sondern das ist ein gesunder Menschenverstand.
Aber wenn es sich häuft und wenn es eben tausend solche Anfragen gibt, dann hast du vielleicht ein Qualitätsproblem in deinem Produkt.
Aber eben auch dann wird irgendjemand in der Firma, der für die allgemeine Zielverantwortung zuständig ist, dann irgendwann auch vielleicht fragen, was macht man hier eigentlich mit der Zeit? Also warum fixt ihr nur Kundenanfragen und wir haben doch eigentlich andere Ziele? Und dann muss man mal ein anderes Gespräch führen. Wir sind hier zu schnell durchgepeitscht und das kommt ständig.
Wir müssen ja vielleicht erstmal in unsere Gruppe ist halt irgendwie weiter reingucken.
Dann eine ganz andere Frage. Wir hatten davor die Kritikpunkte an anderen Frameworks, beziehungsweise ich glaube, Anfik sagt ja auch über sich selber, dass es gar kein Framework in dem Sinne sei, aber dennoch die Kritiken an anderen. Jetzt gar nicht, dass es zu unflexibel wäre, sondern eher auf den Punkt, dass...

[1:11:48] Ja, zum Beispiel, wir machen jetzt safe, Punkt, und jetzt viel Spaß.
So dieses Ungelernte.
Und dann gibt man oft die Kritik an dem Framework, aber weiß vielleicht auch wirklich gar nicht, worum es geht.
Und es war jetzt gar nicht das Problem, dass es zu inflexibel wäre, sondern dass auch gar kein Wissen geherrscht hat.
Und ich denke auch, wenn man jetzt von heute auf morgen, selbst wenn das Wissen darüber da ist, man sagt, man hat da jetzt irgendwie, keine Ahnung, zwei, drei Stunden Schulung, jedem, wie es geht. Aber es ist von heute auf morgen ein großer Kontrast zu vorher. Denkst du, diese Gefahren würden auch bei Unfix herrschen? Oder ist es vielleicht sogar in diesem, nicht Framework, schon drinnen, dass man vielleicht gar nicht so viele Änderungen auf einmal machen muss? Oder dass es auch gar nicht so viele komplizierte Begriffe gibt, dass man es quasi nicht falsch machen kann? Oder würdest du schon eher sagen, Wenn man das machen möchte, sollte es auf jeden Fall ein paar Personen sein, die das mal voll durchgeblickt haben, um es dann auch tatsächlich richtig, im Sinne von richtig für diese Organisation eben zu machen.
Also ich glaube ehrlicherweise, dass so Strukturierungs- und Transformationsprozesse, Ich glaube, es kommt nicht so stark auf das Modell an, tatsächlich, sondern es kommt darauf an.

[1:13:17] Wie man sie einführt und wie man die Personen, die davon betroffen sind, dann einbindet und mit denen kommuniziert.
Und genau das, was du beschreibst, hey Leute, von heute auf morgen, wir machen jetzt alles anders, das funktioniert im Alltag nach meiner Erfahrung nicht so gut.
Und dann muss man eben ganz viel auch wirklich erklären, warum machen wir das denn jetzt so?
Und auch nach meiner Erfahrung fehlt es ja auch total hinzuhören und zu sagen, Leute, seht ihr hier was, was wir vielleicht übersehen haben?
Also weil die Grundprinzipien auch in Anfix oder auch von Agila-Vorgehensweise, oder auch von dem einen Modell, was wir noch nicht erwähnt haben, ist auch von Holacracy zum Beispiel.
Du versuchst Entscheidungsmechanismen, also Stichwort Autonomie.

[1:14:20] So weit wie möglich in die Teile deines Unternehmens zu verlagern, die direkt davon betroffen sind oder die direkt den Informationszugang haben.
Und deswegen ist es meistens, nicht immer, aber meistens eine schlechte Idee, von oben herab komplett krasse Detailplanung zu machen und zu sagen, mal Leute, wir haben uns ausgedacht, wo wir hinwollen und genau so kommen wir dahin. Und.

[1:14:49] Dann hast du eigentlich in der Regel, überlässt du deinen Mitarbeitenden wenig Gestaltungsspielraum und das kann sich eben auch auf Motivation niederschlagen. Und eventuell verpasst du auch Chancen, weil du bestimmte Informationslücken halt gar nicht siehst. Insofern würde ich ich sagen, nee, gibt keine Garantie für, dass das mit unfix dann auch total gut klappt, sondern ich glaube nur bei unfix ist eben der Anspruch, ich gebe dir keinen konkreten Bauplan, den du jetzt nur eins zu eins umsetzen musst und dann wird alles gut. Das ist vielleicht eher das Problem dann, es ist noch ein bisschen schwieriger, weil es dir nicht den konkreten Bauplan gibt und dann das alles gut, sondern du bist quasi gezwungen, das über einen größeren Zusammenhang im Team auszuarbeiten. Hört man Leute, wie wollen wir das dann jetzt machen? Und für diese Frage, wie wollen wir das denn jetzt machen, da bietet es dir sehr viele verschiedene Muster an, die du.

[1:16:03] Nutzen kannst.
Ja, ich finde vor allem diese Balance schon spannend zwischen nicht alles von oben herab vorgeben und in dem Sinne auch nicht micromanagen und die Teams können autonom für sich selber entscheiden, vielleicht nicht was, sondern wie sie etwas arbeiten, wie sie sich strukturieren, wahrscheinlich auch solche Fragen, wie sie sich wann wie treffen und über die Arbeit sprechen.
Im Gegensatz zu wie viel Wissen, wie viel Informationen können jetzt die einzelnen Teams haben, ohne eben, dass der Kopf platzt, um dann diese richtigen Entscheidungen aber auch zu treffen. Das ist auf jeden Fall eine spannende Sicht da drauf und es klingt für Für mich jetzt so, als hätte unfix hier den...

[1:16:55] Die gleichzeitige Herausforderung, aber auch Vorteil, dass man sich irgendwie damit auseinandersetzen muss.
Es kann vielleicht auch ganz einfach sein zu sagen, wir arbeiten jetzt nach diesem Prozess.
Also sagen wir mal, wir haben jetzt fünf Tage in der Woche ein Daily, weil irgendjemand hat mal gesagt, das wäre gut.
Aber wenn man das nicht so für sich selber entschieden hat, wozu man das jetzt eigentlich nutzen will, ich meine, wir kennen wahrscheinlich alle, entweder haben wir es selber im eigenen Leib erfahren müssen oder wir kennen Erzählungen von Freunden und Freundinnen darüber, Wie es heißt, ja, keine Ahnung, Dev1 hat gesagt, ich arbeite an Ticket1, danach arbeite ich an Ticket2.
So, ja gut, schon klar.
Ja, deswegen finde ich das schon auf jeden Fall spannend. Ich denke aber auch, man kann wahrscheinlich nicht davon ausgehen zu sagen, wir machen jetzt dieses Ding, und dann läuft's einfach.
Denn die Frage ist ja auch, wie du am Anfang schon meintest, wie viel Zeit hat man denn eigentlich im Alltag, um sich mal nebenbei um so was zu kümmern?
Hast du da die Erfahrung gemacht oder wie war das bei euch so im Sinne, gab es da jetzt dedizierte Personen, die da mal kurzfristig zumindest irgendwie Vollzeit daran gearbeitet haben oder sogar langfristig Vollzeit an Organisationen arbeiten?
Oder schafft man das irgendwie sogar nebenbei verschiedene Personen?
Wie war es bei euch?

[1:18:18] Ich glaube, der größte Schritt bei uns war quasi von keiner bewussten Organisationsform zu einer.
Also das war schon ein verhältnismäßig großer Schritt.
Weil damit kommen dann eben auch solche Fragen. Es macht nicht mehr jeder alles, sondern dann fängt man ja auch an, so ein bisschen Grenzen einzuziehen zum Unternehmen.
Und das hat immer Redebedarf. Also das halt dann, ist das dann jetzt noch Teil von meinem Job oder nicht?
Und da war es definitiv nicht so ein Ding, was wir so mal eben gemacht haben, sondern da haben wir uns wirklich mehrfach dann mit dem Management und mit dem Leadership-Team zusammen eingeschlossen und viele Sachen gemeinsam erarbeitet und dann eben halt auch gesprochen, wie wir die Sachen dann kommunizieren und wie wir sie tatsächlich einführen.
Und ansonsten ist es bei uns so ein... Naja, also für...

[1:19:19] Jetzt Organisationsentwicklung in dem Sinne und Change, da gibt es jetzt schon feste Prozesse.
Es ist jetzt gerade keine, also bei uns steht jetzt, ist jetzt auch noch nicht in Stein gepeistet, wie am fix wird es jetzt hier als nächstes so, sondern das ist das, was ich aktuell am spannendsten finde und wo ich mir gut vorstellen kann, dass wir uns daraus bedienen.
Aber es gibt jetzt nicht die eine riesengroße Change-Initiative, in der wir sagen, Wir müssen jetzt alle Strukturen, die wir bei uns haben, überprüfen und alle Teams neu basken.
So was gibt's jetzt gerade nicht.
Und wenn es die gebe, dann könnte, würde ich mir vorstellen, würde es bei uns eher so laufen, dass wir, das auch eher so graduell ausrollen und dann eben nochmal vorfühlen, tatsächlich in den Teams und Strukturen, wie gut funktioniert's denn gerade, wo fehlt euch vielleicht mal Information, Informationen, weil was super spannend ist, was du auch beschrieben hast Vanessa, es gibt halt das offizielle Organigramm in der Firma und es gibt das informelle. Und die Leute.

[1:20:33] Besorgen sich immer alle Informationen, die sie brauchen, um ihren Job machen zu können.
Und das geht eigentlich immer kreuz und quer und links oben, geradeaus, rechts unten und, bildet in den allerwenigsten Fällen zum Beispiel den Hierarchie-Layer tatsächlich ab in der Firma.
Und lässt sich auch überhaupt nicht vermeiden. Das ist auch nicht schlimm.
Aber es ist natürlich so, wenn du zum Beispiel merkst, dass du im Alltag häufiger mit Leuten außerhalb von deinem Team sprechen musst als mit deinem Team, dann könnte es angebracht sein, dass du eigentlich in einem anderen Team sitzen musst.
Weil mit deinem Team selber hast du eigentlich keinen Informationsaustausch, sondern du redest eigentlich immer mit der Kraft aus dem anderen Team.
Und ihr habt da eigentlich irgendeine Initiative, die macht ihr gemeinsam oder so.
Das wären dann Punkte, wo das spannend wäre, das zu erfahren.
Alles klar. Gibt es denn ansonsten noch Punkte, auf die du speziell eingehen möchtest?

[1:21:39] Na ja, also ich finde, wie gesagt, ich finde spannend, die verschiedenen Arten von Crews.
Ich finde aber auch spannend, aber da würde ich auch exemplarisch vielleicht nur zwei, Sachen nehmen. Was die eben auch noch zur Hand geben, sind so Modelle und Hilfsmittel tatsächlich dann zur Prozessorganisation. Die sind aber auch nicht so stark, also weil wir jetzt so viel darüber gesprochen haben, so, wann mache ich meine Dailies und Retros und so. Ne, die gehen tatsächlich noch mal so ein bisschen in eine andere Richtung. Die gehen tatsächlich ans Eingemachte, zum Beispiel, Beispiel.

[1:22:20] Wie delegiere ich Arbeit in einem Unternehmen? Und da gibt es zum Beispiel, das ist auch eins zu eins aus diesem Management 3.0 Buch übernommen, da gibt es so eine ganz lustige Übung, aber die ist auch wirklich hilfreich.
Das nennen sie Delegation Levels oder Delegation Poker.
Und da kannst du zum Beispiel mit einem Team halt eine Übung machen und sagen, Hört mal, Leute, ist euch klar, also Führungskraft mit dem Team, nach was für einem Delegationsmuster hier eigentlich Sachen gerade entschieden werden.
Und das kann man tatsächlich auch so, ähnlich wie, das werdet ihr vielleicht mal gemacht haben, wie so Planning-Poker kann man dann Delegation-Poker spielen.
Das ist eigentlich ganz lustig und ganz schön.
Und zwar Delegation im Sinne von, da gibt's dann so unterschiedliche Level, sieben Stück, von Leute, ich erzähle es euch, wie es jetzt gemacht wird, bis hin zu ihr macht es komplett eigenständig und müsst mir auch nicht erzählen, was ihr da treibt.
Und dazwischen gibt es eben aber Graubereiche. Und das finde ich ist das Tolle bei unfix, weil es diese Graubereiche versucht auszufüllen.
Also zu sagen, in den und den Bereichen könnt ihr komplett eigenständig agieren Oder ihr informiert mich zumindest, was ich halt irgendwie mache, jetzt aus der Perspektive der Führungskraft gesprochen.

[1:23:50] Aber in diesem und jenem Bereich möchte ich bitte auch noch weiterhin das letzte Wort haben.
Aber ich committe mich darauf, bevor ich eine Entscheidung treffe, zum Beispiel das Team anzuhören.
Das ist eine andere Vorgehensweise, als zu sagen, ich mache es komplett alleine.

[1:24:09] Und das ist ein ganz, finde ich, schönes und sympathisches Ding und was ich mir vorstellen kann, was die Arbeit erleichtert.
Und am Ende ist das Ziel natürlich davon, dass das Team autonomer wird.
Also muss der Führungskraft auch bereit sein, Dinge dann abzugeben, aber eben auch Klarheit darüber zu haben.
Weil das sind ja immer dann die Sachen, wo es so ein bisschen pritzelt vielleicht in der unternehmischen Gestaltung.
Ist so, bin ich jetzt genügend einbezogen worden? Das Gefühl, das kennt ihr bestimmt auch im Alltag, ist das jetzt ohne mich Erfolg? Warum denn eigentlich? Oder eben auch nicht?
Ich kenne das auch andersrum. Also ich kenne auch die Erfahrungen, in denen man in alles mit einbezogen wird.
Und ich glaube, ich gelte schon immer gerne so ein bisschen als die Dev-Beschützerin.
Ich versuch's nicht zu stark zu machen, aber ich frag mich eben auch manchmal, wo diese Grenze ist an zu viel Information, wenn man grade wieder zur kognitiven Load geht.
Und muss jede Person immer an alles einbezogen werden? Das ist jetzt sehr von eigenen Erfahrungen abhängig.
Also, ich kann mir vorstellen, dass mir grade 50 Leute sehr stark widersprechen wollen.

[1:25:29] Das sind natürlich immer Extrembeispiele dann. Apropos persönliche Erfahrungen, ich habe jetzt gerade schon relativ viele Fragen gestellt.
Hans, hast du noch Einschätzungen dafür? Gefallen dir diese Grauzonen ganz persönlich?
Oder siehst du das eher bei diesen, es ist doch eigentlich auch ganz gut, wenn es ein Regelwerk gibt und wir halten uns einfach alle da dran und dann ist es gut.

[1:25:57] Ja, also ich glaube, das Problem ist ja eben schon ein bisschen angeklungen, auch es gibt halt nicht diese eine Regel im Normalfall, die für alle Szenarien gilt, also man muss halt häufig mal irgendwie situativ reagieren, ne, und mit einer Information oder einer Entscheidung macht man halt eher so nach dem Motto.

[1:26:19] Die muss halt demokratisch gefällt werden.
Manche Sachen willst du halt hierarchisch fällen müssen.
Und das kommt halt so ein Stück weit einfach drauf an, was ist der Kontext, in dem du gerade unterwegs bist.
Wenn deine Website down ist, und du jetzt aber erst noch mal mit allen diskutieren möchtest, wie du denn am besten jetzt den Bug anfasst, und dafür brauchst du halt irgendwie eine Stunde, dann ist das vielleicht nicht so die ideale Vorgehensweise, sondern dann ist es vielleicht ganz gut, eine gewisse Struktur zu haben, ja.
Und wenn die aber vorher gemeinschaftlich bestimmt wurde und da vielleicht die ausreichend sozusagen Demokratie geherrscht hat, dann führt das halt vielleicht dazu, dass du halt dieses, also dass du dahinter stehst, wie es dann abläuft.
Und ich glaube, das ist so ein Stück weit, was man halt für viele Szenarien, die jetzt gerade schon beschrieben wurden oder so, halt gut anwenden kann.
Es ist halt immer situativ, es kommt auf das Unternehmen an.
Wir haben vorhin schon mal angesprochen, es gibt halt auch Unternehmen, bei denen das vielleicht anders gar nicht funktioniert.
Ich nehme mal eine Feuerwehr oder das Militär wurde irgendwann mal, haben wir, glaube ich, einfach mal gesagt am Anfang.

[1:27:30] Das sind halt so, ja, und da muss man halt sehr, sehr gut einfach drauf gucken, in welchem Kontext macht es einfach Sinn, wie sich, also wie organisiert man sich auch?
Und ich glaube, das ist für mich so ein bisschen das, was wir jetzt auch mal gehört haben, auch mit den unterschiedlichen Ansätzen.
Und bei Anfix, glaube ich, Ein Ansatz, der versucht, viele sehr gute Praktiken zu bündeln.

[1:27:58] Ja, so würde ich es auch sagen. Also ich glaube auch, in Anfieber ist nicht drin, also im Gegenteil, jeder redet mit jedem jederzeit.
Also ein bisschen so aus dem Nähkästen kann ich sagen, bei uns findet das manchmal statt.
Also, da würde ich sagen, das ist eher ein relativ hoher Austausch, von dem ich vielleicht dann auch manchmal ein bisschen betroffen bin und dann manchmal denke, okay, Moment, muss das jetzt wirklich alle Leute jetzt irgendwie da angehen oder nicht?
Also, sondern eher wirklich das aktiv zu gestalten und darüber Klarheit zu machen oder Klarheit herzustellen.

[1:28:47] Und Bassan sagt, klar, man muss auch situativ immer noch Entscheidungen treffen können oder auch schnell reagieren können.
Und wenn ihr diese Delegationsskala eigentlich anguckt, die so von eins bis sieben da geht, wenn ihr euch diese Kärtchen anguckt – ich kann es euch auch nochmal schicken –, so, dann ist eigentlich das Schwierigste eigentlich immer, wenn keine direkte Delegation stattfindet, also wenn man sich in der Mitte treffen muss, ist eigentlich immer das Schlimmste. Also wenn alle Beteiligten übereinstimmen müssen, dann ist eigentlich klar, dann braucht es ewig, um eine Entscheidung finden zu können. Und deswegen sind meistens eigentlich die Verfahren, die just good enough sind, also die dann eher andersherum sind. Die Führungskraft berät mit dem Team oder mit einzelnen Mitgliedern aus dem Team, holt da die Expertenmeinung ein und trifft dann die Entscheidung. Oder andersherum, das Team trifft die Entscheidung, aber holt den Rat der Führungskraft ein. Nach meiner Erfahrung, die funktionieren dann auf jeden Fall schneller.
So, das ist einfach völlig klar. Wenn man das aber eben im Vorfeld weiß, dann kann man auf jeden Fall mehr Klarheit darüber im Leben auch herstellen.

[1:30:11] Also das ist auf jeden Fall ein Modell, was ich ganz schön fand und was ich direkt daran anschließend vielleicht noch vorschlagen würde, uns nochmal anzugucken, ist tatsächlich, wo wir auch schon darüber gesprochen haben, wäre Entscheidungsfindung. Also wir haben eben über Delegation gesprochen und das andere ist Entscheidungsfindung.

[1:30:33] Und auch da gibt es quasi so eine Art Spielkarten oder Modell, wo sich ein Team überlegen kann oder eben auch die Führungskraft oder die Organisationsentwickler, in welchen Bereichen wollen wir nach was für einem Verfahren eine Entscheidung treffen?
Also eigentlich genau das, was du gerade meintest, Hans. Also wann ist es quasi urdemokratisch oder wann wird das hier autokratisch durchgeführt?

[1:31:11] Und da ganz viele Sachen kennt man bestimmt auch aus dem Alltag daraus.
Das ist jetzt nicht so revolutionär da drin.
Aber es ist schon spannend, da als Team drüber zu reflektieren.
Und gerade wenn man in, was weiß ich, Scrum-Teams arbeitet und dann auch jemanden hat, der Prozessbegleitung macht, dann können solche Sachen eben in einem Team halt auch vereinfacht werden oder abgekürzt werden.
Und dann sagt man, die super schwerwiegenden Entscheidungen zur Architektur, da muss es in einstimmig oder Mehrheitsvoting mindestens irgendwie dazu kommen und in vermeintlich einfacheren Entscheidungen oder nicht so schwerwiegenderen Sachen, da kann auch jede Dev alleine das entscheiden. Oder ein Verfahren, was ich in der Vergangenheit relativ häufig auch in so Community of Practices angewandt habe, Das ist so dieses...

[1:32:16] Konsentmodell, ich weiß nicht, ob ihr das kennt oder schon mal was von gehört habt.
Also die Frage, die man da stellt, also sprich, ihr habt im Dev-Team irgendwie heftige Diskussionen über, wie soll dieser Customer-Dialog implementiert werden oder irgendwas anderes, lässt sich ja über alles vertrefflich streiten, aber irgendwann muss man eben halt auch zu einer Entscheidung kommen und dann ist die Frage, welche Güte ein Einführungszeichen hat, diese Entscheidung. Und dann ist es eben was anderes zu sagen, wir sind alle einer Meinung, genau das ist es, was wir machen wollen, als zu sagen, also das wäre dann eben Konsens. Als im Konsent stellt man dann immer die Frage.

[1:33:02] Guck mal, wir haben hier den und den Vorschlag, ist das gut genug, als dass wir es ausprobieren sollten. Und wenn nicht, dann ist die Frage, die man immer stellt, gibt es irgendwelche kritischen Einwände an dieser Stelle? Also fällt uns der Himmel auf den Kopf, wenn wir das jetzt wirklich so machen. Dann tretet jetzt bitte vor, dann müssen wir uns leider immer noch unterhalten.
Aber wenn nicht, lasst uns doch mit diesem Vorschlag weitergehen und dann lernen wir gemeinsam, ob der gut ist oder nicht. Und das ist eine ganz andere Diskussion und damit kann man auch viele Sachen echt auch abkürzen. Also man kann sagen, pass auf, das ist zwar nicht meine Lieblingslösung, ich würde es vielleicht anders machen, aber ich kann damit auch leben mit diesem Vorschlag, mit dieser Lösung, die ein anderer Teammember vorgeschlagen hat und das ist gut, genug. Und aber auch solche Verfahren, also das ist zum Beispiel ein Verfahren, was in der Holokratie relativ häufig zur Anwendung kommt. Also, sprich, Holography, Schöpf ja uns vorhin nochmal erwähnt.

[1:34:11] Aber auch da, es ist halt eine feine Linie zwischen qualitativ hochwertige Entscheidungen treffen und Dinge tot diskutieren. Dann muss man eben ein gutes Mittelmaß oder ein gesundes Mittelmaß finden. Und wenn man das aber als Team aktiv reflektiert, dann glaube ich, ist man in der Lage, da schneller das richtige Verfahren einzufinden, überhaupt darüber zu sprechen. In dem Team hört mal nach was nach was für einer form wollen wir das denn jetzt eigentlich entscheiden beim Mail.

[1:34:50] Regelt man es ja eigentlich nicht oder wie kennt ihr es? Oder habt ihr solche Diskussionen oder auch Vorgaben im Alltag?
Also.

[1:35:00] Nee, also eigentlich kenne ich das aus Teams auch nicht, dass man sich da so ein Regelwerk festlegt, aber vielleicht ist es halt das, was es genau viel einfacher machen würde.
Also meistens ist es ja, man diskutiert und diskutiert und irgendwann ist es dann jemand leid und dann sagt man, so jetzt lasst uns doch mal zu einer Entscheidung kommen und dann es geht halt trotzdem immer jemand raus, der dann irgendwie sich nicht so wohl vielleicht fühlt, also bei einer kritischen Sache, ja gibt auch vieles, wo sich Leute einfach allein, aber es geht ja hier um die Sachen, wo es das leider nicht, wo das leider nicht möglich ist.
Und ich glaube, da jemanden auch zu haben, in Anführungsstrichen als Schiedsrichter, Schiedsrichterin, so, ja, was Agile Coaches anbelangt oder Scrum Master anbelangt, und da dann so ein Regelwerk als Grundlage zu haben, wo man sich in einer, zu besseren Zeiten in Anführungsstrichen mal drauf committed hat, das ist ja das, was hilft, ne, weil wir machen es ja immer von den Konfliktfall aus, so wie man es bei Verträgen ja auch macht.
Wir verstehen uns eigentlich immer gut, aber wenn es dann doch mal zum Konflikt kommt, dann haben wir wenigstens hier unser Regelwerk.
Und wenn wir uns da drauf committed haben, glaube ich, dann beugt das halt dem Konflikt vor.
Und das wiederum führt zu einer besseren Team Health.
Das wiederum führt dann dazu, dass du schneller Entscheidungen treffen kannst.
Und vor allem das führt dazu, dass du einfach mehr Stuff dann bekommst.
Und das ist ja, glaube ich, unser aller Ziel irgendwo, ne?

[1:36:30] Ja, also, ich finde das cool. Ich habe das noch nie in Practice irgendwo gesehen.
Aber ich werde das auf jeden Fall auch mal mitnehmen und gerade für neuere Teams, die sich bei uns auch hoffentlich bald gestalten, oder die sich bei uns gestalten, wird das wieder sehr interessant werden, wenn man sich dann doch nochmal unterhält, Wie ist denn ein Team so aufgesetzt? Wie funktioniert denn ein Team in sich?
Aber auch, sagen wir mal, auf einer, sagen wir mal, wenn man viel mit Stakeholdern redet oder in Leadership-Runden, ja, Wo leider, leider muss man ja sagen, diese Themen, so meine Fächer, häufig auch mal ein bisschen kürzer treten und man sehr, sehr viel redet.

[1:37:20] Und dann aber doch vielleicht sich gar nicht auf die Best Practices, die man so an anderer Stelle vielleicht auch mitnimmt, ja, sei es jetzt aus dem agilen Kontext oder ähnlichem, dann vielleicht hinten runterfallen.
Ja, also, ich meine, es ist ja auch immer wirklich auch eine Abwägung von, also, wie viel willst du regulieren und formalisieren und wie viel eben halt auch nicht in einem Unternehmen, so.
Also jede Regel kommt natürlich dann auch wieder mit einem Overhead.
Aber – oder andersherum – jede Regel, die du einführst, ist sehr schwer dann wieder zu revidieren zu einem späteren Zeitpunkt.
Und für Leute, die dazukommen und so, die die Entstehungsgeschichte nicht kennen, kann es auch schwerer werden.
Aber es sind dann eben Verfahren, die dir solche Dinge dann, die helfen, das abzukürzen und da Klarheit drüber zu schaffen.
So wie, wo liegt es denn jetzt eigentlich und in welchem Ermessen und wer wird da einbezogen und so.

[1:38:27] Das finde ich grundsätzlich gut. So, und dann kommt man eben hin.
Es geht ja immer darum, wie enable ich meine Teams, Crews, dass sie möglichst gut ihren Job im Sinne des Unternehmens machen und dabei sich mit allen relevanten, Stakeholdern austauschen können.
Und das sind die entscheidenden Fragen.

[1:39:02] Ja, auf jeden Fall super, super spannendes Thema. Genau, ich kann das leider gar nicht so zur Anwendung bringen in unserem Team, das ist echt ziemlich klein.
Also wir sind da wahrscheinlich noch eher holokratisch. Aber tatsächlich, so Konfliktlösungsansätze, die sind immer gut.
Also das hat man da ja auch, dass man gucken muss, dass man sich dann nicht totoptimiert für die beste Lösung, sondern irgendwann sagt, wir arbeiten ja auch agil, wir können ja immer noch mal verbessern später, aber lass uns mal machen.
Genau. Aber ich glaube, mich würde vielleicht auch noch mal interessieren, was unsere Hörerinnen und Hörer, wo die sich in ihrer Organisation hinentwickelt haben Und ob das, wo sie gerade sind, für sie gut funktioniert und was da gut funktioniert.
Ob ihr Hörer vielleicht auch schon tatsächlich anfix mal implementiert habt bei euch oder dass in eurem Unternehmen vielleicht gelebt wird.
Das würde dich ja auch interessieren, denke ich mal, Milan. Was da so eure Erfahrungen sind und wo das vielleicht auch irgendwie doof ist.
Vielleicht ist es ja auch blöd, dass es keine Guardrails gibt, so viele wie ... Und Vorgaben ...

[1:40:31] Ist ja bei so Frameworks auch so, ne? Manche finden das sehr gut, nicht so viel drüber nachzudenken, sondern einfach zu machen, wie das vorgegeben wird, oder eben andersrum.
Und natürlich auch, wie ihr es safe findet. Das interessiert vor allem die Vanessa.
Und den Hans. Den Hansen interessiert es auch. Um uns das zu erzählen, gibt es immer noch Twitter.
Es gibt Mastodon und wir haben ja auch unseren Community Slack, die ihr alle verlinkt auf unserer Seite findet.
Genau. Und dir, Milan, sagen wir vielen Dank für ein tolles Thema, für die Anregung, das hier mal irgendwie zu besprechen.
Genau, vielen Dank und euch auch viel Erfolg beim weiteren, sozusagen bei der weiteren Evolution und beim Forschen und Weiterentwickeln.
Das hört sich auf jeden Fall sehr spannend und auch sehr cool an, an, dass ihr euch da so viele Gedanken macht.
Ja, vielen Dank und sehr gerne.
Schönen Rapport zusammen. Dankeschön.
Dann hören wir uns nächste Woche wieder. Bis dahin, vielen Dank.
Tschüss. Ciao. Ciao. Tschüss!

[1:41:52] Music.

[1:42:21] Untertitel von Stephanie Geiges.