220 - Multiprojektfähigkeit von Teams etablieren

00:00:00: David Symhoven Einen wunderschönen guten Tag zusammen und zu dieser neuen Folge. Und wir haben wieder eine Frage aus der Community bekommen. Und zwar geht es um das Thema Multiprojektfähigkeit. Und die Frage ist in etwa so, es waren mehr oder weniger Stichworte, wenn ich ehrlich bin. Aber es geht darum, dass jemand hier von den Zuhörer, Zuhörerinnen ein Team hat als Scrum Master, Scrum Masterin und mehrere Auftraggeber aber hat. Also ein Team mit ganz vielen verschiedenen Auftraggebern. Wie viel wissen wir jetzt aktuell nicht.

00:00:27: David Symhoven Und die Frage aus der Community war dann, wie baut man sowas eigentlich auf? Wie strukturiert man eigentlich sowas? Und die Frage nehmen wir uns jetzt einfach mal an, Martin. Aber wir haben gleich mal ein Display mal. Wie immer.

00:00:38: Martin Ainger Ja. Ja, also in guter Alter manier. Also Gerhard Wohland würde davon sagen, das ist eine Wie Frage, die beantwortet er nicht. Ich soll eine neue Frage stellen. Ganz so sind wir nicht. Wir sind ein bisschen praxisunterwegsmäßig, aber da schon noch vorausgeschickt. Also das ist jetzt. Man kann natürlich schon irgendwie beantworten. Also als Fachmann kann man sagen, du, wie würdest du das so grundsätzlich jetzt mal vorgehen? Skizzier das doch mal.

00:01:06: Martin Ainger Und es mag passen. Und es mag für die eine oder andere Situation nicht passen. Und deshalb müsst ihr euch einfach das rauspicken, was bei euch halt passt. Aber so ein paar grundsätzliche Problemstellungen sind natürlich da verhaftet an dieser Multiprojektfähigkeit von Teams. Und einer liegt auf der Hand. Das ist der fehlende Fokus. Das heißt, ich habe Switches von Contents von einem zum anderen.

00:01:30: Martin Ainger Und dabei entsteht Arbeit, die vorher nicht da war. Und dadurch bin ich weniger leistungsfähig. Und das kann ich bis in Exzess treiben. Also wenn ich zwölf Leute habe oder für die ich arbeite oder zwanzig, dann irgendwann komme ich zum Erliegen. Also das kann man grafisch wunderbar darstellen, wie lange das dauert, bis ich dann einfach in den Deadlock reinkomme und nur noch Content-Widgets mache, zu 90 Prozent und nichts mehr leiste.

00:01:53: David Symhoven Genau, wie Martin gerade gesagt hat, also wir können jetzt hier einfach mal skizzieren, welche Fragen wir stellen würden und die erste Frage, die ich mir eigentlich stelle ist, warum ist das überhaupt so und kann das geändert werden? Also, warum gibt es 3, 4, 5, 6 noch mehr im Worst Case wirklich noch mehr verschiedene Auftraggeber?

00:02:12: David Symhoven Wenn das nicht der Fall ist, also wenn auch die Person nicht die Möglichkeit hat, nicht jemanden findet, der das irgendwie ändern kann und weil es in irgendeiner Art und Weise sinnvoll ist in dem aktuellen Kontext, dann ist eben genau die Folge, dann ist Content Switch der Alltag und dann muss das gemanagt werden. Dann kann man da nicht drum rum, sondern dann geht es einfach nur noch darum, wie kriegen wir das hin? Und ich glaube mal, darauf zieht jetzt eben diese Frage ab. Wie kriegen wir diesen ständigen Content Switch gemanagt? Und das ist natürlich hoch anspruchsvoll. Das muss man ehrlich sagen.

00:02:23: Martin Ainger Ja. Ja, genau, es gehen wir quasi mal immanent davon aus, dass wir uns auf diese Sache jetzt eingelassen hätten, was ein Fehler ist.

00:02:48: Martin Ainger Wir haben ein Team, zwölf Entwickler. Dass es richtig Spaß macht, machen wir mal sechs Auftraggeber. Da rockt es mal richtig. Alle schreien und wollen. Was würde man da machen? Ich würde mir erst mal eine Übersicht verschaffen. Ja.

00:02:56: David Symhoven Ja, komm, wir geben alles. Ja, wer ist da überhaupt alles im Spiel? Wer ist im Highfishback mit dabei?

00:03:11: Martin Ainger Genau, wer ist der Spieler? Systemtheoretisch heißt es, die Umwelt des Unternehmens zu analysieren. In dem Fall kann ich das bei den Teams natürlich auch machen. Also, wer ist der Gesellschafter? Was ist der Markt der Relevante? Welche Wertschöpfungstypen habe ich? Was super relevant ist, wenn wir uns die Art der Arbeit anschauen.

00:03:30: David Symhoven Mhm. Ja.

00:03:36: Martin Ainger Funktionale Subsysteme. Welche Projekte laufen da jetzt gerade? Welche Programme, welche Zweckprogramme laufen? Gibt es Schnittstellen? Wie sehen die Entscheidungswege aus? Welche Managementinstrumenten werden eingesetzt? Also Incentivierung, Belohnung, Bestrafung, whatever. Welche sind die Schlüsselpositionen? Und letztendlich, die Stakeholder macht wahrscheinlich Sinn, mit denen mal zu reden. Und zwar mit allen sechs.

00:04:00: David Symhoven Ja, genau. Und aus dieser Umweltanalyse ergibt sich zwangsweise, sehr wahrscheinlich, nehme ich jetzt einfach mal an, eine Menge Widersprüchlichkeiten. Und die Frage ist, wie geht das Team mit diesen Widersprüchlichkeiten um? Also angenommen, Team 1, also Auftraggeber 1 stellt eine Anfrage und Auftraggeber 2 und Auftraggeber 3 gleichzeitig.

00:04:20: David Symhoven Wer gewinnt? Weil gleichzeitig kann nicht alles gemacht werden. Vermutlich. Und selbst wenn. Wir haben gesagt, wir haben zwölf Leute, jetzt kannst du es vielleicht aufteilen. Aber irgendwann ist sozusagen auch dieses Spiel ausgeschöpft. Und dann ist immer die Frage, wer sticht wen? Obersticht unter? Ist das jetzt die Regel hier? Oder man muss ein Gefühl dafür kriegen, welche Anfragen sind denn wirklich relevant oder auch nicht? Die nachgestellte Frage daran ist, die ich mir auch eingangs gestellt habe.

00:04:21: Martin Ainger Ja.

00:04:46: David Symhoven müssen denn wirklich immer alle gleichzeitig bearbeitet werden oder nicht? Weil ich kann ja jetzt im Best Case, jetzt gehen wir mal innerhalb des Worst Case aus, dann finde ich eventuell eine Logik, in der ich diese Auftraggeber abfrühstücken kann. Vielleicht zeitlich. Also ich überspitze, vielleicht kann es ja sein, dass Auftraggeber 1 und 2 immer im Frühjahr bedient werden müssen, weil da einfach relevant ist. Die anderen Auftraggeber kann ich dann danach irgendwann im Frühling und Sommer machen.

00:05:11: David Symhoven und die anderen frühstücke ich dann im Herbst und den letzten halt im Dezember ab, weil dann halt eben wirklich der Druck extrem hoch ist. Das wäre jetzt super vereinfacht. Vielleicht kann ich es fachlich klustern. Das meintest du auch mit den verschiedenen Auftragstypen, die da reinkommen. Kann ich fachliche Cluster bilden, die ich dann, dass ich zumindest so mal einen Fokus rein kriege?

00:05:28: David Symhoven Oder kann ich sozial klustern? Das war jetzt auch der Punkt, den ich gerade meinte. Wer schreit am lausten? Gibt es in diesen ganzen Auftraggebern Leute, die ich einfach bevorzugen muss, weil sonst mein Team aufgelöst wird? Oder ich ignoriere die anderen einfach, da muss ich das aber aushalten. Hm. Ja.

00:05:43: Martin Ainger Ja, ich glaube, das ist so der Kernpunkt, dass man ein bisschen in dieses politische System reinschaut. Also meistens ist es ja so, der am lautesten schreit, hat am wenigsten zu sagen. Und das bringt einen auf den Pfad, dass es vielleicht irgendwie falsch ist oder dass man dann irgendwie einen Schmarrn macht. Also dieses Politiksystem sich anzuschauen. Wer ist denn da wirklich der Auftrag? Aber wer bezahlt das Team? Wer stellt es sicher, dass das weiter passiert, dass da was da passiert?

00:06:12: Martin Ainger Wenn man das mal sich betrachtet, dann macht man für das Team möglicherweise eine Priorisierung. Und im Übrigen, wir merken schon, das ist dysfunctional, weil wir machen jetzt eine Optimierung auf den Fortbestand des Teams.

00:06:27: Martin Ainger Das hat nichts mit Wertschöpfung zu tun. Das hat auch nichts mit unternehmerischen Entscheidungen sinnvoll zu tun. Da geht es nur darum, wie tue ich diesen Stress, der im Team entsteht, der auf einer zeitlichen sozialen Dimension, auf einer Auslastungssituation von dem Team ist? Wie tue ich das jetzt handeln? Das ist eigentlich eine unternehmerisch doofe Entscheidung, die da getroffen wird. Und dieses Team kompensiert das.

00:06:27: David Symhoven Hm. Ja. Ja.

00:06:51: Martin Ainger Und diese Kompensation im Übrigen, diese Kompensationsleistung ist auch wieder Arbeit, die auch wieder geleistet werden muss. Also das, was wir jetzt gerade machen, uns hinzusetzen und nachzudenken, Herrschaftszeiten, wie tun wir jetzt da sechs Auftraggeber machen? Das ist Arbeit, die gäbe es nun mal nicht. Das ist zusätzliche Arbeit, die nicht an der Wertschöpfung orientiert ist. Und der Kunde, wenn jetzt der Kunde da dabeisetzen, ja, seid ihr blöd? Was macht ihr da? Hier, ich, ich bin der Kunde. Natürlich arbeitet ihr für mich. Klar, und zwar alle.

00:06:56: David Symhoven Ja.

00:07:19: David Symhoven Ja, aber das war ja auch der Disclaim ein Stück weit, um jetzt hier die Frage ein bisschen zu schützen, weil das wird der Person jetzt wahrscheinlich nicht helfen. Und wir kennen den Kontext ja nicht. Ich kann mir zwar kein Szenario vorstellen, in dem das in irgendeiner Art und Weise sinnvoll wäre, aber wir gehen jetzt einfach mal davon aus, es ist jetzt halt einfach so und wir müssen... Okay.

00:07:37: Martin Ainger Oh doch, ich garantiere dir, da gibt es ganz schlaue Leute, die dir einen ganz guten Grund sagen können, worum das gut ist. Und das hat auch wieder eine Funktion im Unternehmen, um das zu legitimieren, diesen Schmaden. Also das heißt, wenn du dann reingehen würdest und sagst, nein, das verstehst du nicht, bei uns ist das anders. Also bei uns ist es so und deshalb. An der Länge der Erklärung kann man schon merken, dass es irgendwie hinkt.

00:07:52: David Symhoven Ja. Okay, gut.

00:08:06: Martin Ainger Aber da gibt es bestimmt einen validen Grund und der auch aus einer bestimmten Perspektive total logisch scheint. Was gibt es denn für Anti-Pattern? Was haben wir denn da? Wie können wir jetzt da los schießen auf die Nummer? Ein paar haben wir schon gestriffen. Also sowas wie... Ja. Ja.

00:08:23: David Symhoven Das schlimmste wäre Gießkannenprinzip. Das ist glaube ich das, was intuitiv einem direkt in den Sinn kommt. Hauptsache alle irgendwie ein bisschen bedienen. Ich glaube das würde es im Endeffekt nur noch schlimmer machen, weil wir wissen ja Content Switch und dann zusätzlich dann bei sechs Auftraggebern, die wahrscheinlich auch noch im Worst Case mehrere Aufträge gleichzeitig stellen. Du kommst zu gar nichts mehr. Dann hast du 20 verschiedene Aufgaben am Tag oder noch mehr, die du am Tag bewältigen musst.

00:08:49: David Symhoven Und die Zeit, die dafür für die Content-Switches draufgeht, steht im keinen Verhältnis zu der tatsächlichen Arbeit, als wenn man sich wirklich einfach fokussieren würde. Was der Link ist, den ich eingangs meinte, man muss irgendwie schauen, eine Klammer zu bilden. Die kann fachlich sein, die kann sozial sein, die kann zeitlich sein, wie auch immer, aber irgendwie muss man Themen bündeln.

00:09:04: Martin Ainger Ja.

00:09:11: Martin Ainger Diese Gießkanne ist in der Freien Wildbahn allerdings sehr, sehr, sehr beliebt. Insbesondere aus Management-Sicht, weil das ist so, bei Dienstleistungen ist das besonders stark ausgeprägt, die meistens mit einer strukturellen Überlastung der Teams einhergehen. Also man plant die Teams mit 120 Prozent aus und jeder Kunde, der dann zum Weinen anfängt, der kriegt dann ein bisschen und dann probiert man das so auszubalancieren. Und das klappt ganz gut aus Management-Sicht und aus Baden tut es dann der Projektleiter.

00:09:38: David Symhoven Ja. Es ist halt nur Feuerlöschen. Ja.

00:09:40: Martin Ainger der dann fünf Projekte ausbalancieren muss und der dann gesagt bekommt, ja, du musst der Gießkant-Prinzip machen. Der sagt, ja, das geht nicht. Ja, genau, Feuerlöschen und diese Mehrarbeit, die führt zu einer auch wieder strukturellen Überlastung der Teams. Also das läuft dann natürlich auch. Dieses Content Switches überlasten halt die Teams. Und man wundert sich, worum die nicht produktiv sind. Komisch.

00:10:05: David Symhoven Ja, was haben wir noch für einen Anti-Pattern? Ja. Hm.

00:10:08: Martin Ainger Ja, wir haben es ja schon gestriffen. Priorisierung nach Dezibel heißt das bei mir immer. Und bei anderen Kollegen auch. Also der am lautesten schreit, der kriegt das. Und man kennt das ja von ... Keine Ahnung. Weil du ein paar Rechnungen nicht zahlen kannst. Also der am lautesten droht mit dem Anwalt und schreit, der hat am wenigsten Aktien. Also hat am wenigsten sich durchzusetzen. Dieser Mechanismus ist da genauso.

00:10:37: David Symhoven Woran erkennt man das übrigens? Ich glaube, das habe ich auch schon in der ein oder anderen Folge hier mal erwähnt. Das erkennt man sehr schön an diesen Triple Urgent Bugs, an so einer inflationären Priorisierung Skala. Das ist immer ein sehr, sehr gutes Anzeichen für so eine Dezibel Priorisierung. Wenn dann einfach nur noch Urgent, Medium und Low nicht mehr ausreicht und es dann auf einmal Double Urgent und irgendwann Triple Urgent braucht, dann ist irgendwas grundlegend schiefgelaufen.

00:10:49: Martin Ainger Ja, richtig. Ja.

00:11:03: Martin Ainger Das ist ein super Indikator, aber das ist super. Ich war auch mal Tieradmin, da kam dann ein Team an. Ja, also wir müssen den Status dann nochmal, da brauchen wir noch andere Statis, Status, egal, die wir da einfügen müssen. Ich so, wieso reichen euch drei nicht? Ja, wir haben da so ein AAA plus und so. Ich so, wie jetzt?

00:11:13: David Symhoven Ja.

00:11:21: Martin Ainger Und das ist halt genau da diese Inflation dieser Prio-Skala. Also wenn halt wichtig, wichtig, alles ist gleich wichtig, aber das ist dann noch wichtiger, das Prio 0 irgendwas und dann kommt man dann schon an rein. Also spätestens dann, wenn man sowas dann beobachten kann, weiß man, dass diese eigentlich getroffene Priorisierungsentscheidung keine ist. Also da hakt es an der Priorisierung.

00:11:43: David Symhoven Ja. Ja. Ja. Das heißt, jemand anderes hat seine Aufgaben nicht gemacht.

00:11:50: Martin Ainger Ja, richtig. Wenn das Management die Aufgabe nicht präsiert und nicht macht, dann ist das eine Rückdelegation an das Team, die Priorisierung selbst vorzunehmen, was sie nicht kann und nicht sollte. Ja.

00:12:03: David Symhoven Um jetzt hier auch nochmal die Rolle des Scrum Masters an der Stelle zu stressen, ist das einfach mal eine provokante These, die ich in den Raum stelle. Meine Vermutung ist, dass gerade das Gießkannenprinzip deshalb auch so beliebt ist, weil man damit natürlich den Konflikt scheut. Also man handelt lieber den Konflikt und man kompensiert die Überlast im Team.

00:12:22: David Symhoven anstatt in den Konflikt zu gehen und offensichtlich zu spiegeln, dass da an anderer Stelle schon was schief gelaufen ist. Und da müsste man halt eben in diese Konflikte reingehen, was ultraanstrengend ist kurzfristig, aber langfristig sich hoffentlich dann auszahlt. Ja.

00:12:36: Martin Ainger Ja, Gießkanne ist definitiv kurzfristig. Im Agenturbereich sind die Projekte auch immer recht kurzlebig. Aber es braucht dann zwischendrin mal wieder ein Reset, damit man diesen Rückstand aufholen kann. Das heißt, es ist die einzige Chance, die diese Teams haben, dass dann mal ein Kunde abspringt, weil es ihm reicht. Und dann hat es plötzlich zu wenig, in Anführungszeichen, Kunden. Also da hat es mal eine normale Auslastung von 80 Prozent und hat das Team die Chance, irgendwie wieder aufzuholen. Also das ist gar nicht gäbe im Dienstlassergeschäft, würde ich mal sagen.

00:12:55: David Symhoven Ja. Ja. Genau, ja. Symptom ist da, ist eine hohe Rotation auch in den Teams. Also Teams, die eine extrem hohe Fluktuation haben, ist ein Symptom von G-Scan-Prinzip.

00:13:05: Martin Ainger Ja. Richtig. Ja, richtig. Genau. Also so typische Durchschnittszeiten. Also LinkedIn ist ja da wunderbar und Coonoono zeigt dann das ja an, die übliche Verweildauer der Mitarbeiter. Wenn es dann irgendwie so 1,4 Jahre dort entsteht, dann weißt du schon genau, was läuft. Ja.

00:13:28: David Symhoven Gut, aber dann lass uns doch jetzt mal in die Empfehlungen gehen, auch wenn wir uns da natürlich immer schwer tun und eigentlich kein Freund davon sind, aber wir wollen die Person ja jetzt hier auch nicht...

00:13:37: David Symhoven mit einem Rant dastehen lassen, sondern einfach mal ein paar Tipps geben, was würden wir denn machen, wenn wir jetzt aus dieser Situation nicht rauskommen. Und das erste, was ich jetzt einfach mal sagen würde, ist, wichtig ist, die Teamstruktur auch mal zu betrachten und die Frage zu stellen, wer kann denn was. Und es ist wichtig, gerade bei dieser Fülle an Aufträgen auch Redundanzen im Team aufzubauen und diesen Content-Switch besser zu managen. Also klassische talentbasierte Arbeit. Das ist unglaublich wichtig. Wer fühlt sich von welcher Aufgabe, von welchen Problemen provoziert? Wer geht da in den Lead?

00:13:54: Martin Ainger Ja. Ja. Ja.

00:14:04: David Symhoven Die kümmern sich drum und dann langfristig schauen, dass man Tandems oder sogar mehrere Leute aufbaut, die eben diese Fähigkeiten zumindest teilweise auch ersetzen können. Weil sonst hat man ja wieder im Umkehrschluss das Problem, wenn einer davon ausfällt, ist diese Aufgabe nicht mehr zu bedienen und der Auftraggeber geht leer aus. Das darf nicht passieren.

00:14:23: Martin Ainger Und es ist verlockend, dass man das macht, dass man sagt, okay, jetzt kennst du dich aus, geh nur mal, du all diese Aufgabe, der Rest macht das andere, die anderen Sachen. Das ist sehr verlockend, weil das halt eine kurzfristige Lösung ist, die halt man, die quasi diesen Content Switch ausblendet und eine kurzfristige Effizienz und Effektivität Boost gibt.

00:14:44: Martin Ainger Also das könnte man, wenn man jetzt wirklich vor einer ganz engen Situation, von einer engen Stelle steht, könnte man das kurzfristig machen. Eine langfristige Strategie ist es aber keine, wie du es gerade illustrierst. Das ist also Silobildung, Redundanzen aufbauen. Da sagt einer du, ich mag nicht mehr, ich mag keine 120 Prozent arbeiten, dann hast du gar keinen mehr.

00:14:51: David Symhoven Kurzfristig, ja. Genau.

00:15:03: David Symhoven Auch aus der Systemtheorie, nämlich der Systemumweltdifferenz, wenn wir da wieder drauf schauen, das ist ein Team, das eine extrem komplexe Umwelt hat. Und das heißt, je komplexer die Umwelt, desto komplexer muss auch das Team intern gestaltet sein. Das heißt, Effizienz ist nicht die Lösung. Weil das ist wiederum auf Kompliziertheit ausgelegt. Das heißt, da muss ich intern auch dafür sorgen, dass ich komplexere Strukturen in meinem Team aufbaue, nämlich in Form von Redundanz.

00:15:18: Martin Ainger Klo.

00:15:27: Martin Ainger Genau, das Redundanz ist hier der Schlüssel für einen langfristigen Erfolg, kurzfristigen Erfolg. Ja, also was natürlich total hilft, einfach mit dieser Überlastung oder mit diesem Switch einfach transparent umzugehen. Es ist nur schlau, da mit den Stakeholdern sich an einen Tisch zu setzen, sondern Leute hier schauen, das ist die Kapazität, das ist das Team hier, Stunden, Personentage, whatever.

00:15:34: David Symhoven Was haben wir noch?

00:15:54: Martin Ainger Das haben wir bisher geleistet. Das ist euer Arbeitspensum. Matcht es? Nein, matcht nicht. Also lass uns priorisieren, und zwar gemeinsam. Das wäre die vernünftigste Lösung. Und ich weiß aber, und da bin ich zu lange in der Praxis, dass das oft nicht geht.

00:16:10: Martin Ainger Also dass die Stakeholder miteinander nicht reden wollen, dass die sagen, es ist mir total egal, dass die verweigern oder sowas. Aber dann muss man trotzdem hergehen und sagen, ja gut, wenn ihr nicht wollt, dann nehmen wir jetzt eine Priorisierung vor, wenn ihr das nicht tut. Die sieht wie folgt aus, die machen wir nach bestem Wissen und Gewissen und hier ist sie. Also auch da wieder, selbst wenn es eine One-Way-Priorisierung vom Team ausgeht, in dem schlechtesten Fall diese transparent machen.

00:16:11: David Symhoven Mhm. Ja.

00:16:37: Martin Ainger Visualisieren, klar erzählen, wann liefere ich was? Ja, also und ein System, was quasi Klarheit über Fluss, über Klarheit, wann liefere ich was ist, das kennen wir. Das hat einen Namen. Ganz genau. Ganz genau. So schaut es aus.

00:16:54: David Symhoven Ja, ein stark limitiertes Kanban-System, das müssen wir etablieren. Warum stark limitiert? Auch da haben wir ja oft schon darüber geredet hier im Podcast. Also über WIP-Limits kann ich ein stabiles System zwangsweise erstellen. Dadurch kriege ich eine Vorhersagbarkeit ins System und durch die Vorhersagbarkeit kann ich die Stakeholder frühzeitig abfrühstücken. Eine neue Anfrage kommt rein und aufgrund der Vergangenheit, der vergangenen Daten, kann ich dann sagen, lieber Stakeholder, dein Auftrag wird bearbeitet, voraussichtlich in fünf Wochen.

00:17:24: David Symhoven So, Case Closed. Manche sind dann damit zufrieden. Ansonsten, genau wie du gesagt hast, müssen wir halt selber priorisieren. Ja. Genau.

00:17:31: Martin Ainger Also die Stabilität des Systems ist hier essentiell, damit du valide Vorhersagen machen kannst und diese Stakeholder-Zufriedenheit nicht mit dieser Gießkanne hinkriegst, sondern mit verbindlichen Vorhersagen. Und die Vorhersagen, die können auch wehtun.

00:17:47: Martin Ainger Und man kennt das selber, man kommt aus einem Meeting raus, wie beim Workshop oder so und sagt, ja, wann kriegen wir es denn und so. Ja, übermorgen machen wir das schon so. Ja, nichts übermorgen. Also nächsten Tag bist du platt, holst dich von einem Workshop, übermorgen fängst du zum Denken an und dann bist du dann noch nicht fertig. Das heißt, einfach realistisch eine Zeitplanung. Ja, wie du sagst, in fünf Wochen ist es möglich.

00:18:08: David Symhoven Ja, genau. Und auch da, um da noch konkreter reinzugehen, wir empfehlen, hat sich bisher eigentlich als sehr hilfreich erwiesen, für jeden Auftraggeber eine eigene Swimlane.

00:18:19: Martin Ainger Ja.

00:18:19: David Symhoven Aber nur Martin, das ist ja dein Spezialgebiet, in dem Fall hier eine Fastlane für alle. Nicht für jeden Auftraggeber eine Fastlane, sondern für jeden zwar eine Swimlane, aber es gibt nur eine einzige Fastlane. Wirkliche Notfälle. Ja, genau, richtig, ja. Das ist deine Kreation, oder?

00:18:32: Martin Ainger Es gibt ja nur ein Team. Und da würde ich für diese da fastlane würde ich auch noch empfehlen, eine sogenannte DOFL zu etablieren. Das kennt jetzt nicht. Ja, das habe ich jetzt erfunden. Das kennt nicht jeder. Und das ist eine Definition of Fastlane.

00:18:53: Martin Ainger Sprich, wann ist ein Auftrag berechtigt, in diese Fastlane reinzukommen? Und da ganz knallhart Kriterien aufsetzen. Und es kann sein, Kosten entstehen, das Geschäftsmodell ist bedroht, die Stakeholder werden bestraft oder die Strafe ist besonders hoch vom Markt oder so was.

00:19:13: Martin Ainger Und das wirkt auch wieder gegen diese Priorisierungsinflation, entgegen diese Definition of Fast Lane. Also das ist so der Gegenpart dazu. Wann ist denn das jetzt Fast Lane? Und das Kundenempfinden, was fast ist und nicht, ist sehr variabel. Kann ich garantieren. Das sieht nicht jeder so.

00:19:21: David Symhoven Mhm. Ja. Ja.

00:19:34: Martin Ainger Und bei dieser Fastlane gilt es natürlich auch, Business-Entscheidungen zu treffen. Da geht es um, möchte ich meine Wertschöpfung haben, mache ich Gewinn, was kriegt der Kunde, wann kriegt er das? Das ist eine ganz knallharte Business-Entscheidung. Und da muss der Product Owner mit dabei sein, da muss das Crown Master, vielleicht muss auch der Unternehmer mit dabei sein, um solche Entscheidungen dann zu treffen. Was kommt in die Fastlane ein?

00:20:00: David Symhoven Ja, genau. Nächste Empfehlung, da verweisen wir jetzt einfach auf unsere Folge 167. Da haben wir, glaube ich, zusammen, oder du Martin, mal einen Impuls zugemacht. Activity Flow vs. Value Flow. Wir empfehlen einfach mit einem Activity Flow zu starten, je nach fortgeschrittenem Level des Teams.

00:20:16: David Symhoven Das heißt einfach eine To-Do-Doing-Done-Spalte anfangen, um zu gucken anhand der Aufgaben, welche Muster sich daraus ergeben, um dann daraus langsam einen Value Flow zu etablieren, bis man die Prozesse der verschiedenen Auftraggeber erkennt, weil auch das nochmal, nur um es jetzt betont zu haben, jeder Auftraggeber hat eine eigene Swimlane und jede Swimlane kann für jeden Auftraggeber anders aussehen von den Aktivitäten her und das muss erstmal etabliert werden.

00:20:21: Martin Ainger Ja. Ja, dann muss man

00:20:40: David Symhoven Genau, aber viel mehr würde ich da jetzt gar nicht zu sagen, weil das haben wir in Folge 167, wie gesagt, wir packen den Link in die Show Notes, schon ausführlicher beschrieben. Genau. Ja. Hm.

00:20:49: Martin Ainger Da muss man lernen, was ist denn die Anforderung an das iterative Entwickeln. Und wenn ich jetzt noch ein bisschen großzügiger bin als normal, dann würde ich noch eine weitere Spalte zugestehen und zwar so eine Art Learning Spalte. Das ist Arbeit, die dafür da ist, die Messer zu schärfen, zu lernen und sich weiterzuentwickeln.

00:21:09: Martin Ainger Wenn wir so ein getaktetes, krasses Arbeitssystem, wie wir jetzt gerade beschrieben haben, etablieren, gibt es da gar keine Zeit mehr zum Lernen. Und das ist auch wieder eine unternehmerische Entscheidung. Also will ich, dass dieses Team lernt und sich weiterentwickelt. Kann ja auch sein, dass ich sage, ich will das gar nicht, weil ich das Team mache in einem Jahr zu. Dann soll das einfach jetzt noch das Zeug runterschruppen und dann fällt es und dann sei es gut.

00:21:25: David Symhoven Hm. Ja.

00:21:34: Martin Ainger Das kann sein. Aber in der Regel möchte ich meine Mitarbeiter, hochwertige Softwareentwickler behalten. Und da ist es wertvoll, wenn die sich weiterentwickeln und lernen können. Und auch da braucht es eine reservierte Spalte. Eine Lane, besser gesagt, keine Spalte, wo dann die Lernaktivitäten auch transparent dargestellt werden. Priorisiert werden, mit eingeplant werden. Extrem wichtig, aus meiner Sicht.

00:21:56: David Symhoven Genau. Um diese Renundanzen auch aufzubauen, wenn es jetzt nicht die eigene Fortbildung ist, also wirklich per externer Fortbildung, sondern innerhalb des Teams, was wir vorhin gemeint haben, diese Renundanzen aufzubauen. Welche Tickets können zu mehreren Leuten bearbeitet werden, welche nicht, wo ich wirklich Expertenwissen brauche. Also da muss man im Team einfach ein bisschen diskutieren, wie man diesen Wissenstransfer innerhalb des Teams gestaltet. Aber das explizit zu deklarieren auf dem Board ist eine sehr, sehr gute Idee.

00:22:25: Martin Ainger Ja, und der Kern von diesem Board, in dem wir WIP-Limits einführen, ist natürlich die Limitierung von Arbeit. Also wie auch immer man die nennt. Also ob ich jetzt 14 Tage in der Timebox mache und sage, okay, da packen wir jetzt alles rein, ist auch eine Limitierung von Arbeit. Und diese Limitierung von Arbeit, die muss natürlich von irgendjemand gedeckt werden.

00:22:26: David Symhoven Ja. Mhm.

00:22:50: Martin Ainger Also wenn ich vom Management davon ausgehe, dass es da keine Limitierung geben soll und bitte das Team 120% auszulasten ist, dann wird man auch als Scrum Master Schwierigkeiten haben, das durchzusetzen, weil auf Appellebene geht das nicht, weil das ist eine strukturelle Entscheidung.

00:23:06: Martin Ainger Als Grandmaster oder Begleiter von so einem Team darf man sich einfach Verbündete suchen oder einen Beschützer, der das mitträgt. Der sagt, ja, ich möchte, dass das Team, dass da die Arbeit begrenzt wird und das Team beschützt wird, dass das nicht in Burnout reingearbeitet wird oder das in die Überlast rein. Und diesen formalen Mächtigen brauchen wir systemtheoretisch gesehen, der da so einen Schutzraum drüber stülpt über diese Limitierung der Arbeit.

00:23:33: Martin Ainger Und wie auch immer man die nennt, also die Wörter in Unternehmen sind da sehr unterschiedlich. Klaus Leopold sagt dazu immer Fokus aufbauen und meint natürlich auch Limitierung der Arbeit. Aber so kann man das auch ausdrücken. Also dass man sagt, hey, wir wollen da extrem Fokus aufbauen, dass wir da einen guten Flow haben. Ja, wie machst du das? Und ja, Limitierung von Arbeit.

00:23:55: David Symhoven Genau und auch um dieses zwangsläufige

00:24:00: David Symhoven Feuerlösch-Aktivität einfach runterzufahren, also das Schreien der Stakeholder bedienen zu können, ist es einfach hilfreich, einen Schutzraumstifter und Verbündeten zu haben, der das eben gegenüber diesen Stakeholder noch absichert. Weil die Leute werden schreien und auch das würde ich dann probieren, zumindest das aus dem Team rauszuhalten. Weil das ist dann eigentlich Management-Sache, die dann sagt, ja, lieber Stakeholder. Ist so, wir haben noch sechs andere Auftraggeber oder fünf andere in dem Fall. Deine Arbeit wird halt erst in fünf Wochen fertig. Ist so. Kommt damit klar.

00:24:27: Martin Ainger Ja. Und in der freien Wirtschaft ist es ja im Übrigen was ganz Natürliches, dass immer mehr Arbeit da ist, als das wir machen könnten. Wenn ich ein gut laufendes Unternehmen habe, also an dieser an dieser Haltung im Team, was ich oft zutage trinke. Ja, wir können es alles gar nicht schaffen. Und schlimm, schlimm. Ja, ja, ja. Ich sage ja, Leute, das ist normal Zustand. Es ist immer mehr Arbeit da, als wir schaffen können. Wichtig ist, dass wir die machen, gut machen und damit erfolgreich sind.

00:24:37: David Symhoven Ja.

00:24:57: Martin Ainger Das ist der Fokus. Und dass natürlich immer mehr Arbeit da ist, dass wir machen das ganz normal. Also das ist im ganzen Leben so. Immer.

00:25:07: David Symhoven Sehr schön. Dann haben wir heute einfach mal ein paar Gedanken ausgetauscht zum Thema Multiprojektfähigkeit. Das heißt, wie könnte man denn so ein Team gestalten und wie geht man daran, wenn ein Team mehrere Auftraggeber hat? Und natürlich mit den wenigen Informationen und dem Disclaimer vorausgeschickt,

00:25:24: David Symhoven haben wir ein paar Sachen diskutiert. Auf jeden Fall keine gute Idee Geescan Prinzip. Auf jeden Fall keine gute Idee die Dezibel Priorisierung. Und was wir empfehlen ist aber Content Switch als Arbeit einzuplanen. Ein stark limitiertes Kanban System aufzubauen um einfach Vorhersagbarkeit zu haben. Für jeden Auftraggeber eine eigene Swimlane einzurichten. Es gibt nur eine Fastlane.

00:25:46: David Symhoven Am besten Value Flow, probieren zu etablieren, auf lange Sicht eine Learning Swimlane einzuführen, um Redundanzen aufzubauen und auf jeden Fall Verbündete suchen, um die verschiedenen Priorisierungen der Stakeholder gegenüber dem Team abzusichern. Das ist glaube ich mal ein guter Start und ansonsten vielen Dank für die Frage und wir freuen uns über weitere Fragen, jederzeit einfach melden und dann wünschen wir euch eine gute Woche, viel Spaß beim Beobachten und bis bald.

00:26:14: Martin Ainger Bis dann.